Hello, I'm currently working on an embedding of the miniKanren logic programming language in Pharo (http://minikanren.org/) and I have run into an issue with the method compilation internals I was hoping someone could shed some light on: miniKanren has an operator, fresh, that basically evaluates a block and returns a logic variable. My current syntax for a conjunction of logic variables is: var1 and: var2 When I try to use the same syntax for fresh: var1 and: [ :var2 | var2 ] Compilation fails with "Warning: and: (or:) takes zero-arg block" which seems on first glance to come from the compiler attempting to inline my and: call. If I add an auxiliary method andFresh: that evaluates the block and and:'s the result in 2 steps, my tests pass. What I'd like to know is: 1) Is there a work around to let me use the and: syntax here? 2) Might my overriding of and: and or: for normal logic variables cause other problems I'm not thinking of? Obviously this is not a critical issue, but my code's aesthetics are at stake, and if we can't have pretty code, then what can we have? Thanks, Evan
On 09 Jan 2015, at 15:10, Evan Donahue <emdonahu@gmail.com> wrote:
Hello,
I'm currently working on an embedding of the miniKanren logic programming language in Pharo (http://minikanren.org/ <http://minikanren.org/>) and I have run into an issue with the method compilation internals I was hoping someone could shed some light on:
miniKanren has an operator, fresh, that basically evaluates a block and returns a logic variable. My current syntax for a conjunction of logic variables is:
var1 and: var2
When I try to use the same syntax for fresh:
var1 and: [ :var2 | var2 ]
Compilation fails with "Warning: and: (or:) takes zero-arg block" which seems on first glance to come from the compiler attempting to inline my and: call. yes!
If I add an auxiliary method andFresh: that evaluates the block and and:'s the result in 2 steps, my tests pass.
What I'd like to know is: 1) Is there a work around to let me use the and: syntax here?
you can do it per method by adding the pragma: <compilerOptions: #(- optionInlineAndOr)> or per class by implementing on the class side: compiler ^super compiler options: #(- optionInlineAndOr)
2) Might my overriding of and: and or: for normal logic variables cause other problems I'm not thinking of?
I donât think so⦠Marcus
On 09 Jan 2015, at 15:17, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2015, at 15:10, Evan Donahue <emdonahu@gmail.com <mailto:emdonahu@gmail.com>> wrote:
Hello,
I'm currently working on an embedding of the miniKanren logic programming language in Pharo (http://minikanren.org/ <http://minikanren.org/>) and I have run into an issue with the method compilation internals I was hoping someone could shed some light on:
miniKanren has an operator, fresh, that basically evaluates a block and returns a logic variable. My current syntax for a conjunction of logic variables is:
var1 and: var2
When I try to use the same syntax for fresh:
var1 and: [ :var2 | var2 ]
Compilation fails with "Warning: and: (or:) takes zero-arg block" which seems on first glance to come from the compiler attempting to inline my and: call.
Another thing we can do⦠we could remove the warning in the method #isInlineAndOr. Then the and: would be compiled as a message as in the non-block example. Marcus
Hmm, so that works when I annotate my test class, but I probably shouldn't be exporting pragma concerns to my end users. Was your other suggestion about dealing with the warning itself something I could do, or were you referring to a change to pharo itself? In case it's relevant, the warning also seems to cause an issue where I can't deselect a new class in the system browser and have to re-open the browser. Thanks, Evan -- View this message in context: http://forum.world.st/issue-with-and-or-inlining-tp4798622p4798769.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 10 Jan 2015, at 12:20, Evan Donahue <emdonahu@gmail.com> wrote:
Hmm, so that works when I annotate my test class, but I probably shouldn't be exporting pragma concerns to my end users. Was your other suggestion about dealing with the warning itself something I could do, or were you referring to a change to pharo itself?
I think we should remove the warning. https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and-... <https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and-...> But this just solves the problem for the case where the block for and: has an argument. When you send and: [] to a non-boolean (your own Boolean), it will nevertheless optimize the contruct⦠(but then the #museBeBoolean: magic should take care of it? I think, yes.
In case it's relevant, the warning also seems to cause an issue where I can't deselect a new class in the system browser and have to re-open the browser.
Thanks, Evan
-- View this message in context: http://forum.world.st/issue-with-and-or-inlining-tp4798622p4798769.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 12 Jan 2015, at 10:57, Marcus Denker <marcus.denker@inria.fr> wrote:
On 10 Jan 2015, at 12:20, Evan Donahue <emdonahu@gmail.com <mailto:emdonahu@gmail.com>> wrote:
Hmm, so that works when I annotate my test class, but I probably shouldn't be exporting pragma concerns to my end users. Was your other suggestion about dealing with the warning itself something I could do, or were you referring to a change to pharo itself?
I think we should remove the warning.
https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and-... <https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and-...>
This is now in Pharo4 update 40439
But this just solves the problem for the case where the block for and: has an argument.
When you send and: [] to a non-boolean (your own Boolean), it will nevertheless optimize the contruct⦠(but then the #museBeBoolean: magic should take care of it? I think, yes.
YES! 1 and: [ 2 ] â> DNU SmallInteger and: This means that the code ist compiled with inline and:, then executing calls #mustBeBoolean, and we then do ^ self mustBeBooleanInMagic: thisContext sender Which carefully gets the needed code + data, compile a non-optimized code, executes that and returns it. Magic :-) Marcus
On 12 Jan 2015, at 12:08, Marcus Denker <marcus.denker@inria.fr> wrote:
On 12 Jan 2015, at 10:57, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 10 Jan 2015, at 12:20, Evan Donahue <emdonahu@gmail.com <mailto:emdonahu@gmail.com>> wrote:
Hmm, so that works when I annotate my test class, but I probably shouldn't be exporting pragma concerns to my end users. Was your other suggestion about dealing with the warning itself something I could do, or were you referring to a change to pharo itself?
I think we should remove the warning.
https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and-... <https://pharo.fogbugz.com/f/cases/14701/compile-normal-message-send-for-and-...>
This is now in Pharo4 update 40439
I made another change that removes the checks from all but âifâ inlining: https://pharo.fogbugz.com/f/cases/14716/Remove-all-notify-from-inline-checki... <https://pharo.fogbugz.com/f/cases/14716/Remove-all-notify-from-inline-checki...> maybe we should even remove it from ifTrue*⦠there is checks that the blogs have 0 args. (if we remove it it will instead compile a message send and then raise the error at runtime, making ifTrue&co optimisation transparent, too. Marcus
participants (2)
-
Evan Donahue -
Marcus Denker