In the feedback thread H. S. Teoh is talking about that we need a new/better version of Phobos. I remember having read the same in a comment on some PR recently. How would this better version look like? Is there allready any picture of what we do want? One says, if you don't know the goal, all paths are the wrong ones...

A few things that I remember from various sources:

* Some improvement in the realm of ranges.
* Replacement of some old modules. (std.xml, std.outbuffer, std.socket, what else?)
* Adding some missing modules (std.eventloop, std.database, what else?)
* Unifying some modules (everything covering selfinspection, like std.traits and so on, whar else?)

Anything more?

On Wednesday, 16 October 2019 at 17:20:28 UTC, berni44 wrote:
> In the feedback thread H. S. Teoh is talking about that we need a new/better version of Phobos. I remember having read the same in a comment on some PR recently. How would this better version look like? Is there allready any picture of what we do want? One says, if you don't know the goal, all paths are the wrong ones...
>
> A few things that I remember from various sources:
>
> * Some improvement in the realm of ranges.
> * Replacement of some old modules. (std.xml, std.outbuffer, std.socket, what else?)
> * Adding some missing modules (std.eventloop, std.database, what else?)
> * Unifying some modules (everything covering selfinspection, like std.traits and so on, whar else?)
>
> Anything more?

Getting rid of autodecoding is another big one.

On 17/10/2019 6:20 AM, berni44 wrote:
> In the feedback thread H. S. Teoh is talking about that we need a new/better version of Phobos. I remember having read the same in a comment on some PR recently. How would this better version look like? Is there allready any picture of what we do want? One says, if you don't know the goal, all paths are the wrong ones...
> 
> A few things that I remember from various sources:
> 
> * Some improvement in the realm of ranges.
> * Replacement of some old modules. (std.xml, std.outbuffer, std.socket, what else?)
> * Adding some missing modules (std.eventloop, std.database, what else?)
> * Unifying some modules (everything covering selfinspection, like std.traits and so on, whar else?)
> 
> Anything more?

I expect to start work on std.eventloop as part of the (informal) graphics workgroup soon-ish (although it may not end up as part of Phobos).

However my main concern with developing a new version of Phobos is isInputRange and friends will still exist. Unless the language has a better way of describing it e.g. signatures we may as well call it an incremental improvement not a new version.

On Thu, Oct 17, 2019 at 10:59:11AM +1300, rikki cattermole via Digitalmars-d wrote: [...]
> However my main concern with developing a new version of Phobos is isInputRange and friends will still exist. Unless the language has a better way of describing it e.g. signatures we may as well call it an incremental improvement not a new version.

What's wrong with isInputRange?


T

-- 
"Hi." "'Lo."

On 17/10/2019 11:16 AM, H. S. Teoh wrote:
> On Thu, Oct 17, 2019 at 10:59:11AM +1300, rikki cattermole via Digitalmars-d wrote:
> [...]
>> However my main concern with developing a new version of Phobos is
>> isInputRange and friends will still exist. Unless the language has a
>> better way of describing it e.g. signatures we may as well call it an
>> incremental improvement not a new version.
> 
> What's wrong with isInputRange?
> 
> 
> T
> 

So these sorts of "functions" are aggregates of behavior and properties that require reading the source code to know fully what it entails.

Yes, aggregates of behavior can be complex, and it does make sense to use "functions" to do it. But the key difference here is if you can describe what most of the behaviors and properties are to the compiler it can produce better error messages but also allow code to be more descriptive. I.e.

/// Docs go here
signature InputRange(@named ElementType) {
	@property {
		/// Docs go here
		ElementType front();

		/// Docs go here
		bool empty();
	}

	/// Docs go here
	void popFront();
}

void func(T:InputRange)(T myInputRange) {}

The above uses DIP1020 just to make this conversation a little easier to understand (ElementType will be inferred automatically from the implementation).

And because we have described what an input range is in terms of an interface, we can use it as a value typed vtable that yes can work in -betterC.

Something like this should enable us to have better documentation using much simpler looking features without hiding away details in the source code.

On Wednesday, 16 October 2019 at 22:34:00 UTC, rikki cattermole wrote:
>
> /// Docs go here
> signature InputRange(@named ElementType) {
> 	@property {
> 		/// Docs go here
> 		ElementType front();
>
> 		/// Docs go here
> 		bool empty();
> 	}
>
> 	/// Docs go here
> 	void popFront();
> }
>
> void func(T:InputRange)(T myInputRange) {}
>


The experimental.typecons has an incomplete modification to wrap. It allows wrapping a structure into an interface if it conforms. If the edge cases were worked out then similar logic would be applicable to the function signature.

...) if(implements!(InputRange, R))

What would be nice from the language is the ability to print a message if no template matching occurs. Remember if it does not match it is just pulled from overload resolution.

On 17/10/2019 1:36 PM, Jesse Phillips wrote:
> 
> On Wednesday, 16 October 2019 at 22:34:00 UTC, rikki cattermole wrote:
>>
>> /// Docs go here
>> signature InputRange(@named ElementType) {
>>     @property {
>>         /// Docs go here
>>         ElementType front();
>>
>>         /// Docs go here
>>         bool empty();
>>     }
>>
>>     /// Docs go here
>>     void popFront();
>> }
>>
>> void func(T:InputRange)(T myInputRange) {}
>>
> 
> 
> The experimental.typecons has an incomplete modification to wrap. It allows wrapping a structure into an interface if it conforms. If the edge cases were worked out then similar logic would be applicable to the function signature.
> 
> ...) if(implements!(InputRange, R))
> 
> What would be nice from the language is the ability to print a message if no template matching occurs. Remember if it does not match it is just pulled from overload resolution.

That works for matching an implementation to an interface.

It does miss out on better error messages and any ability to let the interface override or extend the implementation (e.g. extraction of ElementType from front or using the declared type in body of the implementation).

I.e.

signature InputRange(@named ElementType = ElementTypeCompat!(typeof(this)) { ... }

Not to mention it forces what amounts to idiomatic D into a second class position in many use cases. Not preferable IMO.

On Thursday, 17 October 2019 at 00:46:12 UTC, rikki cattermole wrote:
>
> I.e.
>
> signature InputRange(@named ElementType = ElementTypeCompat!(typeof(this)) { ... }
>
> Not to mention it forces what amounts to idiomatic D into a second class position in many use cases. Not preferable IMO.

auto foo(R, E = ElementType!R)() if(implements!(InputRange!E, R))

That seems pretty idiomatic D.

Now as you said, it doesn't improve the error message. But what if the language changed so it could?

On 17/10/2019 4:32 PM, Jesse Phillips wrote:
> On Thursday, 17 October 2019 at 00:46:12 UTC, rikki cattermole wrote:
>>
>> I.e.
>>
>> signature InputRange(@named ElementType = ElementTypeCompat!(typeof(this)) { ... }
>>
>> Not to mention it forces what amounts to idiomatic D into a second class position in many use cases. Not preferable IMO.
> 
> auto foo(R, E = ElementType!R)() if(implements!(InputRange!E, R))
> 
> That seems pretty idiomatic D.

And that's the problem, for what is very common, it is absolutely horrible code.

> Now as you said, it doesn't improve the error message. But what if the language changed so it could?

That would require flow analysis and it won't give good names to different aspects.

We have done research into template constraints and to improve the error messages there. But aggregate checks like isInputRange and with that implements, the compiler can't understand it even with flow analysis sadly.

Right now there is no way to communicate to the compiler the human aspects of a concept. Sure we can do the technical, but that only gets us so far (which we have been doing).

This is what I am arguing for, a way to communicate to the compiler the human aspects of a concept. The behaviors and properties it must exhibit to match our mental model, not the compilers model.

On Wednesday, 16 October 2019 at 17:20:28 UTC, berni44 wrote:
> In the feedback thread H. S. Teoh is talking about that we need a new/better version of Phobos. I remember having read the same in a comment on some PR recently. How would this better version look like? Is there allready any picture of what we do want? One says, if you don't know the goal, all paths are the wrong ones...
>
> A few things that I remember from various sources:
>
> * Some improvement in the realm of ranges.
> * Replacement of some old modules. (std.xml, std.outbuffer, std.socket, what else?)
> * Adding some missing modules (std.eventloop, std.database, what else?)
> * Unifying some modules (everything covering selfinspection, like std.traits and so on, whar else?)
>
> Anything more?

I'd like Phobos to be something like Go's stdlib in a sence that a lot of the stuff needed for day to day programming would be builtin. Crypto stuff, compression stuff, https stuff and etc.