[Fwd: Language Syntax Suggestion]

[Hans-Dieter Dreier]

Matthew Tuck schrieb:

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

OK

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

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).

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

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 ?

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

OK. What about local variables that are initialized on funtion entry and lost
on exit?Strictly speaking, assignments to these are side effects, but since
they depend solely on the start conditions and do not constitute persistent
"state", allowing them should make no difference. Using them couldn't produce
different results from the same start conditions.

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

A higher-order function is one with some of the parameters already provided,
and some not, am I right?

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

A naughty-object! What a funny term. Do you mean a non-constant object that
does not belong to the local scope of the function? Such as a instance variable
or class variable ? Read accesses to those could produce different function
results from the same start condition as well.

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.

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

I agree. At least the programmer must be aware of it and take it into account,
but I think if the rules of lazy evaluation can be made clear (and are not too
awkward), it might be a nice thing even in the presence of side effects. Or it
could be defined that evaluation is guaranteed to take place sometime before
the first side effect occurs - results should then remain the same.

Regards,

Hans-Dieter Dreier