[RFC] Smalltalk scripting syntax

Paolo Bonzini wrote:
I don't mind if you don't quote me in full, but chopping paragraphs in
half is bound to lead to confusion.

What I said was that you don't have to follow that mapping, because the
instance scope is not the same kind of scope as the class scope.

To put it another way: you are creating this new syntax. The only rules
that it has to follow are chosen by you. There are no external
constraints. There is no need to conform to a particular pattern if it
makes for a less useful syntax.

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> I don't mind if you don't quote me in full, but chopping paragraphs in
> half is bound to lead to confusion.

Sorry, that was because I was already lost after the first part.

The original full paragraph was:

> I thought you might say that, but there's really no reason why you
> should insist on defining class instance variables in the class method
> scope. It's a nested scope, and Smalltalk has no inner classes, so
> there's no reason to treat it the same as the outer scope.

And now I see what you probably meant.  Did you mean
"defining class instance variables" instead of *class variables*
"in the class method scope"?

If so, there is a good reason, and it is that class variables
are misused 99% of the time.  Class variables are *global* variables
visible to a hierarchy and, as such, they should be used as little as
possible.  When implementing a singleton, for example, what you *really*
want is a uniqueInstance class-instance variable.

The name of class variables is all wrong.  I would call them "class pool
variables", or "class global variables", and I would say that "class-instance
variables" are the "real" class variables.

Class variables should be used mostly to include constant objects
(as was the case for pool dictionaries before they became a more general
"import namespace" mechanism), so, it makes sense to me to use a syntax
like this to define them:

    Class name: Character extends: Object [
        | value |
        ...

        Cr := Character value: 13.
        Lf := Character value: 10.
        Table := Character initializeConversionTable
    ]

This is similar to how you would write these initializations in a
Character class>>#initialize method.

In addition, it's not necessary that the class scope be a nested scope
(if this bothers you, please tell me).  You can perfectly well write:

    Class ref: Character class [
        del [ ^Character value: 127 ]
    ]

