On Sat, 2015-05-23 at 12:58 +0000, Dennis Ritchie via Digitalmars-d-learn wrote:
> On Saturday, 23 May 2015 at 10:58:33 UTC, Kagamin wrote:
> > Well, list comprehension is built into language in python (and not in D), such level of support is definitely more streamlined.
> 
> Well, what's to keep D more functions to work with slist and
> dlist ?
> In my opinion, lists in D completely bald :)
> 
> After all, there is a module in Phobos std.array, so why not make
> the module std.list.
> Do lists in D can be done as powerful as arrays?

The issue is performance, especially for random access to the sequence. Not all abstractions are equal! List structures are only really useful in very limited circumstances, generally you want more efficient sequence realizations: array, deque, etc.

It is also probably worth noting that lists in Python are not singly or doubly linked lists, they are arrays.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 22 May 2015 at 00:23:30 UTC, Dennis Ritchie wrote:
> Hi,
> I've collected some of Python's features. It seems to me that they are not in the D!
>
> Surely all this is in the D? :)
> http://rextester.com/CNQQR3333

import std.algorithm;
import std.range;
import std.stdio;
import std.conv;

void main() {
	enum n1 = 5;
	writeln(stdin.byLine
		.map!(line => line.split(" ").map!(x => to!int(x)))
	);
	
	writeln("------");
	
	enum n2 = 6;
	writeln(iota(n2)
		.map!(i => chain(
			repeat("2", i),
			only("1"),
			repeat("0", n2 - i - 1),
			only("\n")
		).joiner(" ")).joiner
	);
}


(I omitted evens/odds because it's been addressed and fizzbuzz because there's probably dozens of them floating around)

You seem to be focusing on D's arrays only, but the real meat is in ranges, which are more generic. Also note that the above solution doesn't allocate any of the ranges in the heap; they're all on the stack (as opposed to Python, where you have to allocate lists or use iterators+itertools).

On Saturday, 23 May 2015 at 19:22:40 UTC, Alex Parrill wrote:
> import std.algorithm;
> import std.range;
> import std.stdio;
> import std.conv;
>
> void main() {
> 	enum n1 = 5;
> 	writeln(stdin.byLine
> 		.map!(line => line.split(" ").map!(x => to!int(x)))
> 	);
> 	
> 	writeln("------");
> 	
> 	enum n2 = 6;
> 	writeln(iota(n2)
> 		.map!(i => chain(
> 			repeat("2", i),
> 			only("1"),
> 			repeat("0", n2 - i - 1),
> 			only("\n")
> 		).joiner(" ")).joiner
> 	);
> }
>
>
> (I omitted evens/odds because it's been addressed and fizzbuzz because there's probably dozens of them floating around)
>
> You seem to be focusing on D's arrays only, but the real meat is in ranges, which are more generic. Also note that the above solution doesn't allocate any of the ranges in the heap; they're all on the stack (as opposed to Python, where you have to allocate lists or use iterators+itertools).

This does not work!

enum n1 = 5;
writeln(stdin.byLine
 	.map!(line => line.split(" ").map!(x => to!int(x)))
);
-----
http://rextester.com/VGHZF81178

Even if you wanted to write this:

enum n = 5;
writeln(stdin.byLine
	.map!(line => line.split(" ").map!(x => to!int(x))).take(n)
);
-----
http://rextester.com/COWE75794

That it's still not working. In my opinion, and should not work :)

> You seem to be focusing on D's arrays only, but the real meat is in ranges, which are more generic.

Not sure what kind of meat you mean, but I really don't see much meat in ranges. Of course, this is 10 times better and easier to use than STL iterators C++. For me the most important feature D are mixins, which I, unfortunately, rarely use. I'm waiting for new features from D: for new designs, not simply the expansion of Phobos and fix bugs in DMD :) Should I wait for these new features? It seems to me that everyone is not enough to simply correct C++ — they all want a language in which many different sugar. In my opinion, sugar you can try to shake out of Lisp, if possible :)

