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: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 |
yes!
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)
Marcus
|
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 |
In reply to this post by Marcus Denker-4
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 |
I think we should remove the warning. 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.
|
This is now in Pharo4 update 40439
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 |
I made another change that removes the checks from all but “if” inlining: 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 |
Free forum by Nabble | Edit this page |