Differences Compiler vs. OpalCompiler (or parser)
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.
Hi Nicolai, On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> 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
2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> 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
On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> 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
2015-12-04 20:29 GMT+01:00 Andrei Chis <chisvasileandrei@gmail.com>:
On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> 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
Hi Andrei,
On Dec 4, 2015, at 11:29 AM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
On Sat, Nov 21, 2015 at 3:25 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> 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
2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> 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
Hi Nicolai, On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> 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
2016-02-23 18:58 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> 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
On Tue, Feb 23, 2016 at 2:26 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-02-23 18:58 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess@gmail.com> 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
On 20 Nov 2015, at 22:37, Nicolai Hess <nicolaihess@gmail.com> 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 <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
2015-12-03 16:59 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 20 Nov 2015, at 22:37, Nicolai Hess <nicolaihess@gmail.com> 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
participants (4)
-
Andrei Chis -
Eliot Miranda -
Marcus Denker -
Nicolai Hess