criticism of the new syntax

Hi Paolo and all,
It is great to see the venerable gnu-smalltalk getting a new face lift and
many exciting new features. However, I have to say that the new syntax leave
much to be desired. Granted the old syntax has some problems (too much '!')
but the new syntax just introduce some problems of it's own:
1, too much indention. I don't think the java-ish whole-class-as-a-block
syntax is a very good idea for all but the trival classes. Indention doesn't
really help for long blocks.
2, Now I need to have a category pragma for all the 3 line long method? With
the old syntax casual smalltalker like me don't need to know about pragmas at
all; besides I think pragmas look ugly by themselves.
I understand the appeal of the new syntax for all the java/c# pogrammers out
there; however I myself dig c, objc and c++ so I like to see something like
this:
Object subclass: Person [
    | name age |
]
Person class >> category: 'instance creation' [
        new [
                ...
        ]
...
]
Person >> category: 'printing' [
        printOn: aStream [
                ...
        ]
...
]
Person >> radomLooseMethod [
        ...
]
I have to stick with the old syntax for now. Please tell me the old syntax is
not going away.
Best regards
Derek  


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

Derek Zhou wrote:
> I have to stick with the old syntax for now. Please tell me the old syntax is
> not going away.

Old syntax remains with Compiler package loaded.  It also remains (with
some minor incompatibilities) in the core.  You can also define your own
syntax by writing a parser and altering Stream>>#fileIn and
Behavior>>#evaluatorClass.

Incidentally, Presource will continue to support all syntaxes that also
work with Compiler.

--
Our last-ditch plan is to change the forums into a podcast, then send
RSS feeds into the blogosphere so our users can further debate the
legality of mashups amongst this month's 20 'sexiest' gadgets.
         --Richard "Lowtax" Kyanka


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

First of all, thanks for the constructive criticism.  Some changes to
the syntax will definitely go in post 3.0 after we get user feedback, so
your message is definitely valuable.

> 1, too much indention. I don't think the java-ish whole-class-as-a-block
> syntax is a very good idea for all but the trival classes. Indention doesn't
> really help for long blocks.

I agree, but on the other hand editors are much better at finding
headings for indented scopes, and indented scopes support features such
as folding (which I don't use, but other people do).

Also, most languages (Java, Python, Ruby) are doing
whole-class-as-a-block, and the main objective of the new syntax was to
make the language reasonable to people familiar with those languages.
  > 2, Now I need to have a category pragma for all the 3 line long
method? With
> the old syntax casual smalltalker like me don't need to know about pragmas at
> all; besides I think pragmas look ugly by themselves.

I think most newcomers won't use the category pragmas at all.  I still
hope that one day the file-based syntax will be editable with a browser.

> Person >> category: 'printing' [
> printOn: aStream [
> ...
> ]
> ...
> ]

Yes, that's nice.  Unfortunately, I thought of it as well as of permitting

Person >> new [
     <category: '...'>
]

at toplevel, but they would not be easy to implement in the current
parser.  However, based on you proposal, something I could do pretty
easily is this:

     Object subclass: Person [
         | name age |

         Person class >> category: 'instance creation' [
            new [
                    ...
            ]
             ...
         ]
     ]

What do you think?

Paolo


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

On Monday 17 December 2007 01:01:10 am Paolo Bonzini wrote:
> Also, most languages (Java, Python, Ruby) are doing
> whole-class-as-a-block, and the main objective of the new syntax was to
> make the language reasonable to people familiar with those languages.
I agree; but I still think we should not _enforce_ whole-class-as-a-block like
java does. It would seriously limit the freedom in organizing source code.  
> Yes, that's nice.  Unfortunately, I thought of it as well as of permitting
>
> Person >> new [
>      <category: '...'>
> ]
So loose methods like this are permitted? Come to think of it, there must be a
way to define additional methods outside the main class definition block;
otherwise one of the main strength (being able to add methods without
subclassing) of smalltalk just disappears :)   But this is still whole-class-as-a-block, and it even add another layer of
indention. What I really want is being able to break up a large class into
multiple files, each one defining one of more categories.  
>
> Paolo

Derek


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

On Mon, 2007-12-17 at 23:13 -0800, Derek Zhou wrote:
> On Monday 17 December 2007 01:01:10 am Paolo Bonzini wrote:
> > Also, most languages (Java, Python, Ruby) are doing
> > whole-class-as-a-block, and the main objective of the new syntax was to
> > make the language reasonable to people familiar with those languages.
> I agree; but I still think we should not _enforce_ whole-class-as-a-block like
> java does. It would seriously limit the freedom in organizing source code.  

MyClass extend [
    "more methods!"
]

This is already in there.

> &c

--
Our last-ditch plan is to change the forums into a podcast, then send
RSS feeds into the blogosphere so our users can further debate the
legality of mashups amongst this month's 20 'sexiest' gadgets.
        --Richard "Lowtax" Kyanka

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

