🚀 go-pugleaf

It might help this subthread if Herman Rubin would reveal whether he's
talking about problems of internal floating point formats or not.  
He starts out with

::::: The semantic model of the language can, however, greatly inhibit the
::::: programmer.  Try communicating floating binary from one machine to
::::: another

Now we have this curious pair of exchanges:

:::: From: carroll@dori.cis.udel.edu (Mark C. Carroll)
:::: Message-ID: <1992Nov18.154754.1848@udel.edu>
:::: What does that have to do with the semantic model of the language?
:::: That's a very hardware related issue.
::: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
::: Message-ID: <Bxz8px.FBx@mentor.cc.purdue.edu>
::: Did I say anything about matching the internal representations of
::: the numbers?  [...] there are many situations
::: in which people may wish to communicate non-integers in hex.

:: From: throopw@sheol.UUCP (Wayne Throop)
:: Message-ID: <722322705@sheol.UUCP>
:: So, what does this have to do with the semantic model of the language?
:: What prevents one from converting the floats to binary representation
:: in ascii, transmitting that, reading the result, and doing the
:: inverse conversion?
: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <By4EM9.7qn@mentor.cc.purdue.edu>
: This will not do the job.   The binary representations of floats on
: CRAYs, CYBERs, VAXen, RS/6000s, etc., are all different.

(Note that by "binary representation in ascii" above, I was talking
about a radix-2 internal-format-independent ascii string representing
the number in question.  I could just as easily have said "hex", meaning
a radix-16 notation.)

So... are we talking about internal representations or not?  In ANY
event, we do NOT seem to be talking about the semantic model of any
language.  I listed examples of things I believe fall into this area,
and Herman Rubin ignored them, and seemed to contradict his earlier
position, as per above.

: But now how do you do this if one is not interested in
: communicating the decimal representation, but the hex or octal?
: If one is writing a program, the non-integral constants often should be
: given in octal or hex for various reasons.  This means that the language
: in which that program is written must have some way to read them.

If not already in the language, one writes standard
convert-to/from-radix-N routines, and employs them at runtime in the
usual way, or at compile time as custom macro expansions.  (In C or
other such languages, via a target-specific preprocessing step.
Variant-radix specifications are already available in Lisp and Ada at
least, as I recall. )

This applies whether or not Herman Rubin is talking about hardware
formats.  In either event, one thing Herman ISN'T talking about is the
language's semantic model, though he apparently still thinks he is.

Specifically, if the problem of compile-time recognition of
flexible-radix notations is meant, that's an issue of the language's
lexical form.  If the problem of run-time IO of flexible-radix
notations is meant, that's an issue of the language's application area
coverage.  If the problem of varying internal formats is meant, that's
an issue of hardware architecture.  Again, in NO event are ANY of these
problems ones of a language's semantic model.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw