I've loads of other messages to get back to but while I think of it I'd
like to post a suggestion for you guys to shoot down in flames. ;-)

The printf approach to printing is flexible and fast at rendering
inbuilt types - probably better than anything which came before it - but
it's not perfect. In particular, it means that the code inside printf
which does the rendering needs to know about all types it may be asked
to render in character form. But there are many other types. E.g. a
programmer could want a print routine to render a boolean, an integer, a
float, a record, a table, a list, a widget, etc.

So here's another potential approach. What do you think of it?

The idea is, as with the printf family, to have a controlling string
where normal characters are copied verbatim and special fields are
marked with a % sign or similar. The difference is what would come after
the % sign and how it would be handled.

What I am thinking of is a format specification something like

%EB;

where "E" is a code which identifies the rendering engine, "B" is the
body of the format and ";" marks the end of the format and a return to
normal printing.

The /mechanical/ difference is that rather than the print function doing
all the formatting itself it would outsource any it didn't know. For
outsourcing, the rendering engine would be sent both the value to be
printed AND a pointer to the format string.

As for where rendering engines could come from:

* Some rendering engines could be inbuilt.
* Some could be specified earlier in the code.
* Some could be supplied in the parameter list (see below).

What would the formats look like? As some examples:

%i; a plain, normal, signed integer
%iu; a plain, normal, unsigned integer
%iu02x; a 2-digit zero-padded unsigned hex integer
%Kabc; a type K unknown to the print function

The latter would need the print function to have been previously told
about a rendering engine for "K". The print function would pass to the
rendering engine the format specification and a pointer to the value.
Finally,

%*abc; a dynamic render

The * would indicate that the address of the rendering engine had been
supplied as a parameter as in

printit("This is %*abc;, OK?", R, v)

where R is the rendering engine and v is the value to be rendered
according to the specification abc.

That's it. It's intended to be convenient, efficient, flexible and about
as simple as possible to use. Whether it achieves that is up for debate.

Thoughts/opinions? Is there a better approach to the formatted printing
of arbitrary types?

--
James Harris

On 27/12/2021 14:01, James Harris wrote:
> I've loads of other messages to get back to but while I think of it I'd
> like to post a suggestion for you guys to shoot down in flames. ;-)
>
> The printf approach to printing is flexible and fast at rendering
> inbuilt types - probably better than anything which came before it - but
> it's not perfect. In particular, it means that the code inside printf
> which does the rendering needs to know about all types it may be asked
> to render in character form. But there are many other types. E.g. a
> programmer could want a print routine to render a boolean, an integer, a
> float, a record, a table, a list, a widget, etc.
>
> So here's another potential approach. What do you think of it?
>
> The idea is, as with the printf family, to have a controlling string
> where normal characters are copied verbatim and special fields are
> marked with a % sign or similar. The difference is what would come after
> the % sign and how it would be handled.
>
> What I am thinking of is a format specification something like
>
>   %EB;
>
> where "E" is a code which identifies the rendering engine, "B" is the
> body of the format and ";" marks the end of the format and a return to
> normal printing.
>
> The /mechanical/ difference is that rather than the print function doing
> all the formatting itself it would outsource any it didn't know. For
> outsourcing, the rendering engine would be sent both the value to be
> printed AND a pointer to the format string.
>
> As for where rendering engines could come from:
>
> * Some rendering engines could be inbuilt.
> * Some could be specified earlier in the code.
> * Some could be supplied in the parameter list (see below).
>
> What would the formats look like? As some examples:
>
>   %i;      a plain, normal, signed integer
>   %iu;     a plain, normal, unsigned integer
>   %iu02x;  a 2-digit zero-padded unsigned hex integer
>   %Kabc;   a type K unknown to the print function
>
> The latter would need the print function to have been previously told
> about a rendering engine for "K". The print function would pass to the
> rendering engine the format specification and a pointer to the value.
> Finally,
>
>   %*abc;   a dynamic render
>
> The * would indicate that the address of the rendering engine had been
> supplied as a parameter as in
>
>   printit("This is %*abc;, OK?", R, v)
>
> where R is the rendering engine and v is the value to be rendered
> according to the specification abc.
>
> That's it. It's intended to be convenient, efficient, flexible and about
> as simple as possible to use. Whether it achieves that is up for debate.

Look at that last example. You have to give it three things other than
the surrounding context: v, R and *abc.

At the simplest, you want to do it with just v. Then:

* It will apply the renderer previously associated with that user-type

* If it there isn't one, it will use a default rendering for that
generic type (array, struct etc)

* Or it can say it doesn't know how to do it, or just prints a reference
to v

Next simplest is when you specify some parameters to control the
formatting. How these work depends on what it does above.

Supplying a rendere each time you print I would say is not the simplest
way of doing it! If you're going to do that, you might as well do:

printit("This is %s; OK?", R(v,"abc"))

Then no special features are needed. Except that if R returns a string,
then you need some means of disposing of that string after printing, but
there are several ways of dealing with that.

> %i; a plain, normal, signed integer
> %iu; a plain, normal, unsigned integer
> %iu02x; a 2-digit zero-padded unsigned hex integer
> %Kabc; a type K unknown to the print function

This is too C-like. C-style formats have all sorts of problems
associated with hard-coding a type-code into a format string:

* What is the code for arbitrary expression X?
* What will it be when X changes, or the type of the terms change?
* What is it for clock_t, or some other semi-opaque type?
* What is it for uint64_t? (Apparently, it is PRId64 - a macro that
expands to a string)

