[Fwd: Language Syntax Suggestion]
Hans-Dieter Dreier
Ursula.Dreier@ruhr-uni-bochum.de
Sun, 07 Mar 1999 15:59:00 +0100
Matthew Tuck schrieb:
> Hans-Dieter Dreier wrote:
>
> > I would appreciate if you could give your definition of an AST along with
> > some examples. It seems to me that your concept of an AST is somehat
> > different from mine (which is rather informal).
>
> Well it's basically just a tree that represents the program.
>
> ...
> |
> |
> while
> / \
> = call
> / \ / \
> x y procA y
>
> for "while x = y do procA(y)"
That's what I expected.
>
>
> > That confuses me. I would think that if you extended the syntax (i.e. the
> > formal description of the language) without changing the AST (representing
> > a particular program), the meaning would not change. And isn't "extending"
> > a change ?
>
> Perhaps you're confused by my use of extensions here. What I meant was
> that you create a new sort of tree node that can appear in the tree.
> This subtree would be simpler than the corresponding full form subtree,
> but shorter.
Shorthands are thus implemented by special node types? I wouldn't do this,
because it's not compatible. A parser has to know that node type to be able to
process the shorthand. I would consider such an implementation rather as a
language extension.
IMO a shorthand should be a *pattern* that is recognized by a parser (for
editing purposes).
Example: If we take ...
while x do something end
... as a shorthand for ...
do if not x then break; something end
then the AST should be (in LISP-speak): (do (; (if (not x) break) something)
The pattern would be: (do (; (if (<condition> break) <body>)
This would be displayed as
do if not <condition> then break; <body> end
When expanding <condition>, double negations would have to be removed, _or_
there have to be two patterns, one including the "not" and one without "not".
The advantage of this approach would be that neither the front end nor the
compiler would *have to* know the shorthand; everyone could roll their own
without compromising portability.
> > A higher-order function is one with some of the parameters already
> > provided, and some not, am I right?
>
> No, that's partial application, aka currying. This is where you could
> say take +, and bind a value to one parameter at run-time, giving a
> unary function. It's standard practice functionally, possible to do in
> OOP (by binding parameters inside a wrapper object), and impossible to
> do in general in imperative languages, although possible, if kludgey, in
> most circumstances.
Thanks for the clarification.
> A higher-order function is a function that can take code as a
> parameter. A first-order function could only take data.
Similar to passing a function reference? Or are the parameters included (like
lazy evaluation) ?
> > BTW: The information whether a function causes side effects IMO is a
> > valuable one for the compiler, since being side effect free might be a
> > neccessary condition for some kinds of uses (conversions, conditions, all
> > kinds of stuff that the compiler is free to use or omit). So I think the
> > compiler will check for this and mark the function accordingly. Or the
> > user may mark the function as intended to be side effect free, and the
> > compiler checks this, or both.
>
> I think the latter is useful since it's useful for the programmer too.
> Also, this might be useful typing information, e.g. a method declared to
> be side-effect free can not be overridden by one with side-effects.
> This would be useful for a call to a.b(c) ensuring there is no side
> effect regardless of what class a happens to be.
So it would be part of the "contract".
--
Regards
Hans-Dieter Dreier