Re: Definable operators

Our moderator answers to Dave Lloyd <Dave@occl-cam.demon.co.uk>:
> [If high school math students had to read, understand, and modify proofs
> as big as your typical program, I suspect they'd have just as much trouble
> with mutant notation. Like Henry said, small doses are OK, for large
> programs, the more obvious the better. -John]


To high-school students, just *all* program notations are mutant,
because every such thing is new to them. The difference is that for
some notations, there is lots easily accessible understandable docs,
while for others there isn't any.


      Hence, the solution to adding new syntax is to allow adding new
documentation and documenting behavior. When I learnt Pascal and C
with Borland tools, I could type a word, use the Ctrl-F1 hotkey, and
there I had the full docs. Or I could browse their help file from the
table of contents or the index. If new syntax can be added, new help
must be added in the same way. If the system can high-light known
constructs, new constructs should be high-lightable in the same way.
If there is a module system, syntax and syntax help must be
modularizable. etc.


      Also, ancient BASIC development systems on Ataris and Amigas did
allow to fold/unfold function definitions; Mathematica [23].x) also
does that. Why couldn't arbitrary syntax similarly be folded/unfolded
at will in an automatic fashion? So, if the reader doesn't understand
some notation, he'll warp to the notation's definition (before popping
back to the original place), and if he doesn't like/grok it, he can
just automatically have it folded/unfolded, with any interactively
computable criteria for places he wants it to. User-customizable
defaults apply as to what should be (un)folded when watching new
files, with the possibility to automatically open a help window for
any new notation, etc.


      This requires an integrated development meta-system, of course. If
you're using `cat > foo.mftl ; make foo && ./foo` as a development
system, that's ok to me, but I won't, and don't assume I will. Just
don't cripple other people's languages because your stubborn
development tools can't cope with them; if they don't, it's a problem
with your tools, not with the languages.


      The good tool is that which helps doing the good things, not one
that prevents from doing bad things.


== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"
[Maybe I'm hopelessly old-fashioned, but I'm sceptical of languages in
which you you can't practically print out programs and read them on
paper. I agree, CASE tools are great, but they're not a panacea, and if
you can only understand your program by unfolding, examining, etc., all over
the place, something's wrong. -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.