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