On Friday, June 15, 2012 00:24:15 Timon Gehr wrote:
> On 06/14/2012 06:42 PM, Jonathan M Davis wrote:
> > I wish that you could do
> > 
> > auto f = new float(2.1);
> > 
> > and therefore
> > 
> > auto f = new immutable(float)(2.1);
> > 
> > but you can't.
> 
> This seems to be an arbitrary limitation.
> Imho it should be fixed. Probably it was missed because allocating a
> primitive type on the heap is not a very common operation.

I suggested it quite some time ago, and as I recall it was met with a fair bit of negativity. I don't remember why or who said what. Maybe Walter could be talked into it. I don't know. Personally, I think that it would be the perfectly natural way to do it and find it very bizarre that you can't.

- Jonathan M Davis

On 2012-06-14 17:32, Roman D. Boiko wrote:

> I agree, just looking how to accomplish my goals. I decided to get rid
> of casting, and will store everything on heap. I don't know how to put a
> variable of type float to the heap, and thought that it would be nice to
> allow the user to pass anything inside, but copy when that is not an
> l-value.

Do you really need to put a float on the heap? Just pass it around as a value type, it's not like it's a big struct.

-- 
/Jacob Carlborg

On Friday, 15 June 2012 at 06:25:59 UTC, Jacob Carlborg wrote:
> On 2012-06-14 17:32, Roman D. Boiko wrote:
>
>> I agree, just looking how to accomplish my goals. I decided to get rid
>> of casting, and will store everything on heap. I don't know how to put a
>> variable of type float to the heap, and thought that it would be nice to
>> allow the user to pass anything inside, but copy when that is not an
>> l-value.
>
> Do you really need to put a float on the heap? Just pass it around as a value type, it's not like it's a big struct.
That could be anything. In most cases I'm oversimplifying the task. In this particular case I was interested in building collections which can store objects or structs using pointers to them.

Am 15.06.2012 08:25, schrieb Jacob Carlborg:
> On 2012-06-14 17:32, Roman D. Boiko wrote:
>
>> I agree, just looking how to accomplish my goals. I decided to get rid
>> of casting, and will store everything on heap. I don't know how to put a
>> variable of type float to the heap, and thought that it would be nice to
>> allow the user to pass anything inside, but copy when that is not an
>> l-value.
>
> Do you really need to put a float on the heap? Just pass it around as a
> value type, it's not like it's a big struct.
>

i think he needs to - else he encapsulate the float into an struct which is then also on the heap

(ast/whatever)
  nodex -> float
    nodey -> string
  nodez -> int
  nodew -> double

etc.

in this example a node can contain from n types values - how would you solve that? or better what is the smallest(maybe fastest) representation

there need to be a queryable tree in the end - so there is a need to hold the values - yes he can copy by value - but into whom?

in the end it will be an variant-like type (with members for each type) on heap - whichs is not that good because that will cost much more mem

or something like an class FloatValue -> NodeValue -> Value oop-hierachy whichs also will get onto the heap

i would try to use something like an base-types pool for all the small
float,double,int,string etc values... and pointer to this pool - or just use the heap :)

On 2012-06-15 10:30, dennis luehring wrote:

> i think he needs to - else he encapsulate the float into an struct which
> is then also on the heap
>
> (ast/whatever)
> nodex -> float
> nodey -> string
> nodez -> int
> nodew -> double
>
> etc.
>
> in this example a node can contain from n types values - how would you
> solve that? or better what is the smallest(maybe fastest) representation
>
> there need to be a queryable tree in the end - so there is a need to
> hold the values - yes he can copy by value - but into whom?
>
> in the end it will be an variant-like type (with members for each type)
> on heap - whichs is not that good because that will cost much more mem
>
> or something like an class FloatValue -> NodeValue -> Value oop-hierachy
> whichs also will get onto the heap
>
> i would try to use something like an base-types pool for all the small
> float,double,int,string etc values... and pointer to this pool - or just
> use the heap :)
>

Ah, I see.

-- 
/Jacob Carlborg

On Friday, 15 June 2012 at 08:31:08 UTC, dennis luehring wrote:
> Am 15.06.2012 08:25, schrieb Jacob Carlborg:
>> On 2012-06-14 17:32, Roman D. Boiko wrote:
>>
>>> I agree, just looking how to accomplish my goals. I decided to get rid
>>> of casting, and will store everything on heap. I don't know how to put a
>>> variable of type float to the heap, and thought that it would be nice to
>>> allow the user to pass anything inside, but copy when that is not an
>>> l-value.
>>
>> Do you really need to put a float on the heap? Just pass it around as a
>> value type, it's not like it's a big struct.
>>
>
> i think he needs to - else he encapsulate the float into an struct which is then also on the heap
>
> (ast/whatever)
>   nodex -> float
>     nodey -> string
>   nodez -> int
>   nodew -> double
>
> etc.
>
> in this example a node can contain from n types values - how would you solve that? or better what is the smallest(maybe fastest) representation
>
> there need to be a queryable tree in the end - so there is a need to hold the values - yes he can copy by value - but into whom?
>
> in the end it will be an variant-like type (with members for each type) on heap - whichs is not that good because that will cost much more mem
>
> or something like an class FloatValue -> NodeValue -> Value oop-hierachy whichs also will get onto the heap
>
> i would try to use something like an base-types pool for all the small
> float,double,int,string etc values... and pointer to this pool - or just use the heap :)

