Re: Smalltalk scripting syntax)

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.
> 
> 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?

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.

>>>> 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).  

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
help-smalltalkgnu.org

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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk