On 08/01/2022 20:01, Dmitry A. Kazakov wrote:
> On 2022-01-08 17:29, James Harris 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?
>>
>> Depends on where they are:
>>
>> 1. Globals - reclaimed when the program exits.
>>
>> 2. Locals on the stack or in activation records - reclaimed at least
>> by the time the function exits.
>>
>> 3. Dynamic on the heap - management required.
>
> Now replace integer with string. The work done.

Strings are, in general, not of fixed length.

>
>> Your solution of creating string forms of values is reasonable in a
>> language and an environment which already have dynamic memory
>> management but not otherwise.
>
> You do not need that.
>
>>>> Not all languages have dynamic memory management, and dynamic memory
>>>> management is not ideal for all compilation targets.
>>>
>>> No dynamic memory management is required for handling temporary objects.
>>
>> Where would you put the string forms?
>
> The same place you put integer, float, etc. That place is called stack
> or LIFO.

Integer and Float are of fixed length.

>
>> Whether formatted or not, all IO tends to have higher costs than
>> computation and for most applications the cost of printing doesn't
>> matter. But when designing a language or a standard library it's a bad
>> idea to effectively impose a scheme which has a higher cost than
>> necessary because the language designer doesn't know what uses his
>> language will be put to.
>
> Did you do actual measurements?

Did you?

:-)

>
> printf obviously imposes higher costs than direct conversions. And also
> costs that cannot be easily optimized since the format can be an
> expression and even if a constant it is difficult to break down into
> direct conversions.
>

I am not defending printf.

--
James Harris

On 08/01/2022 19:48, Dmitry A. Kazakov wrote:
> On 2022-01-08 17:50, James Harris wrote:
>> On 02/01/2022 18:40, Dmitry A. Kazakov wrote:
>>> On 2022-01-02 18:54, James Harris wrote:
>>>> On 02/01/2022 17:21, Dmitry A. Kazakov wrote:
>>>
>>>>> If this
>>>>>
>>>>>     Put_Line ("X=" & X'Image & ", Y=" & Y'Image);
>>>>>
>>>>> is a problem in your language, then the job is not done.
>>>>
>>>> That would be poor for small-machine targets. Shame on Ada! ;-)
>>>
>>> That works perfectly well on small targets. You seem unaware of what
>>> actually happens on I/O. For a "small" target it would be some sort
>>> of networking stack with a terminal emulation on top of it. Believe
>>> me, creating a temporary string on the stack is nothing in comparison
>>> to that. Furthermore, the implementation would likely no less
>>> efficient than printf which has no idea how large the result is and
>>> would have to reallocate the output buffer or keep it between calls
>>> and lock it from concurrent access. Locking on an embedded system is
>>> a catastrophic event because switching threads is expensive as hell.
>>> Note also that you cannot stream output, because networking protocols
>>> and terminal emulators are much more efficient if you do bulk
>>> transfers. All that is the infamous premature optimization.
>>
>> I don't know why you bring locking into it. It's neither necessary nor
>> relevant.
>
> Because this is how I/O works.

Why? Where there's no contention and just one task producing a certain
stream's output what is there to lock from?

I have even designed a lock-free way of allowing two or more tasks to
write to the same stream so I don't buy in to conventional wisdom of the
necessity for locks.

>
>> Furthermore, the only use for an output buffer is to make output more
>> efficient; it's not fundamental.
>
> It is fundamental, there is no hardware anymore where you could just
> send a single character to.

Of course there is. For example, a 7-segment display. Another: an async
serial port.

> A small target will write to the network
> stack, e.g. use socket send over TCP, that will coalesce output into
> network packets, these would be buffered into transport layer frames,
> these will go to physical layer packets etc.

In a couple of replies recently you've mentioned a communication stack.
I don't know why you are thinking of such a thing but not all
communication uses the OSI 7-layer model! ;-)

>
> There is no such thing as character stream without a massive overhead
> beneath it. So creating a string on the secondary stack is nothing in
> compare to that especially when you skip stream abstraction. Most
> embedded software do. They tend to do I/O directly in packets. E.g.
> sending application level packets over TCP or using UDP.
>
> Tracing, the only place where text output is actually used,

Tracing is 'the only place where text output is used'? :-o

--
James Harris

On 08/01/2022 19:35, Dmitry A. Kazakov wrote:
> On 2022-01-08 17:18, James Harris wrote:
>> On 02/01/2022 18:25, Dmitry A. Kazakov wrote:
>>> On 2022-01-02 19:05, James Harris wrote:
>>>> On 28/12/2021 09:21, Dmitry A. Kazakov wrote:
>>
>> ...
>>
>>>>> The most flexible is a combination of a string that carries most of
>>>>> the information specific to the datatype (an OO method) and some
>>>>> commands to the rendering environment.
>>>>
>>>> That sounds interesting. How would it work?
>>>
>>> With single dispatch you have an interface, say, 'printable'. The
>>> interface has an abstract method 'image' with the profile:
>>>
>>>     function Image (X : Printable) return String;
>>>
>>> Integer, float, string, whatever that has to be printable inherits to
>>> Printable and thus overrides Image. That is.
>>>
>>> The same goes with serialization/streaming etc.
>>
>> OK, that was my preferred option, too. The trouble with it is that it
>> needs somewhere to put the string form. And you know the problems
>> therewith (lack of recursion OR lack of thread safety OR dynamic
>> memory management).
>
> No idea why you think there is something special about string format or
> that any of the mentioned issues would ever apply. Conversion to string
> needs no recursion,

It does if a to-string function invokes another to-string function.

> is as thread safe as any other call, needs no
> dynamic memory management.

Unless you know the maximum size of the string (and you prohibit
recursion and you keep it thread local) then you cannot reserve space
for it in the activation record of the caller (or in global space). As
you know, if you create it in the activation record of the to-string
function then its memory will go out of scope when the function returns.

However, if the formatter is passed the value and the format (my
suggestion) then it (the formatter) can print the characters one by one
or could write them to a buffer - with the buffer being legitimately and
safely deallocated when the formatter returns.

>
> There should be no format specifications at all. You just need a few
> parameters for Image regarding type-specific formatting and a few
> parameters regarding rendering context in the actual output call.
>
> The former are like put + if positive, base, precision etc; the latter
> are like output field width, alignment, fill character etc.

That sounds good. Perhaps other things should be added: fixed or
floating sign, leading or trailing sign, different potential
representations of bases, digit grouping, fixed-point scaling, response
to exceeding a field width, etc.

--
James Harris

On 2022-01-08 23:11, James Harris wrote:
> On 08/01/2022 19:35, Dmitry A. Kazakov wrote:

>> No idea why you think there is something special about string format
>> or that any of the mentioned issues would ever apply. Conversion to
>> string needs no recursion,
>
> It does if a to-string function invokes another to-string function.

