[Fwd: Language Syntax Suggestion]

[Matthew Tuck]

Hans-Dieter Dreier wrote:

>> 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.
> If some program can't handle something decently anymore because it has
> no definition for it, I'd call that incompatible. What else?

At the moment I don't see an alternative in a multi-viewing world. 
Extensions can be used in other views which will not be understood by
other views.  But if they just translated to full form the extension
would become expanded in the view that created it.

The difficult part is designing the textual view so that it understands
foreign extensions, which I don't see as being insurmountable.  Some
standard rule could be used for parsing and deparsing of these, in the
absence of a shorthand.
 
> Either "while" or "do" is a noise word here (like "if x then ..." where
> either if or then is a noise word). A loop is just one construct, so it
> is represented by one node. It has just one parameter, the loop body.
> It's an endless loop. Breaks are handled separately inside, so you can
> have any number of them at any place as long as it's inside a loop.
> Other loop constructs (for, do..while, while..od, you name it) can be
> viewed as special (crippled) cases of an endless loop with breaks, so
> nothing else is needed. Keep it simple.

The problem with this is that it doesn't store in tree whether or not
the extension is collapsed or expanded.  If you leave it expanded, which
would be the simple thing, shorthands are basically typing conveniences
since they won't stick.  Therefore they do not give readability and
modifiability benefits.

If you try to compulsorily collapse extensions you're left with
extensions always being collapsed when you load them, which is
probably not desired.  Plus the hassle of searching the tree for known
extensions every load time.

Also, the extensions will not have any effect on other views. 
Extensions are usually defined since they are semantically useful rather
than syntactically useful, and this suggests they are language-wide
rather than view-wide.
 
> > 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.
> If they have an efficiency impact inside the generated code, can they
> really be regarded as mere shorthands?Aren't they true extensions then,
> rather? Otherwise the compiler could achieve hte same by optimisation.
> Where do you draw the border between language extension and shorthand?

Well they could have an efficiency impact in two ways - optimising and
code generation could be faster since they are smaller, but also because
higher level structures can have more said about them, therefore
optimisation information would be known earlier.

The second way is through better optimisation.  Specific structures
might have known properties as mentioned above, but the general
structures are too hard.  A normal optimiser could actually try to
recognise these structures, which is essentially collapsing shorthands. 
So since it can do it's own collapsing of this type of shorthand, it's
unlikely to give this benefit in a good implementation.

I think whether they're "language extensions" or "shorthands" is a
semantic quibble, it doesn't really matter what category you put them
in.
 
> How would you define the term "view"?

Probably something like: a window which has code associated with it to
allow the reading or writing or both of the program and associated
entities.  I would call a "cooperative view" a view which keeps up to
date with changes made in other views, or by the compiler (error message
annotations mainly).  Cooperative views can obviously be used in
parallel with other views.

Examples would include structural editors, semi-structured textual
editors, class browsers, error message displayers, extension definers,
etc.  They would access the program through a specific API which is
designed for views to be linkable to the editor at runtime as desired.

>> Yes, a func/proc that takes a func/proc reference/object. 
> So no (actual) parameters are included? Then it's nothing special, since
> I regard references as data.

If you're referring to standard imperative routine parameters, then yes,
basically the same, except that you can pass closures (routines that
are the result of partial application).

Functional languages tend to have a lot of useful higher-order functions
as standard.  Imperative languages with routine parameters tend to often
lack them for some reason.  Jeremy touched on a few in his first
message.

-- 
     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/