(I hope that, with "ref:" as the keyword, it is clearer that the correct
precedence is "Class ref: (Character class)" and not "(Class ref: Character)
class".  If you wish to suggest an alternate keyword, again, please do).

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Sorry, but you've got me confused.  What you've said above is the exact
> opposite of what I understand by "scripting".  Scripting is an
> interpreted dynamic on-the-fly kind of thing.

Scripting is also about lots of libraries that are easy to use and easy
to write.  Which means, having good tools for documentation, cross
referencing, and so on.  Such tools need to understand the structure
the program, they cannot just rely on self-discipline of the library
writers.

So yes, for the user that does not need to create many classes, some
small refinement of the bang syntax we all learned to love and hate
is okay.  But this project is *not* about that.  Small refinements of
the bang syntax are easy enough that I hope, will only have consensus
in the mailing list when we get round to the mailing list.

> In fact, I think there shouldn't
> be.  I understand why there's a need for something better than
> #methodsFor:, but the rest is just way out there, more useful for
> compiler writers than language users.

s/compiler/tool/ and we agree.  But without tool writers, there are
no tools for the language users.

For interactive usage, fully agreed.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
> If so, there is a good reason, and it is that class variables
> are misused 99% of the time.  Class variables are *global* variables
> visible to a hierarchy and, as such, they should be used as little as
> possible.  When implementing a singleton, for example, what you *really*
> want is a uniqueInstance class-instance variable.

Apparently the writers of our class library didn't understand this.

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Mike Anderson wrote:
> Paolo Bonzini wrote:
>> If so, there is a good reason, and it is that class variables
>> are misused 99% of the time.  Class variables are *global* variables
>> visible to a hierarchy and, as such, they should be used as little as
>> possible.  When implementing a singleton, for example, what you *really*
>> want is a uniqueInstance class-instance variable.
>
> Apparently the writers of our class library didn't understand this.

You mean GNU Smalltalk's class library?  Might be.  :-)

If the new syntax teaches us better practices, that can only do
well.

Regarding the singleton example, consider what happens if you have
a hierarchy of singletons and put the "uniqueInstance" class method
in the topmost class.  With class variables, it doesn't work.  With
class-instance variables, it does.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
Your argument does not invalidate my concern or rather it does not
justify taking away something that users appreciate for something that
tool writers like better.

Smalltalk provides sufficient documentation features that can easily be
extended;  if you choose not to use them you should not expect your code
to make much sense.  I believe that's what we fundamentally disagree on.
   A library writer isn't a library writer if he doesn't document and
doesn't write self-documenting code, whatever the language.  Put too
much emphasis (though I haven't heard of languages being modified for
reasons like this one) on tools and you'll have a language that will be
barely usable *without* them.

Slightly off-topic stuff follows.

I am here because I liked what I saw when I started playing around with
Smalltalk.  GNU Smalltalk is the only variant I've ever used and I
haven't considered using others because most of them seemed to be huge
custom graphical environments and weren't free software.  I looked at
GNU Smalltalk and thought "hey, this is something I'd want to use and
spend my time on improving".  I already mentioned (in the other comment)
things that I see as needing attention, which is documentation
(including the web site) and package management, and I'm willing to help
as much as I can because I see potential (for the lack of a better word)
in this language and in this variant of the language in particular.  The
language that it's being turned into is not that language.

(By the way, I can't be the guy who just hates everything new because
two months ago I literally didn't know what Smalltalk looks like.)

Best,
Jānis


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Smalltalk provides sufficient documentation features that can easily be
> extended;  if you choose not to use them you should not expect your code
> to make much sense.  I believe that's what we fundamentally disagree on.
> A library writer isn't a library writer if he doesn't document and
> doesn't write self-documenting code, whatever the language.  Put too
> much emphasis (though I haven't heard of languages being modified for
> reasons like this one)

Because no other language worked so well for years without tools (Smalltalk
barely has tools).  Most other languages either have a syntax that is not
a revolution at all (including Python, Ruby) or have no tools (Tcl comes
to mind, and it fell out of favor compared to the other two or even Lua).

Smalltalk bang syntax is a revolution.  It describes executable code (not
in the sense of "interpretable", as is Ruby or Python syntax) that
reconstructs a working environment.  It's great for some things (i.e.
reconstructing changes to an image after a crash, in IDEs like Squeak
or VisualWorks), it's bad for (almost all) others.

In particular, it's bad for:

1) tools.  We can make a syntax that is as
good as Python or Ruby's (and as non-revolutionary as those) and still
pretty close to Smalltalk.

2) everyday scripting.  You need a more dynamic thing, where every
statement is executed oon the fly and there's no need to declare
temporaries.  I learnt this from your examples in this thread and
I will implement it -- but it's orthogonal to the verbosity and tools
problems.

> on tools and you'll have a language that will be
> barely usable *without* them.

This is a bold statement, and I want to understand more of it.
How can you be sure?  Do you consider Ruby or Python barely usable
without tools?

> I already mentioned (in the other comment)
> things that I see as needing attention, which is documentation
> (including the web site) and package management

Fully agreed.  If time permits, package management may also
make it into the next release (I'm sticking to one-year releases
usually).  If you have ideas for improvements and maybe time to
implement them, we can only be happy about that.

> The language that it's being turned into is not that language.

This is also a bold statement.  Please expand on it, I'm genuinely
interested (they even deserved a subject change!).

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
>> Put too much emphasis on tools and you'll have a language that will
>> be barely usable *without* them.
>
> This is a bold statement, and I want to understand more of it.
> How can you be sure?  Do you consider Ruby or Python barely usable
> without tools?

Heh.  It's a bold statement, I agree.  No, I do not consider Python to
be useless without tools.  (I have about 5 minutes of experience with
Ruby, so actually I can't say much about it.)  In fact, interestingly
enough, I just realized that the only tools that I use with Python is my
text editor and Python itself.  I feel that a language such as Python
was primarily designed to be a language that the authors themselves
would want to use.  I don't think they were guided by how easy it will
be for tool writers to do their job, except for as far as the parser and
compiler is concerned.  If a system is designed with knowledge about
itself and exposes that knowledge, every tool that needs such knowledge
can be implemented from within that system.  Which is why I don't really
need anything else than a text editor and Python.  Hell, I don't even
need the text editor.

>> The language that it's being turned into is not that language.
>
> This is also a bold statement.  Please expand on it, I'm genuinely
> interested (they even deserved a subject change!).
>

It's entirely my own opinion and it's based on one simple fact:  I
wouldn't use it.  I find that the changes you're proposing address some
of the things that I like most about Smalltalk (extreme simplicity, one
paradigm) and languages such as Python (the "scripting" aspect), and I
find that I don't like those changes.  If Smalltalk had been the
language you're trying to implement when I started taking interest in
it, I wouldn't even bother learning it.  In fact, I wouldn't have taken
interest in it in the first place!  And, naturally, that is why I don't
see potential in that language, but again it is my opinion.

Jānis


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>>> Put too much emphasis on tools and you'll have a language that will
>>> be barely usable *without* them.
>> This is a bold statement, and I want to understand more of it.
>> How can you be sure?  Do you consider Ruby or Python barely usable
>> without tools?
>
> Heh.  It's a bold statement, I agree.  No, I do not consider Python to
> be useless without tools.

Ok, so this gives me some confidence that you didn't mean the
proposed Smalltalk extension to be useless without tools.
Ironically, I consider current Smalltalks to be barely usable
without tools (browser), given the problems with the bang
syntax.  AFAIU, you consider the bang syntax amendable instead;
this may be the main disagreement, right?

> Which is why I don't really
> need anything else than a text editor and Python.  Hell, I don't even
> need the text editor.

I can tell you it's the same with Smalltalk -- both current and
proposed syntax.  But the productivity will improve a lot, I think.

Besides, it is just syntactic sugar, you can steer away from it
or you can try it.

>>> The language that it's being turned into is not that language.
>> This is also a bold statement.  Please expand on it, I'm genuinely
>> interested (they even deserved a subject change!).
>
> It's entirely my own opinion and it's based on one simple fact:  I
> wouldn't use it.  I find that the changes you're proposing address some
> of the things that I like most about Smalltalk (extreme simplicity, one
> paradigm)

Here is where I don't understand your point.  The syntax
doesn't add paradigms.  It only touches the most basic constructs
of Smalltalk, which are the ones that are used to structure a
program -- classes, methods, namespaces.  These changes surely don't
add as much complexity as there is in Python's syntax (iterators, for
example: if these enter the GNU Smalltalk class library, it will not
grow new keywords like "yield"; likewise for splicing).  

In fact, the class/class-instance variable example shows how the
new syntax emphasizes the duality between instance variables/methods
and class-instance variables/class methods, while the current bang
syntax only expresses this for the methods, and suggests a wrong
correspondence between instance and class variables.

If a syntax helps improving one's language usage, I find that a
good point in favor of it.

As far as scripting, your suggestions will not be implemented immediately
due to lack of time, but they are a prerequisite for the next release.

Please, tell me which points you disagree on.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
I've written some stuff about this below, I hope that'll make it clear.

I do not necessarily advocate the actions that take place under the hood
when, say, an exclamation point is encountered by the parser.  As far as
I'm concerned, due to Smalltalk's free-form syntax, statements need to
be terminated.  A period would be perfectly fine for that as well.  To
put it simple I am "against" the proposed modifications and not
necessarily "for" the current situation.

Smalltalk's paradigm is objects and messages.  Smalltalk's syntax is
basically "object message".  There are practically no exceptions to this
rule.  It's a one-to-one mapping from a paradigm to syntax;  the syntax
fully represents the language.  What I meant in my last reply is that
the proposed syntax violates or rather ignores that aspect.  Perhaps
what you really want is a language that looks like Smalltalk, but
doesn't have these "limitations" -- there's no sin in that.  Just don't
call it "Smalltalk".

