On 14/11/2022 16:21, James Harris wrote:
> On 14/11/2022 11:11, Bart wrote:
>> On 14/11/2022 10:44, James Harris wrote:
>>> On 14/11/2022 09:26, David Brown wrote:
>
> ...
>
>>> OK, let's take the combination you mentioned:
>>>
>>>    ++E++
>>>
>>> I wonder why you see a problem with it. As I see it, it increments E
>>> before evaluation and then increments E after evaluation. What is so
>>> complex about that? It does exactly what it says on the tin, and in
>>> the order that it says it. Remember that unlike C I define the
>>> apparent order of evaluation so the expression is perfectly well formed.
>>
>> But does this have the same priorities as:
>>
>>     op1 E op2
>>
>> (where op2 is commonly done first) or does it have special rules, so
>> that in:
>>
>>    --E++
>>
>> the -- is done first? If it's different, then what is the ordering
>> when mixed with other unary ops?
>>
>> You explained somewhere the circumstances where you think this is
>> meaningful, but I can't remember what the rules are and I can't find
>> the exact post.
>
> The rules for ++ and -- are simple. *Prefix* ++ or -- happens before
> postfix ++ or --.

Is that for all unary operators or just ++ and --?

If only for those, then those exceptions will make rules for all unary
ops even more bizarre. If for all of them, then one consequence is that
`-P^` is parsed as `(-P)^`, so that you try to negate a pointer, instead
of what's at the pointer target.

However, I have my own exceptions, which are casts:

ref u16(P)^ := 0

If P was a byte pointer, this will now write 16 bits not 8. Here, the
cast is done first, differently from a unary operator.

But I cover this in my list below: casts are syntax so trump everything.
(Which comes first in `ref T (X)[i]`, I don't know, I'd have to test it.
But this would probably be written to as (X[i]) to remove doubt.)

> Your example would probably be better expressed as
>
>   E - 1
>
> !
>
> As for the bigger picture of operator precedences, it's based on the
> transformations which operators naturally make to their operands. For
> example, comparisons (such as less-than) naturally take numbers and
> produce booleans so their precedences put them after numeric operators
> (+, * etc) and before boolean operators (and, or, not, etc). The natural
> series is (simplified)
>
>   locations (such as field selection and array indexing)
>   numbers (retrieved from those locations)
>   comparisons (of those numbers)
>   booleans

So this is about binary ops now? I make that even simpler by saying all
binary ops come after unary ops. The tighest binding, starting with the
tightest, is:

Syntax-bound ("." and "[]" for example)
Unary ops (postfix LTR then prefix RTL)
Binary (**, Mul, Add, Compare, Logical)

>> Because if they ever start to return lvalues, then this becomes possible:
>>
>>     ++E := 0
>>     E++ := 0
>>
>> (Whichever one is legal in your scheme.) So I think there is little
>> useful expressivity to be gained.
>
> Indeed, neither of those is useful.
>
> Interestingly, I just tried
>
>   ++E = 0;
>
> with cc and c++ compilers. The first rejected it (as ++E needing to be
> an lvalue); the second accepted it. That's not a reflection of either
> compiler, BTW, but without checking it's probably more to do with the
> language/dialect definition. FWIW I expect the second compiler could be
> persuaded to issue a warning about unreachable code or suchlike.

What does C++ expect it to mean? I know it allows the result of ?: as an
lvalue, which C doesn't. But the meaning of that is clear, and I have it
too:

(a | b | c) := x # assign to b or c depending on a

(Actually you can have an arbitrarily complex expression on the LHS as
an lvalue, including Switch and if-then-elsif chains. But whether they
still work in my languages, I don't know as I rarely use the feature.

Actually it comes up indirectly here:

F((a | b | c))

when F is a function taking a reference parameter, so the arg must be an
Lvalue. So either b or c is modified in F. This one works, because I
think it came up recently and it had to!)

On 14/11/2022 19:43, Bart wrote:
> On 14/11/2022 17:46, David Brown wrote:
>> On 14/11/2022 16:59, Bart wrote:
>
>>> I have a dynamic language with proper, first class lists, trees,
>>> strings, records, which take care of 90% of the pointer uses in a
>>> C-class language. Yet they can still be useful. This is an extract
>>> from a program that dumps the contents of an EXE file:
>>>
>>> coffptr:=makeref(pedata+coffoffset,imagefileheader)
>>>
>>> genstrln("Coff header: "+tostr(coffptr^))
>>>
>>> genstrln("Machine: "+tostr(coffptr^.machine,"h2"))
>>> genstrln("Nsections: "+tostr(coffptr^.nsections,"h2"))
>>> genstrln("Timestamp: "+tostr(coffptr^.timedatestamp,"h4"))
>>> genstrln("Symtab offset: "+tostr(coffptr^.symtaboffset))
>>> genstrln("Nsymbols: "+tostr(coffptr^.nsymbols))
>>> genstrln("Opt Hdr size: "+tostr(coffptr^.optheadersize))
>>> genstrln("Characteristics: "+tostr(coffptr^.characteristics,"b"))
>>> genline()
>>>
>>
>> None of that needs pointers or references.
>>
>> Initialise a "coff_header" read-only unmutable variable from a slice
>> of the memory array holding the image.
>
> At minimum, this tasks needs to the ability to take a block of bytes,
> and variously interpret parts of it as primitive numeric types of
> specific widths and signedness.

Agreed. Still, pointers are unnecessary there.

>
> That can be helped by having pointers to such types. It can be further
> helped by allowing a struct type which is a collection of such types in
> a particular layout. And a way to transfer data from arbitrary bytes to
> that struct object. Or to map the address of that struct into the middle
> of that block. (Or as I do it above, set a pointer to that struct to the
> middle of the block.)
It is certainly handy to have a way of interpreting the bytes of an
image as a struct type with particular layout. It is not necessary, but
it is handy.

>
> This is stuff which is meat-and-drink to a lower-level language like C,
> or like mine (even my scripting language).
>
> It requires some effort in Python and the result will be clunky (and
> probably require some add-on modules).
>>> import struct # Standard module
>>> bs = open("potato_c.cof").read()

>>> machine, nsections, timestamp, symtaboffset, nsymbols,
optheadersize, characteristics = struct.unpack_from("<HHIIIHH")

That's it. Three lines. I would not think of C for this kind of thing
- Python is /much/ better suited. I'd only start looking at C (or C++)
if I need so high speed that the Python code was not fast enough, even
with PyPy.

> While a functional language will
> struggle (to be accurate, the programmer will struggle because they've
> chosen the wrong language).
I don't believe that. I am not familiar enough with Haskell to be able
to give the code, but I have no doubts at all that someone experienced
with Haskell will manage it fine. IO is not hard in the language, and
it has all the built-in modules needed for such interfaces.

Haskell is apparently number 25 on the list of language popularities on
Github, with about 0.4% usage. That's not huge, but not insignificant
either. But then, it was never intended to be a major practical
language - though some people and companies (Facebook uses it for
content analysis) do use it for practical work. It's main motivations
are for teaching people good software development, developing new
techniques, algorithms and methods, and figuring out what "works" and
could be incorporated in other languages.

It is that last feature that is most noticeable. Most major modern
languages are not pure functional languages in themselves, but contain
aspects from functional programming. I can't think of any serious,
popular language with significant development in the last decade that
does not have lambdas and the ability to work with functions as objects.
Most high-level languages have list comprehensions and higher-order
functions (map, filter, etc.). Many support defining high-level data
structures directly without the need to mess around with pointers
manually. Many encourage immutable data as the norm.

This is why I bring it up here - not because I think the OP should be
making a functional programming language, but because I think he should
be taking inspiration and incorporating ideas from that world.

>
> Here's a more challenging record type that comes up in OBJ files:
>
> type imagesymbol=struct
> union
> stringz*8 shortname
> struct
> u32 short
> u32 long
> end
> u64 longname
> end
> u32 value
> u16 sectionno
> u16 symtype
> byte storageclass
> byte nauxsymbols
> end
>
> (Again, this is defined directly in my /dynamic/ scripting language.)
>
Again, peanuts in Python - and I expect also peanuts in Haskell.

>>> No thanks. My innovation is keeping this stuff simple, accessible,
>>> fast, and at a human scale.
>>>
>>
>> I disagree with your scepticism, but I agree that there are lots of
>> languages with different paradigms for different purposes.
>>
>> However, making yet-another-C is IMHO a pointless exercise. It might
>> be better in some ways, but not enough to make it worth the effort.
>
> If you're going to use a C-class language, then why not one with some
> modern refinements? That's what I do.
> > (For example, default 64-bit everything; a module scheme; value arrays;
> sane type syntax; whole-program compilation; slices; expression-based
> (see below); a 'byte' type! )
Nothing of that is /remotely/ worth making a new language and giving up
on everything C - tools, compilers, developer familiarity, libraries,
and all the rest.

I'm not saying that these are not good things (though I might disagree
with you on some of the details). I am saying that it is not worth it.

This is why we still have C, and why it is so popular in practice - it
is not because anyone thinks it is a "perfect" language, it is because
the benefits of the C ecosystem outweigh the small benefits of minor
variations of the language.

And I think most of what you like could be achieved by using a subset of
C++ along with a few template libraries. (To be fair, that was
certainly not the case when you started your language.)

>
>>> Obviously I can't ban `a + b`. Equally obviously, this code is
>>> pointless:
>>>
>>> a + b;
>>>
>>
>> You can ban that. Rule number 42 - the result of an expression must
>> be assigned to a variable, used in another expression, or passed as
>> the argument to a function call. No problem.
>
> This is effectively what I did. The only expressions allowed as
> standalone statements were assignments; function calls; increments.
> Anything else required an `eval` prefix to force evaluation.
>
Good.

>>> Given an expression-based language, what would you do? In the past,
>>> after working with C, I would unthinkingly type:
>>>
>>> a = b
>>>
>>> in my syntax instead of a := b. This wasn't an error: it would
>>> compare a and b then discard the result. But it was a bug.
>>>
>>
>> Any decent C compile (with the right options) will complain about the
>> C equivalent, "a == b;", as a statement with no effect. It could just
>> as easily be made an error in a language.
>>
>> And if you follow my suggestion that expressions can't have
>> side-effects, then it's easy to distinguish between "statements" and
>> "expressions" because you no longer have a C-style "expression
>> statement".
>
> Because my early languages were loosely based on Algol68, not C, they
> were expression-based. Later I simplified to distinct statements and
> expressions, but now I've gone back.
>
> Now both my languages are expression-based. That is, statements and
> expressions are interchangeable. That's supposed to be good, right,
> because FP languages work the same way? I think expression-based are
> regarded as superior.
>
I have nothing against expressions - I am against side-effects in
expressions.

On 15/11/2022 00:28, Andy Walker wrote:
> On 14/11/2022 20:45, David Brown wrote:
> [To James:]
>> [...]  But there is absolutely
>> /nothing/ about being an imperative language that suggests you need
>> to allow side-effects or assignments /within/ expressions.
>
>     If assignments within expressions are verboten, then you need to
> either forbid assignments within functions or have two classes of function,
> those with and those without [inc sub-procedures].

Yes, I mentioned in one post that functions are a complicating factor
that need to be discussed, but are probably best covered in a separate
thread. Two classes of function was a possibility I mentioned.

> If assignments are
> allowed at all, then you cannot in general tell at compile time whether
> any assignment is reached at run time, leading to further complications.
> If you regard output as a side-effect, that too leads to problems.  Yet
> during program development it is common to insert temporary diagnostic
> printing or variables.  I can understand the concept of languages without
> assignments or other side effects;  and of languages with them;  I find it
> difficult to see the point of languages where such things are allowed in
> some places and not in others.  If we need hair shirts [and I'm not sure
> that we do], they should be worn all the time, not put on and taken off
> in accordance with arcane rules that only high priests understand.
>

Rules need to be clear, certainly. But it entirely possible to have a
language that allows assignment in some places and not others. Impure
functional programming languages (such as OCaml) have that.

There is no easy answer to these kinds of design decisions, and in the
end it is the OP who must decide. I am suggesting ways to make the
language clear and perhaps easier for compiler analysis. There are
always trade-offs going on - every choice makes some things easier and
other things harder.

On 15/11/2022 01:14, Bart wrote:
> On 14/11/2022 16:21, James Harris wrote:
>> On 14/11/2022 11:11, Bart wrote:

....

>> The rules for ++ and -- are simple. *Prefix* ++ or -- happens before
>> postfix ++ or --.
>
> Is that for all unary operators or just ++ and --?

Just ++ and ==, as stated.

>
> If only for those, then those exceptions will make rules for all unary
> ops even more bizarre. If for all of them, then one consequence is that
> `-P^` is parsed as `(-P)^`, so that you try to negate a pointer, instead
> of what's at the pointer target.
>
> However, I have my own exceptions, which are casts:
>
>     ref u16(P)^ := 0

Rather than casts I have conversions. Are they the same? I never really
understood how people use the term 'cast'. Either way, you raise a good
point: Where should type conversions come in the order of precedence.

I currently have them as function calls so they come at the top. I would
have your example as

(ref u16)(P)* = 0

>
> If P was a byte pointer, this will now write 16 bits not 8. Here, the
> cast is done first, differently from a unary operator.
>
> But I cover this in my list below: casts are syntax so trump everything.
> (Which comes first in `ref T (X)[i]`, I don't know, I'd have to test it.
> But this would probably be written to as (X[i]) to remove doubt.)

....

>>> Because if they ever start to return lvalues, then this becomes
>>> possible:
>>>
>>>     ++E := 0
>>>     E++ := 0
>>>
>>> (Whichever one is legal in your scheme.) So I think there is little
>>> useful expressivity to be gained.
>>
>> Indeed, neither of those is useful.
>>
>> Interestingly, I just tried
>>
>>    ++E = 0;
>>
>> with cc and c++ compilers. The first rejected it (as ++E needing to be
>> an lvalue); the second accepted it. That's not a reflection of either
>> compiler, BTW, but without checking it's probably more to do with the
>> language/dialect definition. FWIW I expect the second compiler could
>> be persuaded to issue a warning about unreachable code or suchlike.
>
> What does C++ expect it to mean?

Probably the same as my language (since it retains the lvalue) but I
don't know C++.

--
James Harris

On 14/11/2022 19:51, David Brown wrote:
> On 14/11/2022 19:02, James Harris wrote:
>> On 14/11/2022 17:28, David Brown wrote:
>>> On 14/11/2022 16:14, James Harris wrote:
>>>> On 14/11/2022 10:24, Stefan Ram wrote:
>>>>> James Harris <james.harris.1@gmail.com> writes:

>>>>>> Rather than allowing non-ASCII in source I came up with a scheme
>>>>>> of what
>>>>>> you might call 'named characters' extending the backslash idea of
>>>>>> C to
>>>>>> allow names instead of single characters after the backslash. It's
>>>>>> off
>>>>>> topic for this thread but it allows non-ASCII characters to be named
>>>>>> (such that the names consist of ASCII characters and would thus be
>>>>>> readable and universal).

....

>> What's needed, IMO, is a set of names intended for /processing/ rather
>> than for typesetting.
>>
> That makes little sense to me.  Are you intending to invent your own
> character encoding, or your own fonts here?  Are you planning on making
> your own display or print system?

As I've already said, Unicode and HTML are fine for output. Where
programmers work with the semantics of characters, however, they need
characters to be in semantic categories, you know: letters, arithmetic
symbols, digits, different cases, etc. So far I've not come across
anything to support that multilingually. AISI what's needed is a way to
expand character encodings to bit fields such as

<category><base character><variant><diacritics><appearance>

where