If your Print function is implemented as a regular user-code function,
which your language knows nothing about, then you will need some scheme
which imparts type information to the function, as well as a way of
dealing with such variadic parameter lists.

But if it does, which would be a more modern way of doing so, then the
compiler already knows the types involved. Then the formatting is about
the display, so for an integer:

* Perhaps override signed to unsigned
* Plus sign
* Width
* Justification
* Zero-padding (and padding character)
* Base
* Separators (and grouping)
* Prefix and/or suffix
* Upper/lower case (digits A-F)

Or maybe, this number represents certain quanties (eg. a day of the
week), which will need displaying in a special way. If you're not using
a special type for that, then here it will need a way to override that,
perhaps using an R() function.

You should also look at how the current crop of languages do it. They
are also still tend to use format strings, and some like to put the
expressions to be printed inside the format string.

-----------

(My approach in dynamic code is that there is an internal function
tostr(), fully overloaded for different types, with optional format
data, that is applied to Print items. So that:

print a, b, c:"h" # last bit means hex

is the same as:

print tostr(a), tostr(b), tostr(c, "h")

There is a crude override mechanism, which links 'tostr' and a type T,
to a regular user-code function F.

Then, when printing T, it will call F().

In static code, this part is poorly developed. But Print (which is again
known to the language as it is a statement), can deal with regular
types, including most of those options for integers:

print a:"z 8 h s_" # leading zeros, 8-char field, hex, "_"
separator

)

On 27/12/2021 15:49, Bart wrote:
> On 27/12/2021 14:01, James Harris wrote:

....

>> What would the formats look like? As some examples:
>>
>>    %i;      a plain, normal, signed integer
>>    %iu;     a plain, normal, unsigned integer
>>    %iu02x;  a 2-digit zero-padded unsigned hex integer
>>    %Kabc;   a type K unknown to the print function

....

>>    %*abc;   a dynamic render
>>
>> The * would indicate that the address of the rendering engine had been
>> supplied as a parameter as in
>>
>>    printit("This is %*abc;, OK?", R, v)
>>
>> where R is the rendering engine and v is the value to be rendered
>> according to the specification abc.

....

> Look at that last example. You have to give it three things other than
> the surrounding context: v, R and *abc.

Yes, though this is for /formatted/ output so that's not surprising. And
the last example was in many ways the worst-case scenario.

>
> At the simplest, you want to do it with just v. Then:
>
> * It will apply the renderer previously associated with that user-type
>
> * If it there isn't one, it will use a default rendering for that
>   generic type (array, struct etc)
>
> * Or it can say it doesn't know how to do it, or just prints a reference
>   to v
>
> Next simplest is when you specify some parameters to control the
> formatting. How these work depends on what it does above.
>
> Supplying a rendere each time you print I would say is not the simplest
> way of doing it! If you're going to do that, you might as well do:
>
>    printit("This is %s; OK?", R(v,"abc"))
>
> Then no special features are needed. Except that if R returns a string,
> then you need some means of disposing of that string after printing, but
> there are several ways of dealing with that.

Dealing with memory is indeed a problem with that approach. The %s could
be passed a string which needs to be freed or one which must not be
freed. One option is

%s - a string which must not be freed
%M - a string which must be freed

>
> >    %i;      a plain, normal, signed integer
> >    %iu;     a plain, normal, unsigned integer
> >    %iu02x;  a 2-digit zero-padded unsigned hex integer
> >    %Kabc;   a type K unknown to the print function
>
> This is too C-like. C-style formats have all sorts of problems
> associated with hard-coding a type-code into a format string:
>
>   * What is the code for arbitrary expression X?

It would have to be something to match the type of X.

>   * What will it be when X changes, or the type of the terms change?

The format string would need to be changed to reflect the type change.

>   * What is it for clock_t, or some other semi-opaque type?

Perhaps %sdhh:mm:ss.fff; where d indicates datetime.

>   * What is it for uint64_t? (Apparently, it is PRId64 - a macro that
>     expands to a string)

How about %u; with the renderer being told the width of the type? Or
%u64; with the renderer not needing to know the width of the type?

Or with comma digit separators every 3 places

%u64:s,:3;

Meaning unsigned 64, separator "," every 3 places.

I'm not too worried about the specific format codes. Someone must have
already come up with a set of them which could be used. The main thing
is that any format code would be understood by the programmer and by the
formatter and that it would be clear to everyone where the format code
ended.

That said, it would make sense for the elements of the format string to
appear in some sort of logical order - possibly the order in which they
would be needed by the renderer.

>
> If your Print function is implemented as a regular user-code function,
> which your language knows nothing about, then you will need some scheme
> which imparts type information to the function, as well as a way of
> dealing with such variadic parameter lists.

Agreed.

>
> But if it does, which would be a more modern way of doing so, then the
> compiler already knows the types involved. Then the formatting is about
> the display, so for an integer:
>
>   * Perhaps override signed to unsigned
>   * Plus sign
>   * Width
>   * Justification
>   * Zero-padding (and padding character)
>   * Base
>   * Separators (and grouping)
>   * Prefix and/or suffix
>   * Upper/lower case (digits A-F)

It's a good list. It's amazing how many of those choices printf hits in
a short space.

>
> Or maybe, this number represents certain quanties (eg. a day of the
> week), which will need displaying in a special way. If you're not using
> a special type for that, then here it will need a way to override that,
> perhaps using an R() function.

OK.

