On 11.04.2017 19:43, Walter Bright wrote:
> On 4/11/2017 4:39 AM, rjframe wrote:
>> I have no problem with this specific change, but this method of solving
>> problems is going to turn D into a horrible language with all kinds of
>> weird edge cases. I left Python for D mostly because the language was
>> becoming one hack built on top of another; it would be nice if D could
>> avoid that path. The occasional kludge may be necessary, but it shouldn't
>> be normal or the first thought.
>
> On the other hand, overly principled languages tend to not be as
> successful, because what people need to do with programs is often dirty.
>
> Monads, and "functional reactive programming", are obtuse things

They are actually obvious things that happen to usually be explained in the language of PL researchers, who are not always interested in creating a popular system.

> that
> come about when a functional programming language requires 100% purity
> and immutability.
> ...

Haskell does not do that. Why do you think it does?

> Back in the 80's, like everyone else, I went about creating a GUI user
> interface library. I discovered something interesting - what is
> orthogonal and consistent to a computer is anything but when dealing
> with people. What people view as orthogonal and consistent is a rat's
> nest of exceptions in the code to implement it. This is what makes a
> user interface library fiendishly difficult to pull off.
> ...

Would you mind sharing an example?

> Language design is like that, too.
>

But there is an objective standard of generality, orthogonality and
consistency, set by examples like pure type systems (such as CoC), or
even just the inference rules of first-order logic.

> I hear what you're saying, and agree in principle. That is why this
> feature comes with no new syntax, and existing code should "just work"
> with it to the largest extent possible.

The benefit is that "throw new Exception" becomes @nogc.

In terms of orthogonality and consistency, the proposal does not do so well:

- Orthogonality of 'throw' and 'new' is removed.

- Built-in new being @nogc sometimes but not at other times is inconsistent.

I think this is true for both computers and users.

I don't feel strongly about whether or not the proposal should be accepted as it does not really affect me, but it is a trade-off.

On 4/14/2017 3:41 PM, Timon Gehr wrote:
> Haskell does not do that. Why do you think it does?

Do what? I did not mention Haskell.

>> Back in the 80's, like everyone else, I went about creating a GUI user
>> interface library. I discovered something interesting - what is
>> orthogonal and consistent to a computer is anything but when dealing
>> with people. What people view as orthogonal and consistent is a rat's
>> nest of exceptions in the code to implement it. This is what makes a
>> user interface library fiendishly difficult to pull off.
>> ...
>
> Would you mind sharing an example?

It was 30 years ago. I don't remember specifics, but I can think of one - the tab key. It means different things depending on what box you're in. Some more thoughts - is a box in a fixed position, or is it movable? Is a box user-resizeable or not? Is the size of a box determined by its content do do you throw up scroll bars? or maybe relay out the contents? How do fonts affect this? How about screen resolution? Which parts of a box should be selectable with cut operations and which not? It just goes on and on.

There's the famous Windows 'start' button which you click on to turn the computer off. Of course, it is consistent from a programming point of view, because it starts the shutdown program.

In any case, look at English. It is not remotely consistent, and drives programmers to fits trying to parse it. But people find it intuitive.

>But people find it intuitive.

This is a terrible example as English is anything but intuitive. Just ask any ESL student.

No human language is intuitive, which is why we strive to create intuitiveness and regularity in the languages we create, programming or otherwise.

If D ever becomes a fraction as messy and inconsistent as English, we will know that we have failed. I personally see this language change as a step in that direction, but I am not strongly invested either way.

On Sunday, 9 April 2017 at 03:26:14 UTC, Walter Bright wrote:
> My previous version did not survive implementation. Here's the revised version. I have submitted it as a DIP, and there's a trial implementation up:
>
> [...]

Maybe someone already explained this or the reason is obvious, but why couldn't we use @nogc to make Exceptions refcounted as opposed to needing to specifically use

    throw new Exception();

On 15.04.2017 01:29, Walter Bright wrote:
> On 4/14/2017 3:41 PM, Timon Gehr wrote:
>> Haskell does not do that. Why do you think it does?
>
> Do what?

Require 100% purity and immutability. (You're underquoting.)

> I did not mention Haskell.
> ...

You said "come about when". Those things "came about" in Haskell.

This is the original monad paper (in an fp context): homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf

(The paper mentions other programming languages in the intro, but it is easy to discover that this is just a courtesy/a way to establish relevance.)

This is the original FRP paper: http://conal.net/papers/icfp97/

>>> Back in the 80's, like everyone else, I went about creating a GUI user
>>> interface library. I discovered something interesting - what is
>>> orthogonal and consistent to a computer is anything but when dealing
>>> with people. What people view as orthogonal and consistent is a rat's
>>> nest of exceptions in the code to implement it. This is what makes a
>>> user interface library fiendishly difficult to pull off.
>>> ...
>>
>> Would you mind sharing an example?
>
> It was 30 years ago. I don't remember specifics, but I can think of one
> - the tab key. It means different things depending on what box you're
> in.

Inserting a tab character vs. moving to the next box?

> Some more thoughts - is a box in a fixed position, or is it movable?
> Is a box user-resizeable or not? Is the size of a box determined by its
> content do do you throw up scroll bars? or maybe relay out the contents?
> How do fonts affect this? How about screen resolution? Which parts of a
> box should be selectable with cut operations and which not? It just goes
> on and on.
> ...

I see. Maybe that is why I dislike using GUIs so much. :)

> There's the famous Windows 'start' button which you click on to turn the
> computer off. Of course, it is consistent from a programming point of
> view, because it starts the shutdown program.
>
> In any case, look at English. It is not remotely consistent, and drives
> programmers to fits trying to parse it. But people find it intuitive.
>

People get used to convoluted behaviours especially when in large groups. Synthetic languages are a great deal more orthogonal and consistent, because this is actually useful. I don't buy that aiming for inconsistencies is a way to make a system more intuitive when the user didn't have prior exposure to a similar system. Monads being unpopular has no bearing on whether the proposed feature is intuitive. (It isn't. There is a lot of precedent for a lack of explicit monads, but none for the proposal.)

On 4/14/2017 10:04 PM, Timon Gehr wrote:
> I don't buy that aiming for inconsistencies is a way to
> make a system more intuitive when the user didn't have prior exposure to a
> similar system.

Please propose a better design.

On Thursday, 13 April 2017 at 05:29:28 UTC, Dukc wrote:
> The reason it needs:
>
> {   scope Object ob = new RefCountableType("foo");
>     scope ob2 = ob;
>     ob = new RefCountableType("bar");
> }
>
> The "foo" instance would leak if the destruction would be done by calling at end of scope.

I assume you mean if the compiler calls `delete ob` just before }. What I described would be implemented by the compiler deleting the original value of ob just before }.

On 15.04.2017 10:45, Walter Bright wrote:
> On 4/14/2017 10:04 PM, Timon Gehr wrote:
>> I don't buy that aiming for inconsistencies is a way to
>> make a system more intuitive when the user didn't have prior exposure
>> to a
>> similar system.
>
> Please propose a better design.

I'm criticizing the justification, not the design. (Hence OT.)

What I'm saying is that there is no way that lack of orthogonality/consistency can be an argument in favour of the design.

The arguments in favour of the design (that I can see) are that it is simple, easy to explain, easy to implement, easy to ignore, that it works around the problem, and that it is your own.

On 15.04.2017 07:04, Timon Gehr wrote:
>
> You said "come about when". Those things "came about" in Haskell.
>
> This is the original monad paper (in an fp context):
> homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf

Actually, it is this one: https://page.mi.fu-berlin.de/scravy/realworldhaskell/materialien/the-essence-of-functional-programming.pdf

On Sunday, 9 April 2017 at 20:14:24 UTC, Walter Bright wrote:
> ... a general mechanism for safe refcounting of classes has eluded us.

Regardless of my other comments, which are maybe a little uninformed, DIP74 seems pretty good:

https://wiki.dlang.org/DIP74

Manu started a thread asking about it, but that thread dissolved into a bitter dispute:

http://forum.dlang.org/post/mailman.1002.1444519548.22025.digitalmars-d@puremagic.com

The only valuable information regarding the question was in this post of Andrei's, which did not say very much:

http://forum.dlang.org/post/mvgoa9$1gda$1@digitalmars.com

So what are the corner cases of DIP74? What are the actual problems with it?