category = group (e.g. alphabetic letters, punctuation, etc)
base character = main semantic identification (e.g. an 'a')
variant (e.g. upper or lower case)
diacritics (those applied to this character in this location)
appearance (e.g. a round 'a' or a printer's 'a' or unspecified)

Note that that's purely about semantics; it doesn't include typefaces or
character sizes or bold or italic etc which are all for rendering.

>
> The character "⅘" is easily typed on *nix keyboards with a compose key
> (with common setups), HTML has it as "&frac45;", Unicode has it as
> "U+2158 Vulgar fraction four fifths".  They support fractions that are
> common enough to exist as characters in fonts.  You can't add your own
> personal "twenty two sevenths" character and expect it to turn up when
> printed, nor will you ever come across it when reading files or
> documents from elsewhere.  (Of course you can choose to support only a
> subset of the HTML or Unicode names.)

Anything like that which doesn't scale should be classified as
patronising garbage. I can give you my more-negative comments about such
nonsense, if you like. >:-|

If you want to discuss this further I'd appreciate it if you could start
another thread; I would reply to it. This thread is already full!

>
> And what do you mean by "processing", and what makes you think it is
> remotely relevant to separate diacritics from characters?

A standard is needed. Which to use? If there are 100 letters and 40
diacritics then there would be 140 codes. If they were to be
amalgamated, however, then you could have up to 4000 combined
characters. And that's allowing each letter to have only one diacritic.
Allow two and you have 160,000 potential characters. Etc.

> In some
> languages, "ä" is a letter "a" with a diacritic, in others it is an
> entirely distinct letter of its own.  The same applies to lots of
> characters.  Unicode has a complex system of "normalisation" for
> relating combining diacritics and letters into single combined Unicode
> characters, which are often a better choice for display than you would
> get with by displaying two individual graphemes.

See above.

>
> Are you going to try to split up Chinese or Korean characters into their
> components?  What about Mongolian, or Arabic?

I'd consider it but I don't yet know enough about those languages or how
they are typically processed in programs to comment.

--
James Harris

On 2022-11-15 10:35, James Harris wrote:

> As I've already said, Unicode and HTML are fine for output. Where
> programmers work with the semantics of characters, however, they need
> characters to be in semantic categories, you know: letters, arithmetic
> symbols, digits, different cases, etc. So far I've not come across
> anything to support that multilingually. AISI what's needed is a way to
> expand character encodings to bit fields such as
>
>   <category><base character><variant><diacritics><appearance>
>
> where
>
>   category = group (e.g. alphabetic letters, punctuation, etc)
>   base character = main semantic identification (e.g. an 'a')
>   variant (e.g. upper or lower case)
>   diacritics (those applied to this character in this location)
>   appearance (e.g. a round 'a' or a printer's 'a' or unspecified)
>
> Note that that's purely about semantics; it doesn't include typefaces or
> character sizes or bold or italic etc which are all for rendering.

I am not sure what are you trying to say. The Unicode characterization
is defined in the file:

https://unicode.org/Public/UNIDATA/UnicodeData.txt

Programming languages like Ada (since 2005) define blanks, punctuation,
letters etc in terms of Unicode characterization in order to support
multilingual programs. Not the best idea, IMO, but for what it is worth:

https://docs.adacore.com/live/wave/arm12/html/arm12/arm12-2-3.html#S0002

There is no problem with Unicode string literals whatsoever. You just
place characters as they are. The only escape is "" for ". That is all.

Surely programmers are advised to never ever use anything but ASCII in
identifiers and literals. If you need something else, use the code point
to string conversion and concatenation:

der_Aerger := Wide_Character'Val (16#C4#) & "rger";

(Diaeresis rhymes with diarrhea (:-))

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

On 14/11/2022 20:45, David Brown wrote:
> On 14/11/2022 18:37, James Harris wrote:
>> On 14/11/2022 14:47, David Brown wrote:
>>> On 14/11/2022 11:44, James Harris wrote:
>>>> On 14/11/2022 09:26, David Brown wrote:

....

>>> A big step in that direction is to say that assignment is a
>>> statement, not an expression,
>>
>> Done that.
>>
>>> and that variables cannot be changed by side-effects.
>>
>> I will not be doing that. I know you favour functional programming,
>> and that's fine, but the language I am working on is unapologetically
>> imperative.
>>
>
> Many unapologetically imperative languages do not allow side-effects in
> expressions.  It is a natural rule for functional programming languages,
> since pure functional programming does not have side-effects or
> modifiable variables at all.  But there is absolutely /nothing/ about
> being an imperative language that suggests you need to allow
> side-effects or assignments /within/ expressions.

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??

....

>>
>>>>> These two statements go together as well as Dmitry's toaster and
>>>>> toilet brush.  It doesn't matter how precisely you define how the
>>>>> combination can be used and what it does, it is still not a good or
>>>>> useful thing.
>>>>
>>>> OK, let's take the combination you mentioned:
>>>>
>>>>    ++E++
>>>>
>>>> I wonder why you see a problem with it. As I see it, it increments E
>>>> before evaluation and then increments E after evaluation. What is so
>>>> complex about that? It does exactly what it says on the tin, and in
>>>> the order that it says it. Remember that unlike C I define the
>>>> apparent order of evaluation so the expression is perfectly well
>>>> formed.
>>>>
>>>
>>> The very fact that you are discussing how to define it means it is
>>> not clear and obvious.
>>
>> On that I must disagree.
>
> You think it is /obvious/ what "++E++" means?

If you don't know the rules then its not obvious.

If you know the rules then it's *blindingly* obvious. What's more, the
rules are easy to learn.

....

> "++E++" remains meaningless to experienced programmers.

It may be meaningless to programmers who wrongly try to apply the rules
of other languages to it but why would you do that? It's an invalid
thing to do. Languages differ.

>
>>
>>> It is not obvious which order the increments happen, or if the order
>>> is defined, or if the order matters.  It is not obvious what the
>>> return value should be.  It is not obvious where you have lvalues or
>>> rvalues (not that a language should necessarily have such concepts).
>>> It is not obvious what happens to E.
>>
>> Of course it's not obvious to someone who doesn't know the rules of
>> the language. A language designer cannot produce a language with no
>> rules. What a language designer /can/ do is to make the rules simple
>> and understandable - but someone who reads the code still has to
>> understand what the rules are.
>>
>
> I do not think "++E++" will be clear and obvious to someone who /does/
> know the rules of the language.

It parses as

(++E)++

Operations would appear to be applied in that order, prefix then
postfix. It's not complicated. Take an example:

E = 5
A = (++E)++ ;if it helps you to see it that way but parens not needed
print A, E

result:

6 7

If you want a bit more formality:

++E ==> (E := E + 1; E)
E++ ==> (T := E; E := E + 1; valof(T))

> Remember, this is not something that
> will be commonly used and become idiomatic, like "*p++ = *q++;" is in C.
>  Programmers will always need to look up the details - that's why it is
> not a good idea.

Maybe you find it hard to read because you are trying to look at it as a
single operation - a bit like a spaceship symbol? It's not. It's two
entirely separate operations that just happen to be adjacent. Think of
them in that way and as long as you know the order in which they will be
applied the overall effect is obvious.

>
>> As for the rules we have been discussing here those I have come up
>> with are, in the main, the ones you would be familiar with; even the
>> new ones are logical and simple. Once you understand them it's
>> incredibly easy to parse an expression, even of the kind which, to
>> you, looks like gibberish.
>>
>> In fact, I have to say that neither of those you have objected to
>> should really look like gibberish, even to the uninitiated. Would you
>> find
>>
>>    ++A + B++
>>
>> objectionable?
>
> Yes.
>
>> If not, I cannot see why you would find
>>
>>    ++E + E++
>>
>> so objectionable, either.
>
> It is worse, because you are changing the same thing twice in an
> unordered manner.

That's not true. I've said many times that the apparent order would be
defined. Did you not read what I wrote or is there some other reason you
still think it would be unordered?

Operands to binops like "+" would appear to be evaluated left-then-right.

--
James Harris

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.

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

On 14/11/2022 23:28, Andy Walker wrote:
> On 14/11/2022 20:45, David Brown wrote:
> [To James:]
>> [...]  But there is absolutely
>> /nothing/ about being an imperative language that suggests you need
>> to allow side-effects or assignments /within/ expressions.
>
>     If assignments within expressions are verboten, then you need to
> either forbid assignments within functions or have two classes of function,
> those with and those without [inc sub-procedures].  If assignments are
> allowed at all, then you cannot in general tell at compile time whether
> any assignment is reached at run time, leading to further complications.
> If you regard output as a side-effect, that too leads to problems.  Yet
> during program development it is common to insert temporary diagnostic
> printing or variables.  I can understand the concept of languages without
> assignments or other side effects;  and of languages with them;  I find it
> difficult to see the point of languages where such things are allowed in
> some places and not in others.  If we need hair shirts [and I'm not sure
> that we do], they should be worn all the time, not put on and taken off
> in accordance with arcane rules that only high priests understand.

Largely agreed. I was going to reply to that to tackle the 'alarming
wave' (tm) of recommendations in this group for functional programming
but as it may snowball into a bigger discussion I've started a new
thread. qv

--
James Harris

On 15/11/2022 09:42, James Harris wrote:
> On 15/11/2022 01:14, Bart wrote:
>> On 14/11/2022 16:21, James Harris wrote:
>>> On 14/11/2022 11:11, Bart wrote:
>
> ...
>
>>> The rules for ++ and -- are simple. *Prefix* ++ or -- happens before
>>> postfix ++ or --.
>>
>> Is that for all unary operators or just ++ and --?
>
> Just ++ and ==, as stated.
>
>>
>> If only for those, then those exceptions will make rules for all unary
>> ops even more bizarre. If for all of them, then one consequence is
>> that `-P^` is parsed as `(-P)^`, so that you try to negate a pointer,
>> instead of what's at the pointer target.
>>
>> However, I have my own exceptions, which are casts:
>>
>>      ref u16(P)^ := 0
>
> Rather than casts I have conversions. Are they the same? I never really
> understood how people use the term 'cast'. Either way, you raise a good
> point: Where should type conversions come in the order of precedence.
>

In C terminology, a "cast" is an explicit conversion. So :

int x = 123;
double y = 12.3;

x = y;

is an implict conversion - the value in "y", of type "double", is
converted to type "int" automatically.

x = (int) y;

is a cast - it is an /explicit/ conversion. In this case, it does
exactly the same thing to the value, of course.

"Typecast", on the other hand, is something that happens to actors when
they have played on kind of role too long and people don't think they
can change. It has no meaning in C terminology - though people use it,
thinking it means "cast".

Other languages can have slightly different terminology.

>
>>>> Because if they ever start to return lvalues, then this becomes
>>>> possible:
>>>>
>>>>     ++E := 0
>>>>     E++ := 0
>>>>
>>>> (Whichever one is legal in your scheme.) So I think there is little
>>>> useful expressivity to be gained.
>>>
>>> Indeed, neither of those is useful.
>>>
>>> Interestingly, I just tried
>>>
>>>    ++E = 0;
>>>
>>> with cc and c++ compilers. The first rejected it (as ++E needing to
>>> be an lvalue); the second accepted it. That's not a reflection of
>>> either compiler, BTW, but without checking it's probably more to do
>>> with the language/dialect definition. FWIW I expect the second
>>> compiler could be persuaded to issue a warning about unreachable code
>>> or suchlike.
>>
>> What does C++ expect it to mean?
>
> Probably the same as my language (since it retains the lvalue) but I
> don't know C++.
>

In both C and C++, "++E" means precisely the same as "E += 1", which
again means precisely the same as "E = E + 1". (This is assuming no
overloaded operators in C++.)

In C, the result of "(E = E + 1)" is the /value/ of E after the
addition, and is thus an lvalue.

In C++, the result is a /reference/ to E after the addition, and
therefore an lvalue.

I don't know the precise reasoning for the difference - perhaps it is
simply that the addition of references to the language made it natural
to have an lvalue in such cases, while C does not have references.

("References" in C++ terminology are just names for lvalues. They can
be thought of as non-null pointers that are dereferenced automatically -
except the compiler will not actually make pointers or put things in
memory unless necessary.)

On 15/11/2022 12:44, James Harris wrote:
> On 14/11/2022 20:45, David Brown wrote:
>> On 14/11/2022 18:37, James Harris wrote:
>>> On 14/11/2022 14:47, David Brown wrote:
>>>> On 14/11/2022 11:44, James Harris wrote:
>>>>> On 14/11/2022 09:26, David Brown wrote:
>
> ...
>
>>>> A big step in that direction is to say that assignment is a
>>>> statement, not an expression,
>>>
>>> Done that.
>>>
>>>> and that variables cannot be changed by side-effects.
>>>
>>> I will not be doing that. I know you favour functional programming,
>>> and that's fine, but the language I am working on is unapologetically
>>> imperative.
>>>
>>
>> Many unapologetically imperative languages do not allow side-effects
>> in expressions.  It is a natural rule for functional programming
>> languages, since pure functional programming does not have
>> side-effects or modifiable variables at all.  But there is absolutely
>> /nothing/ about being an imperative language that suggests you need to
>> allow side-effects or assignments /within/ expressions.
>
> 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??
>

As I said before (a couple of times at least), function calls are
another matter and should be considered separately.

One possibility is to distinguish between "functions" that have no side
effects and can therefore be freely mixed, re-arranged, duplicated,
omitted, etc., and "procedures" that have side-effects and must be
called exactly as requested in the code. Such "procedures" would not be
allowed in expressions - only as statements or part of assignment
statements.

In many cases where you have modification of parameters or passing by
non-const address, a more advanced language could use multiple returns :

bytes, data = read(fd, max_count)

But that might require considerable compiler effort to generate
efficient results in other cases.

> ...
>
>>>
>>>>>> These two statements go together as well as Dmitry's toaster and
>>>>>> toilet brush.  It doesn't matter how precisely you define how the
>>>>>> combination can be used and what it does, it is still not a good
>>>>>> or useful thing.
>>>>>
>>>>> OK, let's take the combination you mentioned:
>>>>>
>>>>>    ++E++
>>>>>
>>>>> I wonder why you see a problem with it. As I see it, it increments
>>>>> E before evaluation and then increments E after evaluation. What is
>>>>> so complex about that? It does exactly what it says on the tin, and
>>>>> in the order that it says it. Remember that unlike C I define the
>>>>> apparent order of evaluation so the expression is perfectly well
>>>>> formed.
>>>>>
>>>>
>>>> The very fact that you are discussing how to define it means it is
>>>> not clear and obvious.
>>>
>>> On that I must disagree.
>>
>> You think it is /obvious/ what "++E++" means?
>
> If you don't know the rules then its not obvious.

Yes.

>
> If you know the rules then it's *blindingly* obvious. What's more, the
> rules are easy to learn.

No. If you see that written, it is blindingly obvious that the
programmer is a smart-arse that thinks it is "cool" to write something
that looks like a flourish or ornament at the end of a book chapter,
instead of writing "E += 2" or "E = E + 2".

I am not interested in pandering to smart-arse programmers. There are
too many of them already, and they don't need encouragement.

On 15/11/2022 08:07, David Brown wrote:
>
> On 14/11/2022 19:43, Bart wrote:

> > It requires some effort in Python and the result will be clunky (and
> > probably require some add-on modules).

> >>> import struct        # Standard module
> >>> bs = open("potato_c.cof").read()
>
> >>> machine, nsections, timestamp, symtaboffset, nsymbols,
> optheadersize, characteristics = struct.unpack_from("<HHIIIHH")
>
> That's it.  Three lines.  I would not think of C for this kind of thing
> - Python is /much/ better suited.  I'd only start looking at C (or C++)
> if I need so high speed that the Python code was not fast enough, even
> with PyPy.

I said it will be clunky and require add-on modules and it is and does.
(BTW you might be missing an argument in that struct.unpack_from call.)

Using that approach for the nested structs and unions of my other
example is not so straightforward. You basically have to fight for every
field.

The result is a tuple of unnamed fields. You really want a proper
record, which is yet another add-on, with a choice of several modules
depending on which set of characterics you need.

The elements of the tuple are also normal Python variables. If you
wanted to modify elements (which needs a mutable tuple anyway), they
will not behave the same way as those packed types, and then you'd have
to write the whole struct back (using .pack), and will need to know its
provenance, which here has been lost. With a reference like mine, that
is built-in.

In short, it's a hack. But it's a typical approach using in scripting
languages.

'struct' is also not a true Python module; it's a front end for an
internal one called `_struct`, likely implemented in C, and almost
certainly using pointers.

(Whereas, by having pointers as intrinsic features, I know I could
implement such a module in my language, if I needed to. Think of it as a
language building feature.)

> > While a functional language will
> > struggle (to be accurate, the programmer will struggle because they've
> > chosen the wrong language).
> I don't believe that.  I am not familiar enough with Haskell to be able
> to give the code, but I have no doubts at all that someone experienced
> with Haskell will manage it fine.  IO is not hard in the language, and
> it has all the built-in modules needed for such interfaces.
>
> Haskell is apparently number 25 on the list of language popularities on
> Github, with about 0.4% usage.  That's not huge, but not insignificant
> either.  But then, it was never intended to be a major practical
> language - though some people and companies (Facebook uses it for
> content analysis) do use it for practical work.  It's main motivations
> are for teaching people good software development, developing new
> techniques, algorithms and methods, and figuring out what "works" and
> could be incorporated in other languages.

I group them all together: ML, OCaml, Haskell, F#, sometimes even Lisp.

Anything that makes a big deal out of closures, continuations, currying,
lambdas and higher order functions. I have little use for such things
otherwise.

Haskell is great for elegantly defining certain kinds of types and
algorithms, not so good for reams of boilerplate code or UI stuff which
is what much of programming is.

It doesn't even have loops (AIUI); one task of the EXE reader is to
displays lists of sections, imports, exports, base relocations...

Loops are such a basic requirement, and yet a language designer decides
they don't need them. After all you can emulate any loop using
recursion, no matter that it makes for less readable, less intuitive
(and less efficient) code.

> It is that last feature that is most noticeable.  Most major modern
> languages are not pure functional languages in themselves, but contain
> aspects from functional programming.

Yeah. It turns out that pretty every language you've heard of (except C)
has higher-order functions. Too much pressure from academics I reckon.

Such features have some very subtle behaviours which I find incredibly
hard to get my head around.

(See the 'twice plus-three' example in
https://en.wikipedia.org/wiki/Higher-order_function. It me ages to
figure out what was going on there, and what was needed in an
implementation to make it work.)

They make understanding whatever:

E++^

means child's play by comparison. And yet THIS is the feature you want
to ban! I don't get it. Remember not everone is a mathematician.

E++^ is well defined in my code. Instead of:

doswitch c:=p++^
when 'A'..'Z' then...

which involves modifying two things, I'd have to write ... actually I
don't know what; there is nowhere to put them. I'd have to split that
loop and switch, and add a new indent level:

do
c := S[p] # change to an indexed string
p := p + 1
switch c
...

It's a bit like turning HLL code into assembly! Plus, with that extra S,
two extra 'p's, and that '1' there are quite a few extra things to get
wrong, and extra lines for somebody to grok and relate to each other.

>  I can't think of any serious,
> popular language with significant development in the last decade that
> does not have lambdas and the ability to work with functions as objects.

Exactly, and that is totally wrong. Too much attention is paid to
academics who seem to know little about designing accessible languages.

In Python, every function is really a variable initialised [effectively]
to some anonymous function. Which means that with 100% of the functions,
you can do this for any defined function F:

F = 42

Or, more subtly, setting it to any arbitrary functions. That sounds
incredibly unsafe.

So Python has immutable tuples, but mutable functions! Every identifier
is a variable that you can rebind to something else.

With my scripting language, you can do that with exactly 0% of the
defined functions. If you want mutable function references, /then/ you
use a variable: G := F.

> This is why I bring it up here - not because I think the OP should be
> making a functional programming language, but because I think he should
> be taking inspiration and incorporating ideas from that world.

Sure, I've taken lots of ideas from functional languages, ones that
still work in an imperative style. For example I use functions like
head() and tail() from Haskell (except mine aren't lazy). I once had
list-comps too, but they fell into disuse.

I don't have lambda functions, but I have a thing called deferred code,
which I haven't yet gotten around to. The problem is figuring out
exactly how in-depth the implementation should be, because no matter
what you do, there will be yet another example from the FP world which
reveals one more dimension you hadn't realised existed.

Then I start to think, I don't really want the people who might use a
language like mine to need to bother their heads about it. Code should
be clear and obvious; relying on the incredibly subtle and obscure
behaviours associated with lambdas, closures et al, isn't.

> >
> > Here's a more challenging record type that comes up in OBJ files:
> >
> >      type imagesymbol=struct
> >          union
> >              stringz*8 shortname
> >              struct
> >                  u32   short
> >                  u32   long
> >              end
> >              u64      longname
> >          end
> >          u32  value
> >          u16  sectionno
> >          u16  symtype
> >          byte storageclass
> >          byte nauxsymbols
> >      end
> >
> > (Again, this is defined directly in my /dynamic/ scripting language.)
> >
> Again, peanuts in Python - and I expect also peanuts in Haskell.

I'm sure there is a way to do it with enough effort. But as effortlessly
as this, as readable, and with the abilty to just do P.shortname to get
an actual string? You will get there eventually, but it's basically DIY.

You don't believe amateurs can add value to what mainstream languages
can do. The trouble is that you don't appreciate the things that add
value, so long as there is some unreadable, unsafe way to hack your way
around a task.

> Nothing of that is /remotely/ worth making a new language and giving up
> on everything C - tools, compilers, developer familiarity, libraries,
> and all the rest.

With an army of people behind it, such tools can be created for a new
language.

On 15/11/2022 15:26, Bart wrote:
> On 15/11/2022 08:07, David Brown wrote:

....

>> Most major modern
>> languages are not pure functional languages in themselves, but contain
>> aspects from functional programming.
>
> Yeah. It turns out that pretty every language you've heard of (except C)
> has higher-order functions. Too much pressure from academics I reckon.
>
> Such features have some very subtle behaviours which I find incredibly
> hard to get my head around.
>
> (See the 'twice plus-three' example in
> https://en.wikipedia.org/wiki/Higher-order_function. It me ages to
> figure out what was going on there, and what was needed in an
> implementation to make it work.)
>
> They make understanding whatever:
>
>    E++^
>
> means child's play by comparison. And yet THIS is the feature you want
> to ban! I don't get it.

Good point! Preferences definitely vary.

....

> This discussion is about whether to have a shorter way of writing:
>
>   <expr> := <the exact same expr> + 1
>
> And whether that is:
>
>   <expr> +:= 1
>
> or either of:
>
>   ++<expr>
>   <expr>++
>
> (This example uses the non-value-returning variety.)

Yes, AISI the discussion was primarily about what such operations should
mean and how they should be ordered relative to each other. The subtext
was whether they should be included at all. At least now I've got a good
way to include them that choice is still open. That's far better than
just simply banning them and avoiding the challenge.

--
James Harris

On 2022-11-15 17:22, James Harris wrote:

> Yes, AISI the discussion was primarily about what such operations should
> mean and how they should be ordered relative to each other. The subtext
> was whether they should be included at all. At least now I've got a good
> way to include them that choice is still open. That's far better than
> just simply banning them and avoiding the challenge.

That depends on your priorities. E.g. the Rubik's cube. You rotate a
row, four sides change. That's fun. But me, a prosaic programmer, just
pluck the slates one by one and put them back in order... (:-))

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

On 15/11/2022 14:22, David Brown wrote:
> On 15/11/2022 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??
>>
>
> As I said before (a couple of times at least), function calls are
> another matter and should be considered separately.

Then you wouldn't be able to prevent a programmer coding

a = b + nudge_up(&c) + d;

and therefore the programmer may query why ++c is not available in the
first place.

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.

>
> One possibility is to distinguish between "functions" that have no side
> effects and can therefore be freely mixed, re-arranged, duplicated,
> omitted, etc., and "procedures" that have side-effects and must be
> called exactly as requested in the code.  Such "procedures" would not be
> allowed in expressions - only as statements or part of assignment
> statements.

Classifying functions by whether they have side effects or not is not as
clear-cut as it may at first appear. Please see the thread I started
today on functional programming.

>
> In many cases where you have modification of parameters or passing by
> non-const address, a more advanced language could use multiple returns :
>
>     bytes, data = read(fd, max_count)
>
> But that might require considerable compiler effort to generate
> efficient results in other cases.

Thanks for the suggestion. I wondered about that and I like it in
principle but couldn't see how one would then sensibly (i.e. efficiently
and in keeping with the rest of the language) then go on to write the
data (whose length we would not know in advance, although we would know
its maximum size) to the correct part of the buffer.

....

>>> You think it is /obvious/ what "++E++" means?
>>
>> If you don't know the rules then its not obvious.
>
> Yes.
>
>>
>> If you know the rules then it's *blindingly* obvious. What's more, the
>> rules are easy to learn.
>
> No.  If you see that written, it is blindingly obvious that the
> programmer is ...

No, it is not. In languages in which 'nudge' operators are supported
many programmers may write

++E

as a subexpression if they want E to be incremented before it is
evaluated. They may also write

E++

if they want E to be incremented after it is evaluated. And if the
algorithm they are they are implementing calls for E to be incremented
before and after then programmers should be able to code both. This is
not about them being clever. It's about them being able to have the code
naturally express the intent of the algorithm and to reflect the
processing that's in the programmer's mind.

All that's required, compared with C, is for the apparent evaluation
order to be defined.

--
James Harris

On 15/11/2022 16:35, Dmitry A. Kazakov wrote:
> On 2022-11-15 17:22, James Harris wrote:
>
>> Yes, AISI the discussion was primarily about what such operations
>> should mean and how they should be ordered relative to each other. The
>> subtext was whether they should be included at all. At least now I've
>> got a good way to include them that choice is still open. That's far
>> better than just simply banning them and avoiding the challenge.
>
> That depends on your priorities. E.g. the Rubik's cube. You rotate a
> row, four sides change. That's fun. But me, a prosaic programmer, just
> pluck the slates one by one and put them back in order... (:-))

