On Thu, Feb 22, 2018 at 02:06:20AM +0000, psychoticRabbit via Digitalmars-d-announce wrote:
> On Wednesday, 21 February 2018 at 16:58:22 UTC, H. S. Teoh wrote:
> > On Wed, Feb 21, 2018 at 02:46:56PM +0000, psychoticRabbit via Digitalmars-d-announce wrote: [...]
> > > Syntax is EVERYTHING. It can make or break a language.
> > 
> > And semantics doesn't matter.
> > 
> > :-D
[...]
> assert("easy on the eyes" == "easy on the brain");

Therein lies the rub: "easy on the eyes" is subjective. Meaning that reasonable people will disagree on what exactly constitutes "easy on the eyes".  I'm pretty sure a Lisp geek would consider Lisp as very easy to read, and everything else as an eyesore.  Does that mean everyone should use Lisp syntax to the exclusion of all else?  I hope not.


> wtf! I get an assertion failure??

See, even dmd agrees with me. :-D


> programming languages are just dumb tools to write syntax ;-)

In Soviet Russia, programming languages write your syntax for you!


> the semantics are in a different domain.

Meaning, semantics are outside the domain of programming languages? That's ... an intriguing idea.  I would like to subscribe to your newsletter. :-D


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!

> auto result = foo(), bar();

Does this compile? In variable declaration statement comma already has meaning as separator of declarators. Does it apply to enums too? This is difficult to parse.

On Thursday, 22 February 2018 at 10:42:33 UTC, Jonathan M Davis wrote:
> On Thursday, February 22, 2018 10:30:44 psychoticRabboit via Digitalmars-d- announce wrote:
>> On Thursday, 22 February 2018 at 09:42:47 UTC, Atila Neves wrote:
>> > I'm going to a) never write these imports and b) pretend this
>> > feature doesn't exist.
>> >
>> > Atila
>>
>> what about something like this then?
>>
>> import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever;
>>
>> just one simple rule; multiple imports on a line are seperated with ;
>>
>> surely the parser or whatever it's called, could work with that clean and simple solution.
>
> Honestly, I'm against importing multiple modules on a single line just like I'm against putting multiple variable declarations on a single line. They're harder to read and easier to screw up.
>
> - Jonathan M Davis

+1
I agree 100%

On Thu, Feb 22, 2018 at 09:42:13PM +0000, Zoadian via Digitalmars-d-announce wrote:
> On Thursday, 22 February 2018 at 10:42:33 UTC, Jonathan M Davis wrote:
> > On Thursday, February 22, 2018 10:30:44 psychoticRabboit via
[...]
> > > what about something like this then?
> > > 
> > > import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever;
> > > 
> > > just one simple rule; multiple imports on a line are seperated with ;
> > > 
> > > surely the parser or whatever it's called, could work with that clean and simple solution.

No it cannot. There's an ambiguity here: does the ';' mean the end of the import statement, or a delimiter between multiple modules? ';' cannot be used for this purpose.


> > Honestly, I'm against importing multiple modules on a single line just like I'm against putting multiple variable declarations on a single line. They're harder to read and easier to screw up.
[...]
> +1
> I agree 100%
[...]

+1. I agree 200%.  It's an eyesore, hard to read, easy to screw up, and worst of all, *completely unnecessary*. There's nothing new it offers that we cannot already do, and it's just adding redundant syntax for marginal benefit (if even).

I'm a little disappointed that a change like this got in, whereas something that's actually helpful, like DIP 1009, is sitting in limbo.


T

-- 
My program has no bugs! Only undocumented features...

On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:
Regarding the sheer amount of discussion I want to note that this was primarily seen as a regularization of the existing grammar.

import mod1, mod2 : sym1, sym2;

Certainly other languages have decided on a clearer syntax for selective imports, but that's what was chosen for D a long time ago.
Learning D you'll find that the selective import syntax is ambiguous in your first week, so I've stopped being annoyed by that some 5 years ago.

The main use-case for craming multiple imports into a line is not libraries but scripting, examples, and maybe unit tests.
And indeed the changelog entry could have been a bit clearer and easier to grasp.

----

Unfortunately it's a bit hard to find arguments in the discussion below, would have been cool if there were a few well argumented comments instead dozens of +1s.

- this grammar is ambiguous

  It has always been in various ways and that's annoying to learn when you first deal with D. Personally I find it even more annoying that you can mix imports and selective imports, but only in a very specific exception.

- why not X instead

  Go for it and try to find a consensus. I don't think the issue is big enough to warrant a huge design and bikeshedding discussion.

- each imported module should be on it's own line

  That's your opinion, my opinion is that importing 6 symbols from 6 different modules for a tiny cli tool sucks and bloats code example. So the alternative is to not use selective imports, but only those and static imports have a clear path to become lazy (https://issues.dlang.org/show_bug.cgi?id=13255).
  For projects and libraries it hardly matters, just adopt to the style-guide and existing code.
  Apparently I didn't use it a single time here https://github.com/MartinNowak/io, but all the time here https://github.com/MartinNowak/AoC17.
  Cannot say that it even took an active decision. It's just a very different mode if you want to quickly script sth. or if you set aside time to write a well-documented library.

- use std.experimental.scripting

  Indeed an alternative with a similar goal, reducing the amount of typing/noise for hacking. Importing all phobos modules will lead to a couple of symbol conflicts (e.g. write), and it still increases compile times and binary sizes noteably (though compile time is a lot better than it used to be).
  Not sure that this approach will pan out in the long-term, but a well curated package of the most used functions would indeed be helpful as of today.