Recursion is when a function calls itself not another function.

>> is as thread safe as any other call, needs no dynamic memory management.
>
> Unless you know the maximum size of the string

Again, that is not required. You should really take a look how stacks
work. You can return an indefinite object without prior knowledge of its
size until actual return. It is no rocket science.

> However, if the formatter is passed the value and the format (my
> suggestion) then it (the formatter) can print the characters one by one

It cannot.

1. Check how I/O works

2. Observe output fields, alignments, padding, columns of output

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

On 2022-01-08 22:58, James Harris wrote:
> On 08/01/2022 19:48, Dmitry A. Kazakov wrote:
>> On 2022-01-08 17:50, James Harris wrote:
>>> On 02/01/2022 18:40, Dmitry A. Kazakov wrote:
>>>> On 2022-01-02 18:54, James Harris wrote:
>>>>> On 02/01/2022 17:21, Dmitry A. Kazakov wrote:
>>>>
>>>>>> If this
>>>>>>
>>>>>>     Put_Line ("X=" & X'Image & ", Y=" & Y'Image);
>>>>>>
>>>>>> is a problem in your language, then the job is not done.
>>>>>
>>>>> That would be poor for small-machine targets. Shame on Ada! ;-)
>>>>
>>>> That works perfectly well on small targets. You seem unaware of what
>>>> actually happens on I/O. For a "small" target it would be some sort
>>>> of networking stack with a terminal emulation on top of it. Believe
>>>> me, creating a temporary string on the stack is nothing in
>>>> comparison to that. Furthermore, the implementation would likely no
>>>> less efficient than printf which has no idea how large the result is
>>>> and would have to reallocate the output buffer or keep it between
>>>> calls and lock it from concurrent access. Locking on an embedded
>>>> system is a catastrophic event because switching threads is
>>>> expensive as hell. Note also that you cannot stream output, because
>>>> networking protocols and terminal emulators are much more efficient
>>>> if you do bulk transfers. All that is the infamous premature
>>>> optimization.
>>>
>>> I don't know why you bring locking into it. It's neither necessary
>>> nor relevant.
>>
>> Because this is how I/O works.
>
> Why? Where there's no contention and just one task producing a certain
> stream's output what is there to lock from?

How the file system knows that there is only one task accessing the stream?

> I have even designed a lock-free way

Lock-free does not mean no locking. It only means that synchronization
is achieved per busy waiting rather than per signaling an event.

>>> Furthermore, the only use for an output buffer is to make output more
>>> efficient; it's not fundamental.
>>
>> It is fundamental, there is no hardware anymore where you could just
>> send a single character to.
>
> Of course there is. For example, a 7-segment display. Another: an async
> serial port.

The hardware used in actual applications. Even for an UART it is not
true, consider software handshaking as a counter-example. In practice
serial protocols need a considerable amount of locking, sometimes, even
hard timeouts. As an example consider MODBUS RTU. It is a serial
protocol. Even a simple modem requires locking, or for that matter an
serial dot-matrix printer if you find one.

>> A small target will write to the network stack, e.g. use socket send
>> over TCP, that will coalesce output into network packets, these would
>> be buffered into transport layer frames, these will go to physical
>> layer packets etc.
>
> In a couple of replies recently you've mentioned a communication stack.
> I don't know why you are thinking of such a thing but not all
> communication uses the OSI 7-layer model! ;-)

And the overhead coming from each of the layers.

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

