September 29, 2020
On 9/29/20 11:35 AM, ddcovery wrote:
> Hi Steve,
> 
> I agree, I really appreciate your point and I understand it is difficult to an experienced D developer to understand my point.
> 
> My "difficulty" (I assume it is my problem) is when reading documentation about methods returning "auto"... it's hard, at the beginning, to transform this mentally in something I can understand (trying not to hide mentally the information)... D plasticity differs to other simplest "generics" type systems (like Scala) and you need double effort to understand it.
> 
> An added difficulty  (that I don't know if the "swift developers" will suffer with xcode) is the missing of a good "autocomplete" or "type inference" that helps developers to understand the type that an "auto" function is really returning in the context of an evocation (i.e.: Right now, I am working with flutter/dart and vscode shows me the inferred type of a variable when hovering with the mouse).
> 

I am not NEW NEW, but new enough that I remember precisely the feeling you are describing; you are right on with respect to one of the hardest mental barriers in the D learning curve.

This [`auto` being used to simplify complex return types; and the notion of potentially very complex template-generated return types in general, especially as a componetn of the stdlib] is something that I think would improve visibility and adoption if it were explicitly addressed in tutorials, documentation, books, etc.

September 29, 2020
On Tue, Sep 29, 2020 at 04:11:29PM +0000, Dukc via Digitalmars-d wrote: [...]
> -Using templates and defining simple ones is easy and tidy. But defining really good templates tends to get difficult. Look at Phobos source code: complex template constraints.
[...]

IMO, overly-complex and opaque sig constraints is a sign that the template was not properly designed. A lot of the complex constraints in Phobos leak implementation details and really should belong in static ifs inside the function body.  This malady is often accompanied by an excessive number of overloads of the template function, many of which have no obvious reason why they are separate overloads, the reason having to do with implementation details that the user really shouldn't need to see or know about.

Properly-written sig constraints should be very straightforward and simple to understand -- it should accept all types in the class of logically-acceptable types.  Any types in that class that cannot be accepted due to implementation details or case-specific reasons really should be handled by static asserts in the function body, accompanied by a message explaining why that type cannot be used -- rather than obscure, unreadably complex sig constraints that, when they fail, generate equally obscure, unreadably-long template-not-matched error messages.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
September 29, 2020
On Tuesday, 29 September 2020 at 16:57:52 UTC, H. S. Teoh wrote:
>> Look at Phobos source code: complex template constraints.
> [.> IMO, overly-complex and opaque sig constraints is a sign that the template was not properly designed. A lot of the complex constraints in Phobos leak

Agreed. This will benefit compile times aswell.
September 29, 2020
On Tue, Sep 29, 2020 at 05:08:17PM +0000, Per Nordlöw via Digitalmars-d wrote:
> On Tuesday, 29 September 2020 at 16:57:52 UTC, H. S. Teoh wrote:
> > > Look at Phobos source code: complex template constraints.
> > [.> IMO, overly-complex and opaque sig constraints is a sign that the template was not properly designed. A lot of the complex constraints in Phobos leak
> 
> Agreed. This will benefit compile times aswell.

I doubt it will benefit compile times (evaluating sig constraints vs static ifs pretty much make no difference to the compiler), but at least it will make Phobos templates more user-friendly!


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
September 29, 2020
On Tue, Sep 29, 2020 at 12:52:30PM -0400, James Blachly via Digitalmars-d wrote: [...]
> This [`auto` being used to simplify complex return types; and the notion of potentially very complex template-generated return types in general, especially as a componetn of the stdlib] is something that I think would improve visibility and adoption if it were explicitly addressed in tutorials, documentation, books, etc.

Yeah, this needs to be addressed head-on, rather than skirted around or deferred to the reference docs.  I think a lot of newcomers to D wouldn't have the concept of opaque types that they don't need to know explicitly yet can use effectively.  That's a pretty advanced concept rarely found in other languages; it would do a lot of good to explain this concept right from the get-go.


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC
September 29, 2020
On Tuesday, 29 September 2020 at 09:56:47 UTC, Petar Kirov [ZombineDev] wrote:
> I think one extravagant, but definetely workable solution would be create a template DSL (ofc it could also be string mixin-based) in D to prototype a multiple
> inheritance system (with e.g. the Eiffel features `rename`, `export`, `undefine`, `redefine` / `override`, and `select`). Being just a prototype, it should be acceptable to go with custom functions like `isSubTypeOf`, `asBaseType`, etc., instead of using the built-in language syntax and semantics. (Sort of like https://code.dlang.org/packages/openmethods adds multiple dispatch.)

This is an interesting idea, basically implement the Eiffel compiler (the OO part) as a D library, and perhaps also use openmethods, then we will have a Lisp's multi-methods + Eiffel OO inheritance.

I'm not sure how complex this implementation is going to look like.


Hey, as I mentioned here:

https://forum.dlang.org/post/ufypgxzckjdstifhlrtk@forum.dlang.org

many (if not all) Eiffel compilers actually compile Eiffel program to C (as target language).

I just uploaded SmartEiffel (open source) 1.1 compiler, and my previous visitor example to:

https://github.com/mingwugmail/dlang_tour/tree/master/eiffel

e.g. the generated C code of my example is:

https://github.com/mingwugmail/dlang_tour/blob/master/eiffel/visitor/app1.c


We can use D compiler's `-betterC` option to build it, the we are done :-)

September 29, 2020
On 29/9/20 19:20, H. S. Teoh wrote:
> On Tue, Sep 29, 2020 at 12:52:30PM -0400, James Blachly via Digitalmars-d wrote:
> [...]
>> This [`auto` being used to simplify complex return types; and the
>> notion of potentially very complex template-generated return types in
>> general, especially as a componetn of the stdlib] is something that I
>> think would improve visibility and adoption if it were explicitly
>> addressed in tutorials, documentation, books, etc.
> 
> Yeah, this needs to be addressed head-on, rather than skirted around or
> deferred to the reference docs.  I think a lot of newcomers to D
> wouldn't have the concept of opaque types that they don't need to know
> explicitly yet can use effectively.  That's a pretty advanced concept
> rarely found in other languages; it would do a lot of good to explain
> this concept right from the get-go.
> 
> 
> T
> 

I think this is an area were "concepts" [1] would shine. It would be cool if there were some kind of "statically typed interface" that you would declare as a type, exposing the needed functionality, and that would hide the implementation details. Something like this (AIUI the UDA makes possible even to leave out `auto`):

```
@models!(isInputRange) foo = ....; // Very long UCFS chain.
```

This would tell you all that you should reasonably need to know about the type, while still allowing lower level access if needed, because the actual type would remain unchanged. Also, it would statically check that the guarantees are kept, i.e. that if a template is supposed to return an input range, it actually does without some corner case silently breaking `empty`, for instance.

It would be great then if the IDE tools could make use of this, and even more to have a more compact syntax built-in into the language.

A.

[1]: https://code.dlang.org/packages/concepts
September 29, 2020
On Tuesday, 29 September 2020 at 17:33:47 UTC, mw wrote:
> On Tuesday, 29 September 2020 at 09:56:47 UTC, Petar Kirov [ZombineDev] wrote:
>> I think one extravagant, but definetely workable solution would be create a template DSL (ofc it could also be string mixin-based) in D to prototype a multiple
>> inheritance system (with e.g. the Eiffel features `rename`, `export`, `undefine`, `redefine` / `override`, and `select`). Being just a prototype, it should be acceptable to go with custom functions like `isSubTypeOf`, `asBaseType`, etc., instead of using the built-in language syntax and semantics. (Sort of like https://code.dlang.org/packages/openmethods adds multiple dispatch.)
>
> This is an interesting idea, basically implement the Eiffel compiler (the OO part) as a D library, and perhaps also use openmethods, then we will have a Lisp's multi-methods + Eiffel OO inheritance.
>
> I'm not sure how complex this implementation is going to look like.

There are precedents to this approach. One is fairly well known: CLOS, which is an object system that supports open multi-methods and multiple inheritance (and method combination, which I don't find very convincing). CLOS is written entirely in Common Lisp.

Another example is COS: the C Object System (https://github.com/CObjectSystem/COS). COS is pretty much CLOS written in C and CPP macros.

D is a great language for experimenting with language features. Maybe not as good as Lisp (at least currently) but certainly much better than C. I know at least two examples: Atila's tardy (golang-style interfaces) and my own openmethods.

Regarding mutliple inheritance, I have always been convinced that it was a good feature. Or rather, that restricting inheritance to single is completely unnatural. My very first open source project was a modified version of Microsoft's MFC library that supported multiple inheritance.

I think that C++ got something right: sometimes we need shared inheritance, and sometimes repeated inheritance. Although, in my experience, I rarely needed repeated inheritance. CLOS, in contrast, gives you only one option, namely, shared inheritance. On the other hand, C++ makes the sharing of a base a property of the inheritance relationship (virtual inheritance), not of the base. So, if a base is inherited non-virtually in an inheritance lattice, it becomes impossible to request only one copy when merging hierarchies. Perhaps it should be up to the deriving class to specify the inheritance lattice, including which sub-objects are shared and which are repeated.

Anyway, back to mw's post, I am pretty sure that it is possible to write a fairly good CLOS in D.

September 29, 2020
On Tuesday, 29 September 2020 at 18:26:42 UTC, Jean-Louis Leroy wrote:
>> This is an interesting idea, basically implement the Eiffel compiler (the OO part) as a D library, and perhaps also use openmethods, then we will have a Lisp's multi-methods + Eiffel OO inheritance.
>>
>> I'm not sure how complex this implementation is going to look like.
...
> Anyway, back to mw's post, I am pretty sure that it is possible to write a fairly good CLOS in D.

Good to hear, I opened an discussion issue here:

https://github.com/jll63/openmethods.d/issues/19

Anyone who's interested in the implementation, let's continue the brain storming there.
September 29, 2020
On Tuesday, 29 September 2020 at 18:38:29 UTC, mw wrote:
> [snip]
>
> Good to hear, I opened an discussion issue here:
>
> https://github.com/jll63/openmethods.d/issues/19
>
> Anyone who's interested in the implementation, let's continue the brain storming there.

You might recall that back in June I wrote [1] that D does not have the ability to properly disable base members and member functions, which would make implementing Eiffel-like semantics significantly easier as part of the base language.

[1] https://forum.dlang.org/post/tpwwzkvcarqquqslspul@forum.dlang.org