Re: syntax heresy

[Boyko Bantchev <boykobb@...>]

Thank you Claus, David, and Uli,
for responding with comments.

Having read your postings, I feel that I should answer
some of your criticism, and, conjointly, provide a rationale
for what I described in my initial posting.

First of all, I did not mean my proposal to be, as you might
have thought, the beginning of some more ambitious work of
mine.  It was really about a simple-minded preprocessor that,
I think, allows me to create Lua programs in a more rational,
succinct and readable way.

I wanted to receive some opinions, which I did.  I also hoped
to hear about more or less similar work being done, or having
been done already.  In this I (almost) failed, but I will
continue waiting.

Uli Kusterer wrote:

> I've seen enough people try to write such "language
> translators" using simple search/replace patterns or
> regular expressions. Most of them got pretty far, than
> realized that they wanted to do more than this solution
> would allow. As you seem to be using the same technique
> (at least that's what some of your statements sounded
> like to me), I didn't really have much hope for this
> getting anywhere.

As I said, I din't want to get anywhere else.  What the
proposal aimed at is what it already does.  I may change
some details, or even redo the whole thing in awk, in order
to deal with the problems I mentioned, but that is all.
On the other hand, I am interested in learning about
relevant work of other people, if there is such.

David Given wrote:

> I think what you actually *want* to do is to implement a
> functional language compiler that produces Lua byte-code.

I do not want to do this.  Why should I?  :)

> ... a lot of the other syntactic changes look like
> abbreviations for the sake of it ...

I am not sure which exactly of the abbreviations you mean,
so here is some partial rationale, in brief:

`&', `|' and `~':
much more easily recognizable in the text than the
corresponding words, and widely used in other languages

`.t', `.f':
better visually recognizable than the respective words

`++', `+=' etc.:
well known, handy idioms

`\':
borrowed from Haskell, and said to resemble the letter
`lambda'; much more convenient, esp. for anonymous functions

`?':
easier to recognize than the word `nil';
and, `nil' is mistakable: I once used `nul' instead --
similar meaning plus `u' and `i' are neighbours on the
keyboard; the program was still correct, but only because
the value of nul was obviously nil!

`break end', `do break end':
there is no break without end in Lua, so better avoid
redundancy and use a symbol for better discernibility

similar for `return' without arguments

`end':
this word itself is somewhat redundant: it is actually a
terminating `symbol', so better write it as a true symbol;
besides, `end's tend to occupy each one a line, while one
would more willingly write `. . . .', much like `))))'
in Lisp

`then':
an awfully void of meaning word in programming, so at least
use a single character instead (Ruby has a symilar to Lua
syntax but does not have `then')

Some other arguments follow below.

> For example, I simply don't see a *need* to abbreviate
> the coroutine calls to four-character mnemonics ---
> they're not something that are used particularly often...