On 2022-01-08 22:05, Bart wrote:
> On 08/01/2022 20:49, Dmitry A. Kazakov wrote:
>> On 2022-01-08 21:22, Bart wrote:
>>
>>> This didn't work (I guess ' has higher precedence than +?). But
>>> neither did:
>>>
>>>       Put_Line ((X+Y)'Image);
>>>
>>> 'Image' can only be applied to a name, not an expression; why?
>>
>> Because 'Image is a type attribute:
>>
>>     <subtype>'Image (<value>)
>
> And yet it works with X'Image when X is a variable, not a type.

That is another attribute. The type of a variable is known. The type of
an expression is not.

>>> You need to be able to just do this:
>>>
>>>      println X+Y
>>
>> Nope, I don't need that at all. In Ada it is just this:
>>
>>     Put (X + Y);
>
> So it's overloading Put() with different types. But the language doesn't
> similarly overload Put_Line()?

Why should it? It is never happens to print one data point per line
except when the whole line is printed and then that is a string.

>> See the package Integer_IO (ARM A.10.8). The point is that is is
>> almost never used, because, again, not needed for real-life software.
>
> Huh? Have you never written data to a file?

Not this way.

Besides it is about formatted output, not about data. Data are written
in binary formats from simple to very complex like in the databases.

Formatted output is performed into a string buffer which is then output.
Always, no exceptions.

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

On 2022-01-08 22:41, James Harris wrote:
> On 08/01/2022 19:54, Dmitry A. Kazakov wrote:
>> On 2022-01-08 17:36, James Harris wrote:
>>> On 02/01/2022 17:21, Dmitry A. Kazakov wrote:
>>>
>>> ...
>>>
>>>> If this
>>>>
>>>>     Put_Line ("X=" & X'Image & ", Y=" & Y'Image);
>>>>
>>>> is a problem in your language, then the job is not done.
>>>
>>> What's wrong with
>>>
>>>    put_line("X=%i;, Y=%i;", X, Y)
>>>
>>> ?
>>
>> Untyped, unsafe, messy, non-portable garbage that does not work with
>> user-defined types.
>
> That's just wrong. It is typesafe,

So the text "%i" is checked against the type of X during compile-time?

> clean

Obviously not. Counting formats and argument positions, come on!

> and portable.

Varlists are inherently non-portable.

> What's more, per
> the suggestion I made to start this thread it will work with
> user-defined types.

The suggestion made no sense being a low-level mess lacking minimal
safety checks.

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

On 2022-01-08 22:18, Bart wrote:
> On 08/01/2022 21:04, Dmitry A. Kazakov wrote:
>> On 2022-01-08 21:46, Bart wrote:
>>> On 08/01/2022 20:01, Dmitry A. Kazakov wrote:
>>>> On 2022-01-08 17:29, James Harris wrote:
>>>
>>>>>> No dynamic memory management is required for handling temporary
>>>>>> objects.
>>>>>
>>>>> Where would you put the string forms?
>>>>
>>>> The same place you put integer, float, etc. That place is called
>>>> stack or LIFO.
>>>
>>> (1) integer, float etc are a fixed size known at compile-time
>>
>> So what?
>>
>>> (2) integer, float etc are usually manipulated by value
>>
>> Irrelevant.
>
> Relevant because you are suggesting that strings can be manipulated just
> like a 4- or 8-byte primitive type.

Regarding memory management they can.

>>> Apparently Ada strings have a fixed length.
>>
>> Apparently not:
>>
>>     function Get_Line (File : File_Type) return String;
>
> Yet I can't do this:
>
>   S: String;

Yet you cannot. So?

> "unconstrained subtype not allowed". It needs a size or to be
> initialised from a literal of known length.

Wrong:

S : String := Get_Line (Standard_Input); -- Perfectly legal

>> To widen your horizon a little bit, a stack LIFO can be implemented by
>> many various means: using machine stack, using machine registers,
>> using thread local storage as well as various combinations of.
>
> Suppose you have this:
>
>      Put_Line(Get_Line(...));
>
> Can you go into some detail as to what, exactly, is passed back from
> Get_Line(),

That depends on the compiler. Get_Line could allocate a doped string
vector on the secondary stack and return a reference to it on the
primary stack. Or the dope and reference on the primary stack and the
body on the secondary stack.

> what, exactly, is passed to Put_Line(),

Reference to the vector on the secondary stack or else the dope and the
reference.

> bearing in mind that
> 64-bit ABIs frown on passing by value any args more than 64-bits, and
> where, exactly, the actual string data, which can be of any length,
> resides during this process, and how that string data is destroyed when
> it is no longer needed?

The object's length computable from the vector's dope. E.g.

8 + high-bound - low-bound + 1 + rounding

assuming 32-bit bounds. The secondary stack containing arguments of
Put_Line is popped upon return from it.

> Then perhaps you might explain in what way that is identical to passing
> a Integer to Put().

Just same. Push arguments on the stack, pop it upon return. In the case
of Integer it could be the primary stack instead of secondary stacks.
Which one uses GNAT for Ada calling convention I don't know.

>>> But Ada also has unbounded strings:
>>>
>>> "Unbounded strings are allocated using heap memory, and are
>>> deallocated automatically."
>>
>> Unbounded_String is practically never needed and discouraged to use.
>> Because heap is a bad idea and because text processing algorithm
>> almost never require changing length/content of a string.
>
> It seems you've never written a text editor either!

On the contrary. I wrote text editors in FORTRAN-IV which had no
character type at all. The text buffer was LOGICAL*1 allocated
programmatically in a single huge static array.

Hint, it is an incredible bad idea to use Unbounded_String for a text
buffer.

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

On 08/01/2022 23:12, Dmitry A. Kazakov wrote:
> On 2022-01-08 22:05, Bart wrote:
>> On 08/01/2022 20:49, Dmitry A. Kazakov wrote:
>>> On 2022-01-08 21:22, Bart wrote:
>>>
>>>> This didn't work (I guess ' has higher precedence than +?). But
>>>> neither did:
>>>>
>>>>       Put_Line ((X+Y)'Image);
>>>>
>>>> 'Image' can only be applied to a name, not an expression; why?
>>>
>>> Because 'Image is a type attribute:
>>>
>>>     <subtype>'Image (<value>)
>>
>> And yet it works with X'Image when X is a variable, not a type.
>
> That is another attribute. The type of a variable is known. The type of
> an expression is not.

But it is known with Put(X+Y) ?

>
>>>> You need to be able to just do this:
>>>>
>>>>      println X+Y
>>>
>>> Nope, I don't need that at all. In Ada it is just this:
>>>
>>>     Put (X + Y);
>>
>> So it's overloading Put() with different types. But the language
>> doesn't similarly overload Put_Line()?
>
> Why should it? It is never happens to print one data point per line
> except when the whole line is printed and then that is a string.

The common-sense way of doing this is to define Put/Putln to work
identically, but the latter writes a newline as the end.

I'm not sure where you get the idea that one item per line never happens
unless it's a string. If I wanted to output N numbers, I can do N calls
to Put, but each has to be followed by Put_Line("") or Put_Line(" ") to
separate them? Instead of just doing N calls of Put_Line(x).

It's an unnecessary restriction. (Have a look at a FizzBuzz program.)

The most convenient for the user is to be able to print any number of
items per line, of mixed types. Which is exactly how my Println works.

>>> See the package Integer_IO (ARM A.10.8). The point is that is is
>>> almost never used, because, again, not needed for real-life software.
>>
>> Huh? Have you never written data to a file?
>
> Not this way.
>
> Besides it is about formatted output, not about data. Data are written
> in binary formats from simple to very complex like in the databases.
>
> Formatted output is performed into a string buffer which is then output.
> Always, no exceptions.

Nonsense. There are no rules for what someone may want to write to a
text file. Here's a program to write N random numbers to a file, of
which the first line is N:

n:=random(1 million)
println @f, n
to n do
println @f, random(0)
end

Um, just one number per line...

There are also files with mixed text and binary content, eg. PGM files.

On 2022-01-08 22:45, James Harris wrote:
> On 08/01/2022 20:01, Dmitry A. Kazakov wrote:
>> On 2022-01-08 17:29, James Harris 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?
>>>
>>> Depends on where they are:
>>>
>>> 1. Globals - reclaimed when the program exits.
>>>
>>> 2. Locals on the stack or in activation records - reclaimed at least
>>> by the time the function exits.
>>>
>>> 3. Dynamic on the heap - management required.
>>
>> Now replace integer with string. The work done.
>
> Strings are, in general, not of fixed length.

So what? Length is irrelevant when dealing with a stack. You push a
chuck, you pop a chunk.

>>> Whether formatted or not, all IO tends to have higher costs than
>>> computation and for most applications the cost of printing doesn't
>>> matter. But when designing a language or a standard library it's a
>>> bad idea to effectively impose a scheme which has a higher cost than
>>> necessary because the language designer doesn't know what uses his
>>> language will be put to.
>>
>> Did you do actual measurements?
>
> Did you?

It is not my claim. The burden of proof is on your side.

>> printf obviously imposes higher costs than direct conversions. And
>> also costs that cannot be easily optimized since the format can be an
>> expression and even if a constant it is difficult to break down into
>> direct conversions.
>
> I am not defending printf.

Promoting undefendable, even better? (:-))

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

