Fear and loathing of the "perlification" of Smalltalk

Igor Stasenko siguctua at gmail.com
Wed Sep 5 19:47:53 UTC 2007


On 05/09/07, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> 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.
>
>
Dont forget about pragma syntax in smalltalk.
Currently it used only for generating primitives in method headers,
but with subtle changes pragma can be used as a macro without
introducing any new #... constructs.

Then sample above can be written with pragma:

MyClass>>someRandomMethod
  Logger log: <MyClass generateTimestamp> , ' entering someRandomMethod'

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list