On 9/5/07, Blake <blake at kingdomrpg.com> wrote:
> On Tue, 04 Sep 2007 21:35:43 -0700, Jason Johnson
> <jason.johnson.081 at gmail.com> wrote:
>
> One rarely sees "Self" in Delphi. The constant references to "self" is one
> of the clunkier things about Smalltalk, in my view, and is inconsistent to
> boot (you have to use self to access methods but not fields?).

I don't find it clunky because the methods are so small.  I don't find
it inconsistent because variables are the only thing that are not
messages, so if you don't see it in the method declaration it's an
instance variable.  But that's just me, this is all so much easier
then C++ was.

> I've always felt macros tended to obscure things, but then I've only used
> them in things like the C-family and PL/I.

No no no.  I don't know PL/I but it's a joke to call what C has
macros.  That is just search and replace prepossessing nonsense.  A
lisp-style macro is the full power of the language at compile time.
The only rule is, what ever the function produces has to be valid
syntax because when the method is compiled, any macros are executed
and their output is expanded at the call site.

So, contrived example:

MyClass>>generateTimestamp
  ^ stream contents: [:stream|
       stream
         nextPutAll: 'Method compiled by ';
         nextPutAll: MyClass current_author;
         nextPutAll: ' on the date of ';
         nextPutAll: DateAndTime now ]

MyClass>>someRandomMethod
   Logger log: ##(MyClass generateTimestamp), ' entering someRandomMethod'

Now, as I said, this is contrived, but the thing to notice here is
that the string generated by #generateTimestamp is inserted *at
compile time* and is therefor a constant with all the values fixed to
what they were when the method was compiled.

The main use of macros in Lisp is actually to implement new control
structures because the other property of macros is that they don't
force evaluation of their arguments (unless they want to).  So they
basically take the source code text as input and modify what actually
gets compiled as C macros do, but the big difference is they have any
function that was defined prior (built in or otherwise) available to
help make the transformations.  Speed of the functions don't matter so
much because it's at compile time (and likely incrementally compiled).

Having said all that, macros aren't the same enabler in Smalltalk that
they are in Lisp, but one place that stands out to me as a place they
can really help Smalltalk is situations like this about adding syntax.
 In Lisp the # is the place for putting custom extensions so people
make reader macros for new # syntax.  If we had something like this in
Smalltalk then it would mean to do what {} does we wouldn't have to
touch a compiler.  Just define a reader macro (how ever that would be
done) that does the text conversion of e.g. #{} to the smalltalk
syntax equivalent of whatever {} is outputting now.