[Fwd: Language Syntax Suggestion]

[Hans-Dieter.Dreier@Materna.DE]

--Wu6nMkfU062XxQI0R1ObaTxdOvwClFZ2
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Matthew Tuck 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?

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

>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 w=
ould take, say, window handles, just because "everything has to be in a cla=
ss" does not really add clearness nor simplicity. Why not use the underlyin=
g API function in the first place?

GetWindowXYZ (hWnd) instead of cWnd->GetWindowXYZ ()

Maybe classes with just one instance item (hWnd) are somewhat degenerate, b=
ut they are sad truth nowadays. Remembers me of that odd "goto" issue, wher=
e people packed things into functions just to be able to "return" instead o=
f "goto".

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

>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 shorthan=
ds?
I thought shorthands would be just a mapping of *existent* ASTs to some spe=
cialized view representation?

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

>I don't know that it would have to be an engine.  What I've been
>thinking of has been more of a integrated functional capability.  Some
>functional language aspects would not be present, such as lazy
>evaluation and infinite lists, but things like referential transparency
>and higher-order functions would be.  The existing imperative concept of
>a function could be adapted to support this.

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 s=
pread, but I admit that my knowledge regarding functional languages is supe=
rficial at best. Maybe we can even put these specials in. If function defin=
itions and function calls were classes, there could be (at least in princip=
le) various implementations - why not one with lazy parameter evaluation?

--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--Wu6nMkfU062XxQI0R1ObaTxdOvwClFZ2
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a22331a.txt IA5 DX-MAIL X.400 User Agent=

--Wu6nMkfU062XxQI0R1ObaTxdOvwClFZ2--