Re: Smalltalk scripting syntax

Paolo Bonzini wrote:
> The exclamation point is going to remain exactly for
interactive
> sessions.  Remember that -- anyway -- what's badly
needed is, as Mike
> pointed out earlier in this thread, nothing more than
an easily parsable 
> syntax that denotes the *structure* of the program
rather than how to
> reconstruct it.
> 
> That's the main reason why I am suspicious of syntaxes
that are
> pure Smalltalk.  It looks to me, though I might be
wrong, that
> having "Object subclass: #MyClass!" is as bad
as having
> "Object methodsFor: 'abc'!".  If somebody
just adds a new method
> like
> 
>     refine
>         "Define a subclass of self, with the same
name, in the current
>          namespace."
>         self environment = Namespace current ifTrue: [
self halt ].
>         self subclass: self name!
> 
> how can you expect things to be parsed correctly when
one writes:
> 
>     Set refine!
>     Set comment: 'not your ordinary set'!
> 

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.  What I see
above is a
static resolve-all-symbols-at-compile-time kind of thing,
which
incidentally reminds me of a certain language.  I don't
think there is
difference between "denoting structure" and
"reconstruction" of a
program in a scripting environment.  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.  Python's a scripting
language:

    >>> f = lambda a, b: a + b + c
    >>> f(3, 4)
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
      File "<stdin>", line 1, in
<lambda>
    NameError: global name 'c' is not defined
    >>> c = 5
    >>> f(3, 4)
    12
    >>>

Note how a reference to an undefined variable is an
execution-time
exception.  That's the direction I'd like to see GNU
Smalltalk heading.

Best,
Jānis


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

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.

>     >>> f = lambda a, b: a + b + c
>     >>> f(3, 4)
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>       File "<stdin>", line 1, in
<lambda>
>     NameError: global name 'c' is not defined
>     >>> c = 5
>     >>> f(3, 4)
>     12
>     >>>
> 
> Note how a reference to an undefined variable is an
execution-time
> exception.  That's the direction I'd like to see GNU
Smalltalk heading.

For interactive usage, fully agreed.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

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