On 16/01/2022 11:01, Bart wrote:
[I wrote:]
>>>      Well, I jotted down A68G code for what seems to be roughly
>>> your "fprint[ln]" example.  It comes to 19 lines, inc six lines to
>>> implement a couple of bells-and-whistles [...].
[Bart:]
>> That's a reasonable attempt at emulating 'fprint/ln'. It's an
>> approach I can't use in my systems language, because it doesn't
>> have automatic tagged unions as used here; arbitrary array
>> constructors; nor that automatic 'rowing' feature to turn one item
>> into a list.

Tagged unions: They aren't exactly an unusual feature of
languages [Wiki gives examples from Algol, Pascal, Ada, ML, Haskell,
Modula, Rust, Nim, ..., tho' sometimes, as in C, a certain amount
of pushing and squeezing is needed]. If your unions aren't tagged,
it's a recipe for unsafe use of types [as in C].

Arbitrary array constructors: ??? You mean the ability to
write down an actual row of things and have the language treat it
as a row of things? How awful.

Rowing: Well, you're on better ground here, as the rowing
coercion is one of the features of Algol that has been touted as
something that perhaps ought not to have been included. But it's
only syntactic sugar, so it's easily worked around if your language
doesn't have it.

> Actually your example demonstrates your argument in reverse: it's
> full of complex language features which I decided are not necessary
> to build in to my systems language. (Not just that: they are hard to
> implement, and inefficient.)

Complex? Did you find my code difficult to follow? I can
easily explain anything if necessary, but I found it easy to write.
Indeed, part of my point was that it was /too/ easy. It was hard
to resist the temptation to add more and more and more bells and
whistles, which any competent programmer could supply and which
[in a library or as part of the language] take longer to describe
and learn than to write "ab initio".

Hard to implement? Possibly. But it's been done. You
[and more importantly, in context, James] don't need to re-invent
wheels, any more than you need to invent new parsing techniques
or new ways of sorting lists. Just copy the code from any of the
many PD compilers out there.

Inefficient? ???

> You are saying a language shouldn't have this type of formatting
> control built-in, because it's so easy to emulate a half-working
> version with different behaviour using other features.

Half-working? What's the other half, and what do you
expect for a few minutes working from your examples rather than
from a formal spec? Yes, I could very easily have added things
like L/R justification, better control of places before/after
decimal points, alternative decimal "point"s [such as ",", for
our continental friends], alternatives to "#", ..., but they
would have cluttered the code for no interesting benefit. If
you have need for these things, go ahead and implement them;
but there's no need to have them defined in the syntax or even
in a required/specified library routine.

> Provided the language has those features, as A68 coincidentally
> happens to have!

Coincidence? Or a decision based on decades of actual
experience? No language was more debated before and during its
initial implementation than Algol; see the pages, over nearly
30 years, of Algol Bulletin. Of course, that was around half a
century ago, and much has happened since to both hardware and
software, so parts of that debate [and some of the results] now
look quite silly or outdated. The depressing thing is not the
mistakes of Algol and other languages of the period, but that
recent languages persist in repeating those mistakes.

> Meanwhile it also demonstrates one or two features that are missing
> from A68, which I do have in my systems language and consider more
> useful: local static variables (that retain their value betweeen
> calls), and optional function parameters with default values.

"Local static variables" were in Algol 60, were problematic
in detailed specification and were therefore dropped in Algol 68 [RR
0.2.6f]. Some of the reasons are expanded in the well-known book on
"Algol 60 Implementation" by Randell and Russell, esp in relation to
"own" arrays. The effects are easy to obtain in other ways. [Most
other prominent languages don't have them either.] For optional
function parameters, see AB37, and note that partial parametrisation
meets many of the needs and is in A68G.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Mayer

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2022-01-18 20:19, antispam@math.uni.wroc.pl wrote:
> > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> >> On 2022-01-02 18:50, Bart wrote:
> >>> On 02/01/2022 17:21, Dmitry A. Kazakov wrote:
> >>>> On 2022-01-02 18:08, Bart wrote:
> >>>>> On 02/01/2022 16:37, Dmitry A. Kazakov wrote:
> >>>>>> On 2022-01-02 17:06, James Harris wrote:
> >>>>>>
> >>>>>>> If you convert to strings then what reclaims the memory used by
> >>>>>>> those strings?
> >>>>>>
> >>>>>> What reclaims memory used by those integers?
> >>>>>
> >>>>> Integers are passed by value at this level of language.
> >>>>
> >>>> This has nothing to do with the question: what reclaims integers?
> >>>> FORTRAN-IV passed everything by reference, yet calls
> >>>>
> >>>> ??? FOO (I + 1)
> >>>>
> >>>> were OK almost human life span ago.
> >>>
> >>> Fortran didn't allow recursion either.
> >>
> >> Irrelevant. What reclaims integer I+1?
> >
> > Relevant. Early Fortrans statically allocated storage to I + 1.
> > Storage was "reclaimed" by OS at program termination, but
> > reserved for the whole run. Such static allocation is
> > impossible without static bound on maximal size of object
> > and it does not work in case of recursion.
>
> And still irrelevant, whatever reclaims integers can reclaim strings and
> conversely. Furthermore all that has nothing to do with the parameter
> passing mode or where and how call frames get allocated.

Low level issues are very relevant for disscussion here. You can
postulate that language should have ability to return strings, fine.
There is well-know method to implement that: heap allocation +
garbage collection (for purpose of this disscussion reference
counting is just specific way to implement garbage collection).
However you claimed that returning of strings can be implemented
without heap allocation, which is exactly question how language
manages memory and is closely related to how call frames get
allocated. Now, if religious fanatics banned heap allocation,
than you are right that one can do return using stacks. But
it goes well beyond what integer or to that matter fixed size
objects need. Namely only called routine knows how big string
will be so needs to allocate storage for it (on stack if you
insist). Then you need to copy it to caller storage. If
caller allocate it on its own stack, copy can be done only
after called routine returned: only at that poit one can
enlarge callers stack space. So you need to copy string from
called routine to secondary stack before return and than
copy it back to callers stack. It is tempting to optimize
and create string directly on secondary stack or just keep
it all the time on secondary stack but that may easily led
to bugs. So you either have rather inefficient implementation
which performs a lot of copies (and needs sufficient space
on secondary stack for all objects "in transit") or some
(probably complicated) code in compiler that tries to
recognize optimizable cases (which probably does not help
much in general case). Compared to that heap allocation
is simpler to implement and likely more efficient.

To put it differently, retuning integer on modern machine
requires very little code in compiler and during runtime,
one just puts value in designated return register. The
whole call-return machinery and stack frame allocation
can be done in say 200 lines of compiler code. The
machinations needed to handle variable sized object are
order or tow orders of magnitude more complicated. So
saying that "whatever reclaims integers can reclaim strings"
is at best misleading.

P.S. I used to like very much idea of allocating variable
size objects on stack(s). But after looking at various
tradeofs I am no longer convinced that it makes sense.

--
Waldek Hebisch

Andy Walker <anw@cuboid.co.uk> wrote:
> On 07/01/2022 18:14, Bart wrote:
> [I wrote:]
> >> [...] I don't know why you and James are so opposed to the use
> >> of heap storage [and temporary files, if you really want strings
> >> that are many gigabytes]?
> > Because heap storage requires a more advanced language to manage
> > properly, ie. automatically. (I don't care for speculative GC
> > methods.)
>
> Oh. Well, a language either provides heap storage or it
> does not. Even C does, even if in an unsafe and rather primitive
> way. The techniques involved aren't exactly cutting-edge recent.

Well, there are shades of gray here. To explain, there is concern
about small machines. Small means different things for various
people, some think 256M is small. But I mean really small,
think about 4k storage in total (program + data). Microcontrollers
of that size are widely used. One can program them using C++,
however any attempt to use runtime featurs will pull most of
standard library which may be more than 100k code (that is real
date from my target). So, to support such small machines
you want to be able to create programs which need only minimal
runtime support. I must say that C 'printf' is one of first
things to ban: it is well-known that even most space-efficient
versions of 'printf' are much larger than specialized code
for single type. Also, buffering needed on larger systems can
be simplifed when exact hardware/software configuration is
known.

So I do not understand why James wants fancy Print on small
systems. But desire to run without heap storage is IMHO
quite resonable.

--
Waldek Hebisch

On 2022-01-19 02:25, antispam@math.uni.wroc.pl wrote:

> To put it differently, retuning integer on modern machine
> requires very little code in compiler and during runtime,
> one just puts value in designated return register. The
> whole call-return machinery and stack frame allocation
> can be done in say 200 lines of compiler code. The
> machinations needed to handle variable sized object are
> order or tow orders of magnitude more complicated.

Or reverse, advanced algorithms of register optimizations are incredibly
complicated while dealing with arrays is very straightforward. You make
assumptions about certain implementations which confirm nothing but
these assumptions.

> So
> saying that "whatever reclaims integers can reclaim strings"
> is at best misleading.

No, it is exactly the point. Integers and strings and all other objects
managed by the language are created and reclaimed by the language memory
management system. Which in turn can operate in a LIFO policy even if
the object sizes are indeterminable.

That came as a little surprise to some, which led to silly claims
regarding need of heap/GC or parameter passing by reference etc.

> P.S. I used to like very much idea of allocating variable
> size objects on stack(s). But after looking at various
> tradeofs I am no longer convinced that it makes sense.

Your loss. Using the heap is a crime on a multi-core architecture.

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

On 19/01/2022 07:42, Dmitry A. Kazakov wrote:
> On 2022-01-19 02:25, antispam@math.uni.wroc.pl wrote:
>
>> To put it differently, retuning integer on modern machine
>> requires very little code in compiler and during runtime,
>> one just puts value in designated return register.  The
>> whole call-return machinery and stack frame allocation
>> can be done in say 200 lines of compiler code.  The
>> machinations needed to handle variable sized object are
>> order or tow orders of magnitude more complicated.
>
> Or reverse, advanced algorithms of register optimizations are incredibly
> complicated while dealing with arrays is very straightforward. You make
> assumptions about certain implementations which confirm nothing but
> these assumptions.

No need; the ABI will specify how primitive types are passed, such as
integers, and in which registers.

Strings are not considered a primitive type; their handling is largely
up to the language.

So that itself tells you they cannot be dealt with the same way.

>> So
>> saying that "whatever reclaims integers can reclaim strings"
>> is at best misleading.
>
> No, it is exactly the point. Integers and strings and all other objects
> managed by the language are created and reclaimed by the language memory
> management system. Which in turn can operate in a LIFO policy even if
> the object sizes are indeterminable.

At the point where a Print routine has finished with a string associated
with an item in print-list, how will the language know how to recover
any resource used by that string, or if it needs to do so? Remember that
at different times through the same code:

* The string might be a literal (so it can be left)
* It can be constructed just for this purpose (so must be recovered)
* It could belong to a global entity (so can be left)
* It could be shared (so a reference count may need adjusting)

This is NEVER going to be as simple as just passing a number of 32 or 64
bits. I don't know why you keep saying it is other than to be contrary.

> Your loss. Using the heap is a crime on a multi-core architecture.

Huh? Pretty much everything is multi-core now other than on small devices.

How else are you going to use all those GB of memory other than using a
heap? Do you really want to insist on LIFO allocation everywhere? That
would be a highly restricted language, and makes ordinary data
structures either impossible, or highly inefficient.

You may as well insist that file storage on a disk is allocated in a
LIFO manner too; that would get rid of all that pesky fragmentation!
People who invent file systems seem to have missed a trick.

On 19/01/2022 01:02, Andy Walker wrote:
> On 16/01/2022 11:01, Bart wrote:
> [I wrote:]
>>>>      Well, I jotted down A68G code for what seems to be roughly
>>>> your "fprint[ln]" example.  It comes to 19 lines, inc six lines to
>>>> implement a couple of bells-and-whistles [...].
> [Bart:]
>>> That's a reasonable attempt at emulating 'fprint/ln'. It's an
>>> approach I can't use in my systems language, because it doesn't
>>> have automatic tagged unions as used here; arbitrary array
>>> constructors; nor that automatic 'rowing' feature to turn one item
>>> into a list.
>
>     Tagged unions:  They aren't exactly an unusual feature of
> languages [Wiki gives examples from Algol, Pascal, Ada, ML, Haskell,
> Modula, Rust,  Nim, ..., tho' sometimes, as in C, a certain amount
> of pushing and squeezing is needed].  If your unions aren't tagged,
> it's a recipe for unsafe use of types [as in C].

There are different kinds of tagged unions, sum types and complex
enumerations. And various ways of implementing them, and lots of
possible ways of assigning things to them.

For example, your use of Algol68 unions doesn't name the individual
'fields'; it uses a form of pattern matching and assignment to an
arbitrary named entity to get access to a particular type and value.

So there isn't really one clear way to this stuff.

The sort of tagged unions /I/ would want, would need a tag value that is
a global enum. Different cases could also have the same type.

>     Arbitrary array constructors:  ???  You mean the ability to
> write down an actual row of things and have the language treat it
> as a row of things?  How awful.

My language has fixed-size arrays. But even there, I haven't implemented
all possibilities:

proc D([3]int x)={}

static [3]int A = (10,20,30) # OK
[3]int B := (10,20,30) # OK
[3]int C

C := (10,20,30) # OK
D((10,20,30)) # Not supported in codegen pass

The last is slightly tricky as space for the data needs to arranged.

With variable-length arrays, I can use slices for that purpose, although
they were intended for views into existing arrays.

So a slice can pass that information to a function, but I haven't
developed a constructor type for a slice for an array of values:

proc D(slice[]int S)={}

[3]int A
[300]int B

D(A) # OK
D(B) # OK
D[50..60] # OK
D((10,20,30)) # Not implemented
D((P, N)) # Will create an slice descriptor

These are the language choices /I/ made. Doubtless you would have made
very different ones.

Remember that with my other car, sorry, language, anything goes:

proc D(S) = {}

D((10, 20.0, "30", 40..50, (60,70,80)))

so the lack of expressiveness in the lower level language is not of
concern; only enough needs to work to implement the higher level one.

>     Rowing:  Well, you're on better ground here, as the rowing
> coercion is one of the features of Algol that has been touted as
> something that perhaps ought not to have been included.  But it's
> only syntactic sugar, so it's easily worked around if your language
> doesn't have it.

It's a type issue; such a feature reduces type safety. It stops a
language detecting the use of scalar rather than a list, which could be
an error on the user's part.

>> Actually your example demonstrates your argument in reverse: it's
>> full of complex language features which I decided are not necessary
>> to build in to my systems language. (Not just that: they are hard to
>> implement, and inefficient.)
>
>     Complex?  Did you find my code difficult to follow?

That nested union I found hard to understand: so 'r' and 'w' are reals
and strings, but 'k' is yet another union of int and long int. And it
knows how to print such a type. Which means it knows how to print any
element of a[] anyway; the case statement is just to control the default
display.

It's also a use of CASE in A68 that I hadn't seen for a long type:
tagging each possibility to make it each clear what each branch is
operating one.

Maybe that ought to be possible here too:

FOR i FROM 1 TO 4 DO
print((
CASE i
IN
"one",
"two",
"three"
OUT
"other"
ESAC, newline))
OD

While my example is clear, elsewhere it would be useful to have have 1:,
2: etc in front of each branch.

> You
> [and more importantly, in context, James] don't need to re-invent
> wheels, any more than you need to invent new parsing techniques
> or new ways of sorting lists.  Just copy the code from any of the
> many PD compilers out there.
>
>     Inefficient?  ???

Yeah. Earlier discussion touched on the inefficiency of turning
something into an explicit string before printing (say, an entire array,
instead of one element at time).

Here, you're turning a set of N print-items into an array, so that it
can traverse them, deal with them, then discard the array.

>> You are saying a language shouldn't have this type of formatting
>> control built-in, because it's so easy to emulate a half-working
>> version with different behaviour using other features.
>
>     Half-working?

Well, how big a UNION would be needed for all possible printable types?
My static language limits them, but could easily decide to print arrays
and user-defined records if it wants. The diversity is handled within
the compiler.

It's also missing per-item formating codes. A solution using only
user-code, even in Algol68, is unwieldy and ugly.

Look at what C++ ended up with using a solution based on
language-building features:

std::cout << A << " " << B << std::endl;

> our continental friends], alternatives to "#", ..., but they

