Re: Immutability and other attributes, please review
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
Getting a range over a const Container
Hi, I have a const std.container object (e.g., a const(Array!int)) of which I'd like to have a range which can traverse that container having read-only access. This does not seem to be possible with opSlice(). Is there an alternative? Best regards, Matthias
Re: Getting a range over a const Container
On Friday, June 15, 2012 09:14:45 Matthias Walter wrote: Hi, I have a const std.container object (e.g., a const(Array!int)) of which I'd like to have a range which can traverse that container having read-only access. This does not seem to be possible with opSlice(). Is there an alternative? opSlice is the only way to get a range out of Array. It looks like it lacks a const overload for opSlice - hence why it's not working for you. Feel free to open an enhancement request: http://d.puremagic.com/issues - Jonathan M Davis
Re: Immutability and other attributes, please review
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.
Re: Immutability and other attributes, please review
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 :)
Re: Immutability and other attributes, please review
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
Re: Immutability and other attributes, please review
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.
Re: Immutability and other attributes, please review
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 :)
Re: Lazy KMP range
On 15.06.2012 23:03, bearophile wrote: A lazy Knuth-Morris-Pratt that works on a Input Range: http://ideone.com/dUs5B Do you have suggestions for improvements of the code? Maybe do I have to turn it into a Forward Range if the first range is a Forward one? Is something similar to this useful for Phobos? Yes, definitely just decouple table preparation and searching range itself. It's common to use KMP and its ilk to do a lot of series of searches for the same needle. Bye and thank you, bearophile -- Dmitry Olshansky
Re: Lazy KMP range
On Friday, 15 June 2012 at 19:03:56 UTC, bearophile wrote: A lazy Knuth-Morris-Pratt that works on a Input Range: http://ideone.com/dUs5B Do you have suggestions for improvements of the code? Maybe do I have to turn it into a Forward Range if the first range is a Forward one? Is something similar to this useful for Phobos? Bye and thank you, bearophile Pay attention to Licensed under the PSF License for your source implementation. You will not be able to include it into Phobos unless implementation details that you borrowed from Python implementation can be found elsewhere under terms that allow applying Boost license.
Re: Lazy KMP range
On Friday, 15 June 2012 at 19:41:35 UTC, Roman D. Boiko wrote: Pay attention to Licensed under the PSF License for your source implementation. You will not be able to include it into Phobos unless implementation details that you borrowed from Python implementation can be found elsewhere under terms that allow applying Boost license. You might also ask the author for permission to change license, provided that that person didn't get it elsewhere under some other terms :)
Re: Lazy KMP range
On 15.06.2012 23:41, Roman D. Boiko wrote: On Friday, 15 June 2012 at 19:03:56 UTC, bearophile wrote: A lazy Knuth-Morris-Pratt that works on a Input Range: http://ideone.com/dUs5B Do you have suggestions for improvements of the code? Maybe do I have to turn it into a Forward Range if the first range is a Forward one? Is something similar to this useful for Phobos? Bye and thank you, bearophile Pay attention to Licensed under the PSF License for your source implementation. You will not be able to include it into Phobos unless implementation details that you borrowed from Python implementation can be found elsewhere under terms that allow applying Boost license. Bearophile if license is a problem you might try your hand on these: http://www-igm.univ-mlv.fr/~lecroq/string/ A lot of stuff ;) -- Dmitry Olshansky
Re: Lazy KMP range
Dmitry Olshansky: Yes, definitely just decouple table preparation and searching range itself. It's common to use KMP and its ilk to do a lot of series of searches for the same needle. OK. Regarding the license, this is a translation from another language of a basic algorithm. I don't think the original license applies. And if it applies, the author is Eppstein (http://en.wikipedia.org/wiki/David_Eppstein ) that I know well. For a translation of such small amount of code he will probably accept a Boost re-licensing :-) Bye, bearophile
