finding relevant information on the wiki isn't straightforward
for newcomers.
Good point, operators in particular need some navigational
help. I'll do something about it.
Thanks. Btw, other things I've been looking for are timeline,
process, committee information, and software information
(which JS-in-JS tools to use for prototyping language design
ideas). The meetings page could perhaps link to an archive
search for this mailing list, for the meeting notes?
2. Do they make any provisions for specifying operator
precedence/associativity?
Certainly not. We are not trying to enable new operators to
be defined. We are not trying to enable user-defined changes
to the precedence, e.g., of * vs. +. These are anti-goals. Moreso
(stronger anti-goal language) for associativity!
Ah, that explains it. But I'm sorry to hear this. I can understand
that redefining properties of standard operators is not something
you want (source of programmer confusion), but that concern
does not apply to defining new operators.
It is very strange for me to see specific operators hard-coded
in the language syntax, but that is less worrying than not being
able to define my own operators. There is just no way that the
language designers can foresee all possible application domains
or the operators that are useful for those.
Embedded domain-specific languages are a major program
design pattern, and library-defined operators are a small part
of making languages like Haskell so successful at that game.
Library-defined infix operators are also important for
extracting common programming patterns into reusable
libraries, without library users drowning in excessive syntax.
Many of the operators that are now "standard" in Haskell
practice belong to libraries that didn't exist when the core
language was specified. Not to mention the operators that
are "standard" in specific application domains.
The more programming languages are becoming foundations
on which to provide useful programming patterns, the more
important it becomes that core syntax does not get in the way.
I'm not sure why user-defined infix operators are such an
anti-goal for you? Perhaps because you have to cater for
such a wide range of programmers?
It may be helpful to keep in mind that programmers who
might have trouble with this concept need not use it directly,
but ruling it out completely deprives library authors of an
important tool for making their libraries more useable (and
library users have no more trouble using
standard-for-their-library infix operators than they have with
standard-for-their-language infix operators).
Claus
PS: If they cannot define new operators, library authors will
be tempted to re-interpret the operators which they can
redefine (witness the rise of $), but that won't give them
the same range of operators, and it will be even more
confusing to programmers if, say, '*' suddenly means
sequential composition, instead of a new, dedicated
operator being defined for that purpose.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
