www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why won't mmutable ranges stack?

reply doubleagent <doubleagent03 gmail.com> writes:
Compare the following two programs which take a string of whitespace separated
binary and decode it's message eg echo "01001101 01100101 01110010 01110010
01111001 00100000 01000011 01101000 01110010 01101001 01110011 01110100
01101101 01100001 01110011 00100001 00100001 00100001" | ./main.d

http://ompldr.org/vNnE5eA
http://ompldr.org/vNnE5eQ

The former works while the latter fails.  It looks like there's some
manipulation of 'bytes' and 'list' when writefln forces evaluation.  My
question is should this happen?

Also, is there a more idiomatic way to do byte conversions?  Something in the
stdlib, perhaps?
Dec 26 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
doubleagent <doubleagent03 gmail.com> wrote:

 The former works while the latter fails.  It looks like there's some
 manipulation of 'bytes' and 'list' when writefln forces evaluation.  My
 question is should this happen?

void main() { immutable auto bytes = splitter(stdin.readln(), ' '); immutable auto list = map!(byteToChar)(bytes); // Here immutable auto msg = reduce!("a ~ b")("", list); writefln("%s", msg); } The problem is on the marked line here - map and other non-array ranges don't deal well with being immutable or const. Remove the immutable part from list, and it works wondrously: void main() { immutable bytes = splitter(stdin.readln(), ' '); auto list = map!(byteToChar)(bytes); // Here immutable msg = reduce!("a ~ b")("", list); writefln("%s", msg); } Also note that auto is unnecessary when another storage class is specified (const,immutable). There have been several asking for tail-const (i.e. const(int)[]) support for ranges other than arrays. I have even written an implementation that to an extent works, but more language support would be preferable.
 Also, is there a more idiomatic way to do byte conversions?  Something  
 in the stdlib, perhaps?

std.conv.parse[1] with a second parameter (radix) of 2 works for me: #!/opt/dmd2/linux/bin/rdmd import std.stdio, std.algorithm, std.conv; immutable(char) byteToChar(string b) { return cast(char)parse!ubyte(b,2); } void main() { immutable bytes = splitter(stdin.readln(), ' '); auto list = map!(byteToChar)(bytes); immutable msg = reduce!("a ~ b")("", list); writefln("%s", msg); } [1]: http://www.digitalmars.com/d/2.0/phobos/std_conv.html#parse -- Simen
Dec 26 2010
parent doubleagent <doubleagent03 gmail.com> writes:
== Quote from Simen kjaeraas (simen.kjaras gmail.com)'s article
 Also note that auto is unnecessary when another storage class is
 specified (const,immutable).

Ah, that's right!
 There have been several asking for tail-const (i.e. const(int)[])
 support for ranges other than arrays. I have even written an
 implementation that to an extent works, but more language support would
 be preferable.

That seems like a really important feature to have. If I'm not mistaken there are certain functional data structures which would be impossible to implement without first working around this limitation. Is there a discussion thread for this?
 std.conv.parse[1] with a second parameter (radix) of 2 works for me:

Thanks!
Dec 26 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
doubleagent <doubleagent03 gmail.com> wrote:

 There have been several asking for tail-const (i.e. const(int)[])
 support for ranges other than arrays. I have even written an
 implementation that to an extent works, but more language support would
 be preferable.

That seems like a really important feature to have. If I'm not mistaken there are certain functional data structures which would be impossible to implement without first working around this limitation. Is there a discussion thread for this?

There is one in digitalmars.D, called tail const. Most of it is about a month old. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=123380 There is also bug 5377: http://d.puremagic.com/issues/show_bug.cgi?id=5377 -- Simen
Dec 26 2010