On 15/11/2022 12:14, Dmitry A. Kazakov wrote:
> On 2022-11-15 12:44, James Harris wrote:
>
>> Do you also believe that the Unix
>>
>>    bytes = read(fd, &buf[1], reqd);
>>
>> should be prohibited since it has the side effect within the
>> expression of modifying the buffer? If so, what would you replace it
>> with??
>
> That is simple. Ada's standard library has it:
>
>    procedure Read
>              (  Stream : in out Root_Stream_Type;
>                 Item   : out Stream_Element_Array;
>                 Last   : out Stream_Element_Offset
>              )  is abstract;
>
> Item is an array:
>
> type Stream_Element_Array is
>    array (Stream_Element_Offset range <>) of aliased Stream_Element;
>
> It is also a "virtual" operation in C++ terms to be overridden by new
> implementation of stream. Last is the index of the last element read.
> Notice non-sliding bounds, as you can do this:
>
>    Last := Buff'First  - 1;
>    loop
>       Read (S, Buff (Last + 1..Buff'Last), Last); -- Non-blocking chunk
>       exit when Last = Buff'Last;                 -- Done
>    end loop;
>
> Since bounds do not slide Last stays valid for all array slices.

That's cool. So the call passes to Read a 'virtual' array, aka a view of
part of an array, and Last is /output/ from the call? Presumably the
array is made into a view (rather than an actual array) by means of the
"aliased" keyword. Is that correct?

Since Last is output from Read why do you set it before the loop starts?

If there's no more data does Read throw an exception?

It's interesting that the array is termed an /out/ parameter even though
only part of it might be overwritten!

--
James Harris

On 18/11/2022 07:12, David Brown wrote:

....

> ... I find it sad and disappointing that someone can have such strong
> opinions about something they have never really considered or tried to
> learn about, ...

A bit like those who have strong opinions on how a programming language
should be designed but have never designed one themselves, you mean?!

> and consequently don't understand, but I guess that is
> human nature.  It's ancient survival tactics, honed by evolution - when
> something is new, different and unknown, human instinct is to fear it
> and run away, rather than investigate and study it.
>
> The bit that really bugs me is how you (and James) can hold such strong
> opinions about how /other people/ might like and use these features and
> languages that support them.

There's an old maxim: Try and design a language for other people to use
and you'll end up with PL/I or Cobol. Try and design a language for
yourself and you might find that others of like mind also appreciate it.

That's a reasonable maxim although I'd add to keep it simple: cut down
on those ad-hoc rules or others will find it too hard to remember, even
if you as the language designer can remember them all.

--
James Harris

On 18/11/2022 11:00, David Brown wrote:
> On 15/11/2022 18:32, James Harris wrote:

....

>> The side effects of even something awkward such as
>>
>>    *(++p) = *(q++);
>>
>> are little different from those of the longer version
>>
>>    p = p + 1;
>>    *p = *q;
>>    q = q + 1;
>>
>> The former is clearer, however. That makes it easier to see the intent..
>
> Really?  I have no idea what the programmer's intent was.  "*p++ =
> *q++;" is common enough that the intent is clear there, but from your
> first code I can't see /why/ the programmer wanted to /pre/increment
> "p".  Maybe he/she made a mistake?  Maybe he/she doesn't really
> understand the difference between pre-increment and post-increment? It's
> a common beginners misunderstanding.

I don't think I know of any language which allows a programmer to say
/why/ something is the case; that's what comments are for. Programs
normally talk about /what/ to do, not why. The very fact that the
assignment does something non-idiomatic is a sign that a comment could
be useful. It's akin to

for (i = 0; i <= n ....

If the test really should be <= then a comment may be useful to explain why.

>
> On the other hand, it is quite clear from the separate lines exactly
> what order the programmer intended.
>
> What would you say are the differences in side-effects of these two code
> snippets?  (I'm assuming we are talking about C here.)

That depends on whether the operations are ordered or not. In C they'd
be different, potentially, from what they would be in my language. What
would you say they are?

>
>>
>> Just blaming operators you don't like is unsound - especially since,
>> as you seem to suggest below, you use them in your own code!!!
>>
>
> All I am saying is that it's worth considering the advantages and
> disadvantages of making a decision about such operators.  I'm not
> denying that the operators can be useful - I am questioning whether
> those uses are enough in comparison to the advantages of /not/ having them.

It's always useful to have one's preferences challenged. :-)

--
James Harris

On 2022-11-18 20:19, James Harris wrote:
> On 15/11/2022 12:14, Dmitry A. Kazakov wrote:
>> On 2022-11-15 12:44, James Harris wrote:
>>
>>> Do you also believe that the Unix
>>>
>>>    bytes = read(fd, &buf[1], reqd);
>>>
>>> should be prohibited since it has the side effect within the
>>> expression of modifying the buffer? If so, what would you replace it
>>> with??
>>
>> That is simple. Ada's standard library has it:
>>
>>     procedure Read
>>               (  Stream : in out Root_Stream_Type;
>>                  Item   : out Stream_Element_Array;
>>                  Last   : out Stream_Element_Offset
>>               )  is abstract;
>>
>> Item is an array:
>>
>> type Stream_Element_Array is
>>     array (Stream_Element_Offset range <>) of aliased Stream_Element;
>>
>> It is also a "virtual" operation in C++ terms to be overridden by new
>> implementation of stream. Last is the index of the last element read.
>> Notice non-sliding bounds, as you can do this:
>>
>>     Last := Buff'First  - 1;
>>     loop
>>        Read (S, Buff (Last + 1..Buff'Last), Last); -- Non-blocking chunk
>>        exit when Last = Buff'Last;                 -- Done
>>     end loop;
>>
>> Since bounds do not slide Last stays valid for all array slices.
>
> That's cool. So the call passes to Read a 'virtual' array, aka a view of
> part of an array, and Last is /output/ from the call? Presumably the
> array is made into a view (rather than an actual array) by means of the
> "aliased" keyword. Is that correct?

Aliased is only needed for pointers. Stream_Element_Array has aliased
elements for interoperability with the OS. It means that you can take a
pointer to any array element and pass it down to our beloved C's fread (:-))

> Since Last is output from Read why do you set it before the loop starts?

Because it moves from Buff'First - 1 to Buff'Last as we read the stream
into Buff.

> If there's no more data does Read throw an exception?

No, it returns available data. So the above is busy polling when S is
non-blocking. If you need non-busy interface you must have an event you
could wait for and reset (without falling into a race condition).
Usually, this stuff is kept inside the implementation of the stream.
E.g. S keeps an event, or creates one per each task/thread in the
extreme case of shared I/O. Read returns available data or waits for the
event which is reset atomically with getting buffered data.

> It's interesting that the array is termed an /out/ parameter even though
> only part of it might be overwritten!
There is no much difference between out and in out arrays. Basically out
means that the callee won't expect anything in the array. Note that the
bounds (and other constraints) cannot be changed. That is the key
difference between out-argument and a result. E.g. you cannot mutate an
argument into something else.

You could try to refine I/O modes (views) like in, out, in out. E.g. the
file system and databases support blocking of portions of data. The
corresponding I/O mode would be when some parts of the array are in the
in mode other parts are in the out or in out mode. You could consider
extending that on structures and other containers, of course.

I have no idea how to express that on the language level, but you get
the idea. Type algebra is an exciting subject. Alas, nobody pays any
attention these days.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2022-11-18 20:01, James Harris wrote:
> On 15/11/2022 21:40, David Brown wrote:

>> Imagine if you were to stop treating "letters", "digits" and
>> "punctuation" separately, and say "They are all just characters.
>> Let's treat them the same".  Now people can name a function "123", or
>> "2+2". It's conceivable that you'd work out a grammar and parsing
>> rules that allow that (Forth, for example, has no problem with
>> functions that are named by digits.  You can redefine "2" to mean "1"
>> if you like).  Do you think that would make the language easier to
>> learn and less awkward to use?
>
> Certainly not. Why do you ask?

Well, let me intervene. Actually early languages played with such ideas.
It is worth to mention Forth, Lisp, TeX, all sorts of preprocessors etc.
That time the idea that you could "program" the language syntax was
very popular.

Then evolution of languages took a different turn. Polymorphism was
achieved through decomposition (first procedural, then OO, relational,
functional) keeping the language syntax stable.

(Software reuse choked the ugly spawn. If each programmer created his
own new language reuse would not be possible)

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 17/11/2022 11:24, Bart wrote:

....

> If I wanted to display UTF8 right now on Windows, say from a C program
> even, I would have to fight it. If I write this (created with Notepad):
>
>   #include <stdio.h>
>   int main(void) {
>       printf("€°£");
>   }
>
> and compile with gcc, it shows:
>
> €°£
>
> I'm not sure what code page it's on, but if I switch to 65001 which is
> supposed to be UTF8, then it shows:
>
> �������
>
> (or equivalent in the terminal font). If I dump the C source, it does
> indeed contain the E2 82 AC sequence which is the UTF8 for the 20AC code
> for the Euro sign.
>
> I'm sure that on Linux it works perfectly within a terminal window. But
> I'm on Windows and I can't be bothered to do battle. Even if /I/ get it
> to work, I can't guarantee it for anyone else.

I presume you piped the output into hd or xxd to see exactly what was
being sent to the terminal - and hopefully prove it was the correct UTF-8.

I can't comment on how to get Windows to display Unicode chars from
UTF-8. I found Windows terminal drivers (VT-102 etc) often failed to
produce the correct output whereas Unix terminal emulation for the same
terminals looked perfect.

--
James Harris

On 19/11/2022 16:05, James Harris wrote:
> On 17/11/2022 11:24, Bart wrote:
>
> ...
>
>> If I wanted to display UTF8 right now on Windows, say from a C program
>> even, I would have to fight it. If I write this (created with Notepad):
>>
>>    #include <stdio.h>
>>    int main(void) {
>>        printf("€°£");
>>    }
>>
>> and compile with gcc, it shows:
>>
>> €°£
>>
>> I'm not sure what code page it's on, but if I switch to 65001 which is
>> supposed to be UTF8, then it shows:
>>
>> �������
>>
>> (or equivalent in the terminal font). If I dump the C source, it does
>> indeed contain the E2 82 AC sequence which is the UTF8 for the 20AC
>> code for the Euro sign.
>>
>> I'm sure that on Linux it works perfectly within a terminal window.
>> But I'm on Windows and I can't be bothered to do battle. Even if /I/
>> get it to work, I can't guarantee it for anyone else.
>
> I presume you piped the output into hd or xxd to see exactly what was
> being sent to the terminal - and hopefully prove it was the correct UTF-8.

Well, gcc using puts, or bcc/tcc using puts or prints, work correcly.

For some reason gcc+printf doesn't deal with it properly. I assumed
those characters were raw UTF8 bytes, and redirecting it now to a file,
that is exactly what I get.

gcc+printf is bypassing something it shouldn't.

My language supports it too (but needs external tools to get that
Unicode text into my source files as UTF8), even when translated to C
and passed through gcc. Here however, the C uses its own printf declaration.

Going back to the C, replacing #include <stdio.h> with:

extern int printf(const char*, ...);

makes it work with gcc too.

So the main failure is associated with gcc. But there are other issues,
such as ensuring the correct code pages, making it work with graphical
output, and other failures which I'm sure will come up. I don't want the
headache.

On 19/11/2022 16:20, Bart wrote:
> On 19/11/2022 16:05, James Harris wrote:
>> On 17/11/2022 11:24, Bart wrote:
>>
>> ...
>>
>>> If I wanted to display UTF8 right now on Windows, say from a C
>>> program even, I would have to fight it. If I write this (created with
>>> Notepad):
>>>
>>>    #include <stdio.h>
>>>    int main(void) {
>>>        printf("€°£");
>>>    }
>>>
>>> and compile with gcc, it shows:
>>>
>>> €°£
>>>
>>> I'm not sure what code page it's on, but if I switch to 65001 which
>>> is supposed to be UTF8, then it shows:
>>>
>>> �������
>>>
>>> (or equivalent in the terminal font). If I dump the C source, it does
>>> indeed contain the E2 82 AC sequence which is the UTF8 for the 20AC
>>> code for the Euro sign.
>>>
>>> I'm sure that on Linux it works perfectly within a terminal window.
>>> But I'm on Windows and I can't be bothered to do battle. Even if /I/
>>> get it to work, I can't guarantee it for anyone else.
>>
>> I presume you piped the output into hd or xxd to see exactly what was
>> being sent to the terminal - and hopefully prove it was the correct
>> UTF-8.
>
> Well, gcc using puts, or bcc/tcc using puts or prints, work correcly.
>
> For some reason gcc+printf doesn't deal with it properly. I assumed
> those characters were raw UTF8 bytes, and redirecting it now to a file,
> that is exactly what I get.
>
> gcc+printf is bypassing something it shouldn't.

Is printf supposed to handle non-ASCII strings? Remember that it is
expected to interpret the first string whereas puts isn't.

Actually, including UTF8 in any simple string sounds dodgy. As an
example, imagine an embedded byte value of 0x80 on a 1s complement
machine. It would likely terminate the string.

IOW I wouldn't expect any of this stuff to work portably.

And as I said before, source should be pure ASCII....!

--
James Harris

On 19/11/2022 19:47, James Harris wrote:
> On 19/11/2022 16:20, Bart wrote:
>> On 19/11/2022 16:05, James Harris wrote:
>>> On 17/11/2022 11:24, Bart wrote:
>>>
>>> ...
>>>
>>>> If I wanted to display UTF8 right now on Windows, say from a C
>>>> program even, I would have to fight it. If I write this (created
>>>> with Notepad):
>>>>
>>>>    #include <stdio.h>
>>>>    int main(void) {
>>>>        printf("€°£");
>>>>    }
>>>>
>>>> and compile with gcc, it shows:
>>>>
>>>> €°£
>>>>
>>>> I'm not sure what code page it's on, but if I switch to 65001 which
>>>> is supposed to be UTF8, then it shows:
>>>>
>>>> �������
>>>>
>>>> (or equivalent in the terminal font). If I dump the C source, it
>>>> does indeed contain the E2 82 AC sequence which is the UTF8 for the
>>>> 20AC code for the Euro sign.
>>>>
>>>> I'm sure that on Linux it works perfectly within a terminal window.
>>>> But I'm on Windows and I can't be bothered to do battle. Even if /I/
>>>> get it to work, I can't guarantee it for anyone else.
>>>
>>> I presume you piped the output into hd or xxd to see exactly what was
>>> being sent to the terminal - and hopefully prove it was the correct
>>> UTF-8.
>>
>> Well, gcc using puts, or bcc/tcc using puts or prints, work correcly.
>>
>> For some reason gcc+printf doesn't deal with it properly. I assumed
>> those characters were raw UTF8 bytes, and redirecting it now to a
>> file, that is exactly what I get.
>>
>> gcc+printf is bypassing something it shouldn't.
>
> Is printf supposed to handle non-ASCII strings? Remember that it is
> expected to interpret the first string whereas puts isn't.

The only characters printf formats care about are '%', which indicates
the start of a format sequence, and 0, which indicates the end of the
string.

Besides, all the other printf versions I tried worked (and it works on
Linux).

Window + gcc + printf didn't, but I don't think it got as far as calling
a normal printf; doubtless it's doing something too clever. The relevant
characters get to the output, but somehow bypass the part where the OS
console driver converts the character stream to Unicode.

> Actually, including UTF8 in any simple string sounds dodgy. As an
> example, imagine an embedded byte value of 0x80 on a 1s complement
> machine. It would likely terminate the string.

What machines use 1s complement these days? You might as well worry
about those using 7-bit characters! Or EBCDIC.

UTF8 was designed to be transparent to anything processing 8-bit
strings. On ones completed it presumably wouldn't work, unless
characters were wider than 8 bits.

(Don't tell me you're avoiding the use of UTF8 for that reason. For
anyone still using ones complement, probably ASCII would be too advanced
as they're still using 5-bit telegraph codes!)

> IOW I wouldn't expect any of this stuff to work portably.
>
> And as I said before, source should be pure ASCII....!

Sure. But this is mostly about data within programs which can be anything.

Restricting source code means you can't have Unicode content in
comments, or inside string constants.

The means not being able to have "°", you'd need an escape sequence. Or
convert any pasted Unicode string into such a string.

This is unreasonable considering that providing such support within a
compiler requires pretty much zero effort.

On 17/11/2022 13:20, Dmitry A. Kazakov wrote:
> On 2022-11-17 13:35, Bart wrote:
>> On 17/11/2022 12:12, Dmitry A. Kazakov wrote:
>>> On 2022-11-17 12:24, Bart wrote:
>>>
>>>> If I wanted to display UTF8 right now on Windows, say from a C
>>>> program even, I would have to fight it. If I write this (created
>>>> with Notepad):
>>>>
>>>>    #include <stdio.h>
>>>>    int main(void) {
>>>>        printf("€°£");
>>>>    }

....

>>> In CMD:
>>>
>>>  >CHCP 65001
>>> Active code page: 65001
>>>
>>>  >main.exe
>>> €°£
>>>
>>> Of course, you could use the code you wrote under the condition that
>>> both the editor and the compiler use UTF-8.
>>
>> The point about UTF8 is that it doesn't matter. So the string contains
>> 'character' E2; in C, this is just a byte array, it should just pass
>> it as it is to the printf function.

....

>> That would work, but is also completely impractical for large amounts
>> of non-ASCII content. Or even small amounts. You /need/ editor
>> support. I don't have it and don't do enough with Unicode to make it
>> worth the trouble.
>
> That's is another guideline topic: you never ever place localization
> stuff in the source code.

I was going to say the same. Where Bart says that typing "large amounts
of non-ASCII content" needs editor support I would go the other way. In
source code use pure ASCII, and ship with files which map the source to
different locales.

--
James Harris

On 19/11/2022 20:20, Bart wrote:
> On 19/11/2022 19:47, James Harris wrote:
>> On 19/11/2022 16:20, Bart wrote:

....

>>> For some reason gcc+printf doesn't deal with it properly. I assumed
>>> those characters were raw UTF8 bytes, and redirecting it now to a
>>> file, that is exactly what I get.
>>>
>>> gcc+printf is bypassing something it shouldn't.
>>
>> Is printf supposed to handle non-ASCII strings? Remember that it is
>> expected to interpret the first string whereas puts isn't.
>
> The only characters printf formats care about are '%', which indicates
> the start of a format sequence, and 0, which indicates the end of the
> string.

Well, is printf /specified/ to accept all other 8-bit codes? If not, you
may find printf working in some cases but not in others.

>
> Besides, all the other printf versions I tried worked (and it works on
> Linux).

I'm sure you know that "it works here" is irrelevant because C's
specification includes much IB and UB. One could /very/ easily find some
code doing what one wants in one environment and not doing what one
wants in another. The effect of UB could even vary depending on whether
it was Tuesday or not. Seriously, we need to keep well away from
anything in C which is not defined.

IOW the fact that something works when tried is *meaningless* if it's
contrary to the specs.

....

>> Actually, including UTF8 in any simple string sounds dodgy. As an
>> example, imagine an embedded byte value of 0x80 on a 1s complement
>> machine. It would likely terminate the string.
>
> What machines use 1s complement these days? You might as well worry
> about those using 7-bit characters! Or EBCDIC.

As I say, if you write non-specified C code it may happen to work on one
machine but that's no guarantee it will work on another.

>
> UTF8 was designed to be transparent to anything processing 8-bit
> strings. On ones completed it presumably wouldn't work, unless
> characters were wider than 8 bits.

Well, UTF8 on a 1's complement machine embedded in a string which the
runtime expects to be ASCII sounds like a recipe for trouble. Even
characters having a set the top bit may lead to problems with char
signedness on a 2s complement machine.

>
> (Don't tell me you're avoiding the use of UTF8 for that reason. For
> anyone still using ones complement, probably ASCII would be too advanced
> as they're still using 5-bit telegraph codes!)

Baudot rules :-)

In fact, I'd use UTF8 in auxiliary files but not in the source.

>
>
>> IOW I wouldn't expect any of this stuff to work portably.
>>
>> And as I said before, source should be pure ASCII....!
>
> Sure. But this is mostly about data within programs which can be anything.

That's OK. Data read would be pure bits and octets. It's when something
tries to interpret those bits that problems can arise - e.g. to_upper
.... and the printf control string.

>
> Restricting source code means you can't have Unicode content in
> comments, or inside string constants.

Exactly.

>
> The means not being able to have "°", you'd need an escape sequence. Or
> convert any pasted Unicode string into such a string.

Not quite. If that char (which appears to be a degree character) varied
between locales it could go in an aux file. If it was universal,
however, the source could include its name with such as

"\degree/"

>
> This is unreasonable considering that providing such support within a
> compiler requires pretty much zero effort.

This is not to help the compiler or the compiler writer. The idea of
restricting source to a lingua franca is to help teams of humans
collaborate on the source even if they are from different locales.

--
James Harris

On 19/11/2022 20:20, Bart wrote:
> On 19/11/2022 19:47, James Harris wrote:
>> On 19/11/2022 16:20, Bart wrote:
>>> On 19/11/2022 16:05, James Harris wrote:
>>>> On 17/11/2022 11:24, Bart wrote:
>>>>
>>>> ...
>>>>
>>>>> If I wanted to display UTF8 right now on Windows, say from a C
>>>>> program even, I would have to fight it. If I write this (created
>>>>> with Notepad):
>>>>>
>>>>>    #include <stdio.h>
>>>>>    int main(void) {
>>>>>        printf("€°£");
>>>>>    }
>>>>>
>>>>> and compile with gcc, it shows:
>>>>>
>>>>> €°£

....

>>> gcc+printf is bypassing something it shouldn't.
>>
>> Is printf supposed to handle non-ASCII strings? Remember that it is
>> expected to interpret the first string whereas puts isn't.
>
> The only characters printf formats care about are '%', which indicates
> the start of a format sequence, and 0, which indicates the end of the
> string.
>
> Besides, all the other printf versions I tried worked (and it works on
> Linux).

As I said in the other reply, if this is contrary to the specification
then this stuff is poisonous. But curious to see what would happen in my
particular environment I tried your code. The source file had your
string between the quotes as

e2 82 ac c2 b0 c2 a3

What is that? UTF8?

When run, also on Unix, it outputs the same bytes.

$ ./a.out | hd
00000000 e2 82 ac c2 b0 c2 a3

Hence no change for this specific test.

It's 7 bytes, though, and when you ran it on Windows you said you got

€°£

which is also 7 characters. At a guess, were those chars from the
codepage your Windows terminal was using (rather than it interpreting UTF8)?

--
James Harris

On Saturday, November 19, 2022 at 3:13:52 PM UTC-6, James Harris wrote:
> On 19/11/2022 20:20, Bart wrote:

> > Besides, all the other printf versions I tried worked (and it works on
> > Linux).
> As I said in the other reply, if this is contrary to the specification
> then this stuff is poisonous. But curious to see what would happen in my
> particular environment I tried your code. The source file had your
> string between the quotes as
>
> e2 82 ac c2 b0 c2 a3
>
> What is that? UTF8?

Yep. That's UTF-8. With a little practice it's pretty easy to parse, or at least to find
the character code boundaries. The first byte starts with some number of ones
in the most significant position, from 0 to 4 (or maybe 6 in rare applications).
That number tells you the length of the encoding for that character.

So e2 is the start of a 3 byte code. And c2 is the start of a 2 byte code.

On 18/11/2022 20:01, James Harris wrote:
> On 15/11/2022 21:40, David Brown wrote:
>> On 15/11/2022 20:09, James Harris wrote:
>>> On 15/11/2022 17:31, David Brown wrote:
>>>> On 15/11/2022 17:58, James Harris wrote:
>
> ...
>
>>> The question is not whether prevention would be possible but whether
>>> you (i.e. DB) would consider it /advisable/. If you prevented it then
>>> a lot of familiar programming patterns and a number of existing APIs
>>> would become unavailable to you so choose wisely...! :-)
>>>
>>
>> I am not the language designer here
>
> Uh, huh.
>
>
>> - and I still don't really grok what kind of language /you/ want, what
>> you understand from before, what uses it should have, or what you
>> think is wrong with existing languages.  (Or maybe this is all for fun
>> and interest, which is always the best reason for doing anything.)
>> That makes it hard to give recommendations.
>
> ...
>
>>>> You assume /so/ many limitations on what you can do as a language
>>>> designer.  You can do /anything/.  If you want to allow something,
>>>> allow it.  If you want to prohibit it, prohibit it.
>>>
>>> Sorry, but it doesn't work like that.
>>
>> Yes, it does.
>
> No, it does not. Your view of language design is far too simplistic.
> Note, also, that in a few paragraphs you say that you are not the
> language designer whereas I am, but then you go on to try to tell me how
> it works and how it doesn't and, previously, that anything can be done.
> You'd gain by /trying/ it yourself. They you might see that it's not as
> straightforward as you suggest.
>

That is a fair point. But I challenge you to show me where there are
rules written for language designs. Explain to me exactly why you are
not allowed to, say, provide an operator "-" without a corresponding
operator "+". Tell me who is banning you from deciding that source code
lines must be limited to 40 characters, or that every assignment
statement shall be preceded by the keyword "please". I'm not saying any
of these things are a good idea (though something similar has been done
in other cases), I am saying it is /your/ choice to do that or not.

You can say "I can't have feature A and feature B and maintain the
consistency I want." You /cannot/ say "I can't have feature A". It is
/your/ decision not have feature A. Choosing to have it may mean
changing or removing feature B, or losing some consistency that you had
hoped to maintain. But it is your language, your choices, your
responsibility - saying "I can't do that" is abdicating that responsibility.

>>
>>> A language cannot be built on ad-hoc choices such as you have suggested.
>>

It most certainly can. Every language is a collection of design
decisions, and most of them are at least somewhat ad-hoc.

However, my suggestions where certainly /not/ ad-hoc - it was for a
particular way of thinking about operators and expressions, with
justification and an explanation of the benefits. Whether you choose to
follow those suggestions or not, is a matter of your personal choices
for how you want your language to work - and /that/ choice is therefore
somewhat ad-hoc. They only appear ad-hoc if you don't understand what I
wrote justifying them or giving their advantages.

Of course you want a language to follow a certain theme or style (or
"ethos", as you called it). But that does not mean you can't make
ad-hoc decisions if you want - it is inevitable that you will do so.
And it certainly does not mean you can't make the choices you want for
your language.

Too many ad-hoc choices mean you loose the logic and consistency in the
language. Too few, and your language has nothing to it. Excessive
consistency is great for some theoretical work - Turing machines,
lambda calculus, infinite register machines, and the like. It is
useless in a real language.

Look at C as an example. Not everyone likes the language, and the only
people who find nothing to dislike in it are people to haven't used it
enough. But it is undoubtedly a highly successful language. All binary
operators require the evaluation of both operands before evaluating the
operator. (And before you start thinking that is unavoidable, it is
not, and does not apply to all languages.) Except && and ||, where the
second operand is not evaluated if it is not needed - that's an ad-hoc
decision, different from the general rule. All access to objects must
be through lvalues of compatible types - except for the ad-hoc rule that
character type pointers can also be used.

To be successful at anything - program language design or anything else
- you always need to aim for a balance. Consistency is vital - too much
consistency is bad. Generalisation is good - over-generalisation is
bad. Too much ad-hoc is bad, so is too little.

>> I haven't suggested ad-hoc choices.  I have tried to make reasoned
>> suggestions.  Being different from languages you have used before, or
>> how you envision your new language, does not make them ad-hoc.
>
> Saying you'd like selected combinations of operators to be banned looks
> like an ad-hoc approach to me.
>

Then you misunderstand what I wrote. I don't know if that was my fault
in poor explanations, or your fault in misreading or misunderstanding -
no doubt, it was a combination.

> ...
>
>>>>> BTW, any time one thinks of 'treating X separately' it's good to be
>>>>> wary. Step-outs tend to make a language hard to learn and awkward
>>>>> to use.
>>>>>
>>>>
>>>> So do over-generalisations.
>>>
>>> Not really.
>>
>> Yes, really.
>
> You simply repeating phrases back to me but in the negative does not
> make your assertions correct or mine wrong.

That's why I gave the example below...

>
>>
>> Imagine if you were to stop treating "letters", "digits" and
>> "punctuation" separately, and say "They are all just characters.
>> Let's treat them the same".  Now people can name a function "123", or
>> "2+2". It's conceivable that you'd work out a grammar and parsing
>> rules that allow that (Forth, for example, has no problem with
>> functions that are named by digits.  You can redefine "2" to mean "1"
>> if you like).  Do you think that would make the language easier to
>> learn and less awkward to use?
>
> Certainly not. Why do you ask?

I ask, because it is an example of over-generalisation that makes a
language harder to learn and potentially a lot more confusing to understand.

>
>>
>>> It's ad-hoc rules which become burdensome.
>>
>> Agreed.
>
> Phew!
>
> ...
>
>>> Seriously, try designing a language, yourself. You don't have to
>>> implement it. Just try coming up with a cohesive design of something
>>> you would like to program in.
>>>
>>
>> If I had the time...  :-)
>>
>> I fully appreciate that this is not an easy task.
>
> I'm sure you do but your view of the details is superficial. You have
> ideas which are interesting in themselves but you don't appear to
> appreciate how decisions bear on each other when you have to bring
> hundreds of them together.
>

Oh, I do appreciate that. As I have said all along, I am not giving
recommendations or claiming that my suggestions are the only way to do
things. It is all up to /you/.

> ...
>
>>> Bart came up with an example something like
>>>
>>>    +(+(+(+ x)))
>>>
>>> That's not at all sensible. You want that banned, too?
>>>
>>
>> Yes :-)  Seriously, I appreciate that there will always be compromises
>> - trying to ban everything silly while allowing everything sensible
>> would mean countless ad-hoc rules, and you are right to reject that.
>> I am advocating drawing a line, just like you - the difference is
>> merely a matter of where to draw that line.  I'd draw the line so that
>> it throws out the increment and decrement operators entirely.  But if
>> you really wanted to keep them, I'd make them postfix only and as
>> statements, not in expressions - let "x++" mean "x += 1" which means
>> "x = 1" which should, IMHO, be a statement and not allowed inside an
>> expression.
>
> This does, indeed, in a sense, come down to where the designer decides
> to draw the line. Unfortunately there is no simple line.
>

On 20/11/2022 12:28, David Brown wrote:

> Look at C as an example.  Not everyone likes the language, and the only
> people who find nothing to dislike in it are people to haven't used it
> enough.

I disliked C at first glance having never used it. But I loved Algol68,
having never used that either.

But given a task now and the choice was between those two languages, I
would choose C, mainly because some design choices of Algol68 syntax
make writing code more painful than in C. (Ahead of both would be one of
my two, by a mile.)

However I can admire Algol68 for its design, even if it needed tweaking
IMO, but I would never be able to do that for C, since a lot of it looks
like it was thrown together with no thought at all, or under the
influence of some substance.

> But it is undoubtedly a highly successful language.

On the back of Unix inflicting it on everybody (can anyone prise Unix
and C apart?), and the lack of viable alternatives.

Successful languages, then, needed to be able to bend the rules a
little, do underhand stuff, which C could do in spades (so could mine!).
You can't really do that with a Wirth language or ones like Algol68.
Ones like PL/M disappeared.

Now people look askance at such practices, but C already had its foot in
the door.

On 18/11/2022 21:14, James Harris wrote:
> On 18/11/2022 11:00, David Brown wrote:
>> On 15/11/2022 18:32, James Harris wrote:
>
> ...
>
>>> The side effects of even something awkward such as
>>>
>>>    *(++p) = *(q++);
>>>
>>> are little different from those of the longer version
>>>
>>>    p = p + 1;
>>>    *p = *q;
>>>    q = q + 1;
>>>
>>> The former is clearer, however. That makes it easier to see the intent..
>>
>> Really?  I have no idea what the programmer's intent was.  "*p++ =
>> *q++;" is common enough that the intent is clear there, but from your
>> first code I can't see /why/ the programmer wanted to /pre/increment
>> "p".  Maybe he/she made a mistake?  Maybe he/she doesn't really
>> understand the difference between pre-increment and post-increment?
>> It's a common beginners misunderstanding.
>
> I don't think I know of any language which allows a programmer to say
> /why/ something is the case; that's what comments are for. Programs
> normally talk about /what/ to do, not why. The very fact that the
> assignment does something non-idiomatic is a sign that a comment could
> be useful. It's akin to
>
>   for (i = 0; i <= n ....
>
> If the test really should be <= then a comment may be useful to explain
> why.

Ideally there should be no need for a comment, because the code makes it
clear - for example via the names of the identifiers, or from the rest
of the context. That rarely happens in out-of-context snippets.

>
>>
>> On the other hand, it is quite clear from the separate lines exactly
>> what order the programmer intended.
>>
>> What would you say are the differences in side-effects of these two
>> code snippets?  (I'm assuming we are talking about C here.)
>
> That depends on whether the operations are ordered or not. In C they'd
> be different, potentially, from what they would be in my language. What
> would you say they are?
>

You said the side-effects are "a little different", so I wanted to hear
what you meant.

In C, there is no pre-determined sequencing between the two increments -
they can occur in any order, or can be interleaved. As far as the C
abstract machine is concerned (and that's what determines what
side-effects mean), unsequenced events are not ordered and it doesn't
make sense to say which happened first. You can consider them as
happening at the same time - and if that affects the outcome of the
program, then it is at least unspecified behaviour if not undefined
behaviour. (It would be undefined behaviour if "p" and "q" referred to
the same object, for example.)

So I don't think it really makes sense to say that the order is
different. If the original "*(++p) = *(q++);" makes sense at all, and
is defined behaviour, then it's behaviour is not distinguishable from
within the C language from the expanded version.