Re: Diversity - existence, value, and pursuit.

[Michael Vanier <address@hidden>]

Sorry it took me so long to reply; I was offline for a few days.

> Date: Mon, 03 Dec 2001 16:39:36 -0800
> From: Paul Prescod <paul@prescod.net>
> 
> Michael Vanier wrote:
> > 
> >...
> > don't think people really have a problem with scheme's semantics, just with
> > the syntax and with the mostly-functional programming model that is natural
> > in scheme (which is a whole other issue).
> 
> Could you differentiate between "programming model" and "semantics" for
> me? Do you mean just "idioms" for programming model? I'm curious what
> things like "for loops", class statements and regular expressions would
> look like in your syntax. In other words are we talking about merely a
> thin layer of syntax or a thick layer -- to the point where it is almost
> another language?
> 
>  Paul Prescod
> 

Warning: lots of rambling discussion ahead.

I was not being sufficiently precise.  First off, there is no such thing as
"my syntax" since I (a) haven't thought out what syntax I'd like (and it
would probably be different for different applications, much like Rebol's
dialects), and (b) the point is to allow any syntax as long as there is a
reasonably straightforward mapping to a lower-level form, which is
presumably a prefix form much like scheme (for want of a better candidate).

Now, it's true that if you layer enough new syntax on a base syntax, you
get something that looks and feels totally different from the original
language.  But what I was thinking about (hoping, I suppose) was that the
layer would be rather thin, and would reflect personal preferences about
how a language was supposed to *look* like.  I'm tired of the time people
spend arguing over syntax, especially since it's really a solved problem.
If person A prefers curly-brace delimited blocks and statements that end in
a semicolon, and person B prefers whitespace-delimited blocks and
statements that end in a newline, is that really a good reason that they
can't possibly use the same language infrastructure?  By infrastructure, I
don't just mean the same VM as in Parrot (great though that would be), but
rather a whole language core like scheme.  What I'd like is if the
discussion on computer languages shifted to semantic and implementation
issues instead of syntax.  Syntax is a user-interface issue.

Example of a syntactic issue: there is a python extension proposal (PEP)
for extending the arithmetic operators to handle aggregate data much like
in matlab.  This can't be done just by operator overloading because there
are two kinds of matrix multiplication: "proper" matrix multiplication and
elementwise multiplication.  The proposal suggests having new operators
like @+ for elementwise multiplication.  Now, I have no trouble believing
that in some domains, this would be a huge win.  But for most programmers,
it would be a lose, because now they have to remember a new operator, know
its precedence, etc. even if they don't use it (because other code will use
it).  I think a better solution would be to define an "array math" dialect
that could extend the syntax (or replace the syntax) of python with
something more suitable for that specific domain.  Similarly, you could
have a "string" syntax which might predefine certain things in the language
(like regexes) which are not generally part of the syntax in most languages
(except for perl).

Example of an implementation issue: you can model exceptions and threads
with call/cc.  However, doing so is not as efficient as providing
exceptions and threads as primitives (given the way modern computers are
organized).  Therefore, exceptions and threads should probably be
implemented as primitives.

The reason I said that people don't have a problem with scheme's semantics
is that scheme fully supports imperative programming as well as functional
programming, and can easily be adapted to support OO.  Scheme adapts well
to other programming paradigms as well.  Many people (not me) don't like
the syntax, so why not give them what they want and preserve the core of
scheme that is generally useful?  I challenge anyone to define a
dynamically-typed language that is more powerful than scheme.  Of course,
"powerful" is a tricky issue to pin down as well...

Now, many people (again, not me) also have a problem with the
mostly-functional programming model that is encouraged by scheme's base
syntax (e.g. writing the somewhat long-winded "(set! a 10)" instead of "a =
10" and using tail recursion for iteration).  It is true that syntax can
subtly or not-so-subtly encourage or discourage different programming
paradigms.  But this, to me, is a clear indication of the need for multiple
syntaxes with a single base language!  You can have the
"imperative-friendly syntax", the "functional-friendly syntax", etc.

Another issue is that when you can mutate the base syntax, you can
sometimes define what are usually thought of as fundamental constructs in
terms of pre-existing ones.  So you can define classes in terms of
procedures just by using macros in scheme.  Does this mean that OO is not a
fundamental concept and is just a syntactic issue?  I don't think so.  Just
because you can do it that way doesn't mean it's the most efficient way to
do it.  Implementing classes as macros may be demonstrably less efficient
than implementing classes in the base language (or, more precisely,
implementing primitives that can be used to implement an efficient class
system).  This is an implementation issue again, not a syntactic one.  OO
is a nice example because it's full of both syntactic issues and
semantic/implementation issues (e.g. do I use generic functions or
classes?).

I guess what I'd really like is if the semantic/implementation issues and
the syntactic issues were cleanly separated and could be treated
separately, instead of having each new language define a slightly different
syntax coupled inextricably with a slightly different semantics and
slightly different implementation decisions.  Then we could compare
different languages on the basis of their semantics and the specific
implementation decisions that they embody and not stress about syntax so
much.  That strikes me as being in line with the nebulous goal of
little-language-hood.

Mike