Class declaration and parser structure

> 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'

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

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

>>> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>