Class declaration and parser structure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Class declaration and parser structure

Damien Pollet
I've been looking at how to declare classes and traits with a proper
syntax (currently it has to be done in evaluation blocks, i.e. between
[]).

I'm going for something like the current trait declaration syntax:

        Class named: #Foo
                superclass: #Object
                instanceVariables: #(a b c)
                classVariables: #()
                category: 'Bar'

or, for a trait:

        Trait named: #TFoo
                uses: {}
                category: 'Bar'

The explicit Class or Trait is a strong point, as it will allow to
declare other kinds of things than classes and traits in the future.
I'm open to feedback and suggestions for wording (e.g. extends:
instead of superclass:) or variants, like #named:category: (reasonable
defaults), or Class named: Foo -> SuperFoo (capitalized identifiers
instead of symbols for class names, and arrow to denote inheritance).

Basically a declaration is a single keyword message, and will result
in that message being evaluated in the image, but there are some
validations. I use <coralDeclaration> pragmas to declare which methods
in the image can be used as a declaration in a coral script, and you
can't pass anything in the arguments. Literals are OK of course, but
for trait composition I need to authorize curly arrays and binary
messages as well. Still this limits the syntax to a small subset of
Smalltalk.

Now, for problems and things to do:

• There is no separate AST building / semantic analysis phase. Methods
are compiled on the fly, blocks executed in the middle of parsing,
etc. It's probably possible to kludge my way around that but it's evil
and hinders testability.

• I'm starting to feel like everything I start is a rabbit hole that
leads to rewriting half of the system, so a some help establishing a
priority list would be nice…

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

_______________________________________________
Pharo-coral mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Class declaration and parser structure

Stéphane Ducasse

On Mar 28, 2012, at 5:54 PM, Damien Pollet wrote:

> I've been looking at how to declare classes and traits with a proper
> syntax (currently it has to be done in evaluation blocks, i.e. between
> []).
>
> I'm going for something like the current trait declaration syntax:
>
> Class named: #Foo
> superclass: #Object
> instanceVariables: #(a b c)
> classVariables: #()
> category: 'Bar'
>
> or, for a trait:
>
> Trait named: #TFoo
> uses: {}
> category: 'Bar'

Thanks for pushing that!

> The explicit Class or Trait is a strong point, as it will allow to
> declare other kinds of things than classes and traits in the future.
> I'm open to feedback and suggestions for wording (e.g. extends:
> instead of superclass:)

I really prefer superclass:
because extensions is overloaded in Smalltalk

> or variants, like #named:category: (reasonable
> defaults), or Class named: Foo -> SuperFoo (capitalized identifiers
> instead of symbols for class names, and arrow to denote inheritance).

I like with reasonable default.
Foo -> SuperFoo is strange because it will not be a name.


> Basically a declaration is a single keyword message, and will result
> in that message being evaluated in the image, but there are some
> validations. I use <coralDeclaration> pragmas to declare which methods
> in the image can be used as a declaration in a coral script, and you
> can't pass anything in the arguments. Literals are OK of course, but
> for trait composition I need to authorize curly arrays and binary
> messages as well. Still this limits the syntax to a small subset of
> Smalltalk.
>
> Now, for problems and things to do:
>
> • There is no separate AST building / semantic analysis phase. Methods
> are compiled on the fly, blocks executed in the middle of parsing,
> etc. It's probably possible to kludge my way around that but it's evil
> and hinders testability.

Build an ast but is it necessary now?
Focus on what make the system working.

> • I'm starting to feel like everything I start is a rabbit hole that
> leads to rewriting half of the system, so a some help establishing a
> priority list would be nice…

Be pragmatic.
Make it work make it work make it work make it used
make it nice after!


>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
>
> _______________________________________________
> Pharo-coral mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral


_______________________________________________
Pharo-coral mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Class declaration and parser structure

abergel
>> I'm going for something like the current trait declaration syntax:
>>
>> Class named: #Foo
>> superclass: #Object
>> instanceVariables: #(a b c)
>> classVariables: #()
>> category: 'Bar'

We should support the variation, if there is no IV or no classVariable. For example:

Object subclass: #Foo
Object subclass: #Foo ivs: 'a b c'
Object subclass: #Foo ivs: 'a b c' category: 'MyCategory'

Alexandre





>>
>> or, for a trait:
>>
>> Trait named: #TFoo
>> uses: {}
>> category: 'Bar'
>
> Thanks for pushing that!
>
>> The explicit Class or Trait is a strong point, as it will allow to
>> declare other kinds of things than classes and traits in the future.
>> I'm open to feedback and suggestions for wording (e.g. extends:
>> instead of superclass:)
>
> I really prefer superclass:
> because extensions is overloaded in Smalltalk
>
>> or variants, like #named:category: (reasonable
>> defaults), or Class named: Foo -> SuperFoo (capitalized identifiers
>> instead of symbols for class names, and arrow to denote inheritance).
>
> I like with reasonable default.
> Foo -> SuperFoo is strange because it will not be a name.
>
>
>> Basically a declaration is a single keyword message, and will result
>> in that message being evaluated in the image, but there are some
>> validations. I use <coralDeclaration> pragmas to declare which methods
>> in the image can be used as a declaration in a coral script, and you
>> can't pass anything in the arguments. Literals are OK of course, but
>> for trait composition I need to authorize curly arrays and binary
>> messages as well. Still this limits the syntax to a small subset of
>> Smalltalk.
>>
>> Now, for problems and things to do:
>>
>> • There is no separate AST building / semantic analysis phase. Methods
>> are compiled on the fly, blocks executed in the middle of parsing,
>> etc. It's probably possible to kludge my way around that but it's evil
>> and hinders testability.
>
> Build an ast but is it necessary now?
> Focus on what make the system working.
>
>> • I'm starting to feel like everything I start is a rabbit hole that
>> leads to rewriting half of the system, so a some help establishing a
>> priority list would be nice…
>
> Be pragmatic.
> Make it work make it work make it work make it used
> make it nice after!
>
>
>>
>> --
>> Damien Pollet
>> type less, do more [ | ] http://people.untyped.org/damien.pollet
>>
>> _______________________________________________
>> Pharo-coral mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral
>
>
> _______________________________________________
> Pharo-coral mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-coral mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Class declaration and parser structure

Stéphane Ducasse
alex

why damien proposed

Class

Trait

is that we want to be able to distinguish an expression from a smalltalk expression.

Damien I was thinking that the following expressions:

> Object subclass: #Foo
> Object subclass: #Foo ivs: 'a b c'
> Object subclass: #Foo ivs: 'a b c' category: 'MyCategory'

could also be a class construction because it contains the selector subclass:, subclass:ivs ….

BTW
        vars: #(a b c)
        classVars: #L:KJJKKLJ

would be better than instanceVariables:

stef


>>> I'm going for something like the current trait declaration syntax:
>>>
>>> Class named: #Foo
>>> superclass: #Object
>>> instanceVariables: #(a b c)
>>> classVariables: #()
>>> category: 'Bar'
>
> We should support the variation, if there is no IV or no classVariable. For example:
>
> Object subclass: #Foo
> Object subclass: #Foo ivs: 'a b c'
> Object subclass: #Foo ivs: 'a b c' category: 'MyCategory'
>
> Alexandre
>
>
>
>
>
>>>
>>> or, for a trait:
>>>
>>> Trait named: #TFoo
>>> uses: {}
>>> category: 'Bar'
>>
>> Thanks for pushing that!
>>
>>> The explicit Class or Trait is a strong point, as it will allow to
>>> declare other kinds of things than classes and traits in the future.
>>> I'm open to feedback and suggestions for wording (e.g. extends:
>>> instead of superclass:)
>>
>> I really prefer superclass:
>> because extensions is overloaded in Smalltalk
>>
>>> or variants, like #named:category: (reasonable
>>> defaults), or Class named: Foo -> SuperFoo (capitalized identifiers
>>> instead of symbols for class names, and arrow to denote inheritance).
>>
>> I like with reasonable default.
>> Foo -> SuperFoo is strange because it will not be a name.
>>
>>
>>> Basically a declaration is a single keyword message, and will result
>>> in that message being evaluated in the image, but there are some
>>> validations. I use <coralDeclaration> pragmas to declare which methods
>>> in the image can be used as a declaration in a coral script, and you
>>> can't pass anything in the arguments. Literals are OK of course, but
>>> for trait composition I need to authorize curly arrays and binary
>>> messages as well. Still this limits the syntax to a small subset of
>>> Smalltalk.
>>>
>>> Now, for problems and things to do:
>>>
>>> • There is no separate AST building / semantic analysis phase. Methods
>>> are compiled on the fly, blocks executed in the middle of parsing,
>>> etc. It's probably possible to kludge my way around that but it's evil
>>> and hinders testability.
>>
>> Build an ast but is it necessary now?
>> Focus on what make the system working.
>>
>>> • I'm starting to feel like everything I start is a rabbit hole that
>>> leads to rewriting half of the system, so a some help establishing a
>>> priority list would be nice…
>>
>> Be pragmatic.
>> Make it work make it work make it work make it used
>> make it nice after!
>>
>>
>>>
>>> --
>>> Damien Pollet
>>> type less, do more [ | ] http://people.untyped.org/damien.pollet
>>>
>>> _______________________________________________
>>> Pharo-coral mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral
>>
>>
>> _______________________________________________
>> Pharo-coral mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>


_______________________________________________
Pharo-coral mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Class declaration and parser structure

Damien Pollet
On 28 March 2012 21:19, Stéphane Ducasse <[hidden email]> wrote:
> is that we want to be able to distinguish an expression from a smalltalk expression.

Well in fact they are out of [] so that's easy to see.

Class named: #Foo category: 'Bar'

[ Transcript show: 'baz' ]

> Damien I was thinking that the following expressions:
>
>> Object subclass: #Foo
>> Object subclass: #Foo ivs: 'a b c'
>> Object subclass: #Foo ivs: 'a b c' category: 'MyCategory'
>
> could also be a class construction because it contains the selector subclass:, subclass:ivs ….

True… either I make a list of the standard ones, or I add a coral
pragma to detect them.

> BTW
>        vars: #(a b c)
>        classVars: #L:KJJKKLJ
>
> would be better than instanceVariables:

Indeed. What will be clumsy is class-side traits…

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

_______________________________________________
Pharo-coral mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral
Loading...