(One point about "#": when I wrote my CASE example, I commented out your
FPRINT code, using #...# comments. Of course the embedded #s interfered
with that, creating mysterious errors later on.

It could really do with line comments, as block comments for commenting
out code are troublesome.)

>     "Local static variables" were in Algol 60, were problematic
> in detailed specification and were therefore dropped in Algol 68 [RR
> 0.2.6f].  Some of the reasons are expanded in the well-known book on
> "Algol 60 Implementation" by Randell and Russell, esp in relation to
> "own" arrays.  The effects are easy to obtain in other ways.  [Most
> other prominent languages don't have them either.]

It's not clear what is problematic about them, other than making
functions impure.

I just went ahead and implemented them! Sure you can get round the
omission by other means, such as using globals, but that is
unsatisfactory (clashing names with statics belong to other functions
and less safe, as they can be modified by any code).

On 2022-01-19 11:48, Bart wrote:
> On 19/01/2022 07:42, Dmitry A. Kazakov wrote:
>> On 2022-01-19 02:25, antispam@math.uni.wroc.pl wrote:

>> No, it is exactly the point. Integers and strings and all other
>> objects managed by the language are created and reclaimed by the
>> language memory management system. Which in turn can operate in a LIFO
>> policy even if the object sizes are indeterminable.
>
> At the point where a Print routine has finished with a string associated
> with an item in print-list, how will the language know how to recover
> any resource used by that string, or if it needs to do so? Remember that
> at different times through the same code:
>
> * The string might be a literal (so it can be left)
> * It can be constructed just for this purpose (so must be recovered)
> * It could belong to a global entity (so can be left)
> * It could be shared (so a reference count may need adjusting)

Which exactly applies to integer. Moreover things are far more
complicated to integers. An integer can be

- packed and misaligned in a container
- in a register
- optimized away value
- atomic access value
- mapped to an I/O port non-relocatable value

>> Your loss. Using the heap is a crime on a multi-core architecture.
>
> Huh? Pretty much everything is multi-core now other than on small devices.

See, could not even claim the green grapes.

> How else are you going to use all those GB of memory other than using a
> heap?

For doing something useful, maybe?

> You may as well insist that file storage on a disk is allocated in a
> LIFO manner too; that would get rid of all that pesky fragmentation!

Well, if you looked how journaling file systems function or how flash
does you might experience another revelation...

> People who invent file systems seem to have missed a trick.

Sure. None uses heap to transfer memory blocks, I hope. Oh, don't tell
me you just wrote one. You'll get me a PTSD...

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

On 19/01/2022 12:24, Dmitry A. Kazakov wrote:
> On 2022-01-19 11:48, Bart wrote:
>> On 19/01/2022 07:42, Dmitry A. Kazakov wrote:
>>> On 2022-01-19 02:25, antispam@math.uni.wroc.pl wrote:
>
>>> No, it is exactly the point. Integers and strings and all other
>>> objects managed by the language are created and reclaimed by the
>>> language memory management system. Which in turn can operate in a
>>> LIFO policy even if the object sizes are indeterminable.
>>
>> At the point where a Print routine has finished with a string
>> associated with an item in print-list, how will the language know how
>> to recover any resource used by that string, or if it needs to do so?
>> Remember that at different times through the same code:
>>
>> * The string might be a literal (so it can be left)
>> * It can be constructed just for this purpose (so must be recovered)
>> * It could belong to a global entity (so can be left)
>> * It could be shared (so a reference count may need adjusting)
>
> Which exactly applies to integer. Moreover things are far more
> complicated to integers. An integer can be
>
> - packed and misaligned in a container
> - in a register
> - optimized away value
> - atomic access value
> - mapped to an I/O port non-relocatable value

This is an integer being passed to a function. The Win64 ABI specifies
that a /copy/ of its value is passed in register RCX if it is the first
argument.

What does it say about the values of strings?

>>> Your loss. Using the heap is a crime on a multi-core architecture.
>>
>> Huh? Pretty much everything is multi-core now other than on small
>> devices.
>
> See, could not even claim the green grapes.

Huh?

>> How else are you going to use all those GB of memory other than using
>> a heap?
>
> For doing something useful, maybe?

Next you're going to tell me that all those languages that need garbage
collection are doing it all wrong.

>
>> You may as well insist that file storage on a disk is allocated in a
>> LIFO manner too; that would get rid of all that pesky fragmentation!
>
> Well, if you looked how journaling file systems function or how flash
> does you might experience another revelation...

I'm talking about normal, random-access, read-write devices. And surely
any other with special technological requirements, will allow you to
delete any arbitrary file, without the storage used being lost forever.

(Exceptions include WORM devices, but they don't have stack-like
capabilities either.)

>> People who invent file systems seem to have missed a trick.
>
> Sure. None uses heap to transfer memory blocks, I hope. Oh, don't tell
> me you just wrote one. You'll get me a PTSD...
>

Huh? again. Are you on something?

On 2022-01-19 14:34, Bart wrote:
> On 19/01/2022 12:24, Dmitry A. Kazakov wrote:
>> On 2022-01-19 11:48, Bart wrote:
>>> On 19/01/2022 07:42, Dmitry A. Kazakov wrote:
>>>> On 2022-01-19 02:25, antispam@math.uni.wroc.pl wrote:
>>
>>>> No, it is exactly the point. Integers and strings and all other
>>>> objects managed by the language are created and reclaimed by the
>>>> language memory management system. Which in turn can operate in a
>>>> LIFO policy even if the object sizes are indeterminable.
>>>
>>> At the point where a Print routine has finished with a string
>>> associated with an item in print-list, how will the language know how
>>> to recover any resource used by that string, or if it needs to do so?
>>> Remember that at different times through the same code:
>>>
>>> * The string might be a literal (so it can be left)
>>> * It can be constructed just for this purpose (so must be recovered)
>>> * It could belong to a global entity (so can be left)
>>> * It could be shared (so a reference count may need adjusting)
>>
>> Which exactly applies to integer. Moreover things are far more
>> complicated to integers. An integer can be
>>
>> - packed and misaligned in a container
>> - in a register
>> - optimized away value
>> - atomic access value
>> - mapped to an I/O port non-relocatable value
>
> This is an integer being passed to a function. The Win64 ABI specifies
> that a /copy/ of its value is passed in register RCX if it is the first
> argument.

If your language does not support out and in/out parameters it is your
problem and this has nothing to do with ABI, at all. The following is
legal Ada:

function Foo (X : String) return String;
pragma Convention (Stdcall, Foo);

Takes string returns string and has Win32 calling convention. The
compiler will give you a friendly warning that it would be tricky to use
it from C, but otherwise there is no problem.

> What does it say about the values of strings?

Win32 says pretty much same: LPSTR, LPLONG.

>>>> Your loss. Using the heap is a crime on a multi-core architecture.
>>>
>>> Huh? Pretty much everything is multi-core now other than on small
>>> devices.
>>
>> See, could not even claim the green grapes.
>
> Huh?

Usually when cornered you claim that you don't even need a feature X.

>>> How else are you going to use all those GB of memory other than using
>>> a heap?
>>
>> For doing something useful, maybe?
>
> Next you're going to tell me that all those languages that need garbage
> collection are doing it all wrong.

Certainly. The performance gain is wasted on garbage software written by
incompetent programmers. The Moore's Law allowed to produce not steaming
piles of but mountains of volcanic guano piercing the stratosphere...

>>> You may as well insist that file storage on a disk is allocated in a
>>> LIFO manner too; that would get rid of all that pesky fragmentation!
>>
>> Well, if you looked how journaling file systems function or how flash
>> does you might experience another revelation...
>
> I'm talking about normal, random-access, read-write devices.

What every Linux machine runs...

>>> People who invent file systems seem to have missed a trick.
>>
>> Sure. None uses heap to transfer memory blocks, I hope. Oh, don't tell
>> me you just wrote one. You'll get me a PTSD...
>
> Huh? again. Are you on something?

Yes, nobody would willingly have used MS-DOS unless under threats of
bodily harm, yet... Now, if you wrote a file system, how do I know that
it is not on a device I might own? A frightening thought... (:-))

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

