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.sch...@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?
>>
>>
