You could create your own immutable type that holds a `Ptr`, and then define respective `unsafe` functions that convert from `Symbol` to `Ptr` and back:
```Julia # Take a symbol, convert to a bitstype: sym = :car ptr = Cstring(sym) isbits(ptr) # Convert back to a symbol sym2 = Symbol(unsafe_wrap(String, ptr)) sym2 === sym ``` The call to the `Symbol` constructor is probably expensive, as Julia will have to traverse its internal set of existing symbols to determine whether this symbol is new. I assume that "hiding" symbols in pointers in this way will break e.g. serialization. If you define your own serialization format (where you serialize the pointer instead of the bitstype pointer) you should be fine. There might be other gotchas like this as well. -erik PS: Yes, symbols in Julia should be bitstypes. On Wed, Aug 17, 2016 at 8:26 AM, Cedric St-Jean <[email protected]> wrote: > Good points. > > Given that symbols have a name which is a string, I don't see how they > could be a bits-type unless they just became numbers to index into a global > array somewhere...... i.e. a pointer. Stack-allocating non-bits-type > immutables is on the roadmap to 1.0, so that should solve your problems. > > Maybe you can solve the CategorizedPoint problem by using an @enum. > > On Wed, Aug 17, 2016 at 6:48 AM, Oliver Schulz < > [email protected]> wrote: > >> Hello Andreas, >> >> consider iterating over a Dict{Symbol,Int64}: >> >> d = Dict(:foo => 42, :bar => 77) >> for x in d println("$(typeof(x)), $(isbits(x))") end >> >> >> During iteration, a lot of stack allocated "Pair{Symbol,Int64}" objects >> are created. That is very bad for performance. >> >> immutable CategorizedPoint >> x::Float64 >> y::Float64 >> category::Symbol >> end >> >> >> Also, consider a (hypothetical) data type for categorized points (with a >> finite number of categories - but extensible, so that Symbol is a better >> fit than using an enum): >> >> immutable CategorizedPoint >> x::Float64 >> y::Float64 >> category::Symbol >> end >> >> I would definitely want this to be a bits-type, and not have every >> instance heap-allocated. >> >> >> Cheers, >> >> Oliver >> >> >> On Wednesday, August 17, 2016 at 11:44:13 AM UTC+2, Andreas Lobinger >> wrote: >>> >>> Hello colleague, >>> >>> On Wednesday, August 17, 2016 at 11:12:51 AM UTC+2, Oliver Schulz wrote: >>>> >>>> Sure - I was assuming that as Symbol (as an interned string) is >>>> basically just a pointer. So comparisons are O(1), etc. What I'd like to >>>> understand is, why can't it be a bitstype? Currently, it's not, so Symbol >>>> cannot be used in a lightweight (i.e. stack-allocated) immutable type. I >>>> assume there's a good reason for it, I just want to understand why. >>>> >>> >>> Could you make an example how you would like to use Symbol in >>> lightweight types? >>> >>> > -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/