On 19/01/2022 13:59, Dmitry A. Kazakov wrote:
> On 2022-01-19 14:34, Bart wrote:
>> On 19/01/2022 12:24, Dmitry A. Kazakov wrote:

>>> - packed and misaligned in a container
>>> - in a register
>>> - optimized away value
>>> - atomic access value
>>> - mapped to an I/O port non-relocatable value
>>
>> This is an integer being passed to a function. The Win64 ABI specifies
>> that a /copy/ of its value is passed in register RCX if it is the
>> first argument.
>
> If your language does not support out and in/out parameters it is your
> problem and this has nothing to do with ABI, at all. The following is
> legal Ada:
>
>    function Foo (X : String) return String;
>    pragma Convention (Stdcall, Foo);
>
> Takes string returns string and has Win32 calling convention. The
> compiler will give you a friendly warning that it would be tricky to use
> it from C, but otherwise there is no problem.
>
>> What does it say about the values of strings?
>
> Win32 says pretty much same: LPSTR, LPLONG.

Those types are 64-bit pointers on Win64.

LPSTR points to a sequence of bytes, terminated with zero to represent a
crude C-style string.

That says nothing about the management of those bytes, which is the bit
that you are saying is so utterly trivial that it's not worth discussing.

An LPSTR value is /not/ the value of the string which what I asked
about; it's the value of the pointer.

On 2022-01-19 15:38, Bart wrote:
> On 19/01/2022 13:59, Dmitry A. Kazakov wrote:
>> On 2022-01-19 14:34, Bart wrote:
>>> What does it say about the values of strings?
>>
>> Win32 says pretty much same: LPSTR, LPLONG.
>
> Those types are 64-bit pointers on Win64.

For example this:

procedure Foo (X : in out LONG);
pragma Convention (Stdcall, Foo);

will deploy LPLONG for X. The value will be passed by reference (LPLONG)
as Win32 Stdcall prescribes. See any pointers? Right, there is none.

> LPSTR points to a sequence of bytes, terminated with zero to represent a
> crude C-style string.

Yes, and the following works perfectly well:

declare
procedure Foo (X : char_array);
pragma Convention (Stdcall, Foo);
X : char_array := "abc";
begin
Foo (X & "d" & NUL);

Foo will get null-terminated "abcd". If implemented in C, it would use
LPSTR. Again, no pointers in sight. And, no, heap will not be used.

You are thoroughly confused regarding calling conventions and memory
management. These things are only vaguely related. It is indeed possible
to invent conventions that would make no reasonable management possible,
but it is rarely the goal of the people designing them...

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

On 19/01/2022 15:20, Dmitry A. Kazakov wrote:
> On 2022-01-19 15:38, Bart wrote:
>> On 19/01/2022 13:59, Dmitry A. Kazakov wrote:
>>> On 2022-01-19 14:34, Bart wrote:
>>>> What does it say about the values of strings?
>>>
>>> Win32 says pretty much same: LPSTR, LPLONG.
>>
>> Those types are 64-bit pointers on Win64.
>
> For example this:
>
>    procedure Foo (X : in out LONG);
>    pragma Convention (Stdcall, Foo);
>
> will deploy LPLONG for X. The value will be passed by reference (LPLONG)
> as Win32 Stdcall prescribes. See any pointers? Right, there is none.

Actually, yes. A reference is a pointer, just an implicit one. The 'P'
in LPLONG stands for 'Pointer'; what did you think it was?

>> LPSTR points to a sequence of bytes, terminated with zero to represent
>> a crude C-style string.
>
> Yes, and the following works perfectly well:
>
>    declare
>       procedure Foo (X : char_array);
>       pragma Convention (Stdcall, Foo);
>       X : char_array := "abc";
>    begin
>       Foo (X & "d" & NUL);
>
> Foo will get null-terminated "abcd". If implemented in C, it would use
> LPSTR. Again, no pointers in sight. And, no, heap will not be used.

Not even for Foo(X*1000000)?

Sure, if you say so:

* No pointers are involved

* No heap storage is necessary, no matter what language

* No memory resources are involved

* Passing an arbitrary string expression is just like passing an integer
expression

If that's what you really believe, than that's OK; it doesn't look like
anyone will be able to persuade you otherwise.

Meanwhile some of us have to actually implement this stuff for real.

On 2022-01-19 17:00, Bart wrote:
> On 19/01/2022 15:20, Dmitry A. Kazakov wrote:
>> On 2022-01-19 15:38, Bart wrote:
>>> On 19/01/2022 13:59, Dmitry A. Kazakov wrote:
>>>> On 2022-01-19 14:34, Bart wrote:
>>>>> What does it say about the values of strings?
>>>>
>>>> Win32 says pretty much same: LPSTR, LPLONG.
>>>
>>> Those types are 64-bit pointers on Win64.
>>
>> For example this:
>>
>>     procedure Foo (X : in out LONG);
>>     pragma Convention (Stdcall, Foo);
>>
>> will deploy LPLONG for X. The value will be passed by reference
>> (LPLONG) as Win32 Stdcall prescribes. See any pointers? Right, there
>> is none.
>
> Actually,  yes. A reference is a pointer, just an implicit one. The 'P'
> in LPLONG stands for 'Pointer'; what did you think it was?

LONG, see the declaration of Foo.

>>> LPSTR points to a sequence of bytes, terminated with zero to
>>> represent a crude C-style string.
>>
>> Yes, and the following works perfectly well:
>>
>>     declare
>>        procedure Foo (X : char_array);
>>        pragma Convention (Stdcall, Foo);
>>        X : char_array := "abc";
>>     begin
>>        Foo (X & "d" & NUL);
>>
>> Foo will get null-terminated "abcd". If implemented in C, it would use
>> LPSTR. Again, no pointers in sight. And, no, heap will not be used.
>
> Not even for Foo(X*1000000)?