The `how often' question depends on what you do.  Lua's
authors seem to consider them usable often enough to justify
introducing the coroutine.wrap function as a shortcut.
Besides, I consider the operations with coroutines to be
really control structuring operations (are they not?) rather
than just library functions.  I would guess that the fact
that they are implemented as a library is a mere consequence
of them not having been put in the language from its birth.

Let me explain why I also chose to provide shortcuts for
most of the entries in the math library.  Except that I
do consider them frequently usable (though of course this
is a matter of viewpoint), I find it terrible that, in
programming (regardless of the specific language) we
speak of `mathematical functions', which makes no more
sense than, say, `vegetal flowers' or `metal iron'.
Pi is pi -- a number, `sin' is the sine function,
`min' is the function that tells me which one of two
or more is the smallest etc.  Mathematicians, physicists,
engineers and other professions use them without that
meaningless qualification.  In my school, when I learned
of square root, I wasn't told it was a `mathematical
square root'.  And do we have `mathematical numbers' and
`mathematical cosines' or just numbers and cosines on our
pocket calculators?

That is why I introduced .pi (not a true Lua variable name)
for math.pi, and maybe I should have written also .abs,
.sin, etc. instead of the :: notation, but I decided to
stick with one consistent notation for library function
shortcuts and another one for named constants... anyway,
that is changeable and not the point here.

>From a more general perspective, let me remind that
shortcuts are not unknown to Lua.  Being a practical
language, it already offers shortcuts for function calls
and definitions, as well as for table construction.

> ... so why go to the effort of reducing them to
> difficult-to-remember mnemonics?

How are they difficult?  Library routines are abbreviated
by initial letters, so :cr: means `coroutine.resume',
:ms: stands for `math.sin' etc.  Where the names are
symbolic, such as :_:, :^:, :\/: and :/\:, they are chosen
for being visually suggestive and/or for being used elsewhere
with the same or related meaning.  Of course, that is, to an
extent, a matter of personal perception.

> ... clarity trumps conciseness any day.  The only reason
> for going for conciseness is when it *aids* clarity by
> making the algorithm more obvious.

It seems to me that, in the debated case, I loose nothing
in terms of clarity: the abstract syntax _is_ the same.
What I am changing is mostly tokens, and my belief is that,
once tokens are visually more distinctive and the program is
more succinct, it is clearer, too.

> Looking at your substitution list, I would hazard a
> guess that you're familiar with functional languages,
> and probably APL too.  I suspect you might also rather
> like Forth.  Am I right?

I have some knowledge of, and esteem for, Haskell,
StandardML, etc. (and not so much for Lisp/Scheme).
Also APL and the more modern J and K.  Definitely not
Forth -- too low-level and restrictive to my taste.
(I wonder what made you think I would like it, though.)
Speaking of stack-based languages, PostScript is what I
like -- it is a very cleverly designed language.  Joy is
also interesting, although so far at experimental stage
only.

> Another comment is that you seem to be very keen on
> using single-purpose symbols to represent library
> functions.  Unfortunately, this is rather against the
> whole Lua philosophy; math.min *isn't* a language
> primitive, it's just a library function.  Presenting
> it as a primitive is misleading.

First, see my comments above on why I prefer to use
shortcuts for some library functions.  Second, there
is no misleading: the shortcuts do not pretend to be
primitives, just what they are -- shortcuts for library
functions, with specific syntax to distinguish them from
true library function citations.  Third, the syntactical
distinction in Lua between library functions and built-in
operators is not so strict (or maybe even not so important,
let alone (not) being a question of language philosophy)
as exemplified by the ^ operator, which is actually a
library function (Lua 5.0 Ref. Man, pp.9,50; or PIL, p.155).
(In a spawned thread, Rici Lake made some specific comments
on `min' and `max'.)

> I suspect that the main problem with your suggestion is
> that it's so tightly tailored to what *you* want to do ...

My proposal consists of the following:
   -- Identifying what tokens, and token sequences, we are
      going to provide shortcuts for.
   -- Deciding on what each kind of shortcut will look like.
   -- For each kind of shortcut, defining the context rules
      that make possible a sequence of characters to be
      treated as a shortcut and thus replaced by a target.

(Note that using the defined substitutions is made possible,
but is not compulsory.  One may choose to use only a part of
them, or to use both the shortcuts and their targets,
whatever seems appropriate for the case.)

So, I do not really understand how what I propose is
`so tightly tailored to what I want to do'.  It does not
even have specific purpose other than to rationalize
writing in Lua _in general_.  Yes, specific details of
what should look how, such as the exact syntax for constants
or keyword shortcuts were decided according to my taste (or
lack of it), but this is not the essence of the proposal.

> ... it doesn't actually meet anyone else's requirements.

Neither do I insist that anyone likes what I do.  But:
   -- I have reasons for doing it, so I wanted to share
      them and discuss with others.
   -- More than the specifics of what I suggest, I consider
      important the considerations that lead me to it (part
      of which I tried to explain in this posting).

Finally, if other people have their own ideas of what and
how they would change (in the same spirit -- without really
changing Lua itself), I would be glad to listen to them, too.
For example,

David Given wrote:
> ... I'm definitely keen on a more abbreviated lambda
> syntax ...

Do you mean you would only rationalize function definitions/
calling?  And do you mean rationalizing Lua in some way, or
you just speak in general?  And if Lua, what would be your
approach to that?

Regards,
   Boyko