>
> You should also look at how the current crop of languages do it. They
> are also still tend to use format strings, and some like to put the
> expressions to be printed inside the format string.

Maybe unfairly I have an antipathy to copying other languages but maybe
in this case it would be useful. Are there any you would recommend?

Incidentally, my real goal is to have the ability to output in a
self-describing 'binary stream' format rather than necessarily
converting to text but that's a subject in itself and would require
external support. Text will have to do for now!

>
> -----------
>
> (My approach in dynamic code is that there is an internal function
> tostr(), fully overloaded for different types, with optional format
> data, that is applied to Print items. So that:
>
>    print a, b, c:"h"              # last bit means hex
>
> is the same as:
>
>    print tostr(a), tostr(b), tostr(c, "h")

Maybe that's better: the ability to specify custom formatting on any
argument. I presume that's not just available for printing, e.g. you
could write

string s := c:"h"

and that where you have "h" you could have an arbitrarily complex format
specification.

There looks to be a potential issue, though. In C one can build up the
control string at run time. Could you do that with such as

string fmt := format_string(....)
s := c:(fmt)

?

>
> There is a crude override mechanism, which links 'tostr' and a type T,
> to a regular user-code function F.
>
> Then, when printing T, it will call F().
>
> In static code, this part is poorly developed. But Print (which is again
> known to the language as it is a statement), can deal with regular
> types, including most of those options for integers:
>
>
>     print a:"z 8 h s_"     # leading zeros, 8-char field, hex, "_"
> separator
>
> )

That's the spirit! ;-)

--
James Harris

On 27/12/2021 17:26, James Harris wrote:
> On 27/12/2021 15:49, Bart wrote:

>>     printit("This is %s; OK?", R(v,"abc"))
>>
>> Then no special features are needed. Except that if R returns a
>> string, then you need some means of disposing of that string after
>> printing, but there are several ways of dealing with that.
>
> Dealing with memory is indeed a problem with that approach. The %s could
> be passed a string which needs to be freed or one which must not be
> freed. One option is
>
>   %s - a string which must not be freed
>   %M - a string which must be freed

This has similar problems to hardcoding a type. Take this:

printit("%s", F())

F returns a string, but is it one that needs freeing or not? That's
depends on what happens inside F. Whatever you choose, later the
implementation of F changes, then 100 formats have to change too?

This is a more general problem of memory-managing strings. It's more
useful to be able to solve it for the language, then it will work for
Print too.

