Since the pointer to the symbol's value does not change over time, you can simply store the pointer (i.e. essentially the object id) as an integer value. There is no need to choose an offset.
The advantage of storing the pointer instead of the object id is that you can use the pointer to re-create the symbol. This is not directly possible with the object id. -erik On Wed, Aug 17, 2016 at 1:00 PM, Jameson <vtjn...@gmail.com> wrote: > We could change the implementation of Symbol to be an opaque offset > instead of being and opaque value pointer, but then passing around Symbols > in generic contexts would require boxing that offset. So six of one, half > dozen of the other. Fixing the issue that all immutable objects can't be > allocated inline would probably be the better fix for eliminating the > problem. > > > On Wednesday, August 17, 2016 at 12:44:21 PM UTC-4, Erik Schnetter wrote: >> >> See <https://github.com/eschnett/ValueSymbols.jl> for what I had in mind. >> >> -erik >> >> On Wed, Aug 17, 2016 at 10:32 AM, Yichao Yu <yyc1...@gmail.com> wrote: >> >>> >>> >>> On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz < >>> oliver.sch...@tu-dortmund.de> wrote: >>> >>>> Hi Yichao >>>> >>>> I get that - I was just curious why (and I guess there's likely a very >>>> good reason for it). My intuition would be that a non-GCed interned string >>>> type could be represented by a bitstype (i.e. a pointer or index to the >>>> string table). So I was surprised that Symbol is an object reference and >>>> wanted to understand this a bit better. >>>> >>> >>> It's a pointer to managed memory with tag that's all what's needed for >>> it to be a !pointerfree type. There are way more things that we don't GC >>> and it has nothing to do with whether it's a isbits type or not. >>> >>> >>>> >>>> >>>> Cheers, >>>> >>>> Oliver >>>> >>>> >>>> On Wednesday, August 17, 2016 at 3:35:41 PM UTC+2, Yichao Yu wrote: >>>>> >>>>> >>>>> > PS: Yes, symbols in Julia should be bitstypes. >>>>> >>>>> No, it's a object reference and isn't a `isbits()` type. >>>>> >>>>> >>>>>> >>>>>> On Wed, Aug 17, 2016 at 8:26 AM, Cedric St-Jean <cedric...@gmail.com> >>>>>> 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 < >>>>>>> oliver...@tu-dortmund.de> 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 <schn...@gmail.com> http://www.perimeterinstitute. >>>>>> ca/personal/eschnetter/ >>>>>> >>>>> >>>>> >>> >> >> >> -- >> Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute. >> ca/personal/eschnetter/ >> > -- Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/