:-)

--
James Harris

On 15/11/2022 17:58, James Harris wrote:
> On 15/11/2022 14:22, David Brown wrote:
>> On 15/11/2022 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??
>>>
>>
>> As I said before (a couple of times at least), function calls are
>> another matter and should be considered separately.
>
> Then you wouldn't be able to prevent a programmer coding
>
>   a = b + nudge_up(&c) + d;

Why wouldn't I (as a language designer) be able to prevent that?

We don't live in the days of assemblers where the only thing you know
about a function is its name and a hope that you've got the parameters
right. The declaration of a function (from module import, or however
you want to handle it) can include all sorts of information about the
function. Is it pure? Is it small, suitable for inlining? Can it
throw a exceptions? What are its pre-conditions and post-conditions?
(Some languages support "programming by contract" to make it hugely
easier to check correctness.)

>
> and therefore the programmer may query why ++c is not available in the
> first place.
>

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. Don't run away claiming
you had no choice or hide behind assertions about what other programmers
or other languages do.

If want side-effects in operators, functions, etc., then that's fine -
but it is /your/ choice to support that feature, and /your/ choice to
drop the benefits achievable by /not/ allowing them. You are not forced
to allow them, any more than you are forced to follow any of my
suggestions. (And often my suggestions are not given as
recommendations, but merely to air the options you have.)