Well, my case is actually more complicated: https://github.com/roman-d-boiko/dct/blob/master/fe/syntax.d

Node is a struct that holds:
* instances of Syntax **classes** (these are immutable AST nodes without identity; please don't confuse Node which is a struct and node which is a general term for part of a tree)
* information about their positions of Syntax nodes in source code,
* and links to parent Node instances.

This way we have the ability to reuse most of Syntax nodes during incremental source code edits, only regenerating lightweight Node structs that introduce unique identity to those Syntax nodes.

As I already mentioned, Syntax nodes are immutable classes. They have to be polymorphic (thus classes), but they are value types without identity. They form immutable trees where each parent knows its children. They don't know their positions in source code, only their widths. Node structs know their parent Node structs and on demand can quickly compute their children as Node[] using information about children from their Syntax field.

On 15.06.2012 12:50, Roman D. Boiko wrote:
> On Friday, 15 June 2012 at 08:31:08 UTC, dennis luehring wrote:
>> Am 15.06.2012 08:25, schrieb Jacob Carlborg:
>>> On 2012-06-14 17:32, Roman D. Boiko wrote:
>>>
>>>> I agree, just looking how to accomplish my goals. I decided to get rid
>>>> of casting, and will store everything on heap. I don't know how to
>>>> put a
>>>> variable of type float to the heap, and thought that it would be
>>>> nice to
>>>> allow the user to pass anything inside, but copy when that is not an
>>>> l-value.
>>>
>>> Do you really need to put a float on the heap? Just pass it around as a
>>> value type, it's not like it's a big struct.
>>>
>>
>> i think he needs to - else he encapsulate the float into an struct
>> which is then also on the heap
>>
>> (ast/whatever)
>> nodex -> float
>> nodey -> string
>> nodez -> int
>> nodew -> double
>>
>> etc.
>>
>> in this example a node can contain from n types values - how would you
>> solve that? or better what is the smallest(maybe fastest) representation
>>
>> there need to be a queryable tree in the end - so there is a need to
>> hold the values - yes he can copy by value - but into whom?
>>
>> in the end it will be an variant-like type (with members for each
>> type) on heap - whichs is not that good because that will cost much
>> more mem
>>
>> or something like an class FloatValue -> NodeValue -> Value
>> oop-hierachy whichs also will get onto the heap
>>
>> i would try to use something like an base-types pool for all the small
>> float,double,int,string etc values... and pointer to this pool - or
>> just use the heap :)
>
> Well, my case is actually more complicated:
> https://github.com/roman-d-boiko/dct/blob/master/fe/syntax.d
>
> Node is a struct that holds:
> * instances of Syntax **classes** (these are immutable AST nodes without
> identity; please don't confuse Node which is a struct and node which is
> a general term for part of a tree)
> * information about their positions of Syntax nodes in source code,
> * and links to parent Node instances.
>
Suggest you revisit toNode function  as it does return something strange :)

Just looking at first - last  lines:
pure nothrow auto toNode(R)(R range, immutable(Maybe!Node) parent) if(isInputRange!R && hasLength!R)

	....
		auto result = new Node[](range.length);
		foreach(e; range) result ~= toNode2(e);
		return cast(immutable) range; // <<<<---- WAT
	}

And no need to cast to immutable, compiler will infer things automatically since it's pure. (and correctly for both mutable/immutable)


-- 
Dmitry Olshansky

On Friday, 15 June 2012 at 10:01:42 UTC, Dmitry Olshansky wrote:
> Suggest you revisit toNode function  as it does return something strange :)
>
> Just looking at first - last  lines:
> pure nothrow auto toNode(R)(R range, immutable(Maybe!Node) parent) if(isInputRange!R && hasLength!R)
>
> 	....
> 		auto result = new Node[](range.length);
> 		foreach(e; range) result ~= toNode2(e);
> 		return cast(immutable) range; // <<<<---- WAT
> 	}
>
> And no need to cast to immutable, compiler will infer things automatically since it's pure. (and correctly for both mutable/immutable)
Thanks, fixed. This is the result of not writing tests first :)