[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax

From: Mike Anderson
Subject: Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax
Date: Sat, 10 Mar 2007 13:48:13 +0000
User-agent: Thunderbird (X11/20061025)

Paolo Bonzini wrote:
> Hi everybody,
> in the next few months, Daniele Sciascia will work on the
> implementation of a scripting syntax for GNU Smalltalk.
> The aim of this is to provide a better programming experience
> than is possible with the file-out (bang-separated chunks)
> format.
> This is an ambitious project, and it is best if no false
> starts are made on the syntax.  Therefore, I am attaching
> two examples (taken from and in the
> gst distribution) converted to the new syntax.
> (We still have no parser, so I'm not completely sure that
> it will work exactly as I attach it, but it is enough to
> give the idea).
> Speak now if you wish. :-)
> Paolo

It seems to me that we have never really addressed the question of how
the language is used to write actual scripts. 'Scripting' is not a
precisely defined activity, of course, but it seems to me that scripting
 often does not require defining new classes.

For example, it's perfectly possible to define classes in Perl, but for
most scripts I never do. The built-in arrays, hashes and function refs
are quite adequate for representing complex data structures. Smalltalk
has a very good set of standard classes, including Arrays
[OrderedCollections] and Dictionaries [LookupTables], and I think the
same applies.

So the question is, how do you write structured code? I find three major

a) You have to write methods in order to be able to use ^, and to have
functions. This means that you must have a class, and I find myself
declaring a bogus 'Script' class in order to accomplish this. It also
seems to involve mutating local variables into instance variables,
solely because of scope.

You can, to some extent use blocks as functions, by assigning them to
variables, but you find the the code starts to look like:

afunc value: (bfunc value: 1 value: 'two') value: true.

- complete loss of readability.

b) Having to declare variables is fine (good, in fact) in methods and
blocks. In eval chunks, I find that it becomes onerous. There are good
reasons to name your variables properly and use them for only one thing,
but if it means a trip up to the top of the file, I find that I prefer
to just reuse an existing variable.

c) Filing in packages is slow, and building an image for every script is
not a solution.

I don't have answers to these problems, but I have been thinking that
having an implicit 'Script' class for each file might satisfy (a) and (b).

Perhaps having an explicit 'Script' class is not so bad either,
particularly with the proposed style of method definition (saving the
need to write many methodsFor: statements).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]