On 2022-01-09 00:36, Bart wrote:
> On 08/01/2022 23:12, Dmitry A. Kazakov wrote:
>> On 2022-01-08 22:05, Bart wrote:
>>> On 08/01/2022 20:49, Dmitry A. Kazakov wrote:
>>>> On 2022-01-08 21:22, Bart wrote:
>>>>
>>>>> This didn't work (I guess ' has higher precedence than +?). But
>>>>> neither did:
>>>>>
>>>>>       Put_Line ((X+Y)'Image);
>>>>>
>>>>> 'Image' can only be applied to a name, not an expression; why?
>>>>
>>>> Because 'Image is a type attribute:
>>>>
>>>>     <subtype>'Image (<value>)
>>>
>>> And yet it works with X'Image when X is a variable, not a type.
>>
>> That is another attribute. The type of a variable is known. The type
>> of an expression is not.
>
> But it is known with Put(X+Y) ?

Yes, because Put tells the type it expects.

>>>>> You need to be able to just do this:
>>>>>
>>>>>      println X+Y
>>>>
>>>> Nope, I don't need that at all. In Ada it is just this:
>>>>
>>>>     Put (X + Y);
>>>
>>> So it's overloading Put() with different types. But the language
>>> doesn't similarly overload Put_Line()?
>>
>> Why should it? It is never happens to print one data point per line
>> except when the whole line is printed and then that is a string.
>
> The common-sense way of doing this is to define Put/Putln to work
> identically, but the latter writes a newline as the end.

There is no common sense doing things that are not needed!

> I'm not sure where you get the idea that one item per line never happens
> unless it's a string. If I wanted to output N numbers, I can do N calls
> to Put, but each has to be followed by Put_Line("") or Put_Line(" ") to
> separate them? Instead of just doing N calls of Put_Line(x).

When reasonable people print arrays they do that in columned output.

> It's an unnecessary restriction. (Have a look at a FizzBuzz program.)

It is no restriction, it as a feature nobody needed. You can easily
implement it yourself:

procedure Put_Line (X : Integer) is
begin
New_Line;
Put (X);
end Put_Line;

Ada features are voted by a committee. This one never made it, if it was
ever suggested, which I doubt.

>>>> See the package Integer_IO (ARM A.10.8). The point is that is is
>>>> almost never used, because, again, not needed for real-life software.
>>>
>>> Huh? Have you never written data to a file?
>>
>> Not this way.
>>
>> Besides it is about formatted output, not about data. Data are written
>> in binary formats from simple to very complex like in the databases.
>>
>> Formatted output is performed into a string buffer which is then
>> output. Always, no exceptions.
>
> Nonsense. There are no rules for what someone may want to write to a
> text file.

Of course there are rules, stated above. You may follow them or not.

> There are also files with mixed text and binary content, eg. PGM files.

Once binary always binary.

(Talking to you I begin sounding like a damned psychoanalyst! (:-))

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

On 08/01/2022 23:36, Dmitry A. Kazakov wrote:
> On 2022-01-08 22:18, Bart wrote:

>> Relevant because you are suggesting that strings can be manipulated
>> just like a 4- or 8-byte primitive type.
>
> Regarding memory management they can.
>

>> Suppose you have this:
>>
>>       Put_Line(Get_Line(...));
>>
>> Can you go into some detail as to what, exactly, is passed back from
>> Get_Line(),
>
> That depends on the compiler. Get_Line could allocate a doped string
> vector on the secondary stack and return a reference to it on the
> primary stack. Or the dope and reference on the primary stack and the
> body on the secondary stack.
>
>> what, exactly, is passed to Put_Line(),
>
> Reference to the vector on the secondary stack or else the dope and the
> reference.
>
>> bearing in mind that 64-bit ABIs frown on passing by value any args
>> more than 64-bits, and where, exactly, the actual string data, which
>> can be of any length, resides during this process, and how that string
>> data is destroyed when it is no longer needed?
>
> The object's length computable from the vector's dope. E.g.
>
>    8 + high-bound - low-bound + 1 + rounding
>
> assuming 32-bit bounds. The secondary stack containing arguments of
> Put_Line is popped upon return from it.
>
>> Then perhaps you might explain in what way that is identical to
>> passing a Integer to Put().
>
> Just same. Push arguments on the stack, pop it upon return. In the case
> of Integer it could be the primary stack instead of secondary stacks.
> Which one uses GNAT for Ada calling convention I don't know.

I think you demonstrated above that it is entirely different, it is not
just pushing one 64-bit value:

* Doped string vectors
* References
* Secondary stacks (which appear to be a kind of heap but with
stack-like allocations)

It's also not clear, as James pointed out, how a string created on a
secondary stack in a called function manages to move to the secondary
stack of the caller, since in between there may be secondary stack space
containing local data for the called function (plus possible secondary
stack space pertaining the the caller's argument list).

This is also highly specific to machine, language and ABI.

In other words, nothing like as simple as passing an integer.

c array.
>
> Hint, it is an incredible bad idea to use Unbounded_String for a text
> buffer.

The basis on which most programs work is that memory is a huge array of
mutable bytes. Also, most of the available data memory to a program
(99%) will be in the form of heap memory.

On 2022-01-09 01:15, Bart wrote:

> It's also not clear, as James pointed out, how a string created on a
> secondary stack in a called function manages to move to the secondary
> stack of the caller,

One technique is to use two stacks and swap them over. The arguments and
locals stack vs the results stack so that the callee's arguments and
locals stack is the caller's results stack. The call sequence would be this:

push arguments onto S1
call and swap stacks
push locals on S2 (former S1)
push result onto S1 (former S2)
return and swap stacks
pop S1

Now the result of the call is on the arguments and locals stack as expected.

> This is also highly specific to machine, language and ABI.

This is absolutely non-specific. A machine may provide some support, but
there is no problem if it does not.

> In other words, nothing like as simple as passing an integer.

It is exactly same stack handling for everything. Surely some
optimization like using registers for the stack tops is possible and
welcome.

>> Hint, it is an incredible bad idea to use Unbounded_String for a text
>> buffer.
>
> The basis on which most programs work is that memory is a huge array of
> mutable bytes.

This has nothing to do with the data structures used to implement text
buffers.

The text buffers have certain requirements like effective insertion and
removing portions of text as well as effective text tagging. A character
array is incredibly miserable on these.

So, the short answer, just don't. The long answer read the literature on
the subject, study existing implementations of text buffers.

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

On 09/01/2022 11:57, Dmitry A. Kazakov wrote:
> On 2022-01-09 01:15, Bart wrote:
>
>> It's also not clear, as James pointed out, how a string created on a
>> secondary stack in a called function manages to move to the secondary
>> stack of the caller,
>
> One technique is to use two stacks and swap them over. The arguments and
> locals stack vs the results stack so that the callee's arguments and
> locals stack is the caller's results stack. The call sequence would be
> this:
>
> push arguments onto S1
> call and swap stacks
> push locals on S2 (former S1)
> push result onto S1 (former S2)
> return and swap stacks
> pop S1
>
> Now the result of the call is on the arguments and locals stack as
> expected.
>
>> This is also highly specific to machine, language and ABI.
>
> This is absolutely non-specific. A machine may provide some support, but
> there is no problem if it does not.

It depends on how the language does things. It depends on the ABI. Which
in turn also depends on the machine.

>> In other words, nothing like as simple as passing an integer >
> It is exactly same stack handling for everything.

Keep on saying that, but you're wrong. A simple 64-bit number and a
complex data structure which even you admit can be implemented in
different ways, are not the same thing!

> The text buffers have certain requirements like effective insertion and
> removing portions of text as well as effective text tagging. A character
> array is incredibly miserable on these.

My current editor uses a list of strings (and implemented as interpreted
code). There's no special way to delete or insert elements, so removing
or adding a line is not that efficient. But you won't really notice
until you get to 1 or 2 million lines of text. Most files I edit are a
few thousand lines.

On 08/01/2022 17:15, James Harris wrote:
>>> If you are not convinced by formatted io then what kind of io do
>>> you prefer?
>>      Unformatted transput, of course.  Eg,
>>    print this, that, these, those and the many other things
> OK. I would say that that has /default/ formatting but is still
> formatted.

You can say that if you insist, but ISTM to be an abuse of
language. The point about /formatted/ transput is that the user
prescribes some "mould" into which objects such as integers [for
output] or strings [for input] are "poured" for conversion. So
we get calls like "printf (some_mould, some_value)". It's a
useful distinction from unformatted transput, where the user does
not specify any mould.

[...]
> You have a preferred syntax in which users can express how they want
> values to be formatted? Suggestions welcome!

The whole point would be that unformatted transput doesn't
/have/ a syntax! It just uses the otherwise-existing syntax of the
language. So, no, I don't have a preferred syntax. [Admittedly,
in the case of C, the dividing line is blurred, as C's formatting
strings are part of the library; you could in principle write your
own "printf" procedure from scratch with its own semantics. But
no-one does, as it's a lot of work for little reward. Some other
languages do have special syntax for formats.]

[...]
> The design of the language supports dynamically sized strings. That's
> fine for applications which need them. But that's different from
> imposing such strings and the management thereof on every print
> operation.

How does that differ in principle from "my language has
numbers, but that's different from imposing them on every
arithmetic operation"? The string [array of characters] is the
natural unit of both input and output. The whole point of
transput is to convert values, such as integers [or dates], to
strings for output, or conversely to parse strings into integers
[or dates] for input. If your language has strings, then what
is the objection to using them? If not, then you have to
re-write your conversion/parsing procedures to work character
by character; it's not difficult, but it's extra work and it
means that you can't [easily] use intermediate stages [such as
constructing an array of strings and sorting them before output].

