Bug 14704 – The design, which allows not to write import, import, import ... for selective imports
Status
RESOLVED
Resolution
WONTFIX
Severity
enhancement
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-06-16T15:37:00Z
Last change time
2017-07-05T14:57:15Z
Assigned to
nobody
Creator
dennis.m.ritchie
Comments
Comment #0 by dennis.m.ritchie — 2015-06-16T15:37:09Z
Now we can write this:
import std.stdio : write, writeln;
import std.range : retro, repeat;
But why write several times a keyword `import`, if you can add a similar design:
import {
std.stdio : write, writeln;
std.range : retro, repeat;
// ...
}
import {
std.stdio, std.range,
std.array : array;
// ...
}
Some background here:
http://forum.dlang.org/thread/[email protected]https://issues.dlang.org/show_bug.cgi?id=13855
Comment #1 by ketmar — 2015-06-17T10:04:18Z
change for the sake of change. that rare case when i see nothing wrong with the current situation, and the change doesn't add any value.
Comment #2 by dennis.m.ritchie — 2015-06-17T13:38:27Z
(In reply to Ketmar Dark from comment #1)
> change for the sake of change. that rare case when i see nothing wrong with
> the current situation, and the change doesn't add any value.
I understand that you do not have any experience in sports programming. If you like to write so, please, can go on:
http://codeforces.com/contest/545/submission/11617706
I want to write so:
http://codeforces.com/contest/548/submission/11291102
And at the same time I want to import some functions of selective imports!!!
It's not necessary to make any huge change. Just turn on a similar design, as in Go. It made a human being and not outdated canons of C++.
This design does not prevent you from using outdated canons of C++, the normal programmers can write in the normal!
Comment #3 by ketmar — 2015-06-17T14:43:47Z
(In reply to dennis.m.ritchie from comment #2)
> I understand that you do not have any experience in sports programming.
sure. it's plainly stupid, as most other "sports activity".
> It's not necessary to make any huge change. Just turn on a similar design,
> as in Go.
"as in Go" is a clear sign of "done for dummies".
> This design does not prevent you from using outdated canons of C++, the
> normal programmers can write in the normal!
i must confess that "normal programmers" have exactly zero problems with current import.
Comment #4 by dennis.m.ritchie — 2015-06-17T15:30:39Z
(In reply to Ketmar Dark from comment #3)
> [...]
OK. I formulate the question differently :) If D add the following syntax:
import {
std.math,
std.conv,
std.stdio : doutln = writeln, dout = write;
std.ascii,
std.range : iota, retro;
std.array : array;
std.regex,
std.format : format;
std.bigint : big = BigInt;
std.traits,
std.random : uniform;
std.string : split;
std.numeric,
std.variant,
std.typecons,
std.container,
std.algorithm,
std.typetuple,
std.exception,
core.checkedint;
}
Surely then you will continue to write it? :o)
import std.math;
import std.conv;
import std.stdio : doutln = writeln, dout = write;
import std.ascii;
import std.range : iota, retro;
import std.array : array;
import std.regex;
import std.format : format;
import std.bigint : big = BigInt;
import std.traits;
import std.random : uniform;
import std.string : split;
import std.numeric;
import std.variant;
import std.typecons;
import std.container;
import std.algorithm;
import std.typetuple;
import std.exception;
import core.checkedint;
At the moment, I do not import some functions because it is very time consuming for each Olympiad programming write `import`,` import`, `import`.
And if you have this problem does not occur, it does not mean that it does not arise from the thousands of other people. And I see that Olympiad C ++ programmers write `#include`, #include`,` #include`.
The D is a good modular system, so why should we continue to write as in C++, but not in Go.
Did I suggest something bad? Something leading to the past? After D plans to become easier and more powerful than C++. And this design will make it even easier to use D. It starts with small things, but not with any global problems. Not made in one place easier and better, then why do better elsewhere? There was even no progress without some little things...
Comment #5 by dennis.m.ritchie — 2015-06-17T15:39:32Z
it's so easily doable with simple parser and string mixins, so i can't see any sense in changing the compiler.
Comment #7 by dennis.m.ritchie — 2015-06-17T17:23:03Z
(In reply to Ketmar Dark from comment #6)
> it's so easily doable with simple parser and string mixins, so i can't see
> any sense in changing the compiler.
No one (I repeat, `Nobody`) and will never write like this:
//////////////////////////////////////////////
mixin template include(w...)
{
mixin _include!(w.length - 1, w);
}
mixin template _include(long N, i...)
{
mixin("import " ~ i[N] ~ ";");
mixin _include!(N - 1, i);
}
mixin template _include(long N : 0, i...)
{
mixin("import " ~ i[N] ~ ";");
}
mixin include!(
"std.stdio : writeln, write",
"std.conv : to"
);
void main() {
writeln(to!string(7));
}
//////////////////////////////////////////////
And I'll bet that if D is such a design, almost all and will always write like this:
//////////////
import {
// ...
}
//////////////
I'll never be implemented through the hagfish such things on contests for sports programming, because it is very time consuming. And, yes, in the end I'll never import individual modules and thousands of people (since D becomes popular) in their projects on GitHub will not import the individual functions of the modules so that they will be too lazy to write `import`,` import`, ` import` ...
Do not believe me? And I would argue that it will be so. I understand that changes to the compiler requires a lot of work, but still it's worth it to thousands of people were able to write properly ...
And besides, there is a good principle:
`At the end I want to focus on one philosophical principle, which lies at the basis of my ideas about the ideal programming language. Typically, during the discussion in the forums, when you start to talk in a language that is not X features Y, be sure there is someone who will say: Why, that's if you take the features A, B and C, and screw them crutches D, E, F, then we will get almost Y. Yes, it is. But I do not like this approach. One can imagine that such programmers want some complicated way through the maze. You can go through the maze, but the way the curve and non-obvious. I also want to be instead of the labyrinth has a large area, on which from any point to any other one would go in a straight line. Simply pryamoy.`
And yes. Before you dismiss this issue, think about whether you want to thousands of programmers on GitHub would not be able to import the individual functions of the modules in their projects. And all this because someone did not want to make a small addition to the compiler. I do not want too much to do, but I do it.
And in this case, I think not only about himself but about globolnoy problem. After the changes in the language are reflected in thousands of programmers, thousands!
Comment #8 by dennis.m.ritchie — 2015-06-17T17:27:06Z
(In reply to dennis.m.ritchie from comment #7)
> I'll never be implemented through the hagfish...
Google translator substituted the word `mixins` on `hagfish` :)
Comment #9 by ketmar — 2015-06-17T17:39:35Z
you know what? people invented a great thing called "library", so you can move the code you're using in various places to the library and stop copypasting it everywhere.
and yoy know what else is interesting? i found myself stop doing bulk imports. it's way easier to write a qualified import right in the code block where you need that, and import only the things you need. bulk imports is a sign of bad design. stop doing that, local imports rox. your multiline sample should be burned with fire.
Comment #10 by ketmar — 2015-06-17T17:41:36Z
p.s. to have your #7 right, do "s/programmer/code monkey/" on it.
Comment #11 by dennis.m.ritchie — 2015-06-17T18:00:34Z
(In reply to Ketmar Dark from comment #9)
> you know what? people invented a great thing called "library", so you can
> move the code you're using in various places to the library and stop
> copypasting it everywhere.
You understand that a huge number of serious programming contests are not allowed to use the internet, so your option to copypasting disappears.
> and yoy know what else is interesting? i found myself stop doing bulk
> imports. it's way easier to write a qualified import right in the code block
> where you need that, and import only the things you need. bulk imports is a
> sign of bad design. stop doing that, local imports rox. your multiline
> sample should be burned with fire.
Yes, I agree that local imports are very comfortable in the production code (though not always):
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/sorting.d#L66-L71
But another thing Olympiad programming. Contests are very common, so all write multidimensional imports to not bathe for nothing :)
(In reply to Ketmar Dark from comment #10)
> p.s. to have your #7 right, do "s/programmer/code monkey/" on it.
Alas, most programmers are `code monkeys`, so I'm right! :)
Comment #12 by ketmar — 2015-06-17T19:22:30Z
(In reply to dennis.m.ritchie from comment #11)
> But another thing Olympiad programming.
the last thing in the world language designers should think of.
Comment #13 by dennis.m.ritchie — 2015-06-17T19:26:08Z
(In reply to Ketmar Dark from comment #12)
> the last thing in the world language designers should think of.
But what about the thousands of people with GitHub? :)
Comment #14 by ketmar — 2015-06-18T10:35:12Z
(In reply to dennis.m.ritchie from comment #13)
> But what about the thousands of people with GitHub? :)
i don't see any solid evidences that changing import syntax is the thing they dreaming about. for now that's only your speculation that you have to prove.
Comment #15 by dennis.m.ritchie — 2015-06-18T11:49:42Z
(In reply to Ketmar Dark from comment #14)
> (In reply to dennis.m.ritchie from comment #13)
> > But what about the thousands of people with GitHub? :)
> i don't see any solid evidences that changing import syntax is the thing
> they dreaming about. for now that's only your speculation that you have to
> prove.
You write so as if the changes in the compiler should do you.
I think you need to take a vacation :)
Comment #16 by ketmar — 2015-06-18T12:10:27Z
i'm writing like the only person that see a sense in talking about that. i was hoped that it is a clear hint about importance and acceptance of your proposal. and i was trying to moving you to geting a solid facts to support your proposal. yet i see that there is nothing behind it except "i'm tired to write bulk imports in my code, and my code editor can't even copy-paste one simple word".
besides, there already was a discussion about something similar, and the answer was "no".
i will not close this ER as "resolved/invalid" only 'cause it doesn't make any difference. you have no PR to support it, and it's unlikely that anybody will write such PR.
Comment #17 by dennis.m.ritchie — 2015-06-18T12:42:20Z
Do you agree that one of the directions D - is to write less code than required C++? I really like this way of D.
So why do we have to write more code than you need, in this place?
Comment #18 by dennis.m.ritchie — 2015-06-18T12:48:21Z
tired_eyes wrote:
`If we have shorthand syntax for full imports, why there is no option for shorthand partial imports? This is expected behavior.`
What is not an argument?
Comment #19 by ketmar — 2015-06-18T14:01:43Z
(In reply to dennis.m.ritchie from comment #17)
> Do you agree that one of the directions D - is to write less code than
> required C++?
nope.
(In reply to dennis.m.ritchie from comment #18)
> `If we have shorthand syntax for full imports, why there is no option for
> shorthand partial imports? This is expected behavior.`
>
> What is not an argument?
this is not an argument, this is exactly the "i wan't it 'cause i want it".
Comment #20 by dennis.m.ritchie — 2015-06-18T14:16:07Z
(In reply to Ketmar Dark from comment #19)
> (In reply to dennis.m.ritchie from comment #17)
> > Do you agree that one of the directions D - is to write less code than
> > required C++?
> nope.
Quote of the documentation:
`The main "chip" of the language can be considered as an abundance of syntax, intended to reduce the program's source code (templates, mixins, etc.) and a variety of keywords to test and debug code.`
http://wiki.dlang.org/Reading_the_documentation_%28in_Russian%29#.D0.92.D0.B2.D0.B5.D0.B4.D0.B5.D0.BD.D0.B8.D0.B5
Many people believe that a short code is a distinctive chip D. If you do not think so, then I have to assume that your quibbles are absolutely groundless.
> (In reply to dennis.m.ritchie from comment #18)
> > `If we have shorthand syntax for full imports, why there is no option for
> > shorthand partial imports? This is expected behavior.`
> >
> > What is not an argument?
> this is not an argument, this is exactly the "i wan't it 'cause i want it".
In order to make something better, to find bold argument :)
If you like to write 50 lines instead of 10, it does not make you some kind of guru, and the people who come up with the right design to Go - code monkeys.
Comment #21 by dennis.m.ritchie — 2015-06-18T14:20:23Z
And I want to ask you another question: "Why do not need to add this syntax in D?"
Comment #22 by dennis.m.ritchie — 2015-06-18T14:29:04Z
(In reply to Ketmar Dark from comment #16)
> besides, there already was a discussion about something similar, and the
> answer was "no".
Prior to that, decisions have been bad enough. My solution solves this problem quite well and most complete.
Comment #23 by r9shackleford — 2015-06-18T14:31:09Z
I think this is a good idea, maybe you should bring it up on the main NG.
Comment #24 by ketmar — 2015-06-18T14:34:49Z
(In reply to dennis.m.ritchie from comment #20)
> (In reply to Ketmar Dark from comment #19)
> > (In reply to dennis.m.ritchie from comment #17)
> > > Do you agree that one of the directions D - is to write less code than
> > > required C++?
> > nope.
>
> Quote of the documentation:
> `The main "chip" of the language can be considered as an abundance of
> syntax, intended to reduce the program's source code (templates, mixins,
> etc.) and a variety of keywords to test and debug code.`
> http://wiki.dlang.org/Reading_the_documentation_%28in_Russian%29#.D0.92.D0.
> B2.D0.B5.D0.B4.D0.B5.D0.BD.D0.B8.D0.B5
>
> Many people believe that a short code is a distinctive chip D. If you do not
> think so, then I have to assume that your quibbles are absolutely groundless.
that is not what you asked, and that doesn't means what you think it means.
> > (In reply to dennis.m.ritchie from comment #18)
> > > `If we have shorthand syntax for full imports, why there is no option for
> > > shorthand partial imports? This is expected behavior.`
> > >
> > > What is not an argument?
> > this is not an argument, this is exactly the "i wan't it 'cause i want it".
>
> In order to make something better, to find bold argument :)
"better" has no universal definition, so this is not an argument.
> If you like to write 50 lines instead of 10, it does not make you some kind
> of guru, and the people who come up with the right design to Go - code
> monkeys.
import a;
import b;
import c;
three lines.
import {
a;
b;
c;
}
five lines.
i think that discussion can be closed now.
Comment #25 by dennis.m.ritchie — 2015-06-18T14:49:58Z
(In reply to Ketmar Dark from comment #24)
> import a;
> import b;
> import c;
>
> three lines.
>
> import {
> a;
> b;
> c;
> }
>
> five lines.
>
> i think that discussion can be closed now.
Firstly, the design proposed by me, intended to separate import function module, and not in order to make this substitution:
import a, b, c;
Secondly, I can write so if at this point I take into your head use this syntax:
import {
a, b, c;
}
27 characters (with '\n' 30 characters):
import a;
import b;
import c;
The design proposed by me, not intended for this (15 characters — with '\t' and '\n' 23 characters):
import {
a;
b;
c;
}
My design solves this problem:
import {
a : foo;
b : bar;
c : baz;
}
My design allows you to write less characters and is more readable than:
import a : foo;
import b : bar;
import c : baz;
Comment #26 by dennis.m.ritchie — 2015-06-18T14:56:54Z
At the moment, we can only write this:
import a, b, c : baz;
And we can not write this:
import a : foo, b : bar, c : baz;
So do not be, because it is completely unreadable (if a lot of modules - a comma separates bad visibility modules, as it was written in the topic of Martin Novak):
import a : foo, b : bar, c : baz;
https://issues.dlang.org/show_bug.cgi?id=13855
My version allows you to write perfectly readable code with a semicolon:
import {
a : foo;
b : bar;
c : baz;
}
Comment #27 by dennis.m.ritchie — 2015-06-18T15:07:39Z
(In reply to weaselcat from comment #23)
> I think this is a good idea, maybe you should bring it up on the main NG.
Where can I do it? I understand that it's here somewhere:
news.digitalmars.com
Sorry, but I don't know how to enter :)
Comment #28 by ketmar — 2015-06-18T18:49:00Z
(In reply to dennis.m.ritchie from comment #25)
> My design ... is more readable
no.
Comment #29 by dennis.m.ritchie — 2015-06-18T19:34:46Z
(In reply to Ketmar Dark from comment #28)
> (In reply to dennis.m.ritchie from comment #25)
> > My design ... is more readable
> no.
For you it is more readable:
import std.stdio : write, writeln, readf, std.range : iota, chain, std.algorithm : sort, copy, fill;
what is this?
import {
std.stdio : write, writeln, readf;
std.range : iota, chain;
std.algorithm : sort, copy, fill;
}
I recall that in D there is no any other option, but there is a stump:
import std.stdio, std.range, std.algorithm : sort, copy, fill;
Maybe you're a racist?
http://ketmar.no-ip.org/
I see a sign on your website. A normal person would not allow himself to write such nonsense:
http://i.imgur.com/T2lMf0f.png
And I do not want to hear your opinion nagging. And dispose of, please, I'm picky on your opinion, if you are not obvious obvious.
Comment #30 by ketmar — 2015-06-18T20:27:19Z
(In reply to dennis.m.ritchie from comment #29)
> For you it is more readable:
>
> import std.stdio : write, writeln, readf, std.range : iota, chain,
> std.algorithm : sort, copy, fill;
>
> what is this?
>
> import {
> std.stdio : write, writeln, readf;
> std.range : iota, chain;
> std.algorithm : sort, copy, fill;
> }
this:
import std.stdio : write, writeln, readf;
import std.range : iota, chain;
import std.algorithm : sort, copy, fill;
> Maybe you're a racist?
yes, i am. do you feel offended? i'm glad. and i'm glad that you ran out of silly arguments and start personal attacks.
Comment #31 by dennis.m.ritchie — 2015-06-18T21:08:57Z
(In reply to Ketmar Dark from comment #30)
> yes, i am. do you feel offended? i'm glad. and i'm glad that you ran out of
> silly arguments and start personal attacks.
No, I'm not offended. I just really funny. You behave like a baby :)
You do not understand that the Russian people are very strong nerves, so the writing on your website only amuses me. And besides, nobody canceled the VPN. And I believe that politicians in the programming can not be.
Comment #32 by r9shackleford — 2015-06-18T21:47:16Z
don't argue with ketmar, nothing productive will come out of it.
Comment #33 by ketmar — 2015-06-19T03:19:48Z
(In reply to dennis.m.ritchie from comment #31)
so i was right: you choose to go personal 'cause you have zero technical arguments. thanks for not hiding that fact.
Comment #34 by dennis.m.ritchie — 2015-06-22T19:52:52Z
(In reply to Ketmar Dark from comment #33)
> (In reply to dennis.m.ritchie from comment #31)
> so i was right: you choose to go personal 'cause you have zero technical
> arguments. thanks for not hiding that fact.
This is a real project:
https://shardsoft.com/stash/projects/SHARD/repos/dap/browse/source/dap/Standalone.d
Why 29 times to copy the keyword `import`, if you can write only once?
Comment #35 by dennis.m.ritchie — 2015-06-22T19:58:25Z
(In reply to dennis.m.ritchie from comment #34)
> Why 29 times to copy the keyword `import`, if you can write only once?
Proper programming is ergonomic programming!
Comment #36 by dlang-bugzilla — 2017-07-05T14:57:15Z
Hello,
Changes to the language need to be proposed through the DIP process:
https://github.com/dlang/DIPs
Bugzilla is not the correct place for language enhancements.
If you still believe your proposal has merit, please submit a DIP. The current DIP manager can assist you through the process.