languages

[Jecel Assumpcao Jr]

Faré wrote: 
> That's a problem with literal strings being mutable by default,
> which I think is a bad choice for any high-level language,
> especially since converting from immutable to mutable is quick and safe,
> while the other way round is unsafe. Lower-level languages from time when
> memory was scarce (and/or targetted to small embedded platforms) may want
> to avoid any copying for space-efficiency reasons, but even these reasons
> are moot on today's generic architecture with lots of RAM and COW MMU).

You will be happy to know that Self uses immutable strings for literals.

> Your rule is wrong in both theory and practice.
> Even if it works in many simple cases,
> that's precisely what differentiates an ugly hack from a nice design.

I agree. But I also note that we are using ugly hacks (mailing
programs, OSes, protocols, etc...) to discuss the advantages of nice
designs, which I find rather ironic.

> What if the program has interactive features, that may invoke EVAL ?

I didn't understand this - it would seem to me that in this case you
would find EVAL in the source code.

> What if the programmer would have specifically liked to disable EVAL ?

Including EVAL in the source code seems to be a stupid way to try to
achieve this ;-)

Of course, my ugly hack will enable EVAL if the programmer includes a
comment along the lines "For this program to work, EVAL must be
disabled!!" since grep doesn't parse the sources in any way. Which
mostly proves your point, I guess.

> What if EVAL is actually called through COMPILE ? Etc.

Unless the programmer purposely tried to hide it (as in your example,
which I note you changed to look more dangerous :-), the word EVAL is
still likely to be present in the source.

> LISP's lack of expressiveness in negative assertions and module interfaces
> is a cruel misdesign. It's precisely what limits its ability
> to be used as a framework for many people to develop modules
> that interact nicely, by requiring a lot of manual, non-automatable
> communication and synchronization between programmers
> (ultimately, centralized control).

That should be easy to fix as long as you are note worried about
standards. It should be no more than a day's work to add something at
least as good as Perl or Python have. A little more and you will be at
the Java or Oberon level.

-- Jecel