[Fwd: Language Syntax Suggestion]

[Matthew Tuck]

Hans-Dieter.Dreier@Materna.DE wrote:

>> The trouble with "the art of getting all the functionality" is general
>> concepts tend to be fine with general programming, but often the general
>> feature is not needed.  An example is defining a whole class just to get
>> a method to act like a procedure parameter.  The object-oriented concept
>> is more general and eradicates the need for procedure parameters, but
>> makes them longer to type.  Hence a shorthand might be useful.
> Agreed. Can you give some example?

Well, concrete examples usually evade me, but I know this comes from
actual experience.

> As long as shorthands do not prevent the transformation of their
> corresponding ASTs to something else, shorthands are perfectly OK;
> then they really are mere abbreviations for fairly complex, often
> used clauses.

Yes, all shorthands would definitely have a "convert to full form"
capability, which would involve an action attached to a particular
language element.  An example would be a procedure parameter shorthand,
which, when right-clicked on, brings up a menu, which includes "Expand
To Class" or some such thing.

This could be an example of a editor feature that's language and view
independent.

>> If you program imperatively in an object-oriented language I imagine it
>> would be, but I've always found object-oriented languages to make things
>> easier.  Sure, what's there is harder to handle (visualising class
>> hierachies and stuff), but there's less of it, making it easier overall.
> Well, I found that having a wrapper class to wrap some API functions that
> would take, say, window handles, just because "everything has to be in a
> class" does not really add clearness nor simplicity. Why not use the
> underlying API function in the first place?
> GetWindowXYZ (hWnd) instead of cWnd->GetWindowXYZ ()

I think this is a simplification of the situation.  OOP is about
inheritance not a method call syntax.  The ability of setting up both
type hierachies and implementation inheritance is extraordinarily
useful.  If not designed to take this into account well, they're going
to have the disadvantages of OOP and no advantages.  I found Java's AWT
class hierachy to be usefully set up in terms of hierachy.

> Maybe classes with just one instance item (hWnd) are somewhat degenerate,
> but they are sad truth nowadays.

Some languages provide a singular object facility to do this.  We could
easily implement this as a shorthand too.

> Remembers me of that odd "goto" issue, where people packed things
> into functions just to be able to "return" instead of "goto".

There is a distinct difference between return, which is more like the
restricted "exit", and the unrestricted "goto".

> (But IMO that is just a matter of taste and not really important)

The absence of goto is useful to optimisers.  So is "exit" too, but I
think that goes a little too far.  =)

>> Yes, it would be an AST, possibly with extensions for defining and
>> handling view or user-defined shorthands (what I call extendible ASTs).
>
> Do you want to extend the syntax definitions or the AST to support
> shorthands?  I thought shorthands would be just a mapping of *existent*
> ASTs to some specialized view representation?

Both.  The ASTs would be extendible.  This is by adding some extensions
to the language definition.  This is necessary because any shorthands
need to be able to be seen by other views looking at the AST.  If the
view merely translated into the normal AST, they couldn't, and also the
view itself would no longer see the shorthand next load time.
Constantly scanning for it would probably be a bit too much effort.

The only question is - how do the other views handle these.  Structured
editing views are easy - they can handle these without a care.  Other
types of view are more difficult - text views would need their own
fall-through for extensions they don't understand.  This might even be a
structured editor fragment, if you can stand the dislocation of have two
editing paradigms in one window.

A "shorthand" is a way of telling a text view how to parse and unparse
these extensions.  Users could define these since other views might use
them.  But even if these aren't defined, you can still edit the code
fully through some fall-through mechanism.

> Maybe I (or you?) confused the meta's here? Surely the _syntax_
> might get extended, but an AST (representing a particular program,
> if I understand right) should remain the same, for portability
> reasons. Of course this is only possible if the underlying
> operators etc. (the "library") are the same.

If you extended the syntax without the AST, the shorthands would be lost
in the reverse translation, which is as important in multi-viewing and
normal translation.  The AST format does not change, it is just
extended.  The extensions are included with the AST if needed,
explaining how the extensions map onto the simple format.

It's not perfect, I know.

> I agree. The more integrated, the better. I just am not sure how
> functional features would harmonize with an environment where
> side effects are wide spread, but I admit that my knowledge
> regarding functional languages is superficial at best. Maybe
> we can even put these specials in. If function definitions and
> function calls were classes, there could be (at least in
> principle) various implementations - why not one with lazy
> parameter evaluation?

Well it's certainly not easy to be sure.  Here goes.  For a start, don't
allow side effects in functions.  This has been done before I think, not
sure where.  Side effects do NOT include memory allocation.  To be more
specific side effects are OK, as long as they don't influence
execution.  Examples include changing vars and then resetting them, or
logging values for debugging purposes.  You have to realise that your
function's result may be reused rather than rerun as would happen
traditionally.

Higher-order functions and routines can be done with class parameters,
list classes are present, etc.

Of course, you'll want to avoid side effects.  Side effects in functions
would be the exception rather than the rule.  So you'd need type
assistance to ensure you don't traverse a pointer into memory you can't
touch (you could follow a pointer in an ok-object into a
naughty-object).  Furthermore, you need to ensure you don't execute any
procedures w/ side effects, that is, most implicit writeable parameters.

There's probably more that I can't think of right now - but I think all
of these would contribute valuable functionality to an imperative
language.  Feel free to bring these ideas crashing down around me.

Lazy evaluation is harder.  Actually, it could probably be done safely
for functions, but extending it to procedures is hard - since the
evaluation time changing could produce a different result due to side
effects.

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