> 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.

>>
>> One possibility is to distinguish between "functions" that have no
>> side effects and can therefore be freely mixed, re-arranged,
>> duplicated, omitted, etc., and "procedures" that have side-effects and
>> must be called exactly as requested in the code.  Such "procedures"
>> would not be allowed in expressions - only as statements or part of
>> assignment statements.
>
> Classifying functions by whether they have side effects or not is not as
> clear-cut as it may at first appear. Please see the thread I started
> today on functional programming.
>

You'll notice I've replied to it :-)

The classification is not /entirely/ clear-cut, but not for the reasons
you think or described. It is possible to allow side-effects that have
no visible or logical effect, but exist only as hidden effects for
implementation efficiency purposes. Such a feature has to be controlled
carefully to ensure there are not logical effects.

>>
>> In many cases where you have modification of parameters or passing by
>> non-const address, a more advanced language could use multiple returns :
>>
>>      bytes, data = read(fd, max_count)
>>
>> But that might require considerable compiler effort to generate
>> efficient results in other cases.
>
> Thanks for the suggestion. I wondered about that and I like it in
> principle but couldn't see how one would then sensibly (i.e. efficiently
> and in keeping with the rest of the language) then go on to write the
> data (whose length we would not know in advance, although we would know
> its maximum size) to the correct part of the buffer.
>

I never said this would be easy!

> ...
>
>>>> You think it is /obvious/ what "++E++" means?
>>>
>>> If you don't know the rules then its not obvious.
>>
>> Yes.
>>
>>>
>>> If you know the rules then it's *blindingly* obvious. What's more,
>>> the rules are easy to learn.
>>
>> No.  If you see that written, it is blindingly obvious that the
>> programmer is ...
>
> No, it is not. In languages in which 'nudge' operators are supported
> many programmers may write
>
>   ++E
>
> as a subexpression if they want E to be incremented before it is
> evaluated. They may also write
>
>   E++
>
> if they want E to be incremented after it is evaluated. And if the
> algorithm they are they are implementing calls for E to be incremented
> before and after then programmers should be able to code both. This is
> not about them being clever. It's about them being able to have the code
> naturally express the intent of the algorithm and to reflect the
> processing that's in the programmer's mind.
>
> All that's required, compared with C, is for the apparent evaluation
> order to be defined.
>
>

I can appreciate that you want to give a meaning to "++E", that you want
to give a meaning to "E++", and you expect programmers to use one or the
other in different contexts. I can appreciate that you want to define
order of evaluation within expressions.

But I have yet to see any indication that "++E++" could ever be a
sensible expression in any real code.

On 14/11/2022 15:23, David Brown wrote:
> On 14/11/2022 11:47, Bart wrote:

....

>> In-place, value-returning increment ops written as ++ and -- are
>> common in languages.
>>
>
> Yes.  And bugs are common in programs.  Being common does not
> necessarily mean it's a good idea.
>
> (It doesn't necessarily mean it's a bad idea either - I am not implying
> that increment and decrement are themselves a major cause of bugs!  But
> mixing side-effects inside expressions /is/ a cause of bugs.)

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..