[...]
>> You're making mountains out of
>> molehills.
> Oh? How would you handle
>   widget w
>   print(w)
> ?
> ISTM you are suggesting that w be converted to a string (or array of
> characters) and then printed.

What on earth else would you expect to happen? That's
quite separate from whether a "format" has to be invoked. That's
merely the choice between:

widget w; format f = [whatever]; printf (f, w)

and

widget w; proc g = [whatever]; print (g(w))

where "f" is a "mould" that converts widgets to strings and "g" is
a procedure that converts widgets to strings. The difference is
that "f" needs a special "little language" and "g" doesn't.

[...]
> a. Where would you store the array of characters?

You get an array of characters either way. If your
language has strings that's it. If not, then both "printf"
and "print" in the above notation can be defined to produce
[and print or read] the strings character by character if
that's what your language needs. There's no /important/
difference.

> b. What's wrong with
>   print "String with %v; included" % val

Nothing, except that "%" has become a privileged
character [with two different syntaxes in your example].
But why should anyone prefer it to

print "String with ", val, " included"

[if the default format is OK for you, or replace "val" by
some "g(val)" otherwise]?

[...]
> Cool. But if you agree with my suggestion of a means which can be
> used to render each character in sequence I don't know why you
> suggested conversion to an array of characters.

It's more flexible, and you need the conversion process
anyway. As above, arrays of characters are the natural units;
as in "Hello, world!", which you don't usually, when writing C,
think of as "H" followed by "e" followed by "l", ... [though you
obviously can if you want to, and at a lower level the code for
"printf" is indeed very likely to step through the string].

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

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.
For the limited requirements of strings-for-transput, procedures
such as [in C terms] "malloc" and "free" are entirely sufficient
and safe. If you have control [as you do for your own language]
of the compiler, then you can implement strings-as-results even
without any off-stack storage [simply copy them, or indeed any
data structures that don't involve pointers, down into the stack
space of the calling procedure as part of exiting the returning
function]. But of course it's easier, from the PoV of the
programmer, if heaps and strings are already built in. [Of
course, as discussed elsewhere in the thread, strings aren't
necessary either, merely convenient.]