(Personally, I don't get involved with this at all, not in low level code.

Functions that return strings generally return a pointer to a local
static string that needs to be consumed ASAP. Or sometimes there is a
circular list of them to allow several such calls per Print. It's not
very sophisticated, but that's why the language is low level.)

If you want a more rigorous approach, perhaps try this:

printit("%H", R(v, "abc"))

H means handler. R() is not the handler itself, but returns a descriptor
(eg. X) the contains a reference to a handler function, and references
to those two captured values (a little like a lambda or closure I think).

The Print handler then calls X() with a parameter to request the value.
And can call it again with another parameter to free it. Or perhaps it
can be used to iterate over the characters, or sets of strings.

The latter might be more suitable when you have a 1-billion element
array to print (eg. to a file), and you don't want or need to generate
one giant string in one go.

But this starts to get into generators and iterators. Perhaps it is a
too advanced approach if your language is anything like mine.

>>
>>  >    %i;      a plain, normal, signed integer
>>  >    %iu;     a plain, normal, unsigned integer
>>  >    %iu02x;  a 2-digit zero-padded unsigned hex integer
>>  >    %Kabc;   a type K unknown to the print function
>>
>> This is too C-like. C-style formats have all sorts of problems
>> associated with hard-coding a type-code into a format string:
>>
>>    * What is the code for arbitrary expression X?
>
> It would have to be something to match the type of X.
>
>>    * What will it be when X changes, or the type of the terms change?
>
> The format string would need to be changed to reflect the type change.
>
>>    * What is it for clock_t, or some other semi-opaque type?
>
> Perhaps %sdhh:mm:ss.fff; where d indicates datetime.

The problem with doing it in C is that clock_t could be u32, u64, i32,
i64 or even a float type; what number format to use? It's not a string
anyway; you can turn it into one, but then that's my DOW example.

>>    * What is it for uint64_t? (Apparently, it is PRId64 - a macro that
>>      expands to a string)

Again this is for C; the problem being that a format string should not
need to include type information:

* The compiler knows the type
* You may not know the type (eg. clock_t)
* You may not know the format needed (eg. uint64_t)
* You don't want to have to maintain 1000 format strings as
expressions and types of variables change

> That said, it would make sense for the elements of the format string to
> appear in some sort of logical order - possibly the order in which they
> would be needed by the renderer.

But then somebody has to remember them! I ensure the order doesn't matter.

> Maybe unfairly I have an antipathy to copying other languages but maybe
> in this case it would be useful. Are there any you would recommend?

I have the same approach to other languages. Generally I find their
print schemes over-elaborate, so tend to do my own thing. Yet they also
have to solve the same problems.

>> (My approach in dynamic code is that there is an internal function
>> tostr(), fully overloaded for different types, with optional format
>> data, that is applied to Print items. So that:
>>
>>     print a, b, c:"h"              # last bit means hex
>>
>> is the same as:
>>
>>     print tostr(a), tostr(b), tostr(c, "h")
>
> Maybe that's better: the ability to specify custom formatting on any
> argument. I presume that's not just available for printing, e.g. you
> could write
>
>   string s := c:"h"
>
> and that where you have "h" you could have an arbitrarily complex format
> specification.

Well, ":" is specifically used in print-item lists (elsewhere it creates
key:value pairs). I would write your example in dynamic code as one of:

s := sprint(c:"h") # sprint is special, like print
s := tostr(c,"h") # tostr is a function-like operator

(sprint can turn a list of items into one string; tostr does one at a
time, although that one item can be arbitrarily complex.)

In my cruder static code, it might be:

[100]char str
print @str, c:"h"

> There looks to be a potential issue, though. In C one can build up the
> control string at run time. Could you do that with such as
>
>   string fmt := format_string(....)
>   s := c:(fmt)
>
> ?

Sure, what comes after ":" is just any string expression:

ichar fmt = (option=1 "Hs_" | "s,")

print 123456:fmt # displays 1_E240 or 123,456

(Separator grouping is 3 digits decimal; 4 digits hex/binary.)

I've exercised my print formatting recently and found some weak areas,
to do with tabulation. Getting things lined up in columns is tricky,
especially with a header.

I do have formatted print which looks like this:

fprint "#(#, #) = #", fnname, a, b, result

If I want field widths, they are written as:

fprint "#: # #", a:w1, b:w2, c:w3

where w1/w2/w2 are "12" etc. Here, the first problem is a disconnect
between each #, and the corresponding print item. This is why some
languages bring them inside.

But the main thing here is that I don't get a sense of what it looks
like until I run the program. Something I've seen in the past would look
a bit like:

fprint "###: ####### #############", a, b, c

The widths are the number of # characters. That same string could be
used for headings:

const format = "###: ####### #############"

fprint format, "No.", "Barcode", "Description"
....
fprint format, i, item[i].code, item[i].descr

I haven't implemented this, it's just an idea. This an actual example of
the kind of output I'm talking about, but done the hard way by trial and
error:

Type Seg Offset Symbol/Target+Offset
-------------------------------------------------------
1: imprel32 code 00000024 MessageBoxA
2: locabs64 code 00000015 idata 02E570B0
3: locabs64 code 0000000B idata 02E570B6

On 27/12/2021 14:01, James Harris wrote:
> The printf approach to printing is flexible and fast at rendering
> inbuilt types - probably better than anything which came before it -
> but it's not perfect.

No, it's rubbish. If you need formatted transput [not
entirely convinced, but chacun a son gout], then instead of all
the special casing, the easiest and most flexible way is to
convert everything to strings. Thus, for each type, you need
an operator that converts values of that type into strings [and
vv for reading]. You can incorporate formatting details [such
as whether decimal points are "," or ".", whether leading zeros
are suppressed, etc., etc] into the operator, or as parameters
to a suitable procedure call. Such operators are separately
useful, eg for sorting. The default operator could, eg, be one
that converts [eg] an integer into the shortest possible string.
That way, the actual transput routines need to know almost
nothing about the types and formatting details of this parameters,
only how to write/read an array of characters.

[...]
> So here's another potential approach. What do you think of it?
> The idea is, as with the printf family, to have a controlling string
> where normal characters are copied verbatim and special fields are
> marked with a % sign or similar. The difference is what would come
> after the % sign and how it would be handled.

Then what you've done is to use "%" where you should
instead simply be including a string. So the specification of
"printf" becomes either absurdly complicated [as indeed it is
in most languages] or too limited [because some plausible
conversions are not catered for]. The "everything is a string"
approach has the advantage that for specialised use, eg if you
want to read/write your numbers as Roman numerals, you just have
to write the conversion routines that you would need anyway, no
need to change anything in "printf".

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

On 2021-12-27 23:02, Andy Walker wrote:
> On 27/12/2021 14:01, James Harris wrote:
>> The printf approach to printing is flexible and fast at rendering
>> inbuilt types - probably better than anything which came before it -
>> but it's not perfect.
>
>     No, it's rubbish.

Patently obvious rubbish, rather.

> then instead of all
> the special casing, the easiest and most flexible way is to
> convert everything to strings.

Sure, though, usually not everything is converted to string. For
example, formatting symbols or extensions of the idea: meta/tagged
formats like HTML, XML etc are inherently bad.

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.

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

On 27/12/2021 22:02, Andy Walker wrote:
> On 27/12/2021 14:01, James Harris wrote:
>> The printf approach to printing is flexible and fast at rendering
>> inbuilt types - probably better than anything which came before it -
>> but it's not perfect.
>
>     No, it's rubbish.  If you need formatted transput [not
> entirely convinced, but chacun a son gout],

If you are not convinced by formatted io then what kind of io do you
prefer?

> then instead of all
> the special casing, the easiest and most flexible way is to
> convert everything to strings.

If you convert to strings then what reclaims the memory used by those
strings? Not all languages have dynamic memory management, and dynamic
memory management is not ideal for all compilation targets.

The form I proposed had no need for dynamic allocations. That's part of
the point of it.

> Thus, for each type, you need
> an operator that converts values of that type into strings [and
> vv for reading].

Yes, there's a converse (and in some ways even more involved) issue with
reading.

....

>> So here's another potential approach. What do you think of it?
>> The idea is, as with the printf family, to have a controlling string
>> where normal characters are copied verbatim and special fields are
>> marked with a % sign or similar. The difference is what would come
>> after the % sign and how it would be handled.
>
>     Then what you've done is to use "%" where you should
> instead simply be including a string.  So the specification of
> "printf" becomes either absurdly complicated [as indeed it is
> in most languages] or too limited [because some plausible
> conversions are not catered for].  The "everything is a string"
> approach has the advantage that for specialised use, eg if you
> want to read/write your numbers as Roman numerals, you just have
> to write the conversion routines that you would need anyway, no
> need to change anything in "printf".
>