Just blaming operators you don't like is unsound - especially since, as
you seem to suggest below, you use them in your own code!!!

....

[discussion of ++ and -- operators]

>> Is your point that you shouldn't have either of those operators?
>
> Yes!  What gave it away - the first three or four times I said as much?

....

> ... (Of course I use increment operator, especially in loops,
> because that's how C is written.  But a new language can do better than
> that.)

If you think ++ and -- shouldn't exist then why not ban them from your
own programming for a while before you try to get them banned from a new
language?

--
James Harris

On 15/11/2022 16:26, Bart wrote:
> On 15/11/2022 08:07, David Brown wrote:
>>
>> On 14/11/2022 19:43, Bart wrote:
>
>
>>  > It requires some effort in Python and the result will be clunky (and
>>  > probably require some add-on modules).
>
>>  >>> import struct        # Standard module
>>  >>> bs = open("potato_c.cof").read()
>>
>>  >>> machine, nsections, timestamp, symtaboffset, nsymbols,
>> optheadersize, characteristics = struct.unpack_from("<HHIIIHH")
>>
>> That's it.  Three lines.  I would not think of C for this kind of
>> thing - Python is /much/ better suited.  I'd only start looking at C
>> (or C++) if I need so high speed that the Python code was not fast
>> enough, even with PyPy.
>
> I said it will be clunky and require add-on modules and it is and does.

It is not "clunky" by any sane view - certainly not compared to your
code (or code written in C). And no, it does not require add-on modules
- the "struct" module is part of Python.

> (BTW you might be missing an argument in that struct.unpack_from call.)

No, I am not. There is an optional third argument, but it is optional.

>
> Using that approach for the nested structs and unions of my other
> example is not so straightforward. You basically have to fight for every
> field.

You have to define every field in every language, or define the ones you
want along with offsets to skip uninteresting data.

>
> The result is a tuple of unnamed fields. You really want a proper
> record, which is yet another add-on, with a choice of several modules
> depending on which set of characterics you need.

You can do that in Python.

>
> The elements of the tuple are also normal Python variables. If you
> wanted to modify elements (which needs a mutable tuple anyway), they
> will not behave the same way as those packed types, and then you'd have
> to write the whole struct back (using .pack), and will need to know its
> provenance, which here has been lost. With a reference like mine, that
> is built-in.
>
> In short, it's a hack. But it's a typical approach using in scripting
> languages.

In short, you are making up shit in an attempt to make your own language
look better than other languages, because you'd rather say something
silly than admit that any other language could be better in any way for
any task.

>
> 'struct' is also not a true Python module; it's a front end for an
> internal one called `_struct`, likely implemented in C, and almost
> certainly using pointers.
>

Please re-think what you wrote there. I hope you can realise how
ridiculous you are being.

> (Whereas, by having pointers as intrinsic features, I know I could
> implement such a module in my language, if I needed to. Think of it as a
> language building feature.)
>
>
>>  > While a functional language will
>>  > struggle (to be accurate, the programmer will struggle because they've
>>  > chosen the wrong language).
>> I don't believe that.  I am not familiar enough with Haskell to be
>> able to give the code, but I have no doubts at all that someone
>> experienced with Haskell will manage it fine.  IO is not hard in the
>> language, and it has all the built-in modules needed for such interfaces.
>>
>> Haskell is apparently number 25 on the list of language popularities
>> on Github, with about 0.4% usage.  That's not huge, but not
>> insignificant either.  But then, it was never intended to be a major
>> practical language - though some people and companies (Facebook uses
>> it for content analysis) do use it for practical work.  It's main
>> motivations are for teaching people good software development,
>> developing new techniques, algorithms and methods, and figuring out
>> what "works" and could be incorporated in other languages.
>
> I group them all together: ML, OCaml, Haskell, F#, sometimes even Lisp.
>
> Anything that makes a big deal out of closures, continuations, currying,
> lambdas and higher order functions. I have little use for such things
> otherwise.
>

So because /you/ don't understand these things or how they are used, you
assume that people who /do/ understand them can't write programs in
functional programming languages?

> Haskell is great for elegantly defining certain kinds of types and
> algorithms, not so good for reams of boilerplate code or UI stuff which
> is what much of programming is.

As I mentioned in another posts, there are opinions, and there are
/qualified/ opinions.

It's /fine/ if functional programming doesn't interest you. No one can
be interested in everything or learn about all kinds of programming.
But wise people don't make categorical statements about topics they know
nothing about.

>
> It doesn't even have loops (AIUI); one task of the EXE reader is to
> displays lists of sections, imports, exports, base relocations...
>
> Loops are such a basic requirement, and yet a language designer decides
> they don't need them. After all you can emulate any loop using
> recursion, no matter that it makes for less readable, less intuitive
> (and less efficient) code.
>
>
>> It is that last feature that is most noticeable.  Most major modern
>> languages are not pure functional languages in themselves, but contain
>> aspects from functional programming.
>
> Yeah. It turns out that pretty every language you've heard of (except C)
> has higher-order functions. Too much pressure from academics I reckon.
>
> Such features have some very subtle behaviours which I find incredibly
> hard to get my head around.
>

You are a smart guy. You could get your head around it quite easily, if
only you were willing. (I can try and help, if you want - but only if
you promise not to give up before you start, claim that it is all
useless, ugly, or clunky without justification, and not to go off on a
tangent about how much better your own language is.)

> (See the 'twice plus-three' example in
> https://en.wikipedia.org/wiki/Higher-order_function. It me ages to
> figure out what was going on there, and what was needed in an
> implementation to make it work.)

Try pasting the C++ code into godbot.org, and compile with -O2 :

auto twice = [](auto f)
{ return [f](int x) {
return f(f(x));
};
};

auto plus_three = [](int i)
{ return i + 3;
};

int foo()
{ auto g = twice(plus_three);

return g(7);
}

The compiler happily turns "foo" into "return 13".

But I agree that gcc has to work harder to implement this kind of thing
than your own compiler for your own language.

>>   I can't think of any serious, popular language with significant
>> development in the last decade that does not have lambdas and the
>> ability to work with functions as objects.
>
> Exactly, and that is totally wrong. Too much attention is paid to
> academics who seem to know little about designing accessible languages.
>

It's not academics that use these features - it is practical
programmers. A big use of lambdas, for example, is in callbacks and
event handlers - used all the time in GUI programs and Javascript.

Academics may invent this kind of thing, and use languages like Haskell
to play with them - but they are implemented in real languages because
real programmers use them for real code. Rust, Go, C++ - these are not
academics' languages.

> In Python, every function is really a variable initialised [effectively]
> to some anonymous function. Which means that with 100% of the functions,
> you can do this for any defined function F:
>
>     F = 42
>
> Or, more subtly, setting it to any arbitrary functions. That sounds
> incredibly unsafe.

Python /is/ unsafe - it's a very dynamic language, with little
compile-time checking. It is checked at run-time.

But no, Python does not have variables at all. It has /names/, that are
references to objects. A function is an object, usually (but not
necessarily) given a name with a "def" statement. That name can be
rebound to a different object, just like any other name.

>
> So Python has immutable tuples, but mutable functions! Every identifier
> is a variable that you can rebind to something else.

Functions are not mutable in Python. You misunderstand.

>
> With my scripting language, you can do that with exactly 0% of the
> defined functions. If you want mutable function references, /then/ you
> use a variable: G := F.
>

On 15/11/2022 17:31, David Brown wrote:
> On 15/11/2022 17:58, James Harris wrote:
>> On 15/11/2022 14:22, David Brown wrote:
>>> On 15/11/2022 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??
>>>>
>>>
>>> As I said before (a couple of times at least), function calls are
>>> another matter and should be considered separately.
>>
>> Then you wouldn't be able to prevent a programmer coding
>>
>>    a = b + nudge_up(&c) + d;
>
> Why wouldn't I (as a language designer) be able to prevent that?

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...! :-)

....

> 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. A language cannot be built on
ad-hoc choices such as you have suggested. In this very thread you've
suggested I prohibit certain operator combinations, and that I ban side
effects in expressions but maybe not necessarily those from parameters
in function calls. It's not that simple. If a language designer were to
'pick and mix' like that the resultant language would be a nightmare to
learn and use. There has to be a language 'ethos' - i.e. an overall
approach it takes - and it has to follow consistent principles if it is
going to be a good design rather than a bad one.

....

>> 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. It's ad-hoc rules which become burdensome. By contrast,
saying any operator can be 'adjacent' to any other as long as the types
are honoured makes learning a language more logical. It may give the
programmer freedoms you personally don't like but they make the language
easier to learn and use.

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.

>
>>>
>>> One possibility is to distinguish between "functions" that have no
>>> side effects and can therefore be freely mixed, re-arranged,
>>> duplicated, omitted, etc., and "procedures" that have side-effects
>>> and must be called exactly as requested in the code.  Such
>>> "procedures" would not be allowed in expressions - only as statements
>>> or part of assignment statements.
>>
>> Classifying functions by whether they have side effects or not is not
>> as clear-cut as it may at first appear. Please see the thread I
>> started today on functional programming.
>>
>
> You'll notice I've replied to it :-)

:-)

....

>> All that's required, compared with C, is for the apparent evaluation
>> order to be defined.
>>
>>
>
> I can appreciate that you want to give a meaning to "++E",