Yes, for that invoking a contract termination clause would be the best
choice.

However this:
------------------------------ test.adb -------
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.C.Strings; use Interfaces.C, Interfaces.C.Strings;

with Ada.Unchecked_Conversion, System;

procedure Test is
procedure Foo (X : char_array);
pragma Convention (Stdcall, Foo);

procedure Foo (X : char_array) is
function "+" is
new Ada.Unchecked_Conversion (System.Address, chars_ptr);
begin
Put_Line ("Length:" & size_t'Image (strlen (+X'Address)));
end Foo;

function "*" (X : char_array; Y : size_t) return char_array is
begin
return Result : char_array (0..X'Length * Y) do
for I in 1..Y loop
Result ((I - 1) * X'Length..I * X'Length - 1) := X;
end loop;
Result (Result'Last) := NUL;
end return;
end "*";

X : char_array := "abc";
begin
Foo (X * 1000000);
end Test;
----------------------------------------
compiles and works just fine:
----------------------------------------
> gcc -c test.adb
test.adb:7:19: warning: type of argument "Foo.X" is unconstrained array
[-gnatwx]
test.adb:7:19: warning: foreign caller must pass bounds explicitly [-gnatwx]
gnatbind -x test.ali
gnatlink test.ali

> D:\Temp\y\test>test
Length: 3000000
----------------------------------------
Questions?

> Sure, if you say so:
>
> * No pointers are involved

Right. None. In Ada pointer is a distinct type in the declaration of
which contains the keyword "access". Saw any?

> * No heap storage is necessary, no matter what language

Right. Since avoiding heap for dealing with indefinite object is a
computable problem there is no necessity.

> * No memory resources are involved

Wrong. Memory is always required for expression evaluation.

> * Passing an arbitrary string expression is just like passing an integer
> expression

Neither happens. We are not talking about closures.

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

On 19/01/2022 17:17, Dmitry A. Kazakov wrote:
> On 2022-01-19 17:00, Bart wrote:
>> On 19/01/2022 15:20, Dmitry A. Kazakov wrote:
>>> On 2022-01-19 15:38, Bart wrote:
>>>> On 19/01/2022 13:59, Dmitry A. Kazakov wrote:
>>>>> On 2022-01-19 14:34, Bart wrote:
>>>>>> What does it say about the values of strings?
>>>>>
>>>>> Win32 says pretty much same: LPSTR, LPLONG.
>>>>
>>>> Those types are 64-bit pointers on Win64.
>>>
>>> For example this:
>>>
>>>     procedure Foo (X : in out LONG);
>>>     pragma Convention (Stdcall, Foo);
>>>
>>> will deploy LPLONG for X. The value will be passed by reference
>>> (LPLONG) as Win32 Stdcall prescribes. See any pointers? Right, there
>>> is none.
>>
>> Actually,  yes. A reference is a pointer, just an implicit one. The
>> 'P' in LPLONG stands for 'Pointer'; what did you think it was?
>
> LONG, see the declaration of Foo.

The 'P' in 'LPLONG' stands for 'LONG'? Okay.....
>
>>>> LPSTR points to a sequence of bytes, terminated with zero to
>>>> represent a crude C-style string.
>>>
>>> Yes, and the following works perfectly well:
>>>
>>>     declare
>>>        procedure Foo (X : char_array);
>>>        pragma Convention (Stdcall, Foo);
>>>        X : char_array := "abc";
>>>     begin
>>>        Foo (X & "d" & NUL);
>>>
>>> Foo will get null-terminated "abcd". If implemented in C, it would
>>> use LPSTR. Again, no pointers in sight. And, no, heap will not be used.
>>
>> Not even for Foo(X*1000000)?
>
> Yes, for that invoking a contract termination clause would be the best
> choice.
>
> However this:
> ------------------------------ test.adb -------
> with Ada.Text_IO;           use Ada.Text_IO;
> with Interfaces.C.Strings;  use Interfaces.C, Interfaces.C.Strings;
>
> with Ada.Unchecked_Conversion, System;
>
> procedure Test is
>    procedure Foo (X : char_array);
>    pragma Convention (Stdcall, Foo);
>
>    procedure Foo (X : char_array) is
>    function "+" is
>       new Ada.Unchecked_Conversion (System.Address, chars_ptr);
>    begin
>       Put_Line ("Length:" & size_t'Image (strlen (+X'Address)));
>    end Foo;
>
>    function "*" (X : char_array; Y : size_t) return char_array is
>    begin
>       return Result : char_array (0..X'Length * Y) do
>          for I in 1..Y loop
>             Result ((I - 1) * X'Length..I * X'Length - 1) := X;
>          end loop;
>          Result (Result'Last) := NUL;
>       end return;
>    end "*";
>
>    X : char_array := "abc";
> begin
>    Foo (X * 1000000);
> end Test;
> ----------------------------------------
> compiles and works just fine:
> ----------------------------------------
> > gcc -c test.adb
> test.adb:7:19: warning: type of argument "Foo.X" is unconstrained array
> [-gnatwx]
> test.adb:7:19: warning: foreign caller must pass bounds explicitly
> [-gnatwx]
> gnatbind -x test.ali
> gnatlink test.ali
>
> > D:\Temp\y\test>test
> Length: 3000000
> ----------------------------------------
> Questions?

I asked if no heap was used. How can you tell what your Ada code is
doing and how?

I also asked, if memory need to be recovered, which bit of code did
that, and where.

>> Sure, if you say so:
>>
>> * No pointers are involved
>
> Right. None. In Ada pointer is a distinct type in the declaration of
> which contains the keyword "access". Saw any?

So because no explicit pointer denotations are in the source code, that
means that none are used in the implementation?

Gotcha.

>> * No heap storage is necessary, no matter what language
>
> Right. Since avoiding heap for dealing with indefinite object is a
> computable problem there is no necessity.

You really, really don't like heaps don't you? Let me pose a little
challenge: you're writing, in Ada, an interpreter for a language which
creates and destroys ad hoc objects (like, any scripting language).

You can't control how people write programs in that language. How do you
implement the memory managemnt in such a language, without using heaps
in Ada? For example a program has a tree structure where arbitrary nodes
may grow, others may be deleted.

To be clear, I'm not asking how you approach such a task in Ada; the
task has already been coded in another language, and your job is to
implement that language, without using anything that looks like a heap,
or use language features that might implicitly use a heap (but Ada
doesn't, according to you).

>> * No memory resources are involved
>
> Wrong. Memory is always required for expression evaluation.
>
>> * Passing an arbitrary string expression is just like passing an
>> integer expression
>
> Neither happens. We are not talking about closures.
>

OK, since you are being pedantic now, I mean passing the result of
evaluating those respective expressions.

The result of an integer expression will be an integer. The result of an
string expression may be one of half a dozen cateogories of strings
(literal, owned, shared, slice etc), and exactly what is passed depends
on a dozen different ways that strings may be implemented.

Look, just forget it. I can see you're just being mischievous.

On 2022-01-19 23:09, Bart wrote:
> On 19/01/2022 17:17, Dmitry A. Kazakov wrote:
>> On 2022-01-19 17:00, Bart wrote:
>>> On 19/01/2022 15:20, Dmitry A. Kazakov wrote:
>>>> On 2022-01-19 15:38, Bart wrote:
>>>>> On 19/01/2022 13:59, Dmitry A. Kazakov wrote:
>>>>>> On 2022-01-19 14:34, Bart wrote:
>>>>>>> What does it say about the values of strings?
>>>>>>
>>>>>> Win32 says pretty much same: LPSTR, LPLONG.
>>>>>
>>>>> Those types are 64-bit pointers on Win64.
>>>>
>>>> For example this:
>>>>
>>>>     procedure Foo (X : in out LONG);
>>>>     pragma Convention (Stdcall, Foo);
>>>>
>>>> will deploy LPLONG for X. The value will be passed by reference
>>>> (LPLONG) as Win32 Stdcall prescribes. See any pointers? Right, there
>>>> is none.
>>>
>>> Actually,  yes. A reference is a pointer, just an implicit one. The
>>> 'P' in LPLONG stands for 'Pointer'; what did you think it was?
>>
>> LONG, see the declaration of Foo.
>
> The 'P' in 'LPLONG' stands for 'LONG'? Okay.....

?

>>>>> LPSTR points to a sequence of bytes, terminated with zero to
>>>>> represent a crude C-style string.
>>>>
>>>> Yes, and the following works perfectly well:
>>>>
>>>>     declare
>>>>        procedure Foo (X : char_array);
>>>>        pragma Convention (Stdcall, Foo);
>>>>        X : char_array := "abc";
>>>>     begin
>>>>        Foo (X & "d" & NUL);
>>>>
>>>> Foo will get null-terminated "abcd". If implemented in C, it would
>>>> use LPSTR. Again, no pointers in sight. And, no, heap will not be used.
>>>
>>> Not even for Foo(X*1000000)?
>>
>> Yes, for that invoking a contract termination clause would be the best
>> choice.
>>
>> However this:
>> ------------------------------ test.adb -------
>> with Ada.Text_IO;           use Ada.Text_IO;
>> with Interfaces.C.Strings;  use Interfaces.C, Interfaces.C.Strings;
>>
>> with Ada.Unchecked_Conversion, System;
>>
>> procedure Test is
>>     procedure Foo (X : char_array);
>>     pragma Convention (Stdcall, Foo);
>>
>>     procedure Foo (X : char_array) is
>>     function "+" is
>>        new Ada.Unchecked_Conversion (System.Address, chars_ptr);
>>     begin
>>        Put_Line ("Length:" & size_t'Image (strlen (+X'Address)));
>>     end Foo;
>>
>>     function "*" (X : char_array; Y : size_t) return char_array is
>>     begin
>>        return Result : char_array (0..X'Length * Y) do
>>           for I in 1..Y loop
>>              Result ((I - 1) * X'Length..I * X'Length - 1) := X;
>>           end loop;
>>           Result (Result'Last) := NUL;
>>        end return;
>>     end "*";
>>
>>     X : char_array := "abc";
>> begin
>>     Foo (X * 1000000);
>> end Test;
>> ----------------------------------------
>> compiles and works just fine:
>> ----------------------------------------
>>  > gcc -c test.adb
>> test.adb:7:19: warning: type of argument "Foo.X" is unconstrained
>> array [-gnatwx]
>> test.adb:7:19: warning: foreign caller must pass bounds explicitly
>> [-gnatwx]
>> gnatbind -x test.ali
>> gnatlink test.ali
>>
>>  > D:\Temp\y\test>test
>> Length: 3000000
>> ----------------------------------------
>> Questions?
>
> I asked if no heap was used. How can you tell what your Ada code is
> doing and how?

By executing it as I did above.

> I also asked, if memory need to be recovered, which bit of code did
> that, and where.

Use gcc -S and/or gdb.

>>> Sure, if you say so:
>>>
>>> * No pointers are involved
>>
>> Right. None. In Ada pointer is a distinct type in the declaration of
>> which contains the keyword "access". Saw any?
>
> So because no explicit pointer denotations are in the source code, that
> means that none are used in the implementation?

Exactly so. No pointers means no pointers,

>>> * No heap storage is necessary, no matter what language
>>
>> Right. Since avoiding heap for dealing with indefinite object is a
>> computable problem there is no necessity.
>
> You really, really don't like heaps don't you?

This has nothing to with love. It is a statement of fact. You asked
whether heap is necessary for a problem X. The answer is no. It is a
formal question:

Whether the ordering of allocation/deallocation used in X is "random",
actually indeterminable? No it is not, it is well defined in fact.

>>> * Passing an arbitrary string expression is just like passing an
>>> integer expression
>>
>> Neither happens. We are not talking about closures.
>
> OK, since you are being pedantic now, I mean passing the result of
> evaluating those respective expressions.

Define "same". First, you must understand that this is a language
question. If under "same" you mean by-reference vs. by-value then I must
disappoint you. They can be very same. GNAT Ada compiler supports
passing small arrays by-value.

Formally the language Ada mandates this:

- scalar objects must be passed by value
- tagged and limited objects must be passed by reference
- other objects (and arrays fall in this category) are passed at will

Of course all this goes out of the window when Windows calling
convention is requested, sorry for pun. Or another example, if FORTRAN
calling convention is requested, then, of course, integer will be passed
by reference not by value.

> The result of an integer expression will be an integer. The result of an
> string expression may be one of half a dozen cateogories of strings
> (literal, owned, shared, slice etc), and exactly what is passed depends
> on a dozen different ways that strings may be implemented.

Rubbish. The result of string expression is string. Values are not
passed, objects representing values do. It is quite no matter what sort
of value an object holds when passing the object.

Do you really intend to code separately passing each possible type and
aspect of objects? Oh my, now I finally understand your dismay at seeing
the type system of a modern programming language...

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

On 20/01/2022 08:31, Dmitry A. Kazakov wrote:
> On 2022-01-19 23:09, Bart wrote:

>>>> Actually,  yes. A reference is a pointer, just an implicit one. The
>>>> 'P' in LPLONG stands for 'Pointer'; what did you think it was?
>>>
>>> LONG, see the declaration of Foo.
>>
>> The 'P' in 'LPLONG' stands for 'LONG'? Okay.....
>
> ?

FFS, it's very simple: 'LP' in MS types stands for 'Long Pointer', so
the 'P' stands for 'Pointer', you know, the thing you said doesn't exist.

>> So because no explicit pointer denotations are in the source code,
>> that means that none are used in the implementation?
>
> Exactly so. No pointers means no pointers,

Not even in the underlying implementation? (That's that bit /I/ have to
code.)

> This has nothing to with love. It is a statement of fact. You asked
> whether heap is necessary for a problem X. The answer is no. It is a
> formal question:
>
> Whether the ordering of allocation/deallocation used in X is "random",
> actually indeterminable? No it is not, it is well defined in fact.

Not even when X calls random() to decide which parts of a data structure
to allocate/deallocate?

Remember, I am not writing X, I have to implement the language in which
X is written.

> Formally the language Ada mandates this:
>
> - scalar objects must be passed by value
> - tagged and limited objects must be passed by reference
> - other objects (and arrays fall in this category) are passed at will

So, assuming a string is not classed as a scalar, a non-small string is
passed differently from an integer, possibly 'at will'.

Thank you for finally admitting that integers and strings might need
different passing mechanisms.

> Of course all this goes out of the window when Windows calling
> convention is requested, sorry for pun.

So what does SYS V ABI do that is so different?

> Or another example, if FORTRAN
> calling convention is requested, then, of course, integer will be passed
> by reference not by value.

'By-reference' is an extra level of indirection that can be specified
within the code; it can be applied to both integers normally passed by
value, and objects normally passed by reference anyway.

The language specifies which objects can be modified by a callee without
a formal 'by-reference', if any.

>> The result of an integer expression will be an integer. The result of
>> an string expression may be one of half a dozen cateogories of strings
>> (literal, owned, shared, slice etc), and exactly what is passed
>> depends on a dozen different ways that strings may be implemented.
>
> Rubbish. The result of string expression is string.

Yes, which can be one of several categories, not several types, for
example, the string data is owned by the object, or it can be a view
into a separate substring.

And that string can be implemented in a dozen different ways depending
on language.

Do you disagree with that, or is Ada the only possible language under
discussion?

You said, long ago, that dealing with strings is no harder than dealing
with fixed-width integers.

Take this example:

string S:="onetwothree"

case random(1..10)
when 1 then S := "ABC"
when 2 then S := T
when 3 then S := T.[10..20]
when 4 then S := S.[4..6]
when 5 then S := F()*10
esac

T:=""

Now S has something else assigned to it, or goes out of scope, and the
string data MIGHT need to be recovered. But how does it know whether S
owns the string it refers to or not?

This depends on how the language defines strings to work. Maybe all
those assignments and slicing created a fresh copy of the string or
slice, but then T might be a billion characters. Or maybe these are
immutable, shared strings.

> Values are not
> passed, objects representing values do. It is quite no matter what sort
> of value an object holds when passing the object.

I don't understand what you are saying. Of course it is very easy to
utterly dismiss low-level implementation details, and talk about only in
HLL terms (presumably Ada terms).

So you can claim that an implementation does not involve registers or
addresses or pointers or stack or heap or even memory, because those
terms do not appear in the source code.

Which all seems to be a desperate attempt to win an argument.

On 2022-01-20 11:42, Bart wrote:
> On 20/01/2022 08:31, Dmitry A. Kazakov wrote:
>> On 2022-01-19 23:09, Bart wrote:
>
>>>>> Actually,  yes. A reference is a pointer, just an implicit one. The
>>>>> 'P' in LPLONG stands for 'Pointer'; what did you think it was?
>>>>
>>>> LONG, see the declaration of Foo.
>>>
>>> The 'P' in 'LPLONG' stands for 'LONG'? Okay.....
>>
>> ?
>
> FFS, it's very simple: 'LP' in MS types stands for 'Long Pointer', so
> the 'P' stands for 'Pointer', you know, the thing you said doesn't exist.

And I bring the code you conveniently removed:

procedure Foo (X : in out LONG);
pragma Convention (Stdcall, Foo);

*where* is 'LP'?

>>> So because no explicit pointer denotations are in the source code,
>>> that means that none are used in the implementation?
>>
>> Exactly so. No pointers means no pointers,
>
> Not even in the underlying implementation? (That's that bit /I/ have to
> code.)

No idea. What is the underlying implementation? Gates, capacitors,
silicon wafers?

>> This has nothing to with love. It is a statement of fact. You asked
>> whether heap is necessary for a problem X. The answer is no. It is a
>> formal question:
>>
>> Whether the ordering of allocation/deallocation used in X is "random",
>> actually indeterminable? No it is not, it is well defined in fact.
>
> Not even when X calls random() to decide which parts of a data structure
> to allocate/deallocate?

Not even then. The ordering remains same.

> Remember, I am not writing X, I have to implement the language in which
> X is written.
>
>> Formally the language Ada mandates this:
>>
>> - scalar objects must be passed by value
>> - tagged and limited objects must be passed by reference
>> - other objects (and arrays fall in this category) are passed at will
>
> So, assuming a string is not classed as a scalar, a non-small string is
> passed differently from an integer, possibly 'at will'.
>
> Thank you for finally admitting that integers and strings might need
> different passing mechanisms.

Two integers might. So what?

>> Of course all this goes out of the window when Windows calling
>> convention is requested, sorry for pun.
>
> So what does SYS V ABI do that is so different?

I don't remember SysV calling conventions. Why do you care? What is
different? Why would it shatter the earth under you feet?

>> Or another example, if FORTRAN calling convention is requested, then,
>> of course, integer will be passed by reference not by value.
>
> 'By-reference' is an extra level of indirection that can be specified
> within the code; it can be applied to both integers normally passed by
> value, and objects normally passed by reference anyway.

Thank you Captain. So what?

> The language specifies which objects can be modified by a callee without
> a formal 'by-reference', if any.

Ada does without both formal (it has none) and informal (it does not
need any). And?

>>> The result of an integer expression will be an integer. The result of
>>> an string expression may be one of half a dozen cateogories of
>>> strings (literal, owned, shared, slice etc), and exactly what is
>>> passed depends on a dozen different ways that strings may be
>>> implemented.
>>
>> Rubbish. The result of string expression is string.
>
> Yes, which can be one of several categories, not several types, for
> example, the string data is owned by the object, or it can be a view
> into a separate substring.

Nonsense. Ada and other sane languages are specific that the
representation is a property of the type, meaning: same type, same
representation.

> And that string can be implemented in a dozen different ways depending
> on language.

And integer can be implemented in two dozens of ways, maybe in three...

> You said, long ago, that dealing with strings is no harder than dealing
> with fixed-width integers.
>
> Take this example:
>
>     string S:="onetwothree"
>
>     case random(1..10)
>     when 1 then S := "ABC"
>     when 2 then S := T
>     when 3 then S := T.[10..20]
>     when 4 then S := S.[4..6]
>     when 5 then S := F()*10
>     esac

This is illegal in Ada and irrelevant anyway. Try to stay focused on
parameter passing methods and managing temporary objects. Both are well
known issues. I have no idea why are you trying to debunk algorithms
existing, implemented and deployed for multiple decades. It is just
beyond silly.

>> Values are not passed, objects representing values do. It is quite no
>> matter what sort of value an object holds when passing the object.
>
> I don't understand what you are saying.

That for a memory manager it makes absolutely no difference what value
the object has. Just like a heap would not care, so memory manager does not.

> Of course it is very easy to
> utterly dismiss low-level implementation details, and talk about only in
> HLL terms (presumably Ada terms).

As I said, gcc -S is your friend.

The discussion was about the language features and your amazement that
it can have strings and, what a horror, not to use heap when dealing
with string expressions. I don't even understand what are you trying to
say. That compiler vendors lie? That they are in a secret cabal with
programmers who actually do not use their compilers in production code?

> So you can claim that an implementation does not involve registers or
> addresses or pointers or stack or heap or even memory, because those
> terms do not appear in the source code.

Exactly. Unless we are talking about language to language translators. I
remember that there were several Ada to C, Ada to Java translators. But
GNAT for x86 is not one of them. And, again, what is the point? You can
rewrite a program that does not use pointer into a program that uses
them? Yes you can. So what?

> Which all seems to be a desperate attempt to win an argument.

There is no argument, merely statements of facts.

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

On 20/01/2022 12:34, Dmitry A. Kazakov wrote:
> On 2022-01-20 11:42, Bart wrote:

> *where* is 'LP'?

Here, where you said:

"will deploy LPLONG for X. The value will be passed by reference
(LPLONG) as Win32 Stdcall prescribes. See any pointers? Right, there is
none."

And I asked, So what is the P in LPLONG?

>> Not even in the underlying implementation? (That's that bit /I/ have
>> to code.)
>
> No idea. What is the underlying implementation? Gates, capacitors,
> silicon wafers?

I implement languages, which usually means going from HLL source code
down to the native code executed by a processor. That doesn't mean going
down to microprogramming or bitslicing or logic gates or transistors or
right down to the movement of electrons.

Stop being silly.

>>> This has nothing to with love. It is a statement of fact. You asked
>>> whether heap is necessary for a problem X. The answer is no. It is a
>>> formal question:
>>>
>>> Whether the ordering of allocation/deallocation used in X is
>>> "random", actually indeterminable? No it is not, it is well defined
>>> in fact.
>>
>> Not even when X calls random() to decide which parts of a data
>> structure to allocate/deallocate?
>
> Not even then. The ordering remains same.

That very glib, but I notice you don't explain how it's done.

It's like you have a pile of books to be put in order on a shelf. But at
some point, you need to remove a book from the middle of those already
on the shelf.

Now, you want to place the next book, but if it's no wider than the one
just removed, can you reuse that empty slot?

If so, then you have a heap. If not, then you have a very inefficient
system of storing books, and will need more bookcases than necessary.

Or are you arguing that the task of putting books on the shelf, and
removing arbitrary books, can ALWAYs be done in a left to right order,
with never any gaps?

Or do you have to use a technique which pushes all the books to the
right of the gap, to the left to close the gap? (Which will screw up any
external references to the exact location of any book on a shelf, as
well as being hopelessly inefficient.)

>> Thank you for finally admitting that integers and strings might need
>> different passing mechanisms.
>
> Two integers might.

No, why should they if they are the same size? As I said half a dozen
posts ago, a u64 value as the first argumemt on Win64 ABI goes in RCX,
always.

>>> Of course all this goes out of the window when Windows calling
>>> convention is requested, sorry for pun.
>>
>> So what does SYS V ABI do that is so different?
>
> I don't remember SysV calling conventions.

Funny that you can remember Win64 ones!

> Why do you care? What is
> different? Why would it shatter the earth under you feet?

You had a sly dig at Windows calling conventions. I asked you to clarify
what is so bad about it compared with others, but now you don't care!

>> And that string can be implemented in a dozen different ways depending
>> on language.
>
> And integer can be implemented in two dozens of ways, maybe in three...

Really, there is greater diversity in implementing a fixed width small
integer than a string?

>> You said, long ago, that dealing with strings is no harder than
>> dealing with fixed-width integers.
>>
>> Take this example:
>>
>>      string S:="onetwothree"
>>
>>      case random(1..10)
>>      when 1 then S := "ABC"
>>      when 2 then S := T
>>      when 3 then S := T.[10..20]
>>      when 4 then S := S.[4..6]
>>      when 5 then S := F()*10
>>      esac
>
> This is illegal in Ada

OK, so the only language that counts is Ada? I'm glad that point has
been settled.

Actually plenty of languages have mutable variables and allow
conditional assignments of strings like the above.

> and irrelevant anyway. Try to stay focused on
> parameter passing methods and managing temporary objects.

'S' was a temporary object; I asked how, at the end of its scope, it
knew what to do with the string data if refers to.

Transient objects created as intermediate results in expressions are
part of it too, but I thought you would simply deny their existence, as
they don't form any part of the source, so they can't possibly be an
issue anyone has to bother their head about, not even the implementers
of the language!

> The discussion was about the language features and your amazement that
> it can have strings

I've given plenty of examples where string data is not created or
destroyed in a LIFO manner, thus requiring ad hoc allocations and
allocations (so, a heap).

You have chosen to ignore the examples, or dismiss languages where that
is routinely done.

Since you also dismissing the entire concept of GC, which has also been
around for decades, then this conversation is rather pointless.

All I can surmise is that pet language doesn't have a heap allocator

and, what a horror, not to use heap when dealing
> with string expressions. I don't even understand what are you trying to
> say. That compiler vendors lie? That they are in a secret cabal with
> programmers who actually do not use their compilers in production code?
>
>> So you can claim that an implementation does not involve registers or
>> addresses or pointers or stack or heap or even memory, because those
>> terms do not appear in the source code.
>
> Exactly.

I thought so. We're just going around in circles because you are
choosing to ignore any actual realities.

On 2022-01-20 14:21, Bart wrote:
> On 20/01/2022 12:34, Dmitry A. Kazakov wrote:
>> On 2022-01-20 11:42, Bart wrote:
>
>> *where* is 'LP'?
>
> Here, where you said:
>
> "will deploy LPLONG for X. The value will be passed by reference
> (LPLONG) as Win32 Stdcall prescribes. See any pointers? Right, there is
> none."

Right. Ada passes LONG by reference. No pointers.

A C equivalent would be a pointer LONG* since C does not support
by-reference parameter passing.

A FORTRAN-IV equivalent would be INTEGER*4.

> And I asked, So what is the P in LPLONG?

In what language?

>>> Not even in the underlying implementation? (That's that bit /I/ have
>>> to code.)
>>
>> No idea. What is the underlying implementation? Gates, capacitors,
>> silicon wafers?
>
> I implement languages, which usually means going from HLL source code
> down to the native code executed by a processor. That doesn't mean going
> down to microprogramming or bitslicing or logic gates or transistors or
> right down to the movement of electrons.
>
> Stop being silly.

Stop talking about your language. Your language, your problems.

I have no idea what intermediate code GCC uses and I do not care.
Machine language has no pointers, it has instruction modes.

>>>> This has nothing to with love. It is a statement of fact. You asked
>>>> whether heap is necessary for a problem X. The answer is no. It is a
>>>> formal question:
>>>>
>>>> Whether the ordering of allocation/deallocation used in X is
>>>> "random", actually indeterminable? No it is not, it is well defined
>>>> in fact.
>>>
>>> Not even when X calls random() to decide which parts of a data
>>> structure to allocate/deallocate?
>>
>> Not even then. The ordering remains same.
>
> That very glib, but I notice you don't explain how it's done.

Done what? Ordering? Ordering is done by counting. You count arguments
using your fingers. The first argument is the index finger. The second
is the middle finger and so on...

> It's like you have a pile of books to be put in order on a shelf. But at
> some point, you need to remove a book from the middle of those already
> on the shelf.

No, it is not that case. Read previous posts regarding using stacks.

>>> Thank you for finally admitting that integers and strings might need
>>> different passing mechanisms.
>>
>> Two integers might.
>
> No, why should they if they are the same size?

No they don't. Integer_32 and Integer_16 have different sizes.

>>>> Of course all this goes out of the window when Windows calling
>>>> convention is requested, sorry for pun.
>>>
>>> So what does SYS V ABI do that is so different?
>>
>> I don't remember SysV calling conventions.
>
> Funny that you can remember Win64 ones!

It is my job. I am writing a lot of code communicating with Windows and
Linux libraries.

>> Why do you care? What is different? Why would it shatter the earth
>> under you feet?
>
> You had a sly dig at Windows calling conventions. I asked you to clarify
> what is so bad about it compared with others, but now you don't care!

I never said that Windows conventions are especially bad. I said that
conventions have very little to do with what language does with
temporary objects. You are confusing them. Ada can use a lot of
different conventions and yet have string expressions with all of them.
Is that clear?

>>> And that string can be implemented in a dozen different ways
>>> depending on language.
>>
>> And integer can be implemented in two dozens of ways, maybe in three...
>
> Really, there is greater diversity in implementing a fixed width small
> integer than a string?

Sure. There exist hundreds of different integer encodings purposed for
different goals.

>>> You said, long ago, that dealing with strings is no harder than
>>> dealing with fixed-width integers.
>>>
>>> Take this example:
>>>
>>>      string S:="onetwothree"
>>>
>>>      case random(1..10)
>>>      when 1 then S := "ABC"
>>>      when 2 then S := T
>>>      when 3 then S := T.[10..20]
>>>      when 4 then S := S.[4..6]
>>>      when 5 then S := F()*10
>>>      esac
>>
>> This is illegal in Ada
>
> OK, so the only language that counts is Ada? I'm glad that point has
> been settled.

No, the point is that the example is irrelevant since you wondered how
it happens that Ada does not need heap for string expressions. The above
is not Ada and cannot be made Ada with Ada strings. Furthermore it is
not expression and not a call.

> Actually plenty of languages have mutable variables and allow
> conditional assignments of strings like the above.

Actually it is no problem to have conditional *expressions* and
amazingly it does not requires heap either. The following is legal Ada
program:
-----------------------------------------
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Numerics.Discrete_Random;

procedure Test is
type Choice is (Red, Black, Blue);
package Random_Choices is new Ada.Numerics.Discrete_Random (Choice);
use Random_Choices;

procedure Foo (X : String) is
begin
Put_Line (X);
end Foo;

Seed : Generator;
X : constant String := "abcdefgh";
begin
Reset (Seed);
Foo
( (case Random (Seed) is
when Red => "red",
when Black => X (2..6),
when Blue => "Hello " & X & "!")
);
end Test;
-----------------------------------------

>> and irrelevant anyway. Try to stay focused on parameter passing
>> methods and managing temporary objects.
>
> 'S' was a temporary object;

No, S is a variable.

Temporary object is one created and destroyed by the language for the
purpose of evaluation of an expression. The compiler choice to create
any temporary objects shall not change the semantics of the expression.

>> The discussion was about the language features and your amazement that
>> it can have strings
>
> I've given plenty of examples where string data is not created or
> destroyed in a LIFO manner, thus requiring ad hoc allocations and
> allocations (so, a heap).

No you claimed that

- it is impossible to return string from a subprogram without using heap
- it is impossible to pass a string to a subprogram without using heap
- it is impossible to have a string expression as an argument of a
subprogram without using heap
- it is impossible to use strings with Win32 API interfaces

All that is plain wrong, demonstrated by working examples.

> You have chosen to ignore the examples, or dismiss languages where that
> is routinely done.

Right, because they all are irrelevant to the claims you made.

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

On 19/01/2022 01:42, antispam@math.uni.wroc.pl wrote:
[I wrote:]
>> Oh. Well, a language either provides heap storage or it
>> does not. Even C does, even if in an unsafe and rather primitive
>> way. The techniques involved aren't exactly cutting-edge recent.
> Well, there are shades of gray here. To explain, there is concern
> about small machines. Small means different things for various
> people, some think 256M is small. But I mean really small,
> think about 4k storage in total (program + data). [...]
> So I do not understand why James wants fancy Print on small
> systems. But desire to run without heap storage is IMHO
> quite resonable.

Yes, but that's a matter, for a given language/implementation,
of knowing which features use the heap. Presumably, a cross-compiler
targetting a tiny machine knows to avoid space-intensive features, or
at least to issue warnings and suggest work-arounds. Certainly in the
days when I was programming small machines, I knew what constructs to
avoid. Today, I no longer care. But then, my current PC [more than a
decade old] has more RAM than all previous machines that I used [inc
several university mainframes] put together; and my car [now 8yo] has
storage and compute power that an earlier generation could only have
boggled at. Of course, that brings about problems of bloat -- my
current mailer and browser are each a factor of more than 1000x as
large as their predecessors in the '90s, for no proportionate added
value [as far as I am concerned].

Yes, if heap techniques are too big and perhaps too slow for
James's purposes, then of course his new language and compiler should
avoid them. But I don't see that as being closely related to the
preferred style of I/O. Eg, A68R managed to implement very general
I/O facilities [formatted and unformatted] without using the heap.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Valentine

On 20/01/2022 14:35, Dmitry A. Kazakov wrote:

>>> Two integers might.
>>
>> No, why should they if they are the same size?
>
> No they don't. Integer_32 and Integer_16 have different sizes.

That's not an interesting distinction. For passing to functions, they
are likely to be either widened to 64 bits, or occupy the lower part of
a 64-bit value.

> Sure. There exist hundreds of different integer encodings purposed for
> different goals.

At the low level, there are very few encodings (mainly to to with
endianness, so on a specific target, there might be just one).

Strings however don't really exist at that level, so they could be
myriad ways of representing them.

> -----------------------------------------
> with Ada.Text_IO;  use Ada.Text_IO;
> with Ada.Numerics.Discrete_Random;
>
> procedure Test is
>    type Choice is (Red, Black, Blue);
>    package Random_Choices is new Ada.Numerics.Discrete_Random (Choice);
>    use Random_Choices;
>
>    procedure Foo (X : String) is
>    begin
>       Put_Line (X);
>    end Foo;
>
>    Seed : Generator;
>    X    : constant String := "abcdefgh";
> begin
>    Reset (Seed);
>    Foo
>    (  (case Random (Seed) is
>          when Red   => "red",
>          when Black => X (2..6),
>          when Blue  => "Hello " & X & "!")
>    );
> end Test;

(So why was my example illegal in Ada?)

This is not quite as challenging as my example, where T is a global, of
a length not known at compile-time, F()*10 also has a runtime length,
and S is set to refer to a substring within itself.

But also, I don't know the semantics for Ada strings. What happens in a
situation like this (I don't know Ada syntax so I will use a made-up one):

function Bar => String is
String X;
if random()<0.5 then
X := <compute some string at runtime>;
else
X := "ABC";
end if
return X;
end Bar

In your code:

Foo(Bar());

Bar returns the string stored in X, but X is a local that is destroyed
when it exits, so how does that string persist?

And I will ask again, how does it know when the string is done with, and
how does it know whether it is necessary to destroy the string and
recover its memory?

Suppose also that Foo() is changed to copy the string to a global.

Does Ada handle strings by value, which means it copies strings rather
than share them? This would make many things easier (what I used to do),
but is also less efficient.

>>> The discussion was about the language features and your amazement
>>> that it can have strings

First class strings are a heavy duty feature. You don't appreciate that
fact because your language does it all for your.

You claim it does it without using heap memory, so either you're not
telling me what restrictions that imposes, or you've carefully avoided
tricky cases in your examples.

>> I've given plenty of examples where string data is not created or
>> destroyed in a LIFO manner, thus requiring ad hoc allocations and
>> allocations (so, a heap).
>
> No you claimed that
>
> - it is impossible to return string from a subprogram without using heap
> - it is impossible to pass a string to a subprogram without using heap
> - it is impossible to have a string expression as an argument of a
> subprogram without using heap

These are all more difficult to do, and impose more language
restrictions, without using heap-like allocation.

I would find it almost impossible to implement interpreters for example
as I would not be able to model the chaotic allocation patterns of the
programs they run.

(Not actually impossible, as you would just implement a heap-like
allocator on top of a linear one.)

> - it is impossible to use strings with Win32 API interfaces

Win64 ABI doesn't concern itself with strings, as they depend on how the
language decides implement them.

> All that is plain wrong, demonstrated by working examples.
>
>> You have chosen to ignore the examples, or dismiss languages where
>> that is routinely done.
>
> Right, because they all are irrelevant to the claims you made.

I notice you didn't respond to my bookshelf analogy. Everyone knows how
bookshelves work; few know the ins and outs of Ada. Therefore much
easier to hide any limitations.

On 2022-01-20 21:13, Bart wrote:
> On 20/01/2022 14:35, Dmitry A. Kazakov wrote:
>
>> Sure. There exist hundreds of different integer encodings purposed for
>> different goals.
>
> At the low level, there are very few encodings (mainly to to with
> endianness, so on a specific target, there might be just one).

No, they exist all since the language may use any of. But you do not
understand the difference between the programing and the machine languages.

> Strings however don't really exist at that level, so they could be
> myriad ways of representing them.

Irrelevant but wrong. There exist machines with string operation
instructions, DEC VAX.

>> -----------------------------------------
>> with Ada.Text_IO;  use Ada.Text_IO;
>> with Ada.Numerics.Discrete_Random;
>>
>> procedure Test is
>>     type Choice is (Red, Black, Blue);
>>     package Random_Choices is new Ada.Numerics.Discrete_Random (Choice);
>>     use Random_Choices;
>>
>>     procedure Foo (X : String) is
>>     begin
>>        Put_Line (X);
>>     end Foo;
>>
>>     Seed : Generator;
>>     X    : constant String := "abcdefgh";
>> begin
>>     Reset (Seed);
>>     Foo
>>     (  (case Random (Seed) is
>>           when Red   => "red",
>>           when Black => X (2..6),
>>           when Blue  => "Hello " & X & "!")
>>     );
>> end Test;
>
> (So why was my example illegal in Ada?)

Because it used a variable instead of an expression. I fixed that.

> But also, I don't know the semantics for Ada strings. What happens in a
> situation like this (I don't know Ada syntax so I will use a made-up one):
>
>     function Bar => String is
>         String X;
>         if random()<0.5 then
>           X := <compute some string at runtime>;
>         else
>           X := "ABC";
>         end if
>         return X;
>     end Bar

This is illegal for the same reason. A correct code would be

function Bar return String is
begin
if Random < 0.5 then
return "(" & Bar & ")"; -- Recursively calls itself
else
return ""; -- End of recursion
end if
end Bar;

Bar returns a pseudo-random sequence of nested balanced parenthesis. No
heap used.

> Bar returns the string stored in X, but X is a local that is destroyed
> when it exits, so how does that string persist?

What persists? A variable does not survive if there were one. The value
does in a platonic universe, it existed before the first computer was
invented with continue to exist after all of them.

The effect of a string-valued function is, as the name suggests,
evaluation of a string value which becomes the value of some object at
the caller's discretion.

> And I will ask again, how does it know when the string is done with, and
> how does it know whether it is necessary to destroy the string and
> recover its memory?

All objects are destroyed at the end of their scopes.

> Suppose also that Foo() is changed to copy the string to a global.

It could not, unless the length were same if assigning of strings is
what you meant.

> Does Ada handle strings by value, which means it copies strings rather
> than share them?

Strings are exactly like integers with the only difference that the
compiler is free to choose between by-reference and by-value passing.

Assigning a string implies copying its body or parts of, but not the
bounds as they are the object constraint.

>>>> The discussion was about the language features and your amazement
>>>> that it can have strings
>
> You claim it does it without using heap memory, so either you're not
> telling me what restrictions that imposes, or you've carefully avoided
> tricky cases in your examples.

You cannot change any of the object constraints.

- Fixed strings have bounds as the constraint.
- Bounded strings have the maximum length as the constraint.
- Unbounded strings have no constraint, and thus, must use the heap.

Fixed and bounded strings do not use the heap.

>> No you claimed that
>>
>> - it is impossible to return string from a subprogram without using heap
>> - it is impossible to pass a string to a subprogram without using heap
>> - it is impossible to have a string expression as an argument of a
>> subprogram without using heap
>
> These are all more difficult to do, and impose more language
> restrictions, without using heap-like allocation.

Nothing of above is a restriction. The opposite is, like your language
restricting to no string or to an obligatory heap. In Ada you have a
free choice that suits best the problem at hand.

> I would find it almost impossible to implement interpreters for example
> as I would not be able to model the chaotic allocation patterns of the
> programs they run.

That is because you do not understand how a more or less advanced type
system works and why there is no chaos at all.

>> All that is plain wrong, demonstrated by working examples.
>>
>>> You have chosen to ignore the examples, or dismiss languages where
>>> that is routinely done.
>>
>> Right, because they all are irrelevant to the claims you made.
>
> I notice you didn't respond to my bookshelf analogy.

Because it is a wrong analogy. The right one is the poles in the Tower
of Hanoi game with the difference that instead of moving rings one moves
the poles. Though one could move the rings instead, in some rather
inefficient implementation.

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

On 19/01/2022 11:40, Bart wrote:
> The sort of tagged unions /I/ would want, would need a tag value that
> is a global enum.

That makes it [unnecessarily] hard to compile independent
modules. But perhaps I've misunderstood your notion of "global"?

> Different cases could also have the same type.

As they can in Algol [RR3.4.2cC, see the comment]. But of
course the consequence is that the choice of which case is chosen
is then undefined.

[...]
>>      Rowing:  Well, you're on better ground here, as the rowing
>> coercion is one of the features of Algol that has been touted as
>> something that perhaps ought not to have been included.  But it's
>> only syntactic sugar, so it's easily worked around if your language
>> doesn't have it.
> It's a type issue; such a feature reduces type safety. It stops a
> language detecting the use of scalar rather than a list, which could
> be an error on the user's part.

It could, though it's an unlikely error, and the construct
saves a lot of extra work for the user. [Eg, "print (x)" would be
an error without rowing, as the parameter to "print" is an array of
a union of printable types and layout routines, so you would have
to write something like

([1] UNION (OUTTYPE, PROC (REF FILE) VOID) y; y[1] := x; print (y))

except that "OUTTYPE" is a secret type known only to the compiler.]
IRL, I expect some different syntactic sugar would be provided for
such a common case.

>>      Inefficient?  ???
> Yeah. Earlier discussion touched on the inefficiency of turning
> something into an explicit string before printing (say, an entire
> array, instead of one element at time).

The point wasn't that you /had/ to turn things into explicit
strings but that /if/ all you had was single-character output, then
it was possible to do so. But in fact A68 [RR10.3.3.1a] defines
unformatted output in exactly that way, calling "putchar" [RR10.3.3.1b]
to perform the actual transput. Note that "putchar" is a complicated
piece of code, as it is one of the primary interfaces to the OS.
As ever, compilers are free to do things in a more efficient way if
appropriate [and I expect A68G in particular to do so, as it can assume
a Linux-ish OS].

> Here, you're turning a set of N print-items into an array, so that it
> can traverse them, deal with them, then discard the array.

And the time spent doing this, compared with (a) the sum of
the times taken to deal with the N items one at a time, and (b) the
time, in a real application, taken to construct the N items in the
first place is? 0.1% of the total running time of the program? It's
a load of fuss about nothing.

>>      Half-working?
> Well, how big a UNION would be needed for all possible printable
> types? My static language limits them, but could easily decide to
> print arrays and user-defined records if it wants. The diversity is
> handled within the compiler.

Algol already handles that diversity, including arrays and
structure types. The question was whether it is worthwhile to
add the whole panoply of formats [15% of the RR, a similar fraction
of Algol's syntax, probably a similar fraction of the required parts
of the system library] to add a relatively small utility. It's too
late to "rescue" Algol or C from this; but James is developing a
new language.

> It's also missing per-item formating codes. A solution using only
> user-code, even in Algol68, is unwieldy and ugly.

Yes. So is formatted transput in general. The degree of
ugliness is comparable, however it's done. Simple things are easy,
as demonstrated; complicated things are complicated; and formats
require users to learn syntax and semantics that add seriously to
the difficulty of learning and using the language.

>>      "Local static variables" were in Algol 60, were problematic
>> in detailed specification and were therefore dropped in Algol 68 [RR
>> 0.2.6f].  Some of the reasons are expanded in the well-known book on
>> "Algol 60 Implementation" by Randell and Russell, esp in relation to
>> "own" arrays.  The effects are easy to obtain in other ways.  [Most
>> other prominent languages don't have them either.]
> It's not clear what is problematic about them, other than making
> functions impure.

They're hard to implement if they are dynamic arrays, they
need special initialisation, and they're difficult to specify in
a rigorous way. The added utility is very little. Library routines
can use the "letter aleph" dodge [cf C's "__"] to prevent abuse;
user code can circumvent their limitations anyway, so it becomes a
matter of coding standards.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Valentine

On 20/01/2022 23:17, Andy Walker wrote:
> On 19/01/2022 11:40, Bart wrote:
>> The sort of tagged unions /I/ would want, would need a tag value that
>> is a global enum.
>
>     That makes it [unnecessarily] hard to compile independent
> modules.  But perhaps I've misunderstood your notion of "global"?

Typically it might be used like this:

record unitrec_etc =
byte tag # or opcode, opndtype etc
...
end

'tag' is an instance of some global enumeration: token type, AST mode
type, IL or target language opcode.

Or, as the tagged data type of an interpreter, it could represent a
typecode of /the language being intepreted/, not of the language being
used to write the interpreter; so the latter's types are not relevant at
all.

It is anyway something that is used across the program. It is used here
to control how parts of the record might be interpreted, and may be used
in other records too. This is up to user-code to implement.

>> Here, you're turning a set of N print-items into an array, so that it
>> can traverse them, deal with them, then discard the array.

>     And the time spent doing this, compared with (a) the sum of
> the times taken to deal with the N items one at a time, and (b) the
> time, in a real application, taken to construct the N items in the
> first place is?  0.1% of the total running time of the program?  It's
> a load of fuss about nothing.

You don't know that. If the output is to a string or into a file buffer,
then the process of stringifying can be fast if isn't dominated by the
display response time. Then this 'rowing' can be significant.

However I've done a test, and the results are interesting. This is with
dynamic code with 1 million iterations of this, directed to a file:

println a, b, c, d # took 1.8 seconds
println (a, b, c, d) # took 0.9 seconds

So it's faster! But this might be to do with the per-item processing
being done inside the interpreter, not in interpreted bytecode.

If the loop was instead this:

F(a, b, c, d) # F contains println a,b,c,d

it was 1.8 seconds again, but the following that corresponds more with
your approach:

F((a, b, c, d)) # F iterates over a list and prints
# one at a time + discrete space

was 2.8 seconds.

> late to "rescue" Algol or C from this;  but James is developing a
> new language.

Actually I've just started a new one, which may or may go anywhere.

It doesn't touch any of the things recently discussed, as I don't see
anything wrong with them!

Mainly it's an attempt to combine my two languages because it's annoying
that a feature you need on one only works in the other. They can work
together, but...

>     Yes.  So is formatted transput in general.  The degree of
> ugliness is comparable, however it's done.  Simple things are easy,
> as demonstrated;  complicated things are complicated;  and formats
> require users to learn syntax and semantics that add seriously to
> the difficulty of learning and using the language.

Python replaced the 'print' statement with the 'print' function between
Py2 and Py3.

Control over spacing and newlines is done with optional keyword
parameters, which I can never remember.

You always have to know and remember something! With mine, once you know
that it has print and println, that part at least is taken care of.

And if you can't remember how to suppress the automatic space between A
and B here:

print A, B

you will probably remember that the space is only between items of the
same print, or for each comma, so that you have the choice of writing:

print A
print B

to get your work done without having to find and search the docs. This
trick won't work with Python until you can figure out how to hold the
newline.

On 20/01/2022 21:25, Dmitry A. Kazakov wrote:
> On 2022-01-20 21:13, Bart wrote:

>> I notice you didn't respond to my bookshelf analogy.
>
> Because it is a wrong analogy. The right one is the poles in the Tower
> of Hanoi game with the difference that instead of moving rings one moves
> the poles. Though one could move the rings instead, in some rather
> inefficient implementation.

OK. But if I've got a pile of books on one pole (using a hole near one
corner to minimise the inconvenience), how to do I remove a book in the
middle of the pile?

An analogy has to corespond to what people actually want to do.

Here's a very similar one which is about actual code:

* You have a list of strings (could be an editor where each string = one
of an ordered set of lines; or could be anything)

* Let's say the implemention is a linear list of fixed-length
descriptors (eg. pointers), with the string data itself stored elsewhee
(say, in a LIFO stack)

* Now you have the same requirement as the bookshelf: you want to delete
on of those strings, and the accompanying string data

* Here it diverges form the bookshelf, as you probably want to close the
gap, which means moving those descriptors. But it means moving the
string data too - inefficient

* Or we can say that you want to replace one of those strings with a
different string, other shorter or longer.

To retain the LIFO structure of the string data, you will still need to
move all those descriptors and string data.

Now suppose you want to reverse the order of all those strings. Or
randomise them. Using fixed-length descriptors, you can very easily
reverse or randomise that list of descriptors. (Or may you just want to
swap the order of two lines.)

You don't need to touch the string data in its stack-like structure.
However it is now no longer a stack; it's more of a heap, as the
ordering is chaotic.