[Fwd: Language Syntax Suggestion]
Matthew Tuck
matty@box.net.au
Tue, 09 Mar 1999 21:35:35 +1030
Hans-Dieter Dreier wrote:
>> 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.
No they're compatible. ASTs are augmented by the extension definitions
used in the file to allow expansions as necessary. How a textual parser
will handle extensions with no defined parse shorthands is another
question.
> 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".
I'm not sure how exactly the "while" comes into this, you don't seem to
have represented it.
> 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.
Well whether the compiler will see shorthands is not important. They
could get expanded out in a preprocessing step, or we might leave some
known ones there for efficiency reasons.
Usually the user will define the extensions somehow - then a view may
need to know how to represent it - the more automatic the better,
although this would reduce programmer control over syntax. Views might
be able to define their own extensions. This means the front-end is
fairly extension/shorthand independent, although there will need to be
some framework for handling them, especially for textual views.
>> 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) ?
Yes, a func/proc that takes a func/proc reference/object.
>> 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".
Yes.
--
Matthew Tuck - Software Developer & All-Round Nice Guy
mailto:matty@box.net.au (ICQ #8125618)
Check out the Ultra programming language project!
http://www.box.net.au/~matty/ultra/