No, I don't! You have this all wrong. The reason for considering the
inclusion of the operators we have been discussing in this thread is to
allow a more natural style of expression for algorithms that it suits.
You seem to keep thinking the goal is to attribute meaning to symbols.
That's not so.

> that you want
> to give a meaning to "E++", and you expect programmers to use one or the
> other in different contexts.  I can appreciate that you want to define
> order of evaluation within expressions.

I don't /want/ to define the order of evaluation; I /do/ define the
(apparent) order of evaluation. That's part of my language's ethos. If
I, in addition, permit ++ etc and dereference then their apparent order
/has/ to be defined, and it now has been.

>
> But I have yet to see any indication that "++E++" could ever be a
> sensible expression in any real code.

Bart came up with an example something like

+(+(+(+ x)))

That's not at all sensible. You want that banned, too?

--
James Harris

On 15/11/2022 18:05, David Brown wrote:
> On 15/11/2022 16:26, Bart wrote:

>> I group them all together: ML, OCaml, Haskell, F#, sometimes even Lisp.
>>
>> Anything that makes a big deal out of closures, continuations,
>> currying, lambdas and higher order functions. I have little use for
>> such things otherwise.
>>
>
> So because /you/ don't understand these things or how they are used, you
> assume that people who /do/ understand them can't write programs in
> functional programming languages?

No. It's nothing I've ever used, and unlikely ever to use. I like my
functions plain, and static, just like you prefer your expressions to
use only simple operators with no side-effects.

I still can't comprehend why YOU think this stuff is simple and obvious,
yet you are stumped by an increment of a pointer followed by a dereference.

On a list of must-haves for a programming language, not only would they
not be at the top of my list, they wouldn't even be at the bottom!

>> Haskell is great for elegantly defining certain kinds of types and
>> algorithms, not so good for reams of boilerplate code or UI stuff
>> which is what much of programming is.
>
> As I mentioned in another posts, there are opinions, and there are
> /qualified/ opinions.

My opinion comes from 20 years of writing code to /get things done/ in a
working environment. Which includes developing the languages and
choosing the features that that best made that possible. Never once did
I think that 'currying' was going to dramatically transform how I coded;
never did I spend days working around the omissions of closures.

>> Such features have some very subtle behaviours which I find incredibly
>> hard to get my head around.
>>
>
> You are a smart guy.  You could get your head around it quite easily, if
> only you were willing.

No, it is hard, obscure, subtle. Take my word for it.

> Try pasting the C++ code into godbot.org, and compile with -O2 :

> The compiler happily turns "foo" into "return 13".

So what does that mean? C++ clearly has support for this, and some
optimisations which can collapse the function calls into a constant
value. That tells us nothing about how hard the task is or how hard it
is understand exactly why the task is more difficult that it at first looks.

I discussed on Reddit how such a thing would look in my dynamic language
if I decided to implement it, which is like this:

fun twice(f) = {x:f(f(x))} # {...} is my deferred code syntax
fun plusthree(x) = x+3 # 'fun' is for one-liners

g := twice(plusthree)
println g(7)

I instead tried with a mock-up, which had two components: the
transformations my bytecode compiler would do, and the support code that
would need to be supplied by the language. The mock-up within the
working language looked like this:

# Transformed user code
fun af$1(x, f, g) = f(f(x))
fun twice(f) = makecls(af$1, f)
fun plusthree(x) = x+3

g := twice(plusthree)
println callcls(g, 7)

# Emulating interpreter support
record cls = (var fn, a, b)

func makecls(f, ?a, ?b)=
cls(f, a, b)
end

func callcls(c, x)=
fn := c.fn
fn(x, c.a, c.b)
end

This produced the correct result. Enough worked also so that `twice`
could be called again with a different argument, while the original `g`
still worked. (A cruder implementation could hardcode things so that,
while it produced '13', it would only work with a one-time argument to
`twice`.)

This is where it turned out that there were further refinements needed
to make it work with more challenging examples.

In the end I didn't do the necessary changes as, while intriguing to
work on, mere box-ticking was not a worthwhile use of my time, nor a
worthwhile complication in my product, since I was never going to use it.

> It's not academics that use these features - it is practical
> programmers.  A big use of lambdas, for example, is in callbacks and
> event handlers - used all the time in GUI programs and Javascript.

Yes, that was my deferred code feature, itself deferred. (It means I
have to instead define an explicit, named function.)

> Academics may invent this kind of thing, and use languages like Haskell
> to play with them - but they are implemented in real languages because
> real programmers use them for real code.  Rust, Go, C++ - these are not
> academics' languages.

I find idiomatic Rust incomprehensible.

>
>> In Python, every function is really a variable initialised
>> [effectively] to some anonymous function. Which means that with 100%
>> of the functions, you can do this for any defined function F:
>>
>>      F = 42
>>
>> Or, more subtly, setting it to any arbitrary functions. That sounds
>> incredibly unsafe.
>
> Python /is/ unsafe - it's a very dynamic language, with little
> compile-time checking.  It is checked at run-time.

And my dynamic language is a lot less dynamic, so is safer, but of
course Python is superior.

> But no, Python does not have variables at all.  It has /names/, that are
> references to objects.  A function is an object, usually (but not
> necessarily) given a name with a "def" statement.  That name can be
> rebound to a different object, just like any other name.
>
>>
>> So Python has immutable tuples, but mutable functions! Every
>> identifier is a variable that you can rebind to something else.
>
> Functions are not mutable in Python.  You misunderstand.

I've used 'mutable' to mean two things: in-place modification of an
object, and being able to re-bind a name to something else. These are
conflated everywhere, but I reckoned people would get the point.

In Python, a function like this:

def F():
pass

is more or less equivalent to:

def __0001():
pass
F = __0001

Effectively any function is just a variable to which has been assigned
some anonymous function (although in practice, the function retains its
'F' identify even if the user's 'F' variable has been assigned a
different value).

The end result is the same: you can never be sure that 'F' still refers
to that static function.

99.99% of the time you never want such functions to change, so why make
it possible? I can understand that in Python, a bytecode compiler might
not know in advance what F is, but that can be mitigated.

When I once experimented with such a language, any such tentative
functions were initialised at runtime, but once initialised, could not
be changed. So whether an identifier was the name of a function, module,
class or variable, was set at runtime, then fixed.

If you want it to be dynamic, then use a 'variable' (the clue is in the
name).

>>
>> With my scripting language, you can do that with exactly 0% of the
>> defined functions. If you want mutable function references, /then/ you
>> use a variable: G := F.
>>
>
> Function pointers are not function objects.

Is there any practical difference?

>> You don't believe amateurs can add value to what mainstream languages
>> can do. The trouble is that you don't appreciate the things that add
>> value, so long as there is some unreadable, unsafe way to hack your
>> way around a task.
>
> Amateurs can make good things.  But the idea that a single amateur can
> revolutionise a particular field is almost, but not quite, a complete
> myth.

I don't want to revolutionise everything. I just hope someone else
would, but the current state of PL design to me looks dire.

However I can take my ideas and use them myself, and sod everyone else;
it's their loss.

You seem convinced that that incredibly hackish and unprofessional way
of accessing the contents of that executable file is just as good as
doing it properly. Well carry on thinking that if you want.

(I don't know what it is about scripting languages, and the way they
eschew a feature as straightforward as a record with fields defined at
compile-time. Either it doesn't exist, or they try and emulate such a
thing badly and inefficiently.)

>> This is exactly why there can still be a place for a language like C,
>> but tidied up and brought up-to-date without all its baggage. People
>> want a language they feel they know inside-out, and can be made to do
>> anyway; they want to feel in charge and confident.
>>
>
> Where are all these people that want something almost, but not quite,
> exactly like C?

There are loads that want to extend C, or import some favourite feature
of C++ into C, or some that want to write Python-like code in C. This is
apart from the ones doing implementing yet another new take on a
functional language.

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:
>>> On 15/11/2022 14:22, David Brown wrote:
>>>> On 15/11/2022 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??
>>>>>
>>>>
>>>> As I said before (a couple of times at least), function calls are
>>>> another matter and should be considered separately.
>>>
>>> Then you wouldn't be able to prevent a programmer coding
>>>
>>>    a = b + nudge_up(&c) + d;
>>
>> Why wouldn't I (as a language designer) be able to prevent that?
>
> 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 - 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.

Some familiar programming patterns may not be usable, but that's always
the case. And for some common patterns, I say good riddance! I can't
see why there would be issues with API's, however - though you always
need some kind of FFI wrapper.

> ...
>
>> 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.

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

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.

> In this very thread you've
> suggested I prohibit certain operator combinations, and that I ban side
> effects in expressions but maybe not necessarily those from parameters
> in function calls. It's not that simple. If a language designer were to
> 'pick and mix' like that the resultant language would be a nightmare to
> learn and use. There has to be a language 'ethos' - i.e. an overall
> approach it takes - and it has to follow consistent principles if it is
> going to be a good design rather than a bad one.
>

