🚀 go-pugleaf

In article <BEVAN.92Sep2101315@tiger.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen J Bevan) writes:
|> [...]
|> I much more interested in improving the semantics to support higher
|> level concepts (such as those found in APL, Haskell or partly FORTRAN
|> 90), than fussing over syntax.  [...]

The problem is that syntax is probably the *most* important aspect of
the language's design with respect to its usability.

|> [...]                          One reason for this is to find out
|> what the required concepts are, rather than get lost in irrelevant
|> syntax.  [...]

If you get lost in the syntax, it is poorly designed.  And you probably
will not have a well designed language overall - no matter *what* the
semantic features are.

|> [...]      For exmple, consider distributed sum and product in maths:
|> each has a separate notation (sigma, capital pi) and there is no
|> general distribution notation.  As APL programmers have found, there
|> are lots of useful things you can do once you have a general notation
|> for distribution, reducing, scanning ... etc.  [...]

Yet, APL never became overwhelmingly popular - largely because of
its poorly designed syntax.  Yes, the operations of fold, scan, etc.
(as they are called in the haskell standard prelude) are important.
It is also important that they *not* look like `line noise' when used.

|> [...]                                        I therefore advocate
|> getting the semantics right, _then_ you can worry about producing a
|> "nice" syntax.  [...]

I recommend doing both concurrently - and backtracking when conflicts
arise.  The "do the semantics first" approach is why APL is so illegible.

|> [...]                          So whilst I'll agree that "CS
|> people" could be more flexible and try to accomodate "scientists"
|> syntactic wishes, I also think that "scientists" could do with
|> questioning the notation they come up with and look for underlying
|> concepts rather than producing endless stream of special cases.

Yet, when I proposed the same sort of thing about six months ago, the
APL supporters on the net vehemently attacked me because my proposed
*syntax* was different than theirs. 

Also, there are *syntactic* distinctions which are important to ease of
use.  For example, in scientific code, one type of reduction dominates
over all others and is usually used in a different way.  Summation is often
used in tensor work in a way that other reductions seldom are: with disjoint
sets of covariant indices (exclusive-or is used in similar ways for coding
work, but it *is* summation - with add restricted to boolean).  Other
reductions are usually the reduction of a single indexed object (which may
be the result of an expression).  Having a unified syntax for all reductions
*and* an extended for specialized for summation would make legibility and
usability easier than having *only* the single, most general reduction.

-- 
J. Giles