andyferris / generatedtypes.jl Goto Github PK

To be completely seamless, should probably take over Base.@generated instead of introducing a new macro.

Since Julia Type{...}s are not covarient, it is a little inconvenient to define functions on generated types (e.g. make eltype(vec::MyGenVec{3,Float64}) work to return Float64)

The code generator is in code block, but under most circumstances it won't allow a return statement. To make this more consistent with @generated functions, we should find a way to allow return, perhaps by wrapping the code block with an (anonymous) function.

If a function definition under the super's type name is found, we should replace that with the concrete typename, so that people can include inner constructors in their generated code.

After JuliaLang/julia#16040, we can't use eval from @generated functions in Julia 0.5. It is discussed in JuliaLang/julia#16806 that the reason is that some eval calls can cause severe problems during the compilation phase:

It's undefined how your program will behavior if you call eval from an @generated or @pure function. It's generally a straightforward way to corrupt the runtime system state, so in v0.5 it went from being a very dangerous operation that sort-of manages to pass simple tests to safely throwing an error always.

Nevertheless, this package seems to run fine on 0.4 (c.f. "sort-of manges to pass simple tests", above). While it is obvious that there exists some eval calls that might corrupt Julia's runtime system state, it would be useful to know whether these particular eval calls can and will do that. If so, generated types may have to be integrated at the language level (like generated functions) and we need to add prominent warnings to the README. On the other hand, if they are "provably" non-corrupting (under assumptions like the user not trying to predict the mangled name of the concrete subtype), then perhaps we could safely tag a release for METADATA for v0.4.

Generated functions don't care if their output is in an Expr(:block, ...) but at the moment there is a different between returning a quote block or a :(...) quoted expression (the latter returing an error).

Currently the expression parser cannot handle type parameters with restrictions on them. Should be easy enough to implement, but currently it gives a very odd error message.