Re: [julia-users] Re: "eval cannot be used in a generated function"

Naive suggestion: since you can eval inside the macro body (à la FastAnonymous), couldn't your generated function expand into a macro call? On Friday, August 12, 2016 at 12:19:49 PM UTC-4, Erik Schnetter wrote: > > On Fri, Aug 12, 2016 at 4:06 AM, Tomas Lycken > wrote: >

Re: [julia-users] Re: "eval cannot be used in a generated function"

On Fri, Aug 12, 2016 at 4:06 AM, Tomas Lycken wrote: > Julia’s parametric types are not generic enough to support this. > > In my experience, any time I’ve been inclined to reason like this about > one of my use cases, someone (usually Tim Holy :P) has been able to show

Re: [julia-users] Re: "eval cannot be used in a generated function"

In what sense does a generated function need to be pure? I was not aware of this. Does this mean that (1) the generating function needs to be pure (and return only a quoted expression, not modifying any state), or that (2) the quoted expression needs to be pure? The documentation of generated

Re: [julia-users] Re: "eval cannot be used in a generated function"

Julia’s parametric types are not generic enough to support this. In my experience, any time I’ve been inclined to reason like this about one of my use cases, someone (usually Tim Holy :P) has been able to show me a way that works just fine, without magic, by just using the type system in a

Re: [julia-users] Re: "eval cannot be used in a generated function"

> I'm encountering the error "eval cannot be used in a generated function" in Julia 0.5 for code that is working in Julia 0.4. I feel your pain, Erik! > AFAICT, it remains possible to do dynamic type generation if you (1) print the code that would define the type to a file, and (2) `include`

Re: [julia-users] Re: "eval cannot be used in a generated function"

On Thu, Aug 11, 2016 at 3:08 AM, Tomas Lycken wrote: > Late to the party, but what’s wrong with writing FastArray{1,10,1,10} (or > even FastArray{10,10} if you’re OK with implicit 1-based indexing)? It > seems that those (valid) type arguments could convey just as much >

Re: [julia-users] Re: "eval cannot be used in a generated function"

Late to the party, but what’s wrong with writing FastArray{1,10,1,10} (or even FastArray{10,10} if you’re OK with implicit 1-based indexing)? It seems that those (valid) type arguments could convey just as much information as FastArray(1:10, 1:10), and you could then handle any

Re: [julia-users] Re: "eval cannot be used in a generated function"

The upshot of the discussions seems to be "it won't work in 0.5 because the experts say so, and there are no plans to change that". So I'm going to accept that statement. I think I'll use the following work-around: ```Julia immutable Wrapper{Tag,Types} data::Types end ``` where I use `Tag` as

Re: [julia-users] Re: "eval cannot be used in a generated function"

The `eval` there is redundant with `include`. But there's nothing wrong with running julia code during compile-time to dynamically generate code. The confusion there comes from the fact that Julia has a compile-step between each toplevel statement, which allows you to intermix runtime and compile.

Re: [julia-users] Re: "eval cannot be used in a generated function"

AFAICT, it remains possible to do dynamic type generation if you (1) print the code that would define the type to a file, and (2) `include` the file. function create_type_dynamically{T}(::Type{T}) type_name = string("MyType", T) isdefined(Main, Symbol(type_name)) && return nothing

Re: [julia-users] Re: "eval cannot be used in a generated function"

On Wed, Aug 10, 2016 at 5:49 PM, Jameson Nash wrote: > module scope is compile time != runtime This isn't much of an explanation. I think this would seem like less of a "because I say so" if you provided an explanation of what the problem with calling eval within a generated

Re: [julia-users] Re: "eval cannot be used in a generated function"

> Why is it impossible to generate a new type at run time? I surely can do this by calling `eval` at module scope. module scope is compile time != runtime > Or I could create a type via a macro. Again, compile time != runtime > Given this, I can also call `eval` in a function, if I ensure the

Re: [julia-users] Re: "eval cannot be used in a generated function"

On Wed, Aug 10, 2016 at 1:45 PM, Jameson wrote: > AFAIK, defining an arbitrary new type at runtime is impossible, sorry. In > v0.4 it was allowed, because we hoped that people understood not to try. > See also https://github.com/JuliaLang/julia/issues/16806. Note that it is >

Re: [julia-users] Re: "eval cannot be used in a generated function"

AFAIK, defining an arbitrary new type at runtime is impossible, sorry. In v0.4 it was allowed, because we hoped that people understood not to try. See also https://github.com/JuliaLang/julia/issues/16806. Note that it is insufficient to "handle" the repeat calling via caching in a Dict or

Re: [julia-users] Re: "eval cannot be used in a generated function"

I want to create a type, and need more flexibility than Julia's `type` definitions offer (see ). Currently, I have a function that generates the type, and returns the type. I would like to make this a generated function (as it was in Julia 0.4). The

[julia-users] Re: "eval cannot be used in a generated function"

It is tracking the dynamic scope of the code generator, it doesn't care about what code you emit. The generator function must not cause any side-effects and must be entirely computed from the types of the inputs and not other global state. Over time, these conditions are likely to be more