>> Also, most languages (Java, Python, Ruby) are doing
>> whole-class-as-a-block, and the main objective of the new syntax was to
>> make the language reasonable to people familiar with those languages.
>
> I agree; but I still think we should not _enforce_ whole-class-as-a-block like
> java does. It would seriously limit the freedom in organizing source code.  

We do not enforce it; loose methods are permitted of course.  Loose
methods however do not have one level less of indentation.

>> Person >> new [
>>      <category: '...'>
>> ]
>
> So loose methods like this are permitted? Come to think of it, there must be a
> way to define additional methods outside the main class definition block;
> otherwise one of the main strength (being able to add methods without
> subclassing) of smalltalk just disappears :)  

Loose methods are done with "CLASS extend [ ... ]" or "CLASS class
extend [ ... ]".  The syntax I hinted that above was thought of, but as
I said it would be hard to implement it in the current parser.  Maybe
for 3.1.

> But this is still whole-class-as-a-block, and it even add another layer of
> indention. What I really want is being able to break up a large class into
> multiple files, each one defining one of more categories.  

You can do that, even though each will be "very indented" :-P

But in the first place, why do you want large classes? :-)

Paolo


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

I think I will never get used to lists that don't reply to themselves :)

---------- Forwarded message ----------
From: Damien Pollet <[hidden email]>
Date: 17 Dec 2007 13:57
Subject: Re: [Help-smalltalk] criticism of the new syntax
To: [hidden email]


On 17/12/2007, Paolo Bonzini <[hidden email]> wrote:
repeating person and using category: feels redundant... what about

Object subclass: Person [
    | name age |
    class @ 'one-shot category' >> nobody [ ^ NullPerson uniqueInstance ]
    class @ 'instance creation' [
        named: x birthdate: d [...]
        named: x [...]
    ]
    @ 'accessing' [
        name: aName
etc
--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org


--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org


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

On Tuesday 18 December 2007 12:06:59 am Stephen Compall wrote:
>
> MyClass extend [
>     "more methods!"
> ]
>
> This is already in there.
Cool, how about one small step further, like:
MyClass category: 'new category' extend [
    "more methods!"
]
Or reusing the existing syntax:
MyClass extend [
        <category: 'new category'>
    "more methods!"
]
So the category pragma apply to all methods in the same block unless there is
another pragma inside the method to overwrite.
Derek



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

Derek Zhou wrote:
Yes, even without the "extend" keyword, that's feasible.

> Or reusing the existing syntax:
> MyClass extend [
> <category: 'new category'>
>     "more methods!"
> ]
> So the category pragma apply to all methods in the same block unless there is
> another pragma inside the method to overwrite.

No, that would change the category of the class.

Paolo


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

 -------------- Original message ----------------------
From: Paolo Bonzini <[hidden email]>
So, if I want to break down a large class into multiple files with each file containing one category, what should I write?
Object subclass: MyClass [
    | var1 var2|
]

MyClass class >> category: 'instance creation' [
    new [...]
]

MyClass category: 'category1' [
    method1 []
]

MyClass category: 'category2' [
    method2 []
]

What does the keyword "extend" do?

Derek


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

>>> MyClass category: 'new category' extend [
>>>     "more methods!"
>>> ]
>> Yes, even without the "extend" keyword, that's feasible.
>
> So, if I want to break down a large class into multiple files with each file containing one category, what should I write?

So far, you need to use

MyClass extend [
]

and write the category manually in each method.  Regarding

MyClass category: '...' [
]

I said "it's feasible", and I'll implement it.  But not now, it's too
late in the release cycle.  I'm very sorry for this, it is a valuable
addition.

> What does the keyword "extend" do?

It basically says that instance variables declared with "|a b c|" should
be *added* to the existing one, instead of replacing them.

Paolo


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

Thanks for clearing the issue up. I am looking forward for further enhancement to the syntax.
Derek


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

On 20.12.2007 15:11:26, Paolo Bonzini wrote:
        Hi!
It's better to be named methodsCategory: or methodsWithCategory:

BR. Ildar
--
Ildar  Mulyukov,  free SW designer/programmer
================================================
email: [hidden email]
home: http://tuganger.narod.ru/
ALT Linux Sisyphus
================================================


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

On Fri, 2007-12-21 at 10:20 +0600, Ildar Mulyukov wrote:
> It's better to be named methodsCategory: or methodsWithCategory:

Even better would be to look at the code for STInST.GSTParser and work
out a way that the kinds of top-level blocks can be extended, perhaps
based on message name, as they all parse as RBVariableNodes or
RBMessageNodes.

That way you could experiment with different kinds of top-level blocks
without altering the core or even GNU Smalltalk at all.

I have thought about how best to provide this modularly but haven't come
up with anything good.

--
Our last-ditch plan is to change the forums into a podcast, then send
RSS feeds into the blogosphere so our users can further debate the
legality of mashups amongst this month's 20 'sexiest' gadgets.
        --Richard "Lowtax" Kyanka

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