> Also note that the above solution doesn't allocate any of the ranges in the heap; they're all on the stack (as opposed to Python, where you have to allocate lists or use iterators+itertools).

And yet I do not like how the function byLine. It seems to me that we need analogues that will not work so damp as byLine.

All right. Next time I will try to combine features that are not available in D, and of the faster languages: Erlang, Perl, Lisp, Nim, Rust, Scala etc. :)

On Saturday, 23 May 2015 at 19:22:40 UTC, Alex Parrill wrote:
> You seem to be focusing on D's arrays only, but the real meat is in ranges, which are more generic. Also note that the above solution doesn't allocate any of the ranges in the heap; they're all on the stack (as opposed to Python, where you have to allocate lists or use iterators+itertools).

Also present ranges from the time of D1 and Tango, because there is nothing surprising about them. Need new features!

> Not sure what kind of meat you mean, but I really don't see much meat in ranges. Of course, this is 10 times better and easier to use than STL iterators C++. For me the most important feature D are mixins, which I, unfortunately, rarely use. I'm waiting for new features from D: for new designs, not simply the expansion of Phobos and fix bugs in DMD :) Should I wait for these new features? It seems to me that everyone is not enough to simply correct C++ — they all want a language in which many different sugar. In my opinion, sugar you can try to shake out of Lisp, if possible :)
>

I think you are mistaken. The hard part about growing a
programming language isn't adding features, it's finding the right
core of features that are stable yet generic enough to answer
everything in their own way.

This is why C still is such a popular language, it hardly evolvevd
since the begginning. It is also why Java in its time or Go know
are popular among companies: they are boring, just boring. But they
are stable. C++ wanted to address every problem, and look at it
know.

We have to develop a style, not more features. Python has its own
style but every new feature (and they are rare) is very diligently
examined. Most are refused. There is the python way. If python isn't
the right tool for the job, then the best thing to do is finding
another tool, not scotch an extension to the first one.

I like python. I like D. I like other languages. Of course sometimes
I'd like to have, say, UFCS in python or list comprehension in D.
But D isn't the best language to do python, python is. And as there
is a python way, there is a D way.

This is not to say that we should dismiss any good concept of other
languages, but those concepts fit in a philosophy, in an ecosystem.

(just noticed a weird typo trend with know/now....     %s/know/now/g)

On Saturday, 23 May 2015 at 20:25:18 UTC, Dennis Ritchie wrote:
> This does not work!
>
> enum n1 = 5;
> writeln(stdin.byLine
>  	.map!(line => line.split(" ").map!(x => to!int(x)))
> );
> -----
> http://rextester.com/VGHZF81178

The code itself is ok.

That site has broken newlines. You can see here that std.ascii.newline is different from what the site actually feeds to the program: <http://rextester.com/IIT33098>.

You can work around that by passing the correct line terminator to byLine: <http://rextester.com/SOW95508>.

On Saturday, 23 May 2015 at 20:57:10 UTC, anonymous wrote:
> On Saturday, 23 May 2015 at 20:25:18 UTC, Dennis Ritchie wrote:
>> This does not work!
>>
>> enum n1 = 5;
>> writeln(stdin.byLine
>> 	.map!(line => line.split(" ").map!(x => to!int(x)))
>> );
>> -----
>> http://rextester.com/VGHZF81178
>
> The code itself is ok.
>
> That site has broken newlines. You can see here that std.ascii.newline is different from what the site actually feeds to the program: <http://rextester.com/IIT33098>.
>
> You can work around that by passing the correct line terminator to byLine: <http://rextester.com/SOW95508>.

Perhaps that's not the site, and in Windows. That's what gives me in CMD:

456 4 4 8 99 456
[[456, 4, 4, 8, 99, 456]13 546
std.conv.ConvException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(2013): Unexpected end of input when converting from type char[] to type int
----------------
0x0040FD10 in pure @safe int std.conv.parse!(int, char[]).parse(ref char[]) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(2015)
0x00410C74 in pure @safe int std.conv.toImpl!(int, char[]).toImpl(char[]) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(1738)
0x0040FB92 in pure @safe int std.conv.to!(int).to!(char[]).to(char[]) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(296)
0x0040FB7E in pure @safe int acm.main().__lambda1!(char[]).__lambda1(char[]).__lambda2!(char[]).__lambda2(char[])
0x00410DA7 in pure @property @safe int std.algorithm.iteration.__T9MapResultS553acm4mainFZ17__T9__lambda1TAaZ9__lambda1MFAaZ9__lambda2TAAaZ.MapResult.front() at C:\D\dmd2\windows\bin\..\..\src\phobos\
std\algorithm\iteration.d(548)
0x004122D4 in D3std6format169__T11formatRangeTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration76A5C81813C007BD25AC82BE82F3551A66 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(240
9)
0x0041213F in D3std6format169__T11formatValueTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration768E862681E57D43E301EA954AAC63F894 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(311
2)
0x004120AA in D3std6format171__T13formatElementTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iterationC8BE2524D6E8B27505208FE77A7AABE7 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(261
9)
0x00411B89 in D3std6format172__T11formatRangeTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration7956A969C910F877511562257DEEBA50CE at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(241
0)
0x00411A27 in D3std6format172__T11formatValueTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration793B5F1700DB9877FAF5528C7A1A67E5DC at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(311
2)
0x00411991 in D3std6format174__T13formatGenericTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iterationD44607637B1FEE3931BFD9A68911D4FE at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(345
1)
0x0041185C in D3std6format175__T14formattedWriteTS3std5stdio4File17LockingTextWriterTaTS3std9algorithm9iteratD57474F5CD8E0DF85B780AE37888E8BE at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(521
)
0x00411320 in D3std5stdio4File129__T5writeTS3std9algorithm9iteration79__T9MapResultS213acm4mainFZ9__lambda1TSD37A9C7F430415C668F40B8F70856955 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(1200
)
0x0041120A in D3std5stdio129__T7writelnTS3std9algorithm9iteration79__T9MapResultS213acm4mainFZ9__lambda1TS3stC41BC71D1E9C2BC78EB8446AC4667CCD at C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2932
)
0x0040203D in _Dmain at C:\Users\REiS\Documents\Projects\acm\acm\acm.d(21)
0x00427E06 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x00427DDB in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()
0x00427CF3 in _d_run_main
0x00427884 in main
0x0043E701 in mainCRTStartup
0x76BB7C04 in BaseThreadInitThunk
0x775AAD1F in RtlInitializeExceptionChain
0x775AACEA in RtlInitializeExceptionChain

On Friday, 22 May 2015 at 00:23:30 UTC, Dennis Ritchie wrote:
> Hi,
> I've collected some of Python's features. It seems to me that they are not in the D!
>
> Surely all this is in the D? :)
> http://rextester.com/CNQQR3333

After another review, I think some of these conversions to D could be expressed much easier if the built-in slice had multidimensional slicing

It was added in 2.066* but I don't think there's any plans to add support for it to slices.

* - you can see an example at http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html

On Saturday, 23 May 2015 at 21:08:19 UTC, Dennis Ritchie wrote:
> Perhaps that's not the site, and in Windows. That's what gives me in CMD:
>
> 456 4 4 8 99 456
> [[456, 4, 4, 8, 99, 456]13 546
> std.conv.ConvException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(2013): Unexpected end of input when converting from type char[] to type int

That's a different issue. Works fine for me in wine.

You may be typing spaces before/after the numbers. That would result in empty items from `split`. You can `filter` empty items out, or you can use the unary version of `split` (not passing the delimiter) which, as per documentation, splits at whitespace and produces no empty words.