On Sunday, 10 July 2016 at 02:29:15 UTC, Andrei Alexandrescu wrote:
> Yeah, we'd ideally like very little UB and no UB in safe code.

no at all. define it, and for other cases raise an error. for the example given, the code should not compile. at all. cast the thing to ubyte or face the error. and even then, compiler should insert runtime check for not shifting more than 31/63 bits, just like it does for bounds. at least it should do that in @safe code.

On Sunday, 10 July 2016 at 02:44:14 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 9 July 2016 at 08:39:10 UTC, Walter Bright wrote:
>> Seems that in order to make it useful, users had to extend it. This doesn't fit the criteria.
>
> Scheme is a simple functional language which is easy to extend. Why would you conflate "useful" with "used for writing complex programs"?
>
> Anyway, there are many other examples, but less known.
>
>> Wirth's Pascal had the same problem. He invented an elegant, simple, consistent, and useless language. The usable Pascal systems all had a boatload of dirty, incompatible extensions.
>
> I am not sure if Pascal is elegant, but it most certainly is useful. So I don't think I agree with your definition of "useful".
>
Original Pascal was useless. You could not even have separate compilation, there were no strings (packed array of chars of fixed size two arrays of differing size were not compatible, so impossible to write a procedure or a function without defining them for all possible packed array sizes). It became useful thanks to the extensions added by UCSD (units) and the by Turbo Pascal (strings).

On Sunday, 10 July 2016 at 04:13:07 UTC, Meta wrote:
> I agree with Walter here. Scheme is not a language that you can generally do useful things in. If you want to do anything non-trivial, you switch to Racket (which is not as minimalistic and "pure" as Scheme).

Define what you mean by a useful and clean language? I take useful to mean that it has been used for useful programming. And clean that it follows a principled and coherent design.

Both Scheme and Pascal are useful. Scheme is also elegant. For any reasonable definition of "useful" and "elegant".

If you compare D to other languages you'll find a wide array of languages that are useful and way more principled than D.

"useful" is not a good excuse for not cleaning up a develpment environment.

On Sunday, 10 July 2016 at 08:03:03 UTC, Patrick Schluter wrote:
> Original Pascal was useless. You could not even have separate compilation, there were no strings (packed array of chars of fixed size two arrays of differing size were not compatible, so impossible to write a procedure or a function without defining them for all possible packed array sizes). It became useful thanks to the extensions added by UCSD (units) and the by Turbo Pascal (strings).

I've never used the original Pascal, but Pascal dialects were widely implemented and very useful for memory constrained devices. Having a fixed memory layout was common and useful for memory constrained devices. On such devices you use the diskette for storage and manually page in/out disk sectors, or simply live with fixed limits, which is typically better than frequent out-of-memory situations.

On 7/9/2016 7:44 PM, Ola Fosheim Grøstad wrote:
> On Saturday, 9 July 2016 at 08:39:10 UTC, Walter Bright wrote:
>> Seems that in order to make it useful, users had to extend it. This
>> doesn't fit the criteria.
>
> Scheme is a simple functional language which is easy to extend.

If they have to extend it, it isn't Scheme anymore. I bet you don't use Scheme, either.


>> Wirth's Pascal had the same problem. He invented an elegant, simple,
>> consistent, and useless language. The usable Pascal systems all had a
>> boatload of dirty, incompatible extensions.
>
> I am not sure if Pascal is elegant, but it most certainly is useful.

The original Pascal, which you said you'd never used. I have.


> So I don't think I agree with your definition of "useful".

Try and write a program in Wirth's Pascal that reads a character from the keyboard.


>> What programmers think of as "intuitive" is often a collection of
>> special cases.
> I think I would need examples to understand what you mean here.

Dangling else is a classic.

< > for template parameters in C++.

infix notation

On 7/10/16 2:29 AM, ketmar wrote:
> On Sunday, 10 July 2016 at 02:29:15 UTC, Andrei Alexandrescu wrote:
>> Yeah, we'd ideally like very little UB and no UB in safe code.
>
> no at all. define it, and for other cases raise an error.

How do you define use of a pointer after deallocation? -- Andrei

On Saturday, 9 July 2016 at 22:20:22 UTC, Timon Gehr wrote:
> On 09.07.2016 06:39, Andrew Godfrey wrote:
>> On Friday, 8 July 2016 at 21:23:24 UTC, Timon Gehr wrote:
>>> On 08.07.2016 04:25, Andrew Godfrey wrote:
>>>>
>>>> Another example is "return" used for monads in eg Haskell - even if it
>>>> only has one meaning in Haskell, it is too mixed up with a different
>>>> meaning in other common languages. D's "static if" - which is a killer
>>>> feature if I ignore the keyword - gives me a similar feeling (though
>>>> it's much less egregious than "return" in monads).
>>>
>>> 'return' in Haskell is perfectly fine.
>>
>> This (long) talk does a good job of explaining the problem with using
>> the name 'return' in monads.
>>
>> https://www.infoq.com/presentations/functional-pros-cons#downloadPdf
>> ...
>
> The reason you linked to this (long) talk instead of a more digestible source is that the presenter manages to bring across his flawed argumentation in a way that is charismatic enough to fool a biased audience.
>
> It's a reasonable name. 'return' creates a computation that returns the given value. This is a different corner in language design space, why should C constrain Haskell's design in any way?
>
>> Others have said it shorter.
>
> Thanks for providing the links to that material.
>
>> I took this example because it crosses
>> languages. Of course we can't avoid clashing with other languages, there
>> are only so many keywords to use. But there's definitely a principle
>> here worth considering, that is if you care about D adoption.
>> ...
>
> I was complaining about the cheap shot at Haskell. This has become way too fashionable.

Sorry I chose such a charged example. It's not a cheap shot in my case, I have waded through a number of "monad tutorials" and criticisms of monad tutorials, and that talk summed up my experience. But I really can't claim that monads would be easy to learn if they used better naming.
Easier maybe, but they could still be difficult.

Actually maybe Haskell is more relevant as an example to talk about "overreaching features" - like Haskell's lazy evaluation. In D, GC, auto-decode, and dynamic arrays have overreached IMO. But I'm hard pressed to think of something to write in a long-term vision about that. (E.g. I like how Phobos is adopting ranges. Wouldn't want to slow that down. But maybe we're blind to the downsides!) So... you're right, I have no useful suggestions to make after beating on Haskell. :)

On Sunday, 10 July 2016 at 11:49:31 UTC, Andrei Alexandrescu wrote:
> On 7/10/16 2:29 AM, ketmar wrote:
>> On Sunday, 10 July 2016 at 02:29:15 UTC, Andrei Alexandrescu wrote:
>>> Yeah, we'd ideally like very little UB and no UB in safe code.
>>
>> no at all. define it, and for other cases raise an error.
>
> How do you define use of a pointer after deallocation? -- Andrei

bug. error. big boom. note that compiler is allowed to not check that, though, and only *then* it is UB -- only if compiler is not implementing that part of the specs.

On 07/10/2016 08:25 AM, ketmar wrote:
> On Sunday, 10 July 2016 at 11:49:31 UTC, Andrei Alexandrescu wrote:
>> On 7/10/16 2:29 AM, ketmar wrote:
>>> On Sunday, 10 July 2016 at 02:29:15 UTC, Andrei Alexandrescu wrote:
>>>> Yeah, we'd ideally like very little UB and no UB in safe code.
>>>
>>> no at all. define it, and for other cases raise an error.
>>
>> How do you define use of a pointer after deallocation? -- Andrei
>
> bug. error. big boom.

Great spec :o) -- Andrei

On Sunday, 10 July 2016 at 11:21:49 UTC, Walter Bright wrote:
> On 7/9/2016 7:44 PM, Ola Fosheim Grøstad wrote:
>> On Saturday, 9 July 2016 at 08:39:10 UTC, Walter Bright wrote:
>>> Seems that in order to make it useful, users had to extend it. This
>>> doesn't fit the criteria.
>>
>> Scheme is a simple functional language which is easy to extend.
>
> If they have to extend it, it isn't Scheme anymore.

Uh, well in that case there is no C++ at all. And we might as well say that gdc and ldc aren't D compilers either.

> The original Pascal, which you said you'd never used. I have.

I've used the subset, but not Wirth's original. Not that this is an argument for anything.

>> So I don't think I agree with your definition of "useful".
>
> Try and write a program in Wirth's Pascal that reads a character from the keyboard.

D has no _language_ support for I/O, not sure what the point is.

>>> What programmers think of as "intuitive" is often a collection of
>>> special cases.
>> I think I would need examples to understand what you mean here.
>
> Dangling else is a classic.
>
> < > for template parameters in C++.
>
> infix notation

Ok. Those are syntactic conventions. Does not affect the language design as such.