I'm not sure you understand the proposal. To be clear, the print routine
would be akin to

print("String with %kffff; included", val)

where the code k would be used to select a formatter. The formatter
would be passed two things:

1. The format from k to ; inclusive.
2. The value val.

As a result, the format ffff could be as simple as someone could design it.

Note that there would be no requirement for dynamic memory. The
formatter would just send for printing each character as it was generated.

What's wrong with that? (Genuine question!)

--
James Harris

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?

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

----------
If that were relevant in the case of formatted output, which has a
massive overhead, so that even when using the heap (which is no way
necessary) it would leave a little or no dent. I remember a SysV C
compiler which modified the format string of printf in a misguided
attempt to save a little bit memory, while the linker put string
constants in the read-only memory...

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

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.

No heap storage is involved.

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

If memory is allocated for the temporary object, then at some point it
needs to be reclaimed. Preferably just after the print operation is
completed.

If your language takes care of those details, then lucky you. It means
someone else has had the job of making it work.

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.

>>> 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.
>
> If memory is allocated for the temporary object, then at some point it
> needs to be reclaimed. Preferably just after the print operation is
> completed.

Yep.

> If your language takes care of those details, then lucky you. It means
> someone else has had the job of making it work.

Sure.

Evey *normal* language takes care of the objects it creates. And every
*normal* language lets identityless objects (like integers, strings,
records etc) be created ad-hoc and passed around in a unified manner.

If this

Put_Line ("X=" & X'Image & ", Y=" & Y'Image);

is a problem in your language, then the job is not done.

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

On 27/12/2021 19:05, Bart wrote:
> On 27/12/2021 17:26, James Harris wrote:
>> On 27/12/2021 15:49, Bart wrote:
>
>>>     printit("This is %s; OK?", R(v,"abc"))
>>>
>>> Then no special features are needed. Except that if R returns a
>>> string, then you need some means of disposing of that string after
>>> printing, but there are several ways of dealing with that.
>>
>> Dealing with memory is indeed a problem with that approach. The %s
>> could be passed a string which needs to be freed or one which must not
>> be freed. One option is
>>
>>    %s - a string which must not be freed
>>    %M - a string which must be freed
>
> This has similar problems to hardcoding a type. Take this:
>
>     printit("%s", F())
>
> F returns a string, but is it one that needs freeing or not? That's
> depends on what happens inside F. Whatever you choose, later the
> implementation of F changes, then 100 formats have to change too?

I guess that every piece of code which called F() would have to change
whether printit was involved or not. But I take your point.

Note that my suggestion (of passing to a formatter the format and the
value) would not require dynamic memory management.

>
> This is a more general problem of memory-managing strings. It's more
> useful to be able to solve it for the language, then it will work for
> Print too.

Agreed.

