On 08/06/2015 07:13 PM, jmh530 wrote:
> On Thursday, 6 August 2015 at 14:14:30 UTC, Jonathan M Davis wrote:
>> In general, I would have expected it to be a total disaster if a
>> language used any non-ASCII characters in its syntax.
>
> I still think it would be...not everyone uses the same editor. I had to
> look up how to do it in Notepad++. It requires knowing the Unicode key.
> Not exactly user-friendly.

Not a Windows user, but I bet it wouldn't take long to find a better solution.

> I wouldn't have an issue if the editor had a
> layout like Lyx.

Configuration is an O(1) operation. The constant becomes smaller after the first three users of the hypothetical language have set up their environment.

On 08/06/2015 07:50 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 5 August 2015 at 19:56:37 UTC, Timon Gehr wrote:
>> On 08/05/2015 07:32 PM, deadalnix wrote:
>>> Mathematical language is geared toward generality and correctness, not
>>> practicality. That makes sens in the context of math, that do not in the
>>> context of every day programming.
>>
>> I don't see what you are trying to get at here, but I guess it is
>> almost entirely unrelated to choosing a notation for string
>> concatenation.
>
> Well, I don't think practicality is the main issue, but the mnemonic
> aspect of syntax is important.
>
> It is not unreasonable to make the identity of operators/functions
> consist of both name and parameter types like in C++ and D. So you don't
> have "+" as the operator name, you have "+(int,int)" and
> "+(string,string)".
> ...

Certainly, but overloading is not always a good idea.

> It has been argued that functional languages would benefit from teaching
> functional programming in a less mathematical manner (e.g. talk about
> "callbacks" rather than "monads" etc):
>
> https://youtu.be/oYk8CKH7OhE
>

That's not less "mathematical". It is less abstract, maybe. Also, I think he is optimizing for people who pick up the language on their own. (i.e. it is not really about "teaching" in any traditional sense.)

On 26/07/2015 23:58, deadalnix wrote:
> On Sunday, 26 July 2015 at 18:13:30 UTC, Tobias Müller wrote:
>> Alix Pexton <alix.DOT.pexton@gmail.DOT.com> wrote:
>>> On 25/07/2015 9:48 PM, Walter Bright wrote:
>>>
>>>> Unfortunately, Bruce Eckel's seminal article on it
>>>> http://www.mindview.net/Etc/Discussions/CheckedExceptions has
>>>> disappeared. Eckel is not a Java code monkey, he wrote the book
>>>> Thinking
>>>> In Java
>>>> http://www.amazon.com/gp/product/0131002872/
>>>>
>>>
>>>
>>> https://web.archive.org/web/20150515072240/http://www.mindview.net/Etc/Discussions/CheckedExceptions
>>>
>>
>> This is article not convincing at all. His argument is basically "Most
>> programmers are sloppy and tend to catch and ignore checked exceptions."
>>
>
> No it is that checked Exception encourage this behavior.
>
> Ultimately, checked exception are a failure as they completely break
> encapsulation. Let's say you have a logger interface. Some of its
> implementation will just send the log to Dave Null, some write it in a
> file, some will send it over the network to some tailor, and so on. The
> class of error that arise from each is completely different and cannot
> be listed exhaustively at the interface level in any meaningful way.
>

Then define the logger interface as throwing a generic Exception class. (a class that sits at the top of the hierarchy of the other Exceptions)



-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Thursday, 6 August 2015 at 06:54:45 UTC, Walter Bright wrote:
> On 8/3/2015 2:19 AM, Max Samukha wrote:
>> The point is that '+' for string concatenation is no more of an 'idiot thing'
>> than '~'.
>
> Sure it is. What if you've got:
>
>    T add(T)(T a, T b) { return a + b; }
>
> and some idiot overloaded + for T to be something other than addition?

That is a general problem with structural typing. Why not assume that if a type defines 'length', it must be a range? Then call an idiot everyone who defines it otherwise. I admit that special treatment of '+' is justified by its long history, but 'idiot thing' is obviously out of place.

BTW, it happens that '+' does not always have to be commutative: https://en.wikipedia.org/wiki/Near-ring
https://en.wikipedia.org/wiki/Ordinal_arithmetic#Addition

On Monday, 11 July 2016 at 17:02:50 UTC, Max Samukha wrote:
> BTW, it happens that '+' does not always have to be commutative: https://en.wikipedia.org/wiki/Near-ring
> https://en.wikipedia.org/wiki/Ordinal_arithmetic#Addition

Yes, although concatenations ought to be «*»... and the empty string «""» the identity (1).

e.g. a free monoid:

"abc" * "d" == "abcd"
"abc"*"" == "abc"
"abc"*""*"" == "abc"

Then if you want to represent a set of alternate sets like a regexp «ab|cd» you could replace the alternative operator «|» with «+» and let the empty set «{}» be zero (0). Thus get a semiring:

( {"a"} + {"b"} ) + {"c"} == {"a"} + ( {"b"} + {"c"} )  == {"a" + "b" + "c"}
{} + {"a"} == {"a"} + {} == {"a"}
{"a"} + {"b"} == {"b"} + {"a"}  == {"a" + "b"}

( {"a"} * {"b"} ) * {"c"} == {"a"} * ( {"b"} * {"c"} ) == {"abc"}

{"a"} * ({"b"} + {"c"}) == ({"a"} * {"b"}) + ({"a"} * {"c"}) == { "ab" + "ac" }
({"a"} + {"b"}) * {"c"} == ({"a"} * {"c"}) + ({"b"} * {"c"}) == {"ab + "bc" }

{""} * {"a"} == {"a"} * {""} == {"a"}
{} * {"a"} == {"a"} * {} == {}

Sortof...

On Wednesday, 13 July 2016 at 21:33:39 UTC, Ola Fosheim Grøstad wrote:
> Then if you want to represent a set of alternate sets like a

Typo: a set of alternative strings.