Python's syntax is flawed and I recognize that.  It's only truly
marvellous property is the "indentation matters" rule.  To the point,
just because you can get something better than Python doesn't mean it
will be better than what you have right now.

> In fact, the class/class-instance variable example shows how the
> new syntax emphasizes the duality between instance variables/methods
> and class-instance variables/class methods, while the current bang
> syntax only expresses this for the methods, and suggests a wrong
> correspondence between instance and class variables.

I personally think the problem is that the commonly-used class
definition selector contains classVariableNames and not
classInstanceVariableNames.  (Or a shorter equivalent.)  Thus I don't
see it as a problem with the syntax...

> As far as scripting, your suggestions will not be implemented immediately
> due to lack of time, but they are a prerequisite for the next release.

Heh.  I do not expect anyone to immediately jump in on implementing them
and I'm entirely aware that they might not ever get implemented.  No
problem there.

Jānis


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> I've written some stuff about this below, I hope that'll make it clear.
>
> I do not necessarily advocate the actions that take place under the hood
> when, say, an exclamation point is encountered by the parser.  As far as
> I'm concerned, due to Smalltalk's free-form syntax, statements need to
> be terminated.  A period would be perfectly fine for that as well.  To
> put it simple I am "against" the proposed modifications and not
> necessarily "for" the current situation.

So you would be in favor of something like

    Object subclass: #Boolean.
    Boolean instanceVariableNames: 'blah blah'.
    Boolean poolDictionaries: 'ImportSomeNamespace'.

    Boolean methods [
        isIdentity [ <category: 'testing'> ^true ]
        isImmediate [ <category: 'testing'> ^true ]
    ].

etc.?  I'm pretty sure something like this will be available "for
free" once GNU Smalltalk's new syntax is available.

So, personally I'm in favor of a more definite notion of scoping,
like

    Object subclass: #Boolean [
        | blah blah |
        <import: ImportSomeNamespace>

        isIdentity [ <category: 'testing'> ^true ]
        isImmediate [ <category: 'testing'> ^true ]
    ]

but I think both camps can be accomodated.  Then, time can
tell not really "who was right", but more "whose proposal
has been more successful".


>> As far as scripting, your suggestions will not be implemented immediately
>> due to lack of time, but they are a prerequisite for the next release.
>
> Heh.  I do not expect anyone to immediately jump in on implementing them
> and I'm entirely aware that they might not ever get implemented.  No
> problem there.

I meant to say that you *can* expect them to be implemented. ;-)
In fact, I consider your contribution to this thread to have been
extremely useful and constructive.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
Yes, that's what I'd prefer, for the most part.  "Boolean methods [" or
something to that extent is fine, but I'm not happy about further use of
brackets.  My complaint is that they reduce readability and are a pain
to manage.  As far as I understand a method definition is introduced by
a message pattern and terminated either by some special character or a
new message pattern.  This is where I can see exclamation point being
used, the same way it's currently used after #methodsFor: to terminate a
method definition.  And as far as visual indication of where a method
definitions starts and ends is concerned, indentation does the same job
without getting in the way.  (Because most of the time you'd use
indentation anyway.)  So those definitions would look like:

    Boolean methods [
        isIdentity
            ^true!

        isImmediate
            ^true!
    ]

Or on a single line if you prefer.  I'm still not happy about <category:
''> and family either, but I suppose I can live with that.

>>> As far as scripting, your suggestions will not be implemented immediately
>>> due to lack of time, but they are a prerequisite for the next release.
>> Heh.  I do not expect anyone to immediately jump in on implementing them
>> and I'm entirely aware that they might not ever get implemented.  No
>> problem there.
>
> I meant to say that you *can* expect them to be implemented. ;-)
> In fact, I consider your contribution to this thread to have been
> extremely useful and constructive.

Oh, that's good to read.  And thanks!

Best,
Jānis


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk