www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Types: The Next Generation (Was: Why is phobos so wack?)

reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 07/09/2017 09:26 AM, Adam D. Ruppe wrote:
 On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:
 return str.join(" ");
 [...]
 Error: template std.array.join cannot deduce function from argument
 types !()(string, string)
 [...]
 simply trying to join a string[] with a separator.
The error message sucks, but you clearly have a string when you meant string[].
Related to this, I've been giving some thought lately to a little bit of re-designing types themselves. Specifically, type creation tools that go beyond what structs and classes give us and allow better handling D-style generics. It's all very incomplete right now, but basically here's the gist: Awesome as D's generics, ranges, etc all are, they do make two things far more convoluted than when using basic straightforward types: Function declarations, and error messages when things don't match. So, why not encapsulate much of that stuff we merely *describe* in signatures for generic functions into genuine honest-to-goodness types? There would be user-defined symbols, such as "InputRange" or "SomeString", or "RandomAccessRange!SomeString", which the type system sees as actual types. And naturally there would be some mechanism for actually defining those types. Then, defining a function like this: SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...} ...would automatically imply to the compiler all (or at least a lot of) the pluming we usually clutter the function declaration with: Defining the templated types and calling the appropriate if(isBlahBlah) constraints. About the only things remaining would be additional constraints not already defined by the next-gen types, and restrictions on how the parameters relate to each other. Even better, having all that encapsulated into genuine types should make it easier for the compiler to provide better error messages. Thought could also be put into additional type-creation tools that cater specifically to common things (again, such as ranges) to help streamline the process of creating them (ranges are awesome, but let's face it, defining them can be a bother - there's gotta be some way to make it simpler. For example, input ranges especially would GREATLY benefit from being definable in the mannar of C# stackless coroutines). And of course, Nemerle-like (ML/Haskell-inspired) algebraics would be a wonderful capability to encorporate as well. Another area to explore would be merging the two sets of parameter lists (the compile-time list and the run-time list) into one list. Certain types would be known to imply "compile-time". A keyword/attr could be used to force compile-time or runtime. And for other params, a sufficiently-smart compiler could conceivably even choose "runtime" vs "compile-time" (or even, "it varies") based on optimization priorities. It would simplify the syntax for users, and help get around fear of templates. Obviously this is all very incomplete, but it's an idea I think is rather interesting.
Jul 09
next sibling parent reply Meta <jared771 gmail.com> writes:
On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky 
(Abscissa) wrote:
 On 07/09/2017 09:26 AM, Adam D. Ruppe wrote:
 On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:
 return str.join(" ");
 [...]
 Error: template std.array.join cannot deduce function from
argument
 types !()(string, string)
 [...]
 simply trying to join a string[] with a separator.
The error message sucks, but you clearly have a string when
you meant
 string[].
Related to this, I've been giving some thought lately to a little bit of re-designing types themselves. Specifically, type creation tools that go beyond what structs and classes give us and allow better handling D-style generics. It's all very incomplete right now, but basically here's the gist: Awesome as D's generics, ranges, etc all are, they do make two things far more convoluted than when using basic straightforward types: Function declarations, and error messages when things don't match. So, why not encapsulate much of that stuff we merely *describe* in signatures for generic functions into genuine honest-to-goodness types? There would be user-defined symbols, such as "InputRange" or "SomeString", or "RandomAccessRange!SomeString", which the type system sees as actual types. And naturally there would be some mechanism for actually defining those types. Then, defining a function like this: SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...} ...would automatically imply to the compiler all (or at least a lot of) the pluming we usually clutter the function declaration with: Defining the templated types and calling the appropriate if(isBlahBlah) constraints. About the only things remaining would be additional constraints not already defined by the next-gen types, and restrictions on how the parameters relate to each other. Even better, having all that encapsulated into genuine types should make it easier for the compiler to provide better error messages.
I'm sorry if I misunderstood what you're proposing, but isn't this exactly what C++ set out to do with concepts? If that's the case, I'd recommend you look up some of Andrei's refutation of concepts in favour of template guards and `static if`.
Jul 09
parent reply Nick Sabalausky <a a.a> writes:
On Sunday, 9 July 2017 at 20:42:39 UTC, Meta wrote:
 I'm sorry if I misunderstood what you're proposing, but isn't 
 this exactly what C++ set out to do with concepts? If that's 
 the case, I'd recommend you look up some of Andrei's refutation 
 of concepts in favour of template guards and `static if`.
Shit, I hope not :/ I gave up following C++ developments 15 years ago. Happen to have a link handy to that refutation?
Jul 09
parent reply Meta <jared771 gmail.com> writes:
On Sunday, 9 July 2017 at 21:59:04 UTC, Nick Sabalausky wrote:
 On Sunday, 9 July 2017 at 20:42:39 UTC, Meta wrote:
 I'm sorry if I misunderstood what you're proposing, but isn't 
 this exactly what C++ set out to do with concepts? If that's 
 the case, I'd recommend you look up some of Andrei's 
 refutation of concepts in favour of template guards and 
 `static if`.
Shit, I hope not :/ I gave up following C++ developments 15 years ago. Happen to have a link handy to that refutation?
There's a couple posts he's made here but a lot of it's spread out across various talks, articles (I think) as well as newsgroup posts. Here's what I found with a quick google: https://www.reddit.com/r/cpp/comments/4jqg5z/andrei_alexandrescu_on_c_concepts/ https://www.reddit.com/r/programming/comments/4jlkhv/accu_2016_keynote_by_andrei_alexandrescu/d391585/ And there's a ton of info on the internet about the C++ concepts proposal.
Jul 09
parent reply Nick Sabalausky <a a.a> writes:
On Sunday, 9 July 2017 at 22:02:51 UTC, Meta wrote:
 There's a couple posts he's made here but a lot of it's spread 
 out across various talks, articles (I think) as well as 
 newsgroup posts. Here's what I found with a quick google:

 https://www.reddit.com/r/cpp/comments/4jqg5z/andrei_alexandrescu_on_c_concepts/
 https://www.reddit.com/r/programming/comments/4jlkhv/accu_2016_keynote_by_andrei_alexandrescu/d391585/

 And there's a ton of info on the internet about the C++ 
 concepts proposal.
Ah, I guess it is very similar after all, except it'd be based on top of and coexist with all of D's design by introspection stuff (rather than exist without it as with C++), thus avoiding a lot of the downsides and getting best of both worlds.
Jul 09
next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
  On 07/09/2017 09:21 PM, Nick Sabalausky wrote:
 Ah, I guess it is very similar after all, except it'd be based on top of
 and coexist with all of D's design by introspection stuff (rather than
 exist without it as with C++), thus avoiding a lot of the downsides and
 getting best of both worlds.
Ha ha, I still feel more than a little silly for pitching what amounts to contracts as "an out-there idea I've been mulling over", but indulge in a little (partially-baked) taste to show this at least has some merit anyway. Hell, call it "concepts++" or "concepts, the D way" (note: I'm NOT pitching this as a suggestion for something D should do. Not saying D should or should'nt, just speaking purely in the realm of "langauge design brainstorming" here...Just because it's been on my mind and the "Why is phobos so wack?" thread brought some relevence) Behold! The power of combining constraints/design-by-introspection *with* concepts: Current declaration of std.array.join: --------------------------------------------------- ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, scope R sep) if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) && isInputRange!R && is(Unqual!(ElementType!(ElementType!RoR)) == Unqual!(ElementType!R))); ElementEncodingType!(ElementType!RoR)[] join(RoR, E)(RoR ror, scope E sep) if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) && is(E : ElementType!(ElementType!RoR))); ElementEncodingType!(ElementType!RoR)[] join(RoR)(RoR ror) if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR))); --------------------------------------------------- (ie, completely incomprehensible at-a-glance) Just one possibility of an entirely hypothetical D++ (assuming I'm even interpreting the D version correctly): --------------------------------------------------- // Note: This assumes the "ElementEncodingType vs ElementType" distinction // is nothing but a colossal mistake caused purely by the existance of // auto-decoding, which was (as an assumption this psuedo-code is predicated // upon) a complete clusterf*** of misdesign (Ie, *such* a huge stretch of // the imagination ;)), which in this hypothetical ideal langauge has // been killed dead with nuclear fire, and then beaten some more with // spiked crowbars, just to be sure. /++ Params: ror: an input range (or better) of input ranges (or better) of any type (shorthand for 'InputRange!InputRange!Type') sep: a separator that can be any input range ('InputRange!Type'). Returns: Shorthand for 'InputRange!Type': Ie, an input range (or better). Note: This is implicitly templated on typeof(ror) and typeof(sep). +/ InputRange join(InputRange!InputRange ror, InputRange sep) // Relationship constraints: if(UnqualTypeMatch!(ror, sep, return)) /++ Like above, but sep is 'Type' instead of 'InputRange!Type'. Since 'Type' is less specific than 'InputRange!Type', the prior overload is preferred. +/ InputRange join(InputRange!InputRange ror, Type sep) // Relationship constraints: if(unqualTypeMatch!(ror, InputRange!sep, return)) // No separator InputRange join(InputRange!InputRange ror) // Relationship constraints: if(unqualTypeMatch!(ror, return)) // Extra-special specialization: // Why multiple if() allowed? Because it makes the formatting less // of a mess, thus better readability. Good enough reason to me! InputRange join(InputRange!InputRange ror, Type sep) if(unqualTypeMatch!(ror, sep, return)) if(hasLength!typeof(sep)) { /+...take advantage of sep.length...+/ } // Note: Those constraints have further room for syntactical improvement. --------------------------------------------------- That example involves some additional things defined by the stdlib (*extremely* hypothetical syntax): --------------------------------------------------- concept InputRange(Element) { this() { // Current body of isInputRange here } // Most of isInputRange can *optionally* be replaced with: Element front(); void popFront(); bool empty(); } concept ForwardRange : InputRange // Builds upon InputRange { // Author can opt to do this (more powerful): this() { super.this(); typeof(this) x = this.save; } // Or this (more succinct): ForwardRange save(); } // *Anything*: A concrete (instatiable) type, or a templated // stand-in for a type (ie "T"), or an alias, or nothing at all. // Types *themselves* are first-class types! But implemented as // templates, rather than as runtime-OO. algebraic Any : Bottom; // An actual concrete type algrbraic Type : Any if(isType!this); // An actual concrete type? bool isType(Any any) {/+...introspection magic lies here...+/} // This is implicitly a template. bool unqualTypeMatch(InputRange!Any args...) { return args.map!(GetType).map!(Unqual).equal; } // If any is a static type, return any. // If any is a value, return typeof(any) // This is implicitly a template. Type GetType(Any any) { static if(typeof(any) == Type) return any; else return typeof(any); } --------------------------------------------------- Now, something like THAT is the language *I* would love to see. Obviously leaves a TON of details TBD, but one can dream ;)
Jul 09
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-07-10 07:54, Nick Sabalausky (Abscissa) wrote:
   On 07/09/2017 09:21 PM, Nick Sabalausky wrote:
  >
  > Ah, I guess it is very similar after all, except it'd be based on top of
  > and coexist with all of D's design by introspection stuff (rather than
  > exist without it as with C++), thus avoiding a lot of the downsides and
  > getting best of both worlds.
 
 Ha ha, I still feel more than a little silly for pitching what amounts 
 to contracts as "an out-there idea I've been mulling over", but indulge 
 in a little (partially-baked) taste to show this at least has some merit 
 anyway. Hell, call it "concepts++" or "concepts, the D way" (note: I'm 
 NOT pitching this as a suggestion for something D should do. Not saying 
 D should or should'nt, just speaking purely in the realm of "langauge 
 design brainstorming" here...Just because it's been on my mind and the 
 "Why is phobos so wack?" thread brought some relevence)
 
 Behold! The power of combining constraints/design-by-introspection 
 *with* concepts:
 
 Current declaration of std.array.join:
 
 ---------------------------------------------------
 ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, scope R sep)
 if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) && 
 isInputRange!R && is(Unqual!(ElementType!(ElementType!RoR)) == 
 Unqual!(ElementType!R)));
 
 ElementEncodingType!(ElementType!RoR)[] join(RoR, E)(RoR ror, scope E sep)
 if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) && is(E 
 : ElementType!(ElementType!RoR)));
 
 ElementEncodingType!(ElementType!RoR)[] join(RoR)(RoR ror)
 if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)));
 ---------------------------------------------------
 
 (ie, completely incomprehensible at-a-glance)
 
 Just one possibility of an entirely hypothetical D++ (assuming I'm even 
 interpreting the D version correctly):
 
 ---------------------------------------------------
 // Note: This assumes the "ElementEncodingType vs ElementType" distinction
 // is nothing but a colossal mistake caused purely by the existance of
 // auto-decoding, which was (as an assumption this psuedo-code is 
 predicated
 // upon) a complete clusterf*** of misdesign (Ie, *such* a huge stretch of
 // the imagination ;)), which in this hypothetical ideal langauge has
 // been killed dead with nuclear fire, and then beaten some more with
 // spiked crowbars, just to be sure.
 
 /++
    Params:
      ror: an input range (or better) of input ranges (or better) of
           any type (shorthand for 'InputRange!InputRange!Type')
      sep: a separator that can be any input range ('InputRange!Type').
    Returns: Shorthand for 'InputRange!Type': Ie, an input range (or 
 better).
    Note: This is implicitly templated on typeof(ror) and typeof(sep).
 +/
 InputRange join(InputRange!InputRange ror, InputRange sep)
    // Relationship constraints:
    if(UnqualTypeMatch!(ror, sep, return))
 
 /++
    Like above, but sep is 'Type' instead of 'InputRange!Type'.
    Since 'Type' is less specific than 'InputRange!Type', the prior overload
    is preferred.
 +/
 InputRange join(InputRange!InputRange ror, Type sep)
    // Relationship constraints:
    if(unqualTypeMatch!(ror, InputRange!sep, return))
 
 // No separator
 InputRange join(InputRange!InputRange ror)
    // Relationship constraints:
    if(unqualTypeMatch!(ror, return))
 
 // Extra-special specialization:
 // Why multiple if() allowed? Because it makes the formatting less
 // of a mess, thus better readability. Good enough reason to me!
 InputRange join(InputRange!InputRange ror, Type sep)
    if(unqualTypeMatch!(ror, sep, return))
    if(hasLength!typeof(sep))
    {  /+...take advantage of sep.length...+/ }
 
 // Note: Those constraints have further room for syntactical improvement.
 ---------------------------------------------------
 
 That example involves some additional things defined by the
 stdlib (*extremely* hypothetical syntax):
 
 ---------------------------------------------------
 concept InputRange(Element)
 {
      this()
      {
          // Current body of isInputRange here
      }
 
      // Most of isInputRange can *optionally* be replaced with:
      Element front();
      void popFront();
      bool empty();
 }
 
 concept ForwardRange : InputRange // Builds upon InputRange
 {
      // Author can opt to do this (more powerful):
      this()
      {
          super.this();
          typeof(this) x = this.save;
      }
 
      // Or this (more succinct):
      ForwardRange save();
 }
 
 // *Anything*: A concrete (instatiable) type, or a templated
 // stand-in for a type (ie "T"), or an alias, or nothing at all.
 // Types *themselves* are first-class types! But implemented as
 // templates, rather than as runtime-OO.
 algebraic Any : Bottom;
 
 // An actual concrete type
 algrbraic Type : Any
      if(isType!this);
 
 // An actual concrete type?
 bool isType(Any any) {/+...introspection magic lies here...+/}
 
 // This is implicitly a template.
 bool unqualTypeMatch(InputRange!Any args...)
 {
      return args.map!(GetType).map!(Unqual).equal;
 }
 
 // If any is a static type, return any.
 // If any is a value, return typeof(any)
 // This is implicitly a template.
 Type GetType(Any any)
 {
      static if(typeof(any) == Type)
          return any;
      else
          return typeof(any);
 }
 ---------------------------------------------------
 
 Now, something like THAT is the language *I* would love to see.
 
 Obviously leaves a TON of details TBD, but one can dream ;)
Something like this has been proposed several times before, but Andrei doesn't seem to like it. He think it's a failure that all the conditions need to have a name, or something like that. I prefer your approach. -- /Jacob Carlborg
Jul 10
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 07/10/2017 07:32 AM, Jacob Carlborg wrote:
 
 Something like this has been proposed several times before, but Andrei 
 doesn't seem to like it. He think it's a failure that all the conditions 
 need to have a name, or something like that. I prefer your approach.
 
Well, the nice thing about this approach (basing a concept-ish system *on top* of existing D-style design-by-introspection, as opposed to a C++-like concepts with no D-like features to complement it), is that it *doesn't* require every little variation to be named. For example, in the same psuedo-code I posted, there's a function (the last join() overload) that takes an input range, but requires the input range to support hasLength. But notice that there is NO symbol created or used anywhere for InputRangeWithLength. IIUC, it sounds like C++ concepts would require such a symbol to be created. But with this, that would not be needed. One thing to keep in mind is that we're ALREADY creating names for many (not all, but definitely some) of these things. In effect, *every* time we have an 'isXXXXX' function (isSomeString, isForwardRange, etc), we're already creating a name for it. We already implicitly understand that just because it's unrealisting to name *everything* (which, indicentally, reminds me of old Java class hierarchies), doesn't mean we can't or shouldn't name some things. The other important thing I want to emplasize yet again (just in case, because I know from experience in the past it's exactly this kind of point that rarely gets noticed), I'm not proposing D do this. It'd be far too big a change and it's far too incomplete to even think of trying to push. (Even tiny straightforward improvements to D face dowwnright epic levels of resistance any more.) So again, it's just some brainstorming. Maybe D several decades from now, maybe some other language inspired by D, maybe nothing ever, whatever.
Jul 10
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-07-10 19:54, Nick Sabalausky (Abscissa) wrote:

 Well, the nice thing about this approach (basing a concept-ish system
 *on top* of existing D-style design-by-introspection, as opposed to a
 C++-like concepts with no D-like features to complement it), is that it
 *doesn't* require every little variation to be named.

 For example, in the same psuedo-code I posted, there's a function (the
 last join() overload) that takes an input range, but requires the input
 range to support hasLength. But notice that there is NO symbol created
 or used anywhere for InputRangeWithLength. IIUC, it sounds like C++
 concepts would require such a symbol to be created. But with this, that
 would not be needed.

 One thing to keep in mind is that we're ALREADY creating names for many
 (not all, but definitely some) of these things. In effect, *every* time
 we have an 'isXXXXX' function (isSomeString, isForwardRange, etc), we're
 already creating a name for it. We already implicitly understand that
 just because it's unrealisting to name *everything* (which,
 indicentally, reminds me of old Java class hierarchies), doesn't mean we
 can't or shouldn't name some things.
I agree, it's not me that need convincing :)
 The other important thing I want to emplasize yet again (just in case,
 because I know from experience in the past it's exactly this kind of
 point that rarely gets noticed), I'm not proposing D do this. It'd be
 far too big a change and it's far too incomplete to even think of trying
 to push. (Even tiny straightforward improvements to D face dowwnright
 epic levels of resistance any more.) So again, it's just some
 brainstorming. Maybe D several decades from now, maybe some other
 language inspired by D, maybe nothing ever, whatever.
Here I disagree. I think that D should have something like this. -- /Jacob Carlborg
Jul 10
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 07/10/2017 02:55 PM, Jacob Carlborg wrote:
 On 2017-07-10 19:54, Nick Sabalausky (Abscissa) wrote:
 The other important thing I want to emplasize yet again (just in case,
 because I know from experience in the past it's exactly this kind of
 point that rarely gets noticed), I'm not proposing D do this. It'd be
 far too big a change and it's far too incomplete to even think of trying
 to push. (Even tiny straightforward improvements to D face dowwnright
 epic levels of resistance any more.) So again, it's just some
 brainstorming. Maybe D several decades from now, maybe some other
 language inspired by D, maybe nothing ever, whatever.
Here I disagree. I think that D should have something like this.
Oh, I didn't mean to imply that I wouldn't love to have it in D (assuming it was all well-fleshed out and didn't have big problems). I just wanted to be crystal clear that I'm merely discussing a langauge design idea here rather than coming in saying "Hey, you people should all like this idea and go implement it put it into D!!!" It's easy for things to get taken that way here, and can result in knee-jerk reactions and otherwise derailing of what's really only intended as a theoretical academic discussion. If something *were* to come of it, and it worked great, and everybody was happy, then fantastic. That's just not what I'm bringing it up for, that's all.
Jul 10
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 07/10/2017 04:14 PM, Nick Sabalausky (Abscissa) wrote:
 
 Oh, I didn't mean to imply that I wouldn't love to have it in D 
 (assuming it was all well-fleshed out and didn't have big problems). I 
 just wanted to be crystal clear that I'm merely discussing a langauge 
 design idea here rather than coming in saying "Hey, you people should 
 all like this idea and go implement it put it into D!!!" It's easy for 
 things to get taken that way here, and can result in knee-jerk reactions 
 and otherwise derailing of what's really only intended as a theoretical 
 academic discussion. If something *were* to come of it, and it worked 
 great, and everybody was happy, then fantastic. That's just not what I'm 
 bringing it up for, that's all.
I especially wanted to avoid any the "How dare you even consider speaking of something without fully implementing it first!" that tends to be common here. (Speaking of, *that* sort of thing is far more unprofessional than the mere "bad words" some people are so terrified of).
Jul 10
parent Jacob Carlborg <doob me.com> writes:
On 2017-07-10 22:19, Nick Sabalausky (Abscissa) wrote:
 On 07/10/2017 04:14 PM, Nick Sabalausky (Abscissa) wrote:
 Oh, I didn't mean to imply that I wouldn't love to have it in D 
 (assuming it was all well-fleshed out and didn't have big problems). I 
 just wanted to be crystal clear that I'm merely discussing a langauge 
 design idea here rather than coming in saying "Hey, you people should 
 all like this idea and go implement it put it into D!!!" It's easy for 
 things to get taken that way here, and can result in knee-jerk 
 reactions and otherwise derailing of what's really only intended as a 
 theoretical academic discussion. If something *were* to come of it, 
 and it worked great, and everybody was happy, then fantastic. That's 
 just not what I'm bringing it up for, that's all.
I especially wanted to avoid any the "How dare you even consider speaking of something without fully implementing it first!" that tends to be common here. (Speaking of, *that* sort of thing is far more unprofessional than the mere "bad words" some people are so terrified of).
Fair enough. -- /Jacob Carlborg
Jul 10
prev sibling next sibling parent reply bpr <brogoff gmail.com> writes:
On Monday, 10 July 2017 at 01:21:08 UTC, Nick Sabalausky wrote:
 Ah, I guess it is very similar after all, except it'd be based 
 on top of and coexist with all of D's design by introspection 
 stuff (rather than exist without it as with C++), thus avoiding 
 a lot of the downsides and getting best of both worlds.
You've seen this, right? https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template instantiation, but that's another DIP for another time.
Jul 10
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 07/10/2017 11:58 AM, bpr wrote:
 
 You've seen this, right?
 
 https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint
 
 A small step in one such direction, influenced by C++ concepts. That 
 proto-DIP also raises a question I always had about why D doesn't allow 
 chained template instantiation, but that's another DIP for another time.
 
Yea, I've seen that. It'd be a nice improvent for D and I'm definitely in favor of it. It doesn't especially excite me though just because it's a small incremental change and creates further syntactical differences between handling runtime-oriented symbols and compile-time-oriented symbols. Ie, I'd prefer "InputRange r" over "T r if InputRange" because it's vastly simpler and more consistent with non-templated variable declarations. But in a practical sense, that's be a much more major and difficult to retrofit that onto D, so the DIP sounds like an appropriate (if unexciting) direction for D to take. But what I find much more interesting than that DIP (again, from a purely academic standpoint) is taking all of these abilities and finding a way simplify them, while retaining all of their power, and create more overall consistency[1]. (That was *exactly* one of my big original draws to D in the first place - it took C++, then cleaned it all up and enhanced it. I have interest in brainstorming the same for D. I think there's been enough practical experience using D at this point for more streamlined designs to now be possible.) [1] Heck, on the consistency front, it even bugs the hell out of me when people do "foo()" to call/define a function, but then deliberately stick with "if ()"-style instead for keywords. Both are "identifier followed by parens", but whether or not a space is added between is *different* depending on whether the identifier is a symbol or a keyword. Unnecessary inconsistency. Maybe it's all the puzzle games I've played over my lifetime, but...want...to...simplify... ;)
Jul 10
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Monday, 10 July 2017 at 01:21:08 UTC, Nick Sabalausky wrote:
 Ah, I guess it is very similar after all, except it'd be based 
 on top of and coexist with all of D's design by introspection 
 stuff (rather than exist without it as with C++), thus avoiding 
 a lot of the downsides and getting best of both worlds.
You've seen this, right? https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template instantiation, but that's another DIP for another time.
Jul 10
prev sibling parent reply bpr <brogoff gmail.com> writes:
On Monday, 10 July 2017 at 01:21:08 UTC, Nick Sabalausky wrote:
 Ah, I guess it is very similar after all, except it'd be based 
 on top of and coexist with all of D's design by introspection 
 stuff (rather than exist without it as with C++), thus avoiding 
 a lot of the downsides and getting best of both worlds.
You've seen this, right? https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template instantiation, but that's another DIP for another time.
Jul 10
parent bpr <brogoff gmail.com> writes:
On Monday, 10 July 2017 at 16:16:40 UTC, bpr wrote:
 On Monday, 10 July 2017 at 01:21:08 UTC, Nick Sabalausky wrote:
 Ah, I guess it is very similar after all, except it'd be based 
 on top of and coexist with all of D's design by introspection 
 stuff (rather than exist without it as with C++), thus 
 avoiding a lot of the downsides and getting best of both 
 worlds.
You've seen this, right? https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template instantiation, but that's another DIP for another time.
Sorry about the repeat posting, I could observe the software hiccuping on my browser...
Jul 10
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky 
(Abscissa) wrote:
 SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...}
Looks like concepts. We've settled on leveraging the already useful template constraints (at best in CNF [¹]) for better error messages. It's on the Agenda for later this year [²]. [¹]: https://github.com/dlang/phobos/pull/5461 [²]: https://wiki.dlang.org/Vision/2017H2_draft
Jul 10
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 07/10/2017 09:16 AM, Martin Nowak wrote:
 On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky (Abscissa) wrote:
 SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...}
Looks like concepts. We've settled on leveraging the already useful template constraints (at best in CNF [¹]) for better error messages. It's on the Agenda for later this year [²]. [¹]: https://github.com/dlang/phobos/pull/5461 [²]: https://wiki.dlang.org/Vision/2017H2_draft
Sounds nice. But I'm getting the distinct impression people are missing that I never actually proposed that D itself should do this. It's just academic brainstorming.
Jul 10
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky 
(Abscissa) wrote:
 Obviously this is all very incomplete, but it's an idea I think 
 is rather interesting.
You've seen this, right? https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint A small step in one such direction, influenced by C++ concepts. That proto-DIP also raises a question I always had about why D doesn't allow chained template instantiation, but that's another DIP for another time.
Jul 10
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 9 Jul 2017 16:22:16 -0400
schrieb "Nick Sabalausky (Abscissa)"
<SeeWebsiteToContactMe semitwist.com>:

 [=E2=80=A6] a sufficiently-smart compiler could conceivably even
 choose "runtime" vs "compile-time" (or even, "it varies")
 based on optimization priorities.
GCC already does this, i.e. find runtime arguments of constant value and generate a second instance of the function with that argument optimized out. --=20 Marco
Jul 10
prev sibling parent Mark <smarksc gmail.com> writes:
On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky 
(Abscissa) wrote:
 So, why not encapsulate much of that stuff we merely *describe* 
 in signatures for generic functions into genuine 
 honest-to-goodness types?

 There would be user-defined symbols, such as "InputRange" or 
 "SomeString", or "RandomAccessRange!SomeString", which the type 
 system sees as actual types. And naturally there would be some 
 mechanism for actually defining those types. Then, defining a 
 function like this:

 SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...}

 ...would automatically imply to the compiler all (or at least a 
 lot of) the pluming we usually clutter the function declaration 
 with: Defining the templated types and calling the appropriate 
 if(isBlahBlah) constraints. About the only things remaining 
 would be additional constraints not already defined by the 
 next-gen types, and restrictions on how the parameters relate 
 to each other.

 Even better, having all that encapsulated into genuine types 
 should make it easier for the compiler to provide better error 
 messages.
This reminds me of the "RAII vs. scope" arguments that came up on the forum a few times (see e.g. [1]). Many of the features in D (and other programming languages) can be theoretically (and practically, in some languages) implemented using the type system: resource management, template constraints, in/out contracts, function attributes (pure, nothrow, etc.), I/O streams, error handling, and probably others. This is sometimes profitable and sometimes not so much. If you're using some concept all over your code then encapsulating it in a type can reduce code duplication, improve readability and let you exploit various features of the type system to your benefit (e.g. subtyping: A RandomAccessRange being a subtype of InputRange, exception hierarchies, etc.). But if you're only using it once or twice then it's probably not worth the hassle. That is, the issue is scale. My general impression is that C++ tries (and often succeeds, pyrrhically) to do pretty much everything using the type system (specifically, classes): Resources, exceptions, iterators, interfaces, initialization lists, ... Almost everything is encapsulated in a type. Concepts (Lite) seem to me like a way to further enrich the type system, although concepts aren't exactly types. My opinion, in a nutshell, is that "ad-hocish" facilities like template constraints, the scope statement, contracts, etc. don't scale up, while more formal facilities like concepts, RAII, etc. don't scale *down*. As such, there is a need for both of them. With respect to the specific issue of ranges, I don't know Phobos well enough to have an opinion as to whether or not they should be made more formal (as types/concepts/...). The error messages should be more clear and precise, but I'm not convinced that an overhaul of the system is necessary to achieve that. [1] https://forum.dlang.org/post/tlsrpqvfeepcfbyfqzge forum.dlang.org
Jul 15