🚀 go-pugleaf

: From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
: Message-ID: <BxpsHo.MID@mentor.cc.purdue.edu>
: This is not a change in subject.  It is the question of whether one
: is allowed to directly use the machine hardware, or whether one must
: HOPE that the compiler writer considered what you are doing when the
: compiler was produced.  

Nonsense.  Even if your notation is a pointer notation, you must HOPE
that the compiler writer will translate that into the machine
instructions you think are best for your task.  For a trivial example,
"pointer" notation on popular PC architectures has been mapped into
tiny, small, medium, large, huge, and various flavors of
flat-32-bit-address-for-DOS implementations.  From the pointer notation
alone, you can only hope that your translator for pointer notation
chooses the "right" implementation.  In this respect, the difference
between pointer and reference notations is completely irrelevant: they
are IDENTICAL in this. 

The ONLY notations that map directly to the machine hardware are
"assembly" notations.  Even such nearly-assembly-notations as PL/360
have non-selectable machine semantics in their "higher level"
constructs, and limitations in how they can translate expressions. 

If Dr.  Ruben insists on talking about high-level notations and
machine-level details inextricably and confusedly, he will continue to
be like somebody insisting on talking about phlogiston to a modern
chemist.  In each case, experience proves that the language use is
inappropriate to the subject matter. 

: What those who advocate keeping the user from
: the machine are like those who would require people who take their 
: cars into the shop for service to describe the problem to someone 
: who does not understand automobile hardware.

I find a better analogy to be the sort of user who keeps talking about
"carburator problems" and "maybe it's flooded" and "did you try the
choke?" to a mechanic trying to fix the user's fuel injection system. 
Or the user who insists on a new set of spark plugs for the user's
diesel Audi.  Such a car user may understand driving (the application)
and roads (the hardware) very well.  Nevertheless...

: Even HLLs have branches.  But I do know of architectures which are slowed
: because they cannot use lookaheads with unconditional branches (gotos)
: because the hardware does not recognize such a branch except as a case
: of a conditional branch, and hence must consider both branches.  Is
: removing pointers going to similarly weaken hardware?

Who said anything about "removing pointers" from hardware? Or "removing
(recognizably) unconditional branches" from hardware, for that matter?
In fact, I doubt that such silliness is *ever* done for language-inspired 
reasons alone.  Certainly, in the inspired-by-language designs I'm
familiar with, unconditional branches weren't ever on the chopping
block.  Though I'd be glad to hear of specific counterexamples. 

: Are we going to allow the driver to use the steering wheel and the 
: accelerator and brake, or just have a program to run the car?

The steering wheel and accelerator and brake are high-level interfaces.
The better analogy would be allowing the user to time the ignition,
tinker with the exhaust architecture, and so on.  And the answer is,
yes, the users can do those things.  They just can't do them from
the driver's seat and without getting grease on their hands.

: One major advantage of Arabic over Roman is that Arabic can usually
: be written faster.  Are reference notations anywhere near as fast as
: pointers?

Certainly.  Reference notations are *faster* than pointer notations (as
notations), and I've already specified the main reason why: the fact of
indirection is stated once, instead of being stated at every mention of
the pointer/reference. 

And since they map to the same hardware operations, there IS no
run-time speed issue.

But again, the claim raised was that the notation need not contain
an explicit pointer notation in order to have efficient implementations
of the notation which are expressive enough for function variables
and other forms of delayed binding.  And the answer is very clear:
explicit pointer notation is NOT needed for efficiency.

: I have likened this to using infix notation instead of prefix.  Those
: who would restrict access to the machine except in some complicated
: form, such as 99% of the current assembler languages, do not consider
: syntax important.  But the only difference between Arabic numerals
: and Roman numerals, or even writing out the expression for the numbers
: in Sanskrit words, is syntax.

This is again confusing abstract notation issues with concrete
implementation issues.  Postfix, prefix, or infix in a user-oriented
notation have NOTHING to do with hardware implementation issues.  The
popularity of prefix notations for intimate-with-the-machine notations
is purely and simply a reflection of the fact that most machine istream
formats ARE, INDEED, PREFIX FORMATS.  It has NOTHING to do with issues
of whether "syntax is important" to the user or not.   It has to do with
being able to express most nearly directly what's in the machine's istream.

Now, clearly one can define a higher-level notation that will correspond
more closely to what humans "expect", and which will nevertheless have
an exact translation into a machine istream.  Such things have been
done, eg PL/360.  But this inevitably puts a layer between the programmer
and the machine, however slim, and perhaps even more important, is
misleading, because (using a PL/360 example)

              a := b + c * d;

did not mean what a human is most likely to take it to mean.

The bottom line is, either a notation expresses what a human means, ie
what some abstract model means, OR it expresses what a machine means, ie
what some concrete implementation means.  To try to do both at once is,
essentially, impossible, because there are conflicting requirements of
the two goals. 

: There IS a way to get some of this, and I have been assured by those
: who supposedly know that this can even be done, and at not too great
: a cost.  That is to allow a really powerful macro language, which 
: would be a syntactical translator from what the user wants to write
: to what some processor can read.  

Oh foo.  A saying about "teaching your grandmother to suck eggs" springs
to mind, for some completely obscure reason. 

Yes, you can wave your hands and say "macros" and "syntactical
translator" and perhaps "code generation".  Yes, these things "can be
done", and even at "not too great a cost" (for some definitions of
"done" and "not too great"). 

But what do you think providing such "macros" and "syntactical
translations" IS besides writing (or enhancing) a compiler for a
specific translation task?  There are a lot of little details behind that
little unassuming "can be done".  There's even a standard phrase for it:
SMOP (small matter of programming). 

: The translator can employ portable constructs without knowing how they
: will be done, such as the obtaining of a geometric random variable and
: updating the information so that the next time those bits used to
: generate this random variable are not used.  This may or may not be a
: function call.  Another is the example of unpacking I have used here;
: this requires the use of relatively easily understood syntax, which the
: current languages do not support.  At least I hope that most will not
: find understanding a list of results as too hard. 

These two examples are of two rather drastically different things.  One
is parsing a notation into operator/operand/reference in an orderly way,
and the other is generating code for each specific operation. 

But yes indeed, there are many meta-notations which allow the
specification of these two things, such as LEX/YACC grammar processors,
or Lisp reader macros in the one case, or tree-driven code generators or
specialized intermediate languages, or attributed grammars for the
other, to name only a handful of techniques. 

And further, nothing stops anybody from *using* these techniques and
notations for any language desired, from C to Lisp, or roll one's own,
or whatever is wanted.

So what's the big deal? Seems to me that Dr Rubin can go ahead and start
writing his macros and specifing his syntactic translations any time he
pleases, in notations specifically designed to make this sort of thing
easy.  Say, the Amsterdam compiler toolkit, or the UNC language lab, or
any of the many, many metacompiler systems. 

Or hire the guys that say it can be done at "not too great a cost". 
(Though I'd ask them to be a bit more specific about just what they
could do for just how much money before *I'd* hire them...)
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw