Differences Compiler vs. OpalCompiler (or parser)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Differences Compiler vs. OpalCompiler (or parser)

Nicolai Hess-3-2
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?



From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.


Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Eliot Miranda-2
Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> wrote:
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.  The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
^self primitiveFailed

instead of 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>
^self primitiveFailed


The issues are class reference, class redefinition, class removal etc.  I guess we could extend the pragma syntax to allow class references but there's a lot of impact.  I would prefer if we keep things restricted.  There's nothing to stop one using a symbol and mapping it to a class name, e.g.


GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

Also, I *hate* this style of pragma.  Why not

GTDummyExamples class
d: anInteger
    <gtExampleLabel: 'Dummy #d:, depends #c:'
     description: 'should raise an exception as the argument is not anInteger'
     depends: #c:
     raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

?

That's how the system is designed to be used.  Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.





--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Nicolai Hess-3-2


2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> wrote:
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.  The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
^self primitiveFailed

instead of 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>
^self primitiveFailed


The issues are class reference, class redefinition, class removal etc.  I guess we could extend the pragma syntax to allow class references but there's a lot of impact.  I would prefer if we keep things restricted.  There's nothing to stop one using a symbol and mapping it to a class name, e.g.


GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

Thanks eliot

Yes, we have this code too, I think, using the global var instead of a symbol happened by accident.

@andrei (and stefan?) can you check the GTDummyExamples methods
and replace classes with symbol names.

After this is removed I will change the parser to notify about this.

 

Also, I *hate* this style of pragma.  Why not

GTDummyExamples class
d: anInteger
    <gtExampleLabel: 'Dummy #d:, depends #c:'
     description: 'should raise an exception as the argument is not anInteger'
     depends: #c:
     raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

?

no idea.

 

That's how the system is designed to be used.  Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.





--
_,,,^..^,,,_
best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Marcus Denker-4
In reply to this post by Nicolai Hess-3-2

On 20 Nov 2015, at 22:37, Nicolai Hess <[hidden email]> wrote:

GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?


it actually is compiled as a literal… maybe the idea was that it follows how literal arrays work? #(thisisasymbol).
But yes, it it confusing and should be changed.



From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ?

We just use RBParser (or started with RBParser). I think it is intended.

Do we want to keep it?


Yes, I actually like it.

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.

I would say that we change it to be like the old and change set one user.

Marcus


Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Nicolai Hess-3-2


2015-12-03 16:59 GMT+01:00 Marcus Denker <[hidden email]>:

On 20 Nov 2015, at 22:37, Nicolai Hess <[hidden email]> wrote:

GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?


it actually is compiled as a literal… maybe the idea was that it follows how literal arrays work? #(thisisasymbol).
But yes, it it confusing and should be changed.



From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ?

We just use RBParser (or started with RBParser). I think it is intended.

Do we want to keep it?


Yes, I actually like it.

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.

I would say that we change it to be like the old and change set one user.

Marcus




OK

Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Andrei Chis
In reply to this post by Nicolai Hess-3-2


On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <[hidden email]> wrote:


2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> wrote:
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.  The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
^self primitiveFailed

instead of 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>
^self primitiveFailed


The issues are class reference, class redefinition, class removal etc.  I guess we could extend the pragma syntax to allow class references but there's a lot of impact.  I would prefer if we keep things restricted.  There's nothing to stop one using a symbol and mapping it to a class name, e.g.


GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

Thanks eliot

Yes, we have this code too, I think, using the global var instead of a symbol happened by accident.

@andrei (and stefan?) can you check the GTDummyExamples methods
and replace classes with symbol names.

After this is removed I will change the parser to notify about this.

I updated the pragmas to use symbols.

Cheers,
Andrei
 

 

Also, I *hate* this style of pragma.  Why not

GTDummyExamples class
d: anInteger
    <gtExampleLabel: 'Dummy #d:, depends #c:'
     description: 'should raise an exception as the argument is not anInteger'
     depends: #c:
     raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

?

no idea.

 

That's how the system is designed to be used.  Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Nicolai Hess-3-2


2015-12-04 20:29 GMT+01:00 Andrei Chis <[hidden email]>:


On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <[hidden email]> wrote:


2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> wrote:
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.  The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
^self primitiveFailed

instead of 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>
^self primitiveFailed


The issues are class reference, class redefinition, class removal etc.  I guess we could extend the pragma syntax to allow class references but there's a lot of impact.  I would prefer if we keep things restricted.  There's nothing to stop one using a symbol and mapping it to a class name, e.g.


GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

Thanks eliot

Yes, we have this code too, I think, using the global var instead of a symbol happened by accident.

@andrei (and stefan?) can you check the GTDummyExamples methods
and replace classes with symbol names.

After this is removed I will change the parser to notify about this.

I updated the pragmas to use symbols.

Thanks!
 

Cheers,
Andrei
 

 

Also, I *hate* this style of pragma.  Why not

GTDummyExamples class
d: anInteger
    <gtExampleLabel: 'Dummy #d:, depends #c:'
     description: 'should raise an exception as the argument is not anInteger'
     depends: #c:
     raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

?

no idea.

 

That's how the system is designed to be used.  Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.





--
_,,,^..^,,,_
best, Eliot



Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Eliot Miranda-2
In reply to this post by Andrei Chis
Hi Andrei,

On Dec 4, 2015, at 11:29 AM, Andrei Chis <[hidden email]> wrote:



On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <[hidden email]> wrote:


2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> wrote:
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.  The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
^self primitiveFailed

instead of 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>
^self primitiveFailed


The issues are class reference, class redefinition, class removal etc.  I guess we could extend the pragma syntax to allow class references but there's a lot of impact.  I would prefer if we keep things restricted.  There's nothing to stop one using a symbol and mapping it to a class name, e.g.


GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

Thanks eliot

Yes, we have this code too, I think, using the global var instead of a symbol happened by accident.

@andrei (and stefan?) can you check the GTDummyExamples methods
and replace classes with symbol names.

After this is removed I will change the parser to notify about this.

I updated the pragmas to use symbols.

They should be instances of Message, and the Message should hold onto the selector symbol and the argument.  There should also be a Pragma class with an api that supports access.  I'll gather up the relevant Squeak code (including tests) as a guide.  Ok?


Cheers,
Andrei
 

 

Also, I *hate* this style of pragma.  Why not

GTDummyExamples class
d: anInteger
    <gtExampleLabel: 'Dummy #d:, depends #c:'
     description: 'should raise an exception as the argument is not anInteger'
     depends: #c:
     raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

?

no idea.

 

That's how the system is designed to be used.  Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Nicolai Hess-3-2
In reply to this post by Eliot Miranda-2


2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> wrote:
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.  The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

But this means smalltalks scanner and parser needs some very special handling just for this pragma.

Scanner and/or parser explicit check for the name
<primitive: ....>
of the pragma of this error var.



 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
^self primitiveFailed

instead of 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>
^self primitiveFailed


The issues are class reference, class redefinition, class removal etc.  I guess we could extend the pragma syntax to allow class references but there's a lot of impact.  I would prefer if we keep things restricted.  There's nothing to stop one using a symbol and mapping it to a class name, e.g.


GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

Also, I *hate* this style of pragma.  Why not

GTDummyExamples class
d: anInteger
    <gtExampleLabel: 'Dummy #d:, depends #c:'
     description: 'should raise an exception as the argument is not anInteger'
     depends: #c:
     raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

?

That's how the system is designed to be used.  Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.





--
_,,,^..^,,,_
best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Eliot Miranda-2
Hi Nicolai,

On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <[hidden email]> wrote:


2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> wrote:
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.  The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

But this means smalltalks scanner and parser needs some very special handling just for this pragma.

It turns out to be not that bad.  because all the pragmas with error codes are associated with methods that have primitives (either a numbered primitive or a named primitive from a plaugin) the parser has to handle them specially anyway.  So here's what the code looks like in Squeak's compiler:

Parser class>>primitivePragmaSelectors
"Answer the selectors of pragmas that specify VM primitives.
Needed for compile and decomple."
^#(primitive:
primitive:error:
primitive:error:module:
primitive:module:
primitive:module:error:)

and then for each of those there's a method such as

Parser>>primitive: aNameString module: aModuleStringOrNil error: errorCodeVariableOrNil
"Create named primitive with optional error code."
(aNameString isString and: [ aModuleStringOrNil isNil or: [ aModuleStringOrNil isString ] ])
ifFalse: [ ^ self expected: 'Named primitive' ].
self allocateLiteral: (Array 
with: (aModuleStringOrNil isNil 
ifFalse: [ aModuleStringOrNil asSymbol ])
with: aNameString asSymbol
with: 0 with: 0).
errorCodeVariableOrNil ifNotNil:
[encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef].
^117

that answers the number of the primitive for the method.  So there are three methods that contain "errorCodeVariableOrNil ifNotNil: [encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]" to declare the error temp.  I think that's acceptable.  What do you think?


Scanner and/or parser explicit check for the name
<primitive: ....>
of the pragma of this error var.
 
Right, which is why it is simple to handle.


addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
^self primitiveFailed

instead of 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>
^self primitiveFailed


The issues are class reference, class redefinition, class removal etc.  I guess we could extend the pragma syntax to allow class references but there's a lot of impact.  I would prefer if we keep things restricted.  There's nothing to stop one using a symbol and mapping it to a class name, e.g.


GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

Also, I *hate* this style of pragma.  Why not

GTDummyExamples class
d: anInteger
    <gtExampleLabel: 'Dummy #d:, depends #c:'
     description: 'should raise an exception as the argument is not anInteger'
     depends: #c:
     raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

?

That's how the system is designed to be used.  Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.





--
_,,,^..^,,,_
best, Eliot




--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Nicolai Hess-3-2


2016-02-23 18:58 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <[hidden email]> wrote:


2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> wrote:
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.  The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

But this means smalltalks scanner and parser needs some very special handling just for this pragma.

It turns out to be not that bad.  because all the pragmas with error codes are associated with methods that have primitives (either a numbered primitive or a named primitive from a plaugin) the parser has to handle them specially anyway.  So here's what the code looks like in Squeak's compiler:

Parser class>>primitivePragmaSelectors
"Answer the selectors of pragmas that specify VM primitives.
Needed for compile and decomple."
^#(primitive:
primitive:error:
primitive:error:module:
primitive:module:
primitive:module:error:)

and then for each of those there's a method such as

Parser>>primitive: aNameString module: aModuleStringOrNil error: errorCodeVariableOrNil
"Create named primitive with optional error code."
(aNameString isString and: [ aModuleStringOrNil isNil or: [ aModuleStringOrNil isString ] ])
ifFalse: [ ^ self expected: 'Named primitive' ].
self allocateLiteral: (Array 
with: (aModuleStringOrNil isNil 
ifFalse: [ aModuleStringOrNil asSymbol ])
with: aNameString asSymbol
with: 0 with: 0).
errorCodeVariableOrNil ifNotNil:
[encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef].
^117

that answers the number of the primitive for the method.  So there are three methods that contain "errorCodeVariableOrNil ifNotNil: [encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]" to declare the error temp.  I think that's acceptable.  What do you think?

Hi Eliot,
Yes, thats fine, but this part of the parser is independent from how we use the pragma

For
 <primitive:'func' module:'lib' error:#errorCode>
or
 <primitive:'func' module:'lib' error:errorCode>
or
 <primitive:'func' module:'lib' error:'errorCode'>

the code generation is always the same.
But for getting

 <primitive:'func' module:'lib' error:errorCode>

as valid code, we have to use another special code in
Parser>>#pragmaLiteral: selectorSoFar

"This nicety allows one to supply a primitive error
     temp as a variable name, rather than a string."
    ((selectorSoFar beginsWith: 'primitive:')
     and: [(selectorSoFar endsWith: 'error:')
     and: [hereType == #word]]) ifTrue:
        [^self advance].

without this extra check,

 <primitive:'func' module:'lib' error:errorCode>

would raise an error
'Literal constant expected'

In pharo, opal compilers parser accepts both, errorCode without quote or # and class names.

 <primitive:'func' module:'lib' error:errorCode>  - valid
 <someotherpragma keyword:Point>  - valid too
If I change opals parser to not allow the second pragma, I need some special handlign
for the primitive:module:error: pragma - I don't like this.

Is there any difference between
 <primitive:'func' module:'lib' error:errorCode>
and
 <primitive:'func' module:'lib' error:'errorCode'>
both will generate the same code, right?




Scanner and/or parser explicit check for the name
<primitive: ....>
of the pragma of this error var.
 
Right, which is why it is simple to handle.


addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
^self primitiveFailed

instead of 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>
^self primitiveFailed


The issues are class reference, class redefinition, class removal etc.  I guess we could extend the pragma syntax to allow class references but there's a lot of impact.  I would prefer if we keep things restricted.  There's nothing to stop one using a symbol and mapping it to a class name, e.g.


GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

Also, I *hate* this style of pragma.  Why not

GTDummyExamples class
d: anInteger
    <gtExampleLabel: 'Dummy #d:, depends #c:'
     description: 'should raise an exception as the argument is not anInteger'
     depends: #c:
     raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

?

That's how the system is designed to be used.  Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.





--
_,,,^..^,,,_
best, Eliot




--
_,,,^..^,,,_
best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: Differences Compiler vs. OpalCompiler (or parser)

Eliot Miranda-2


On Tue, Feb 23, 2016 at 2:26 PM, Nicolai Hess <[hidden email]> wrote:


2016-02-23 18:58 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <[hidden email]> wrote:


2015-11-20 22:57 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolai,

On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <[hidden email]> wrote:
GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: Literal constant expected -> MessageNotUnderstood>
   
    ^ 1 + anInteger

The old Parser complains about the class name "MessageNotUnderstood" used as a pragma
argument without being a string or symbol

Opal does not complain

Is Opals behavior intended ?

IMO no.  The pragma design is that the only valid syntax is of a message pattern with only literal arguments except for the one piece of syntactic sugar where the error temporary name in a primitive call with an error can be given as an identifier, e.g.

But this means smalltalks scanner and parser needs some very special handling just for this pragma.

It turns out to be not that bad.  because all the pragmas with error codes are associated with methods that have primitives (either a numbered primitive or a named primitive from a plaugin) the parser has to handle them specially anyway.  So here's what the code looks like in Squeak's compiler:

Parser class>>primitivePragmaSelectors
"Answer the selectors of pragmas that specify VM primitives.
Needed for compile and decomple."
^#(primitive:
primitive:error:
primitive:error:module:
primitive:module:
primitive:module:error:)

and then for each of those there's a method such as

Parser>>primitive: aNameString module: aModuleStringOrNil error: errorCodeVariableOrNil
"Create named primitive with optional error code."
(aNameString isString and: [ aModuleStringOrNil isNil or: [ aModuleStringOrNil isString ] ])
ifFalse: [ ^ self expected: 'Named primitive' ].
self allocateLiteral: (Array 
with: (aModuleStringOrNil isNil 
ifFalse: [ aModuleStringOrNil asSymbol ])
with: aNameString asSymbol
with: 0 with: 0).
errorCodeVariableOrNil ifNotNil:
[encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef].
^117

that answers the number of the primitive for the method.  So there are three methods that contain "errorCodeVariableOrNil ifNotNil: [encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]" to declare the error temp.  I think that's acceptable.  What do you think?

Hi Eliot,
Yes, thats fine, but this part of the parser is independent from how we use the pragma

For
 <primitive:'func' module:'lib' error:#errorCode>
or
 <primitive:'func' module:'lib' error:errorCode>
or
 <primitive:'func' module:'lib' error:'errorCode'>

the code generation is always the same.
But for getting

 <primitive:'func' module:'lib' error:errorCode>

as valid code, we have to use another special code in
Parser>>#pragmaLiteral: selectorSoFar

"This nicety allows one to supply a primitive error
     temp as a variable name, rather than a string."
    ((selectorSoFar beginsWith: 'primitive:')
     and: [(selectorSoFar endsWith: 'error:')
     and: [hereType == #word]]) ifTrue:
        [^self advance].

without this extra check,

 <primitive:'func' module:'lib' error:errorCode>

would raise an error
'Literal constant expected'

Yes, good point.
 

In pharo, opal compilers parser accepts both, errorCode without quote or # and class names.

 <primitive:'func' module:'lib' error:errorCode>  - valid
 <someotherpragma keyword:Point>  - valid too
If I change opals parser to not allow the second pragma, I need some special handlign
for the primitive:module:error: pragma - I don't like this.

Is there any difference between
 <primitive:'func' module:'lib' error:errorCode>
and
 <primitive:'func' module:'lib' error:'errorCode'>
both will generate the same code, right?

Right, they produce the same code.

 




Scanner and/or parser explicit check for the name
<primitive: ....>
of the pragma of this error var.
 
Right, which is why it is simple to handle.


addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: errorCode>
^self primitiveFailed

instead of 

addressField
<primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'>
^self primitiveFailed


The issues are class reference, class redefinition, class removal etc.  I guess we could extend the pragma syntax to allow class references but there's a lot of impact.  I would prefer if we keep things restricted.  There's nothing to stop one using a symbol and mapping it to a class name, e.g.


GTDummyExamples class
d: anInteger
    <gtExample>
    <label: 'Dummy #d:, depends #c:'>
    <description: 'should raise an exception as the argument is not anInteger'>
    <depends: #c:>
    <raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

Also, I *hate* this style of pragma.  Why not

GTDummyExamples class
d: anInteger
    <gtExampleLabel: 'Dummy #d:, depends #c:'
     description: 'should raise an exception as the argument is not anInteger'
     depends: #c:
     raises: #MessageNotUnderstood>
    
    ^ 1 + anInteger

?

That's how the system is designed to be used.  Then the message can be implemented by a builder which performs the selector from a visitor.

From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770

Cascading message sends to super.

Compiler refuses to compile
super
    initialize;
    setListProperties


It looks like Opal would compile this to

super initialize.
super setListProperties.

Intended ? Do we want to keep it?

NBNativeCodeGen
parseOptions: optionsArray
uses association symbol -> block instead of block -> block
for caseOf arguments.
The old parser does not accept this.





--
_,,,^..^,,,_
best, Eliot




--
_,,,^..^,,,_
best, Eliot




--
_,,,^..^,,,_
best, Eliot