Using if inside a macro to generate different code

[jedesroches]

Hello again :)

I am trying to write a macro that returns the model for a function, where inside the function something happens or not depending on a boolean parameter to the macro. In it's simplest form, here is what I have written:

(defmacro m [v]
  (if v
    '(print "yes")
    '(print "no")
  )
)

(m False)
(m True)

What I expect to happen is this code to compile to

print("no")
print("yes")

but what happens is that I get

print("yes")
print("yes")

This is especially surprising since if I read the code that is generated for the macro, the if statement looks correct to me:

import hy
hy.macros.macro('m')(lambda v: hy.models.Expression([hy.models.Symbol('print', from_parser=True), hy.models.String('yes')]) if v else hy.models.Expression([hy.models.Symbol('print', from_parser=True), hy.models.String('no')]))

I am obv. missing something trivially dumb here, but I've tried to reduce the example as much as possible, removing any quasiquotes/unquotes/splicing to be sure I'm not misunderstanding something and it looks like the else branch is just completely ignored...

[Kodiologist]

False and True come into the macro as symbols. The symbol False is true. See http://hylang.org/hy/doc/v1.1.0/syntax#hy.models.Symbol

[jedesroches]

Ok, so it makes sense and the universe is saved using hy.eval.

I've re-read the docs you've pointed to, as well as the macro docs, and now I wonder why are True and False symbols, when strings, ints and floats aren't ? Is that just a quirk of the API or is there a design reason behind that choice ?

A regular macro [...] receives parsed models as arguments.

So the parser treats True and False like any other symbol then ? Isn't that inconvenient for optimizations like dead-code elimination and the like ?

[Kodiologist]

why are True and False symbols

It's clear to me why they weren't given their own model type to begin with, which is that Hy started on Python 2, and Python 2 allows you to use True and False like any other variable. I suppose it would be possible to give True, False, and None their own model types at this point, but there's little motivation for it. We already have too many when we could just use a constant model type for a lot of things, a la Python's ast.Constant.

Isn't that inconvenient for optimizations

Hy doesn't optimize anything. That's Python's job.

[jedesroches]

Awesome, thanks for the clear explanation.