On Wed, Dec 3, 2008 at 7:57 AM, Igor Stasenko <siguctua at gmail.com> wrote:
> Another variant and same question: Some of us using a Null class to
> make use of message eating nulls.
> Now, if i want to return null, can i introduce a 'literal constant'
> named 'null' as well?
> Or, what makes 'null' less important (for someone) than 'nil'. A
> little bit of discrimination :)
>
> Another guys can come and say: hey, i'm a matematician, and i want a
> 'literal constant' named 'epsilon' , so lets modify compiler to
> resolve it as a sole instance of Epsilon class.
>
> So, how many of such 'literal constants' we may need in future? Or
> maybe, if we treat such names as globals, then we won't need to hack
> the compiler every time?
> And then, obviously #(true false nil) = (Array with: #true with:
> #false with: #nil)

FWIW, here is the Newspeak angle:

The traditional Smalltalk syntax of #(...) is not valid in any form.

The way you create arrays, other than explicitly talking to Array, are
the braces which work essentially the same way as in Squeak. Except
that Newspeak allows implicit receiver sends that are module-scoped,
meaning one could write

   {null. epsilon. #foo. true. nil}

where the first two elements are implicit receiver sends. The methods
null and epsilon returning a message-eating Null and the Epsilon
singleton do not necessarily have to be implemented by the receiver,
they can also be provided by the module that contains all the code
that wants a special treatment of such "literals". In fact, that would
be the right way to architect the null and epsilon use cases.

Cheers,

--Vassili