So what you actually seem to be saying is that your [or
James's] language "should" be more primitive than C, and should
be incapable of implementing reasonably general data structures,
such as trees, that require heaps, or near equivalents. That
would be a pretty definite deal-breaker for me. I can understand
that you might want a better implementation than C's; but that's
another [and perhaps inspiring] matter.

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

On 09/01/2022 22:05, Andy Walker wrote:
> On 08/01/2022 17:15, James Harris wrote:

>> b. What's wrong with
>>    print "String with %v; included" % val
>
>     Nothing, except that "%" has become a privileged
> character [with two different syntaxes in your example].
> But why should anyone prefer it to
>
>   print "String with ", val, " included"

There are reasons why people would. Most of my Prints are ordinary print
statements like your example, except that they inject spaces between
items (wherever "," is written, with ",," used to suppress that space as
seen below).

But sometimes I decide to use formatted print, or 'fprint', rather than
'print'. 'fprint' starts with a format string. Just see for yourself
whether my choice was justified:

fprint "operator (#)(#,#)#", jtagnames[i]+2, strmode(p.amode),
strmode(p.bmode), strmode(p.rmode)

Using ordinary, it's needs to be written like this:

print "(",, jtagnames[i]+2,, ")", strmode(p.amode),, "," ,,
strmode(p.bmode),, ")",, strmode(p.rmode)

(Typical output is 'operator (+)(int, int)int')

A simpler example:

fprint "[#..#]", ttlower[m], ttlength[m]+ttlower[m]-1

is written unformatted as:

print "[",, ttlower[m],, "..",, ttlength[m]+ttlower[m]-1,, "]"

And a final one:

fprint "Refbit #:# (#,#)", ttname[p.uref.elemtag], p.uref.ptr,
p.uref.bitoffset, p.uref.bitlength

which I won't bother translating...

The 'fprint' versions give a nice overall picture of the layout of the
line, with variable parts represented by '#'. It is is very easy to get
that right and to maintain.

Doing it with normal 'print' is obviously possible, but it's much more
fiddly and much harder to see the result without running the program,
which then usually needs multiple tweaks to get just right.

Sometimes I even use it in simple cases like this (but with somewhat
more elaborate expressions):

fprint "# #", a, b

even though this is exactly equivalent to 'print a, b'. Why? Well, it
immediately tells me that that is the case; compare with:

print longtable[i+2, f(j-2, 1)], longtable[a, b]

where it's not immediately clear that there are only two print items!

I can very easily control the spacing between items; unspaced is "##",
spaced is "# #".

But also, I can instantly change the format to anything else, eg. an
extra space is "# #"; with a comma as well it's "#, #". Try that with
my example:

print longtable[i+2, f(j-2, 1)], ", ", longtable[a, b]

Notice the comma blends in with all the others!

Another advantage is being to able to use a generic format like "(#, #,
#)", and applying to a sequence of 3-element prints, if I wanted them to
all be displayed in the same style. And to change the style, I change it
one place.

Still not convinced? This is an easy and low-cost language feature for
the extra convenience provided.

On 10/01/2022 01:08, Andy Walker 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.
> For the limited requirements of strings-for-transput, procedures
> such as [in C terms] "malloc" and "free" are entirely sufficient
> and safe.  If you have control [as you do for your own language]
> of the compiler, then you can implement strings-as-results even
> without any off-stack storage [simply copy them, or indeed any
> data structures that don't involve pointers, down into the stack
> space of the calling procedure as part of exiting the returning
> function].  But of course it's easier, from the PoV of the
> programmer, if heaps and strings are already built in.  [Of
> course, as discussed elsewhere in the thread, strings aren't
> necessary either, merely convenient.]
>
>     So what you actually seem to be saying is that your [or
> James's] language "should" be more primitive than C, and should
> be incapable of implementing reasonably general data structures,
> such as trees, that require heaps, or near equivalents.  That
> would be a pretty definite deal-breaker for me.  I can understand
> that you might want a better implementation than C's;  but that's
> another [and perhaps inspiring] matter.

Actually, both my languages use similar print features: both have
print/println and fprint/fprintln that work in the same way.

Yet one of them does have first class strings and automatic memory
management. It just means it can print more complex types automatically,
and it is more practical to implement your explicit g() to-string functions.

Some of the discussion was about how to make possible some of that extra
capability in a lower-level language.

Clearly any solutions in my case are not going to be about upgrading the
GC features of the other language; it has work within that level of
language.

On 10/01/2022 01:25, Bart wrote:
[I wrote:]
>> But why should anyone prefer [James's proposal] to
>>    print "String with ", val, " included"
[...]
> But sometimes I decide to use formatted print, or 'fprint', rather
> than 'print'. 'fprint' starts with a format string. Just see for
> yourself whether my choice was justified:
[... examples snipped ...]

Obviously, if your language has /both/ "print" and "printf"
/and/ you're well versed in the details of both, then you can and
should use whichever suits you in particular cases. Most users
are not so familiar with the details of whatever languages they're
using, and have no control over what the language provides. So
the more important question is whether a /new/ language /should/
have both, and if not which is the one that should go. Bearing
in mind that "printf" necessitates the invention of a "little
language" [or not so little!] and perhaps additional syntax, and
will still not be comprehensive [cf your "date" example], ISTM
that the decision is straightforward.

> The 'fprint' versions give a nice overall picture of the layout of
> the line, with variable parts represented by '#'. It is is very easy
> to get that right and to maintain.

Yes, but there are other ways to do that without adding
to the size of the language and its description. Left as an
exercise.

> I can very easily control the spacing between items; unspaced is
> "##", spaced is "# #".
> But also, I can instantly change the format to anything else, eg. an
> extra space is "# #"; with a comma as well it's "#, #".

Not "anything else" [or, at least, not "instantly"]. As
you came close to pointing out, there are dozens of ways in which
dates are commonly [or less commonly!] printed, not all of which
are trivial re-arrangements of "print day, month, year". Even
simple numbers come in a variety of styles, not all of which are
catered for by formats such as "+11d.ddd", or whatever. See
also below.

[...]
> Another advantage is being to able to use a generic format like "(#,
> #, #)", and applying to a sequence of 3-element prints, if I wanted
> them to all be displayed in the same style. And to change the style,
> I change it one place.

Yes, but you don't need "printf" to do that. A procedure
that takes three parameters [or an array, and if you like strings
to act as start, finish and separator] and prints the appropriate
output is essentially trivial to write in any sensible language,
and is just as generic and easy to change. It's also your
choice [as a language designer] whether to provide that procedure
and others like it, in whatever numbers, in the language library
or leave it to relevant users to write their own. It's a matter
of balance. Providing conversions from numbers to strings of
digits is probably highly desirable; providing formatting for
triples of integers probably isn't, and should be left to the
users.

> Still not convinced? This is an easy and low-cost language feature
> for the extra convenience provided.

Providing simple procedures such as the one just suggested
is indeed easy, but not to do with writing little languages, or
adding syntax, and esp not with doubling the documentation needed.

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

On 11/01/2022 23:36, Andy Walker wrote:
> On 10/01/2022 01:25, Bart wrote:
> [I wrote:]
>>> But why should anyone prefer [James's proposal] to
>>>    print "String with ", val, " included"
> [...]
>> But sometimes I decide to use formatted print, or 'fprint', rather
>> than 'print'. 'fprint' starts with a format string. Just see for
>> yourself whether my choice was justified:
> [... examples snipped ...]
>
>     Obviously, if your language has /both/ "print" and "printf"
> /and/ you're well versed in the details of both, then you can and
> should use whichever suits you in particular cases.  Most users
> are not so familiar with the details of whatever languages they're
> using, and have no control over what the language provides.  So
> the more important question is whether a /new/ language /should/
> have both, and if not which is the one that should go.  Bearing
> in mind that "printf" necessitates the invention of a "little
> language" [or not so little!] and perhaps additional syntax, and
> will still not be comprehensive [cf your "date" example], ISTM
> that the decision is straightforward.
>
>> The 'fprint' versions give a nice overall picture of the layout of
>> the line, with variable parts represented by '#'. It is is very easy
>> to get that right and to maintain.
>
>     Yes, but there are other ways to do that without adding
> to the size of the language and its description.  Left as an
> exercise.

I did an experiment: I removed support for 'fprint/fprintln' from my
compiler.

I left in the library support for it, since this will still be needed
whether it's built-in, or implemented via functions.

It made the compiler executable about 0.2% smaller. It made the source
code 50 lines smaller.

However, it leaves a problem: exactly how to I achieve the same thing
using only user-functions?

That is, implement a function like this:

formattedprint(dest, formatstring, x, y, fmtxx(z,"z11"))

where x, y, z are of of arbitrary types. And it introduces the problems
that have been discussed of what to do about the string generated from
fmtxx(). It has the -xx designation because that is also type-specific.

My language doesn't have function overloads, but that wouldn't help:
overloads are used to select one of N functions, but we don't want
separate functions; we need one function that loops through a parameter
list of mixed types.

I don't have variadic parameters either. And I don't want to go
backwards and end up with C's crude solution.

So, saving 50 lines and having a 0.2% smaller core compiler, which is
your suggestion, means having a bunch of heavyweight language features
to design and add.

Or, the easy solution is to require the user to write:

startfmtprint(formatstring, dest)
print_xx(x, "")
print_yy(y, "")
print_zz(z, "z11")
endprint()

Here the 50 lines saved in the compiler, is replaced by 500 lines in
user code. (In one application, by one programmer.)

The payoff is poor.

>> But also, I can instantly change the format to anything else, eg. an
>> extra space is "#  #"; with a comma as well it's "#,  #".
>
>     Not "anything else" [or, at least, not "instantly"].  As
> you came close to pointing out, there are dozens of ways in which
> dates are commonly [or less commonly!] printed, not all of which
> are trivial re-arrangements of "print day, month, year".

This kind of format is used when you get to the point where you /have/ 3
items to print and you know the layout you want.

It is little to do with the language knowing how to deal with:

print d

when 'd' is some user-defined type.

> [...]
>> Another advantage is being to able to use a generic format like "(#,
>> #, #)", and applying to a sequence of 3-element prints, if I wanted
>> them to all be displayed in the same style. And to change the style,
>> I change it one place.
>
>     Yes, but you don't need "printf" to do that.  A procedure
> that takes three parameters [or an array, and if you like strings
> to act as start, finish and separator] and prints the appropriate
> output is essentially trivial to write in any sensible language,

See my example above. Not all formats are just "#, #, #". And in my
example of applying one format to multiple prints, not all those prints
will have the same types.

>  providing formatting for
> triples of integers probably isn't, and should be left to the
> users.

Where did I do that? I gave an example where if you have several Print
that have to output 3 things, then you may want them to share the same
layout.

>> Still not convinced? This is an easy and low-cost language feature
>> for the extra convenience provided.
>
>     Providing simple procedures such as the one just suggested
> is indeed easy, but not to do with writing little languages, or
> adding syntax, and esp not with doubling the documentation needed.

You will still need to document those functions. Or perhaps you are
suggesting every user has to reinvent the same functions for turning
numbers into strings, padding to a given width, justifying left or right
etc etc.

If you supply user-code functions in a library for that, they will still
need documentating, and that code of solution will be poorer.

On 12/01/2022 13:22, Bart wrote:
> I did an experiment: I removed support for 'fprint/fprintln' from my
> compiler.
> I left in the library support for it, since this will still be needed
> whether it's built-in, or implemented via functions.

That depends on what the support entails. If it's anything
even remotely like Algol support for formats, it's simply not needed
if you don't have formats [Algol "$ ... $", often one of the first
things to go in subset languages (inc early versions of A68R)]. If
OTOH you really mean the support for "print", then of course that
will be needed, but that suggests that your idea of formatted
transput is, to say the least, minimal.

> It made the compiler executable about 0.2% smaller. It made the
> source code 50 lines smaller.
> However, it leaves a problem: exactly how to I achieve the same thing
> using only user-functions?

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 [optional trailing
newline, and repeat last format]:

STRING ditto = "";
STRING lastfstring := ditto;
BOOL donewline := TRUE; # set FALSE to suppress trailing newline #

PROC fprint = (STRING s, [] UNION (INT, LONG INT, REAL, STRING) a) VOID:
( STRING fmt = ( s = ditto | lastfstring | lastfstring := s );
INT i := 0;
FOR j TO UPB fmt
DO IF fmt[j] = "#"
THEN CASE a[i +:= 1]
IN (UNION (INT, LONG INT) k): print (whole (k, 0)),
(REAL r): print (fixed (r, -8, 5)),
(STRING w): print (w)
ESAC
ELSE print (fmt[j])
FI
OD;
donewline | print (newline)
);

fprint ( "Hello #! Sqrt # is #, to 5dp", ("World", 2, sqrt(2)) );
fprint ( ditto, ("Bart", 1.69, "1.3") );
fprint ( "Longmaxint is #.", longmaxint )

[prints:

Hello World! Sqrt 2 is 1.41421, to 5dp
Hello Bart! Sqrt 1.69000 is 1.3, to 5dp
Longmaxint is 999999999999999999999999999999999999999999.

]. If this was a serious exercise, there would be more checks
and warnings. But also, there is a strong temptation to add
ever more facilities, which is how you finish up with dozens
of extra parameters or settable variables, and something that
takes serious effort to learn all the details of. Language
designers need to resist. Provide the basics, and let users
add the optional extras. That was how Unix/C started; and
letting people add the kitchen sink is how we got to Linux,
Gcc and documentation that is too much to print or learn.

> That is, implement a function like this:
>    formattedprint(dest, formatstring, x, y, fmtxx(z,"z11"))
> where x, y, z are of of arbitrary types. And it introduces the
> problems that have been discussed of what to do about the string
> generated from fmtxx(). It has the -xx designation because that is
> also type-specific.

To add a "dest", cf the relation between "put" and "print"
[RR10.5.1d; cost minimal]. For arbitrary types, see RR10.3.2.2a,b
and RR10.3.2.3a; but note that the full generality is available
only to the library, not to ordinary user code. For "what to do
about the string" -- just print it! The point is that specific
formats are not necessary, not that no printing is necessary.

[...]
> I don't have variadic parameters either.

Nor does Algol.

[...]
> It is little to do with the language knowing how to deal with:
>      print d
> when 'd' is some user-defined type.

That's not to do with formatted printing either.

[...]> See my example above. Not all formats are just "#, #, #". And in my
> example of applying one format to multiple prints, not all those
> prints will have the same types.

See my code above.

[...]
>>      Providing simple procedures such as the one just suggested
>> is indeed easy, but not to do with writing little languages, or
>> adding syntax, and esp not with doubling the documentation needed.
> You will still need to document those functions. Or perhaps you are
> suggesting every user has to reinvent the same functions for turning
> numbers into strings, padding to a given width, justifying left or
> right etc etc.

How much documentation do you suggest the code above needs?
Surely nothing like the scores of pages needed to describe formats
in C and Algol? [Formatted transput is ~15% of the RR, four times
as much as unformatted (which easily does all the things you're
"suggesting" users might have to reinvent), a similar fraction of
the A68 /syntax/, and is a nightmare to lex, as formats can
contain ordinary code, potentially with embedded formats nested
to arbitrary depth.]

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

On 15/01/2022 19:53, Andy Walker wrote:
> On 12/01/2022 13:22, Bart wrote:
>> I did an experiment: I removed support for 'fprint/fprintln' from my
>> compiler.
>> I left in the library support for it, since this will still be needed
>> whether it's built-in, or implemented via functions.
>
>     That depends on what the support entails.  If it's anything
> even remotely like Algol support for formats, it's simply not needed
> if you don't have formats [Algol "$ ... $", often one of the first
> things to go in subset languages (inc early versions of A68R)].  If
> OTOH you really mean the support for "print", then of course that
> will be needed, but that suggests that your idea of formatted
> transput is, to say the least, minimal.

I already demonstrated it: it's simply using a format string where "#"
characters show where each print item goes.

What is still present in both fprint and normal print are per-item
display options (like width and justify).

You might consider it minimal, but I considered it something that would
benefit from direct language support.

>> It made the compiler executable about 0.2% smaller. It made the
>> source code 50 lines smaller.
>> However, it leaves a problem: exactly how to I achieve the same thing
>> using only user-functions?
>
>     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 [optional trailing
> newline, and repeat last format]:
>
>   STRING ditto = "";
>   STRING lastfstring := ditto;
>   BOOL donewline := TRUE;  # set FALSE to suppress trailing newline #
>
>   PROC fprint = (STRING s, [] UNION (INT, LONG INT, REAL, STRING) a) VOID:
>    ( STRING fmt = ( s = ditto | lastfstring | lastfstring := s );
>      INT i := 0;
>      FOR j TO UPB fmt
>         DO IF fmt[j] = "#"
>              THEN CASE a[i +:= 1]
>                     IN (UNION (INT, LONG INT) k): print (whole (k, 0)),
>                        (REAL r): print (fixed (r, -8, 5)),
>                        (STRING w): print (w)
>                   ESAC
>              ELSE print (fmt[j])
>            FI
>         OD;
>      donewline | print (newline)
>    );
>
>   fprint ( "Hello #!  Sqrt # is #, to 5dp", ("World", 2, sqrt(2)) );
>   fprint ( ditto, ("Bart", 1.69, "1.3") );
>   fprint ( "Longmaxint is #.", longmaxint )
>
> [prints:
>
>   Hello World!  Sqrt 2 is  1.41421, to 5dp
>   Hello Bart!  Sqrt  1.69000 is 1.3, to 5dp
>   Longmaxint is 999999999999999999999999999999999999999999.

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.

My dynamic does have some of these, and there it would look like this:

const ditto=""

proc qfprint(s, items, newline=0) =
static var lastfstring=""

unless items.islist then items:=(items,) end
fmt:=(s=ditto | lastfstring | lastfstring:=s)

i:=0
for j to fmt.len do
if fmt[j]="#" then
print items[++i]
else
print fmt[j]
fi
od
if newline then println fi
end

proc qfprintln(s, items) =
qfprint(s, items, 1)
end

qfprintln( "Hello #! Sqrt # is #", ("World", 2, sqrt(2)) )
qfprintln( ditto, ("Bart", 1.69, "1.3") )
qfprintln( "maxint is #.", i64.max)

* The 'unless' line is to turn a single item into a list

* This actually works for any types, of arbitrary complexity

* Newline has been done using separate qfprint and qfprintln routines

It's not far off what it looks like using native fprint, where it has
less punctuation and allows for per-item format overrides, as well as
the ability to fprint to a file, string or other destination:

fprintln fm:="Hello #! Sqrt # is #", "World", 2, sqrt(2)
fprintln fm, "Bart", 1.69, "1.3"
fprintln "maxint is #.", i64.max

(Note I don't have decimal.max, my long number type; partly because
there is no maximum.)

> [...]
>> I don't have variadic parameters either.
>
>     Nor does Algol.

It has the union trick, and the ability to construct arrays of those
unions of effectively mixed types.

> [...]
>> It is little to do with the language knowing how to deal with:
>>       print d
>> when 'd' is some user-defined type.
>
>     That's not to do with formatted printing either.
>
> [...]> See my example above. Not all formats are just "#, #, #". And in my
>> example of applying one format to multiple prints, not all those
>> prints will have the same types.
>
>     See my code above.
>
> [...]
>>>      Providing simple procedures such as the one just suggested
>>> is indeed easy, but not to do with writing little languages, or
>>> adding syntax, and esp not with doubling the documentation needed.
>> You will still need to document those functions. Or perhaps you are
>> suggesting every user has to reinvent the same functions for turning
>> numbers into strings, padding to a given width, justifying left or
>> right etc etc.
>
>     How much documentation do you suggest the code above needs?
> Surely nothing like the scores of pages needed to describe formats
> in C and Algol?  [Formatted transput is ~15% of the RR, four times
> as much as unformatted (which easily does all the things you're
> "suggesting" users might have to reinvent), a similar fraction of
> the A68 /syntax/, and is a nightmare to lex, as formats can
> contain ordinary code, potentially with embedded formats nested
> to arbitrary depth.]

Yeah, A68 probably went overboard with this stuff. Beyond low-level
printing, the requirements are too diverse and application-specific.

On 16/01/2022 01:22, Bart wrote:
> On 15/01/2022 19:53, Andy Walker 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 [optional trailing
>> newline, and repeat last format]:
>>
>>    STRING ditto = "";
>>    STRING lastfstring := ditto;
>>    BOOL donewline := TRUE;  # set FALSE to suppress trailing newline #
>>
>>    PROC fprint = (STRING s, [] UNION (INT, LONG INT, REAL, STRING) a)
>> VOID:
>>     ( STRING fmt = ( s = ditto | lastfstring | lastfstring := s );
>>       INT i := 0;
>>       FOR j TO UPB fmt
>>          DO IF fmt[j] = "#"
>>               THEN CASE a[i +:= 1]
>>                      IN (UNION (INT, LONG INT) k): print (whole (k, 0)),
>>                         (REAL r): print (fixed (r, -8, 5)),
>>                         (STRING w): print (w)
>>                    ESAC
>>               ELSE print (fmt[j])
>>             FI
>>          OD;
>>       donewline | print (newline)
>>     );
>>
>>    fprint ( "Hello #!  Sqrt # is #, to 5dp", ("World", 2, sqrt(2)) );
>>    fprint ( ditto, ("Bart", 1.69, "1.3") );
>>    fprint ( "Longmaxint is #.", longmaxint )
>>
>> [prints:
>>
>>    Hello World!  Sqrt 2 is  1.41421, to 5dp
>>    Hello Bart!  Sqrt  1.69000 is 1.3, to 5dp
>>    Longmaxint is 999999999999999999999999999999999999999999.
>
> 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.

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

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.

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

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.

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.

--
Waldek Hebisch

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.

P.S. DEC FORTRAN-IV used the machine stack for subroutine calls and
expressions.

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