🚀 go-pugleaf

In article <2426@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

   Which machine's floating point representation are you going to use?

whichever machine you are on.

   The several supercomputers I know, as well as the VAXen, are
   different from IEEE.  If fact, their hardware as actually
   implemented on several models predates IEEE floating- point
   standards.

so?  that really doesn't cause much problem except insofar as accuracy
is concerned.  the actual format of the floating point numbers only
matters in exceedingly rare situations.


	   c{'z} ={tc} {-}{|}{ta}a{'x} OP{mod} {|}{tb}b{'y} {/\{~}w}

   is the way I would write the general vector instruction on the
   CYBER 205.

care to justify this?  or is the fact that you would write it that was
sufficient to make everyone want to write it that way?

   Packing and unpacking floating-point numbers are portable
   constructs, but I know of no HLL which has them.

actually this isn't even true, since the sizes of and limits on the
components can very tremendously from machine to machine.

   These should be operators, not function calls.

you don't ever seem to answer the point that you only need to do fast
what you do often.  do you really unpack as many floats as you
multiply?  why does this operation need to be an operator instead of a
function call?

is it that there some deep psychological need to unpack things
quickly?

   The idea of open subroutines, a cross between macros and inlining,
   existed at the time of Fortran I.  Fortran VI on the CDC3600
   allowed 3 additional types (to make a total of 8), and allowed the
   user to define the Fortran operations on these types, but only by
   subroutine calls.

these seem irrelevant.  unless, of course, you are still programming
in fortran I, or on the 3600.

   Why can we not have additional operator SYMBOLS added to a HLL?

you can.  note prolog.

   C and C++ allow additional types, only they do not call them types.

they do if you define them with typedef in c.  if you don't, then they
aren't really types since they are syntactically distinguished.

in c++, they call them structures or classes.  the fact that they are
types is never denied, this only recognizes the etymology of the
situation. 

   I was informed by soeone at ATT that the non-allowance of
   additional operator symbols in C++ was an unfortunate oversight.

only partially.  it does preserve the ability of the language to be
parsed by a static parser.  if you allow new operators and new
precedences, then you get into the serious problem of needing to
extend the parser in non-trivial ways *at compile time*.  the lisp
community has been trying to get this just right for decades and is
still trying.  prolog newcomers still cause insiders to giggle by
asking for a context free grammer for the language.

why don't you admit that the fact that *you* don't see any reason for
something does not mean that there isn't a reason.  you have provided
ample evidence that it only means that you don't see.

--
	Offer void except where prohibited by law.