>
> (Personally, I don't get involved with this at all, not in low level code.
>
> Functions that return strings generally return a pointer to a local
> static string that needs to be consumed ASAP. Or sometimes there is a
> circular list of them to allow several such calls per Print. It's not
> very sophisticated, but that's why the language is low level.)
>
> If you want a more rigorous approach, perhaps try this:
>
>    printit("%H", R(v, "abc"))
>
> H means handler. R() is not the handler itself, but returns a descriptor
> (eg. X) the contains a reference to a handler function, and references
> to those two captured values (a little like a lambda or closure I think).

AFAICS

R(v, "abc")

would be called before invoking printit. IOW wouldn't the delayed call
of a lambda require a distinct syntax?

....

>>>    * What is it for uint64_t? (Apparently, it is PRId64 - a macro that
>>>      expands to a string)
>
> Again this is for C; the problem being that a format string should not
> need to include type information:
>
>   * The compiler knows the type
>   * You may not know the type (eg. clock_t)
>   * You may not know the format needed (eg. uint64_t)
>   * You don't want to have to maintain 1000 format strings as
>     expressions and types of variables change

OK. If the compiler knows the type T why not have the print function invoke

T.format

with the value and the format string as parameters?

....

> I've exercised my print formatting recently and found some weak areas,
> to do with tabulation. Getting things lined up in columns is tricky,
> especially with a header.
>
> I do have formatted print which looks like this:
>
>    fprint  "#(#, #) = #", fnname, a, b, result
>
> If I want field widths, they are written as:
>
>    fprint "#: # #", a:w1, b:w2, c:w3
>
> where w1/w2/w2 are "12" etc. Here, the first problem is a disconnect
> between each #, and the corresponding print item. This is why some
> languages bring them inside.
>
> But the main thing here is that I don't get a sense of what it looks
> like until I run the program. Something I've seen in the past would look
> a bit like:
>
>    fprint "###:  ####### #############", a, b, c
>
> The widths are the number of # characters. That same string could be
> used for headings:
>
>    const format = "###:  ####### #############"
>
>    fprint format, "No.", "Barcode", "Description"
>    ....
>    fprint format, i, item[i].code, item[i].descr
>
> I haven't implemented this, it's just an idea. This an actual example of
> the kind of output I'm talking about, but done the hard way by trial and
> error:
>
>      Type       Seg      Offset    Symbol/Target+Offset
> -------------------------------------------------------
>   1: imprel32   code     00000024  MessageBoxA
>   2: locabs64   code     00000015  idata 02E570B0
>   3: locabs64   code     0000000B  idata 02E570B6

Perhaps one option is record-based output something akin to

tout.putrec(R, i, item[i].code, item[i].descr)

where tout is terminal out, R is a record format, and the values are
output in binary. The downside is that that would not be plain text and
would require support so that it could be viewed but the upsides would
include allowing the viewer to resize and reorder tables. (The headings
would be metadata; the user could choose whether to see them or not.)

--
James Harris

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. So such a call involved writing
the expression to a static location, and passing a reference to that
location.

The problem here is that you call a function F which returns a string to
be passed to Peint, which may be a literal, or in static memory, or has
a shared reference with other objects, none of which require the memory
to be reclaimed.

Or it may have been created specially for this return value, so then
after use (it's been printed), any resources need to be reclaimed.

Your approach to 'solve' this is to 'just' create a language high enough
is level (and harder to write and slower to run), to get around it.

Which actually doesn't solve it; you've just turned a small job into a
huge one.

More interesting is this: /given/ a language design low enough in level
that it doesn't have first class strings with automatic memory
management, how would you implement the printing of complex objects
requiring elaborate 'to-string' conversions.

> Evey *normal* language takes care of the objects it creates. And every
> *normal* language lets identityless objects (like integers, strings,
> records etc) be created ad-hoc and passed around in a unified manner.
>
> If this
>
>    Put_Line ("X=" & X'Image & ", Y=" & Y'Image);
>
> is a problem in your language, then the job is not done.

My static language is of the lower-level kind described above, yet this
example is merely:

println =X, =Y

You really want a more challenging example.

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?

Not the print function. See below.

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

I disagree slightly with both of you. AISI it doesn't matter whether the
objects to be printed are integers or structures or arrays or widgets.
If there's any reclaiming to be done then it would be carried out by
other language mechanisms which would happen anyway; it would not be
required by the print function. The print function would simply use
them. In reclamation terms it would neither increase nor decrease any
reference count.

For example,

complex c
function F
widget w
....
print(w, c)
endfunction

Widget w would be created at function entry and reclaimed at function
exit. The global c would be created at program load time and destroyed
when the program terminates. The print function would not get involved
in any of that stuff.

....

> 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! ;-)

--
James Harris

On 28/12/2021 09:21, Dmitry A. Kazakov wrote:
> On 2021-12-27 23:02, Andy Walker wrote:

....

>> then instead of all
>> the special casing, the easiest and most flexible way is to
>> convert everything to strings.
>
> Sure, though, usually not everything is converted to string. For
> example, formatting symbols or extensions of the idea: meta/tagged
> formats like HTML, XML etc are inherently bad.
>
> 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?

--
James Harris

On 2022-01-02 19:05, James Harris wrote:
> On 28/12/2021 09:21, Dmitry A. Kazakov wrote:
>> On 2021-12-27 23:02, Andy Walker wrote:
>
> ...
>
>>> then instead of all
>>> the special casing, the easiest and most flexible way is to
>>> convert everything to strings.
>>
>> Sure, though, usually not everything is converted to string. For
>> example, formatting symbols or extensions of the idea: meta/tagged
>> formats like HTML, XML etc are inherently bad.
>>
>> 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.

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

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?

>> If this
>>
>>     Put_Line ("X=" & X'Image & ", Y=" & Y'Image);
>>
>> is a problem in your language, then the job is not done.
>
> My static language is of the lower-level kind described above, yet this
> example is merely:
>
>   println =X, =Y

No it is not. The example creates temporary strings, which possibility
stunned James and you as something absolutely unthinkable, or requiring
heap, which is rubbish and pretty normal in any decent language.

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

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.

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

On 02/01/2022 18:30, Dmitry A. Kazakov 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?
>
>>> If this
>>>
>>>     Put_Line ("X=" & X'Image & ", Y=" & Y'Image);
>>>
>>> is a problem in your language, then the job is not done.
>>
>> My static language is of the lower-level kind described above, yet
>> this example is merely:
>>
>>    println =X, =Y
>
> No it is not. The example creates temporary strings, which possibility
> stunned James and you as something absolutely unthinkable, or requiring
> heap, which is rubbish and pretty normal in any decent language.

Well, your example wasn't easy to scan.

But since you say it requires temporary strings, where does it put them?
They have to go somewhere!

On the stack? The stack is typically 1-4MB; what if the strings are
bigger? What if some of the terms are strings returned from a function;
those will not be on the stack. Example:

println "(" + tostr(123456)*1'000'000 + ")"

this creates an intermediate string of 6MB; too big for a stack.

On 02/01/2022 17:54, James Harris 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?
>
> Not the print function. See below.
>
>>>
>>> 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.
>
> I disagree slightly with both of you. AISI it doesn't matter whether the
> objects to be printed are integers or structures or arrays or widgets.
> If there's any reclaiming to be done then it would be carried out by
> other language mechanisms which would happen anyway; it would not be
> required by the print function. The print function would simply use
> them. In reclamation terms it would neither increase nor decrease any
> reference count.
>
> For example,
>
>   complex c
>   function F
>     widget w
>     ....
>     print(w, c)
>   endfunction
>
> Widget w would be created at function entry and reclaimed at function
> exit. The global c would be created at program load time and destroyed
> when the program terminates. The print function would not get involved
> in any of that stuff.

This is not the issue that had been discussed. Printing an existing
string is no problem; even C can deal with that: you just use
printf("%s", S).

If you are printing a string returned from F(), then any requirement to
reclaim resources it might use is common to any use of it within the
language, and not specific to Print.

The problem is when the string in question has been created directly or
indirectly (explicitly by a function call or implicitly by calling some
handler) within the argument list of the Print function or statement,
and you want any memory allocated specifically for this purpose to be
taken care of automatically.

On 2022-01-02 19:51, Bart wrote:

> But since you say it requires temporary strings, where does it put them?
> They have to go somewhere!
>
> On the stack?

The stack is as big as you specify, it is not the program stack, normally.

The stack is typically 1-4MB; what if the strings are
> bigger? What if some of the terms are strings returned from a function;
> those will not be on the stack. Example:
>
>    println  "(" + tostr(123456)*1'000'000 + ")"
>
> this creates an intermediate string of 6MB; too big for a stack.

Are you going to spill 6MB character long single line on a terminal
emulator? Be realistic.

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

On 02/01/2022 19:23, Dmitry A. Kazakov wrote:
> On 2022-01-02 19:51, Bart wrote:
>
>> But since you say it requires temporary strings, where does it put
>> them? They have to go somewhere!
>>
>> On the stack?
>
> The stack is as big as you specify, it is not the program stack, normally.

So, what are you going to, have a stack which is 1000 times bigger than
normal just in case?

Anyway, if the string is returned from a function, it is almost
certainly on the heap.

>  The stack is typically 1-4MB; what if the strings are
>> bigger? What if some of the terms are strings returned from a
>> function; those will not be on the stack. Example:
>>
>>     println  "(" + tostr(123456)*1'000'000 + ")"
>>
>> this creates an intermediate string of 6MB; too big for a stack.
>
> Are you going to spill 6MB character long single line on a terminal
> emulator? Be realistic.

Who knows what a user-program will do? And who are you to question it?

Besides the print output could redirected to a file, or be piped, or it
could be writing a file anyway.

It could also be on multiple lines if you want:

println "(" + (tostr(123456)+"\n")*1'000'000 + ")"

It depends on contents of the string data the user wants to output,
which as I said could be anything and of any size:

println reverse(readstrfile(filename))

On 2022-01-02 20:42, Bart wrote:
> On 02/01/2022 19:23, Dmitry A. Kazakov wrote:
>> On 2022-01-02 19:51, Bart wrote:
>>
>>> But since you say it requires temporary strings, where does it put
>>> them? They have to go somewhere!
>>>
>>> On the stack?
>>
>> The stack is as big as you specify, it is not the program stack,
>> normally.
>
> So, what are you going to, have a stack which is 1000 times bigger than
> normal just in case?

No, I will never ever print anything that does not fit into a page of
72-80 characters wide.

BTW formatting output is meant to format, which includes text wrapping,
you know.

> Anyway, if the string is returned from a function, it is almost
> certainly on the heap.

No, it is certainly on the secondary stack.

>> Are you going to spill 6MB character long single line on a terminal
>> emulator? Be realistic.
>
> Who knows what a user-program will do?

The developer:

https://spec.cs.miami.edu/cpu2017/flags/gcc.2021-07-21.html#user_Wl-stack

> It could also be on multiple lines if you want:

Now it is time to learn about cycles.

> It depends on contents of the string data the user wants to output,
> which as I said could be anything and of any size:
>
>     println reverse(readstrfile(filename))

It could even be fetching whole git repository tree of the Linux kernel...

1. Why would anybody ever do that?

2. Why would anybody program it in such a stupid way?

Which boils down to the requirements of the application program and its
behavior upon broken input constraints from these requirements.

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

On 02/01/2022 20:25, Dmitry A. Kazakov wrote:
> On 2022-01-02 20:42, Bart wrote:
>> On 02/01/2022 19:23, Dmitry A. Kazakov wrote:
>>> On 2022-01-02 19:51, Bart wrote:
>>>
>>>> But since you say it requires temporary strings, where does it put
>>>> them? They have to go somewhere!
>>>>
>>>> On the stack?
>>>
>>> The stack is as big as you specify, it is not the program stack,
>>> normally.
>>
>> So, what are you going to, have a stack which is 1000 times bigger
>> than normal just in case?
>
> No, I will never ever print anything that does not fit into a page of
> 72-80 characters wide.

You're not even going to allow anything that might spill over multiple
lines? Say, displaying factorial(1000); apparently in your language,
there is no way to see what it looks like.

> BTW formatting output is meant to format, which includes text wrapping,
> you know.
>
>> Anyway, if the string is returned from a function, it is almost
>> certainly on the heap.
>
> No, it is certainly on the secondary stack.

You'll have to explain what a secondary stack is.

>>> Are you going to spill 6MB character long single line on a terminal
>>> emulator? Be realistic.
>>
>> Who knows what a user-program will do?
>
> The developer:
>
> https://spec.cs.miami.edu/cpu2017/flags/gcc.2021-07-21.html#user_Wl-stack

If your program needs to ROUTINELY increase the stack size, then it is
probably broken. You should only need to for some highly-recursive
programs such as the Ackermann benchmark. Not for ordinary Print!

>> It could also be on multiple lines if you want:
>
> Now it is time to learn about cycles.
>
>> It depends on contents of the string data the user wants to output,
>> which as I said could be anything and of any size:
>>
>>      println reverse(readstrfile(filename))
>
> It could even be fetching whole git repository tree of the Linux kernel...

Yes, why not? I think that is exactly what I did once:

dir/s >files # create a large text file
type files # display a large text file

So large files are OK in some circumstances, but not as an argument to
Print?

> 1. Why would anybody ever do that?
>
> 2. Why would anybody program it in such a stupid way?

Somebody does this:

println dirlist("*.c")

The output could be anything from 10 characters to 100,000 or more. (And
yes, the default routine to print a list of strings could write one per
line.)

Language implementers shouldn't place unreasonable restrictions on what
user code can do, because of some irrational aversion to using heap memory.

There might be 4MB of stack memory and 4000MB of heap memory, so why not
use it!

The issues however are with lower-level languages and what can be done
there. Using stack memory is not really practical there either.

Some approaches which don't involve creating discrete string objects I
think have been discussed. But there are also myriad workarounds to get
things done, even if not elegant.

>
> Which boils down to the requirements of the application program and its
> behavior upon broken input constraints from these requirements.

Nothing is broken. Any lack of first string handling and automatic
memory management is by design in some languages. But you are never
going to be stuck getting anything printed, it might just take extra effort.

On 2022-01-02 23:31, Bart wrote:
> On 02/01/2022 20:25, Dmitry A. Kazakov wrote:
>> On 2022-01-02 20:42, Bart wrote:
>>> On 02/01/2022 19:23, Dmitry A. Kazakov wrote:
>>>> On 2022-01-02 19:51, Bart wrote:
>>>>
>>>>> But since you say it requires temporary strings, where does it put
>>>>> them? They have to go somewhere!
>>>>>
>>>>> On the stack?
>>>>
>>>> The stack is as big as you specify, it is not the program stack,
>>>> normally.
>>>
>>> So, what are you going to, have a stack which is 1000 times bigger
>>> than normal just in case?
>>
>> No, I will never ever print anything that does not fit into a page of
>> 72-80 characters wide.
>
> You're not even going to allow anything that might spill over multiple
> lines?

No.

> Say, displaying factorial(1000);

Displaying it to who?

>> BTW formatting output is meant to format, which includes text
>> wrapping, you know.
>>
>>> Anyway, if the string is returned from a function, it is almost
>>> certainly on the heap.
>>
>> No, it is certainly on the secondary stack.
>
> You'll have to explain what a secondary stack is.

Secondary stacks are used to pass large and dynamically sized objects.
They are also used to allocate local objects of these properties.

Secondary stacks are not machine stacks and have no limitations of.

>>>> Are you going to spill 6MB character long single line on a terminal
>>>> emulator? Be realistic.
>>>
>>> Who knows what a user-program will do?
>>
>> The developer:
>>
>> https://spec.cs.miami.edu/cpu2017/flags/gcc.2021-07-21.html#user_Wl-stack
>
> If your program needs to ROUTINELY increase the stack size, then it is
> probably broken.

Right, except that it is your program that tries to create 6MB strings
for no reason.

> So large files are OK in some circumstances, but not as an argument to
> Print?

Exactly.

>> 1. Why would anybody ever do that?
>>
>> 2. Why would anybody program it in such a stupid way?
>
> Somebody does this:
>
>    println dirlist("*.c")

Nobody prints file lists this way. Hint: formatted output presumes
formatting:

https://www.merriam-webster.com/dictionary/format

> The output could be anything from 10 characters to 100,000 or more. (And
> yes, the default routine to print a list of strings could write one per
> line.)

Wrong. For printing lists of files, if anybody cares, there will be a
subprogram with parameters:

- Files path / array of paths
- Wildcard/pattern use flag
- Number of columns
- Output direction: column first vs row first
- First line decorator text
- Consequent lines decorator text
- Filter object
- Sorting order object

etc.

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

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

> Right, except that it is your program that tries to create 6MB strings
> for no reason.

No; my user does so. I can't control what they write.

Should I impose an arbitrary limit like max 80 characters per any print
item, and max 80 characters in total for all items on one print
statement? (But then multiple print statements can write to the same line.)

I'm not implementing Fortran or writing to a line-printer, and my
language copes fine with no such limits. If the user does something
silly, they will find out when it gets slow or they run out of memory.

However, my (higher level) implementation uses managed strings that work
with the heap.

I think (since I've sort of lost track of what we were arguing about)
you were advocating stack storage. And talking about a secondary stack,
which is presumably allocated on the heap.

>> So large files are OK in some circumstances, but not as an argument to
>> Print?
>
> Exactly.
>
>>> 1. Why would anybody ever do that?
>>>
>>> 2. Why would anybody program it in such a stupid way?
>>
>> Somebody does this:
>>
>>     println dirlist("*.c")
>
> Nobody prints file lists this way.

Actually, it's just a list. Should a language allow you to print a whole
list? If not, why not? If you need more control, do it element by
element. Or the format control codes that are optional for every print
item can specify some basic parameters, eg. print one element per line.

My higher-level language still builds a single string for each print
item before it does anything else with it.

Sometimes, that is necessary (eg. the result may be right-justified
within a given field width, so it needs to know the final size);
sometimes it isn't, and it is better to send each successive character
into some destination, but I don't have that yet.

>> The output could be anything from 10 characters to 100,000 or more.
>> (And yes, the default routine to print a list of strings could write
>> one per line.)
>
> Wrong. For printing lists of files, if anybody cares, there will be a
> subprogram with parameters:
>
> - Files path / array of paths
> - Wildcard/pattern use flag
> - Number of columns
> - Output direction: column first vs row first
> - First line decorator text
> - Consequent lines decorator text
> - Filter object
> - Sorting order object

As I said I've lost track of what we discussing. But I know it wasn't
about how to implement DIR or ls!