[Compiler-sig] Number classes

[Finn Bock]

[Jeremy]

>For CPython, I've got a single routine called parsenumber().  It
>converts a string to a PyObject * of the appropriate type.  So for my
>code, the only way I could find out if I've got an int vs. a complex
>is to parse it and check the return type.  But once I've got the
>PyObject *, there's no need to pass a string to ctor.
>
>Is the 'object' type your thinking of for ASDL the generic object type
>of the Python implementation?  So I would actually pass the ComplexNum
>ctor a PyObject *?

Yes, that was the idea, but then there would only be one Num(object n)
ctor. Is it a useless brainfart?

>For the code generator, the various number objects are all treated the
>same way once they're parsed.  (Unless the compiler was doing some
>constant folding, I suppose.)

Interesting. I need to do something different for each num type:

    public Object visitIntNum(IntNum node) throws Exception {
        module.PyInteger(Integer.parseInt(node.n)).get(code);
        return null;
    }

    public Object visitLongNum(LongNum node) throws Exception {
        module.PyLong(node.n).get(code);
        return null;
    }

>If there's no difference to the way the
>numbers are handled, it would be better to mark a generic Num type
>with some flags or attributes that provide the extra info.

That will work for me too, but as I understand your first paragraph
above, CPython don't know the type without parsing the string. 

regards,
finn