function calls in `compile {}` blocks only accept variables as arguments

[driusan]

When there's a constant in a function call in a compile {} macro, the macro silently fails to compile because the func_call declaration in macros.yay only accepts variables as arguments.

This should probably be fixed (or at least documented.)

[ircmaxell]

This was an intentional choice (and yes, should be documented).

The reason is that an integer constant says nothing about the type. and adding support for casts to function arguments would increase complexity vastly. So instead, it's required to be in two lines:

compile {
    $value = (int64) 1;
    add($value, $value);
}

[driusan]

I'm not sure that having the restriction prevents that, though, since the blocks can still reference things from the outer scope. ie. the macros happily generates code if you do:

$value = 1;
compile {
    add($value, $value);
}

[ircmaxell]

True, but that would result in a compile error, no?

[driusan]

It didn't at https://github.com/ircmaxell/php-compiler/pull/60/commits/9116d508ac83e45bec7bc947d90c53893e36e5b9#diff-95e58c95e9cfcc3dc033dc60409d0f94R39, but I guess that might just mean we don't have a test testing the PHP memory allocator.

[marcioAlmada]

@driusan @ircmaxell

When there's a constant in a function call in a compile {} macro, the macro silently fails to compile [...]

Just saw the thread. It's possible to make macros commit after a given prefix, like so:

<?php

$(macro) {
   sigil {
       $! // from now you should get a match or a ParserError error will be thrown 
       point of no $(either(return, chain(way, back))) or syntax error;
   }
} >> {
   // matched
}

sigil {
    point of no retrune or syntax error;
             // ^^^^^^^ intentional typo in the DSL /o\
}

Trying to expand this would result in:

Unexpected T_STRING(retrune) on line 13, expected T_RETURN(return) or T_STRING(way)...

I hope this helps to make your macros emit useful errors instead of failing secretly :sweat_smile:

[ircmaxell]

Oh that's awesome!

[driusan]

Should we close this now that it at least throws an error, or do you still want to document the reason for the restriction?

[ircmaxell]

Yeah, should add some docs...