Re: +=

[Reuben Thomas <rrt@...>]

> > BUT the point is: If we adapt LUA to serve OUR individual tastes, it
> > will grow fast, slow and useless.
>
> Like every committee or fan-base-"enhanced" language in history.

Committee-agreed standards tend to be aiming to unify existing practice (as
in the case of the ANSI/ISO Forth standard), whereas "fan-based"
enhancements tend to extend a language or system.

Both have their ups as well as their downs: Perl and Python have both gone
through periods of massive expansion, which has created problems, but also
given a lot of experience on which to plan Perl 6 and Python 3000, which
both seem to be aiming to remove as well as add functionality.

Similarly, the Haskell 98 standard could not have arisen without the
experimentation in various compilers (especially GHC & Hugs) that preceded
it, and now it has three conforming compilers (nhc, GHC, Hugs), while GHC
especially continues to include new experimental features, which may be
considered for future versions of the standard.

> Remember when Forth was small and elegant?

...and it still is. It's easier with Forth than other languages, because of
the lack of a central fixed parser. The standard did an admirable job of

a) pulling together existing practice (the "easy" bit)
b) making the language machine-independent (hard)
c) giving the language a decent semantics (well-nigh impossible, but they
did it)

I was an active participant in comp.lang.forth from just before the
ratification of the standard for about 3 years, and it was noticeable that
while it attracted a lot of criticism (and caused a lot of pain), once
people had got used to it, there was a much greater sharing of ideas and
code on a common basis.

The standard still has its opponents (notably Forth's inventor, Charles
Moore), but what most of its detractors seem to ignore is that it's a very
flexible beast: you can write a program that makes many (non-standard)
assumptions about e.g. word length and number representation, and then
declare it to be a standard program with environmental dependencies (most
programs come out this way, with a longer or shorter list of dependencies).
This effectively tells you what you need to do to port the program from one
environment to another, something that the ISO C standard did not achieve.

Finally, compilers can implement subsets of the full standard and still be
standard compilers (or restricted compilers if they omit core parts of the
standard), provided they don't contravene the standard; hence, you can
certainly have small, elegant, standard systems (though admittedly not the
1K systems of which Charles Moore is champion).

-- 
http://sc3d.org/rrt/ | Si hoc legere scis nimium eruditionis habes.