- why hasn't this been a DIP

  Because it looked primarily like a minor grammar rectification that doesn't break anything and is entirely optional.
  Also DIPs are a crucial process for our language, and it seems problematic to clog it with trivialities.

----

On the other side please note that:

- you don't have to use it
- it will unlikely land in phobos' style-guide
- it's useful for talks, posts, code puzzles or on a repl where code is size constrained
- there is no ambiguity or chance for bugs
- practical examples of this usage are hardly confusing

  import std.stdio : writeln, std.algorithm : find;

- what's usually of relevance is the call-site not what you import
- there is syntax highlighting
- we're currently proliferating selective imports which cause a lot of D code to become very brittle
  (https://github.com/andralex/phobos/blob/cd3152c7bf4466e74b7fb9bd43d47e996caf5918/std/datetime/systime.d#L10076-L10083)
- remember that some people use `import mod1, mod2, mod3, mod4;` at least sometimes while others
  prefer each import on it's own line
- imports are mostly for tooling, less for humans
  - many java editors collapse the import manifest at the top
  - a lot of languages have an import std.* operator or auto-imports
  - you might want to automate import declarations at some point

And last but not least, the simpler the topic the more opinions, so please refrain from "I don't like it, +1" and leave space for actual arguments.

-Martin

On 2/22/2018 1:56 PM, H. S. Teoh wrote:
> I'm a little disappointed that a change like this got in, whereas
> something that's actually helpful, like DIP 1009, is sitting in limbo.

It's always true that trivia attracts far more attention and far more emotion than issues that require effort to understand.

On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
>
> Unfortunately it's a bit hard to find arguments in the discussion below, would have been cool if there were a few well argumented comments instead dozens of +1s.

Go back and read all of this thread, properly.


> - this grammar is ambiguous

Isn't that an argument?

>
>   It has always been in various ways and that's annoying to learn when you first deal with D. Personally I find it even more annoying that you can mix imports and selective imports, but only in a very specific exception.
>
> - why not X instead

Aren't alternative ideas welcome?


>   Go for it and try to find a consensus. I don't think the issue is big enough to warrant a huge design and bikeshedding discussion.
>

Some don't agree with you.

>
>   That's your opinion, my opinion is that importing 6 symbols from 6 different modules for a tiny cli tool sucks and bloats code example.


That's your opinion.


>
>   Indeed an alternative with a similar goal, reducing the amount of typing/noise for hacking.

You seem overly eager to save some typing, and the expense of comprehension.
I don't get it. That's what bring programming languages into disrepute.

>
> - why hasn't this been a DIP
>
>   Because it looked primarily like a minor grammar rectification that doesn't break anything and is entirely optional.

Go back are read the 'arguments' are but 'optional' aspect.

>   Also DIPs are a crucial process for our language, and it seems problematic to clog it with trivialities.

This doesn't seem that trivial based on the discussion.


> ----
>
> On the other side please note that:
>
> - you don't have to use it
> - it will unlikely land in phobos' style-guide
> - it's useful for talks, posts, code puzzles or on a repl where code is size constrained
> - there is no ambiguity or chance for bugs
> - practical examples of this usage are hardly confusing
>
>   import std.stdio : writeln, std.algorithm : find;

Seriously? You came up with the simplest example to demonstrate you're argument?


> - remember that some people use `import mod1, mod2, mod3, mod4;` at least sometimes while others
>   prefer each import on it's own line
> - imports are mostly for tooling, less for humans

That's your opinion. I happen to think that imports help people discover where stuff resides. I've learnt a lot from looking at imports used.


>   - many java editors collapse the import manifest at the top
>   - a lot of languages have an import std.* operator or auto-imports

That's why nobody know where anything is in the their library.


> And last but not least, the simpler the topic the more opinions, so please refrain from "I don't like it, +1" and leave space for actual arguments.

Again, go back and read this thread properly, and don't be so dismissive of the concerns people have expressed.

On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote:
> On the other side please note that:

Forgot one important point:

- practially unqualified modules are extremely rare, so the tiny ambiguous grammar case is hardly relevant.

On Friday, 23 February 2018 at 00:14:21 UTC, Walter Bright wrote:
> On 2/22/2018 1:56 PM, H. S. Teoh wrote:
>> I'm a little disappointed that a change like this got in, whereas
>> something that's actually helpful, like DIP 1009, is sitting in limbo.
>
> It's always true that trivia attracts far more attention and far more emotion than issues that require effort to understand.

Umm...this requires effort to understand (much more than it should) :

import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1;

Can anyone see why this created attention?

On Friday, 23 February 2018 at 00:47:10 UTC, psychoticRabbit wrote:
> On Friday, 23 February 2018 at 00:14:21 UTC, Walter Bright wrote:
>> On 2/22/2018 1:56 PM, H. S. Teoh wrote:
>>> I'm a little disappointed that a change like this got in, whereas
>>> something that's actually helpful, like DIP 1009, is sitting in limbo.
>>
>> It's always true that trivia attracts far more attention and far more emotion than issues that require effort to understand.
>
> Umm...this requires effort to understand (much more than it should) :
>
> import pkg.mod1 : sym1, sym2, pkg.mod2 : sym1, sym2, pkg.mod3 : sym1;
>
> Can anyone see why this created attention?

If can you don't know the answer, it's because it "requires effort to understand".