I agree with your philosophy here. I disagree that my suggestions don't
fit with that - it's just that the "language ethos", as you call it
(it's as good a term as any other) is different from what you imagined.

> ...
>
>>> 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.

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?

> It's ad-hoc rules which become burdensome.

Agreed.

> By contrast,
> saying any operator can be 'adjacent' to any other as long as the types
> are honoured makes learning a language more logical. It may give the
> programmer freedoms you personally don't like but they make the language
> easier to learn and use.

I don't see a need for operators like ++ and --, either as prefix or
postfix. I don't see a need for assignment, either simple or complex
(like "+=") as returning a value - neither an lvalue, or an rvalue.

There's nothing arbitrary or ad-hoc about not having these in the
language. Lots of languages have nothing like that.

>
> 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.

>>
>>>>
>>>> One possibility is to distinguish between "functions" that have no
>>>> side effects and can therefore be freely mixed, re-arranged,
>>>> duplicated, omitted, etc., and "procedures" that have side-effects
>>>> and must be called exactly as requested in the code.  Such
>>>> "procedures" would not be allowed in expressions - only as
>>>> statements or part of assignment statements.
>>>
>>> Classifying functions by whether they have side effects or not is not
>>> as clear-cut as it may at first appear. Please see the thread I
>>> started today on functional programming.
>>>
>>
>> You'll notice I've replied to it :-)
>
> :-)
>
> ...
>
>>> All that's required, compared with C, is for the apparent evaluation
>>> order to be defined.
>>>
>>>
>>
>> I can appreciate that you want to give a meaning to "++E",
>
> No, I don't! You have this all wrong. The reason for considering the
> inclusion of the operators we have been discussing in this thread is to
> allow a more natural style of expression for algorithms that it suits.
> You seem to keep thinking the goal is to attribute meaning to symbols.
> That's not so.
>
>
>> that you want to give a meaning to "E++", and you expect programmers
>> to use one or the other in different contexts.  I can appreciate that
>> you want to define order of evaluation within expressions.
>
> I don't /want/ to define the order of evaluation; I /do/ define the
> (apparent) order of evaluation. That's part of my language's ethos. If
> I, in addition, permit ++ etc and dereference then their apparent order
> /has/ to be defined, and it now has been.
>
>>
>> But I have yet to see any indication that "++E++" could ever be a
>> sensible expression in any real code.
>
> 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.

Of course, it might also be interesting to go in the other direction
entirely and be very flexible with operators - let users define their
own operators, using Unicode symbols, letters, and mixtures, both for
their own types and existing ones. If someone wants to write code that
involves a lot of squaring, then let them define operators so they can
write "x = squareof y", or "x = y²". They'd be able to write more of a
mess, but also be able to write some things very nicely.

On 15/11/2022 18:05, David Brown wrote:
> On 15/11/2022 16:26, Bart wrote:

>>>  >>> import struct        # Standard module
>>>  >>> bs = open("potato_c.cof").read()
>>>
>>>  >>> machine, nsections, timestamp, symtaboffset, nsymbols,
>>> optheadersize, characteristics = struct.unpack_from("<HHIIIHH")
>>>
>>> That's it.  Three lines.  I would not think of C for this kind of
>>> thing - Python is /much/ better suited.

I don't believe you. The C equivalent of the big struct below will
already exist; would you really waste time on composing a long string of
H and I characters, hoping you don't make a mistake, and then have to
spend time isolating the individual anonymous tuple elements by index?

There are 45 fields here; 61 if you split 'imagedir' into its two
components. A reminder: the code below is /already/ in my scripting
language.

type optionalheader=struct !exe/dll only
wt_word magic
byte majorlv
byte minorlv
wt_dword codesize
wt_dword idatasize
wt_dword zdatasize
wt_dword entrypoint
wt_dword codebase
word64 imagebase
wt_dword sectionalignment
wt_dword filealignment
wt_word majorosv
wt_word minorosv
wt_word majorimagev
wt_word minorimagev
wt_word majorssv
wt_word minorssv
wt_dword win32version
wt_dword imagesize
wt_dword headerssize
wt_dword checksum
wt_word subsystem
wt_word dllcharacteristics
word64 stackreserve
word64 stackcommit
word64 heapreserve
word64 heapcommit
wt_dword loaderflags
wt_dword rvadims
imagedir exporttable
imagedir importtable
imagedir resourcetable
imagedir exceptiontable
imagedir certtable
imagedir basereloctable
imagedir debug
imagedir architecture
imagedir globalptr
imagedir tlstable
imagedir loadconfigtable
imagedir boundimport
imagedir iat
imagedir delayimportdescr
imagedir clrheader
imagedir reserved
end

>> I said it will be clunky and require add-on modules and it is and does.
>
> It is not "clunky" by any sane view - certainly not compared to your
> code (or code written in C).

Most of my code is formatting the output. You access fields using
coffptr.nsections for example.

  And no, it does not require add-on modules
> - the "struct" module is part of Python.
>
>> (BTW you might be missing an argument in that struct.unpack_from call.)
>
> No, I am not.  There is an optional third argument, but it is optional.

What about the second argument? I don't understand how the function call
knows to get the data from 'bs'.

>>
>> Using that approach for the nested structs and unions of my other
>> example is not so straightforward. You basically have to fight for
>> every field.
>
> You have to define every field in every language, or define the ones you
> want along with offsets to skip uninteresting data.

When properly supported, you can define the fields of a struct just as
you would in any static language (see above example), and you can write
handling code just as conveniently.

You don't have to manually write strings of anonymous letter codes and
have to remember their ordering everywhere they are used. That is just
crass.

I went out of my way to add such facilities in my scripting language,
because I felt it was important. So you can code just as you would in a
static language but with the convenience of informal scripting.

Clearly you don't care for such things and prefer a hack.

>>
>> The result is a tuple of unnamed fields. You really want a proper
>> record, which is yet another add-on, with a choice of several modules
>> depending on which set of characterics you need.
>
> You can do that in Python.

Yeah, I know, you can do anything in Python, since there is an army of
people who will create the necessary add-on modules to create ugly and
cumbersome bolted-on solutions.

I can list dozens of things that my scripting language does better than
Python. (Here, such a list exists:
https://github.com/sal55/langs/blob/master/QLang/QBasics.md.)

> In short, you are making up shit in an attempt to make your own language
> look better than other languages, because you'd rather say something
> silly than admit that any other language could be better in any way for
> any task.

Not at all. Python is better for lots of things, mainly because there
are a million libraries that people have written for it, armies of
volunteers who have written suitable, bindings or written all sorts of
shit. And there is huge community and lots of resources to help out.

It is also full of as many advanced, esoteric features that you could
wish for.

But it is short of the more basic and primitive features of the kind I
use and find invaluable.

>> 'struct' is also not a true Python module; it's a front end for an
>> internal one called `_struct`, likely implemented in C, and almost
>> certainly using pointers.
>
> Please re-think what you wrote there.  I hope you can realise how
> ridiculous you are being.

Tell me. Maybe struct.py could be written in pure Python; I don't know.
I'm saying I guarantee mine would have the necessary features to do so.

But this started off being about pointers. Here's another challenge:
this program is for Windows, and displays the first 2 bytes of the
executable image of the interpreter, as loaded in memory:

println peek(0x400000, u16):"m"

fun peek(addr, t=byte) = makeref(addr, t)^

This displays 'MZ' (the signature of PE files on Windows). But of
interest is how Python would implement that peek() function.

On 15/11/2022 21:40, David Brown wrote:

> If someone wants to write code that
> involves a lot of squaring, then let them define operators so they can
> write "x = squareof y", or "x = y²".  They'd be able to write more of a
> mess, but also be able to write some things very nicely.

I have such an operator, called `sqr`. And also briefly allowed the
superscript version (as a postfix op), until Unicode came along and
spoilt it all.

One reason I had sqr was because it was in Pascal (iirc). But it
genuinely comes in useful. Sure, I could also use x**2, but ** used to
be only defined for floats, while `sqr` has been used for much longer.

You could also ask why some languages have a dedicated `sqrt` function
when they could just as easily do x**0.5 or pow(x**0.5).

On 15/11/2022 10:06, Dmitry A. Kazakov wrote:
> On 2022-11-15 10:35, James Harris wrote:
>
>> As I've already said, Unicode and HTML are fine for output. Where
>> programmers work with the semantics of characters, however, they need
>> characters to be in semantic categories, you know: letters, arithmetic
>> symbols, digits, different cases, etc. So far I've not come across
>> anything to support that multilingually. AISI what's needed is a way
>> to expand character encodings to bit fields such as
>>
>>    <category><base character><variant><diacritics><appearance>
>>
>> where
>>
>>    category = group (e.g. alphabetic letters, punctuation, etc)
>>    base character = main semantic identification (e.g. an 'a')
>>    variant (e.g. upper or lower case)
>>    diacritics (those applied to this character in this location)
>>    appearance (e.g. a round 'a' or a printer's 'a' or unspecified)
>>
>> Note that that's purely about semantics; it doesn't include typefaces
>> or character sizes or bold or italic etc which are all for rendering.
>
> I am not sure what are you trying to say.

I am suggesting that a modern language should define a multilingual
model for text /processing/. As part of that, programs need to work with
different aspects of characters. Hence the bitfields, above.

> The Unicode characterization
> is defined in the file:
>
>    https://unicode.org/Public/UNIDATA/UnicodeData.txt

Thanks for the link.

....

> There is no problem with Unicode string literals whatsoever. You just
> place characters as they are. The only escape is "" for ". That is all.

Two problems with that, AISI:

1. some of the characters look like others

2. discussing unrecognised characters with someone else!

--
James Harris