On 2022-01-03 12:19, Bart wrote:

> As I said I've lost track of what we discussing.

We were discussing inability to return a string from a function in your
language in a reasonable way.

You argued that there is no need to have it due to danger that some user
might miss his or her medication or confuse that with certain mushrooms
and so came to an idea of creating terabyte large temporary strings...

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

On 03/01/2022 12:00, Dmitry A. Kazakov wrote:
> On 2022-01-03 12:19, Bart wrote:
>
>> As I said I've lost track of what we discussing.
>
> We were discussing inability to return a string from a function in your
> language in a reasonable way.
>
> You argued that there is no need to have it due to danger that some user
> might miss his or her medication or confuse that with certain mushrooms
> and so came to an idea of creating terabyte large temporary strings...

Unlike Python? Here:

a = [10,]*1000000
s = str(a)
print (len(s))

The length of s is 4 million (1 million times "10, ").

I believe that print(a) would simply apply str() to 'a' then write that
string.

On 02/01/2022 16:06, 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?

Unformatted transput, of course. Eg,

print this, that, these, those and the many other things

[with whatever syntax, quoting, separators, etc you prefer]. Much
the same for "read". Most of the time the default is entirely
adequate. If not, then the choice for the language designer is
either an absurdly complicated syntax that still probably doesn't
meet some plausible needs, or to provide simple mechanisms that
allow programmers to roll their own. Guess which I 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.

AIUI, you are designing your own language. If it doesn't
have strings, eg as results of procedures, then you have much worse
problems than designing some transput procedures. There are lots
of ways of implementing strings, but they are for the compiler to
worry about, not the language designer [at least, once you know it
can be done].

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

There's no need for "dynamic allocations" merely for transput.
Most of the early languages that I used didn't have them, but still
managed to print and read things. You're making mountains out of
molehills.

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

Yes, that's what I thought you meant. C is thataway -->.
You call it "simple"; C is one of the simpler languages of this
type, yet the full spec of "printf" and its friends is horrendous.
Build in some version [exact syntax up to you] of

print "String with ", val, " included"

and you're mostly done. For the exceptional cases, use a library
procedure or your own procedure to convert "val" to a suitable
array of characters, with whatever parameters are appropriate.

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

Nothing. How on earth do you think we managed in olden
times, before we had "dynamic memory"? [Ans: by printing each
character in sequence.]

--
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 04/01/2022 00:35, Andy Walker wrote:
> On 02/01/2022 16:06, 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?
>
>     Unformatted transput, of course.  Eg,
>
>   print this, that, these, those and the many other things

If I do this in A68G:

print(("<",1,">"))

the output is:

< +1>

The "<>" are just to help show the problem: how to get rid of the those
leading spaces and that plus sign? Or write the number with a field
width of your choice?

(It gets worse with wider, higher precision numbers, as it uses the
maximum value as the basis for the field width, so that one number could
take up most of the line. Now you will need to start calling functions
that return strings to get things done properly.)

> [with whatever syntax, quoting, separators, etc you prefer].  Much

>     Yes, that's what I thought you meant.  C is thataway -->.
> You call it "simple";  C is one of the simpler languages of this
> type, yet the full spec of "printf" and its friends is horrendous.

The main problem with C's printf is having to tell it the exact type of
each expression.

But those formatting facilities are genuinely useful and harder to
emulate in user code if they didn't exist.

> Build in some version [exact syntax up to you] of
>
>   print "String with ", val, " included"
>
> and you're mostly done.

Yeah, and it will need this:

print a, " ", b, " ", c, "\n"

instead of:

println a, b, c

Designing Print properly can make a big difference!

>  For the exceptional cases, use a library
> procedure or your own procedure to convert "val" to a suitable
> array of characters, with whatever parameters are appropriate.

Well, this is the problem. Where will the array of characters be located
especially if the size is unpredictable? What happens here:

print val1, val2

Or here:

print val3(f())

where f itself includes a 'print val'.

A language might not be advanced enough to have memory-managed
persistent data structures, but it might want custom printing of
user-defined types. Example:

println "Can't convert", strmode(s), "to", strmode(t)

strmode() turns an internal type code into a human readable type
specificication. This language doesn't have flex strings; strmode just
returns a pointer to a fixed-size static string big enough for the
largest expected type.

In this example, because I know that evaluation is left-to-right, it
doesn't matter that the second strmode call will overwrite the earlier
result. But here it does:

f(strmode(s), strmode(t))

>> 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!)
>
>     Nothing.  How on earth do you think we managed in olden
> times, before we had "dynamic memory"?  [Ans:  by printing each
> character in sequence.]

Probably the printing tasks weren't that challenging. As my A68G example
showed, output tended to be tabulated.

On 04/01/2022 11:31, Bart wrote:
> If I do this in A68G:
>     print(("<",1,">"))
> the output is:
>     <         +1>
> The "<>" are just to help show the problem: how to get rid of the
> those leading spaces and that plus sign? Or write the number with a
> field width of your choice?

"The problem"? It's the A68 /default/. You might prefer
a different default [esp for your own language], but someone had
to choose, without being able to read the minds of contributors
to this newsgroup more than half a century later. If you want
different output in A68, check out the specification of "whole"
[and "fixed" and "float"], RR10.3.2.1, which directly solves the
two "problems" you mention.

> (It gets worse with wider, higher precision numbers, as it uses the
> maximum value as the basis for the field width, so that one number
> could take up most of the line. Now you will need to start calling
> functions that return strings to get things done properly.)

"Worse", "properly"? All you're saying is that you don't
like the default. Note, again for A68, that "whole" [still] works
for all flavours of number. FTAOD, I carefully didn't mention A68
in my previous postings to this thread; I don't greatly care for
A68 transput -- but at least the unformatted [or "formatless" in
RR-speak] version is easy to learn and use.

> The main problem with C's printf is having to tell it the exact type
> of each expression.

The main problem is its complexity! It's as bad as A68,
while not being /anywhere near/ as comprehensive. I suspect you
haven't read N2731 [or near equivalent]. If it takes scores of
pages to describe a relatively simple facility, there's surely
something wrong.

> But those formatting facilities are genuinely useful and harder to
> emulate in user code if they didn't exist.

The RR includes "user code" for both the formatted and
unformatted versions of transput; so if any part of it didn't
exist in some other language, you could easily roll your own.
Not that you should need to.

[...]
>>  For the exceptional cases, use a library
>> procedure or your own procedure to convert "val" to a suitable
>> array of characters, with whatever parameters are appropriate.
> Well, this is the problem. Where will the array of characters be
> located especially if the size is unpredictable?

Why [as a user] do you care? Your language either has
strings as a useful type or it doesn't. If it does, you're in
business. If it doesn't, and you want to write software that
handles things like words or names or anything of the sort, then
you have problems way beyond getting your output to look nice
[but at least Unix/Linux comes with loads of commands to do
that for you]. If, OTOH, you're a compiler writer trying to
implement strings, then there is plenty of source code for
those commands available to give you a start.

[In response to James:]
>> How on earth do you think we managed in olden
>> times, before we had "dynamic memory"?  [Ans:  by printing each
>> character in sequence.]
> Probably the printing tasks weren't that challenging. As my A68G
> example showed, output tended to be tabulated.

Perhaps you could write that in a more patronising form?
[For some of us, "olden times" started more than a decade before
the A68 RR, and we nevertheless managed to write word-processing
and similar "apps" -- despite the absence of mod cons such as
editors, mice, disc storage, files, "dynamic memory", ....]

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

On 05/01/2022 00:54, Andy Walker wrote:
> On 04/01/2022 11:31, Bart wrote:

>> The main problem with C's printf is having to tell it the exact type
>> of each expression.
>
>     The main problem is its complexity!  It's as bad as A68,
> while not being /anywhere near/ as comprehensive.  I suspect you
> haven't read N2731 [or near equivalent].  If it takes scores of
> pages to describe a relatively simple facility, there's surely
> something wrong.

If you mean 7.21.6.1 about fprintf, that's 7 pages, of which the last
two are examples. Yes, it goes on a bit, but that's just its style,
which is a specification hopefully useful to someone needing to
implemement it.

Format codes form a little language of their own. Bear in mind all the
different parameters that could be used to control the appearance of an
integer or float value.

This one for example roughly emulates A68's display for INT:

"%+11d"

In my scheme, the equivalent params are: "+11" (or "11 +"; it's not
fussy about syntax), and the docs (in the form of comments to the
function that turns that style string into a descriptor) occupy 2 lines,
but are rather sparse.

>> Well, this is the problem. Where will the array of characters be
>> located especially if the size is unpredictable?
>
>     Why [as a user] do you care?  Your language either has
> strings as a useful type or it doesn't.

The static language doesn't. It doesn't mean it's not possible to do
things, it's just more work.

But there is a greater need for helpful Print features that involve
text, which are one corner of the language, than to do 100 times as much
work in transforming that language into one with first class strings.

I use this language to implement my higher-level one, and to take care
of things that can't be done in scripting code.

> [In response to James:]
>>> How on earth do you think we managed in olden
>>> times, before we had "dynamic memory"?  [Ans:  by printing each
>>> character in sequence.]
>> Probably the printing tasks weren't that challenging. As my A68G
>> example showed, output tended to be tabulated.
>
>     Perhaps you could write that in a more patronising form?

I've lost track here of your argument.

You say that a language ought to have strings as a proper type. But you
also say it doesn't need them. So which is it?

I think the thread is partly about how to add custom printing to a
language that doesn't have automatically managed string types. Example:

record date =
int day, month, year
end

date d := (5,1,2022)

print d

Ideally the output should be something like "5-Jan-2022". But my static
language doesn't support this at all, not even printing the 3 numbers
involved. My dynamic one just shows "(5,1,2022)".

One solution - this is about static code from now on - is to write a
function like this:

function strdate(date &d)ichar =
static [100]char str
static []ichar months = ("Jan","Feb","Mar","Apr","May","Jun",
"Jul","Aug","Sep","Oct","Nov","Dec")

fprint @str, "#-#-#", d.day, months[d.month], d.year
return str
end

then write:

print strdate(d)

but this has obvious limitations: the result of strdate() must be
consumed immediately for example. For more complex types, the string
could be arbitrarily long; what should that buffer size be?

While returning an allocated string means something needs to deallocate
it sooner or later, preferably sooner, but via which mechanism? It could
also mean arbitrary large strings that can cause issues.

Another approach is to use:

print d

and for it to know, through an association made elsewhere, that turning
d into a string (or otherwise serialising it) involves calling the function.

I don't think it's helpful to suggest that either the language needs to
be transformed into a higher level one, just for Print, or that it
doesn't need any such features, because decades ago we all seemed to
manage to print dates with basic Print. Yes I can do that now too:

print d.day,,"-",,months[d.month],,"-",,d.year # ,, means no space
fprint "#-#-#", d.day, months[d.month], d.year
printdate(d); println

but as you can see it's bit of a pig.

On 05/01/2022 13:12, Bart wrote:
> Format codes form a little language of their own. Bear in mind all
> the different parameters that could be used to control the appearance
> of an integer or float value.

Yes, but that's the point. As you point out with your "date"
example, you're typically on your own if you want to print something
that doesn't fit neatly into the "little language" [such as dates or
Roman numerals], and there are so many "different parameters" that
the little language grows into something bigger, while still being
insufficient for many needs. Learning it is a distraction from the
main programming language involved.

>>> Probably the printing tasks weren't that challenging. As my A68G
>>> example showed, output tended to be tabulated.
>>      Perhaps you could write that in a more patronising form?
> I've lost track here of your argument.

You were implying that before modern times, only simple
output used to be needed. That's patronising rubbish.

> You say that a language ought to have strings as a proper type. But
> you also say it doesn't need them. So which is it?

Both, of course. Proper strings make life easier, but
it's possible to program around that as long as your language
has /some/ way of constructing and printing characters. Any
modern general-purpose language /ought/ to be able to have
arrays [whether of characters, integers, procedures returning
structures, ...] as parameters and as function return values.
You can program around the lack, but these days you shouldn't
have to.

> I think the thread is partly about how to add custom printing to a
> language that doesn't have automatically managed string types.

Well, it was about whether languages should have formats
[presumably somewhat similar to those in C]. I don't see the
point. In C terms, the simple cases [such as "%s", "%d"] can
be replaced by simply printing the string or whatever, the
slightly more complicated cases by some equivalent to the A68
"whole", "fixed" and "float" procedures, and you have to roll
your own with anything complex anyway, as your date example
[snipped] shows.

[...]> While returning an allocated string means something needs to
> deallocate it sooner or later, preferably sooner, but via which
> mechanism? It could also mean arbitrary large strings that can cause
> issues.

You're back to implementation issues. Not the concern
of the user who wants to print dates that look nice. Meanwhile,
the implementation issues were solved more than half a century
ago. 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]?

> I don't think it's helpful to suggest that either the language needs
> to be transformed into a higher level one, just for Print, or that it
> doesn't need any such features, because decades ago we all seemed to
> manage to print dates with basic Print.

"Need" is an exaggeration. But in any case no-one here
has suggested either part of that [esp not if you replace "need"
by "desirable" (with appropriate changes to the grammar)]. It is
indeed desirable for a modern language to have the ability to
allocate [and deallocate] off-stack storage and the ability to
print characters. Is there any major general-purpose computing
language of the past sixty years that has not had such abilities?

Meanwhile, you're proposing adding a "little language"
to the language spec "just for Print". Why is that any better
than adding "fixed", "float" and "whole" to the library?

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

On 07/01/2022 13:20, Andy Walker wrote:
> On 05/01/2022 13:12, Bart wrote:

>     You're back to implementation issues.  Not the concern
> of the user who wants to print dates that look nice.  Meanwhile,
> the implementation issues were solved more than half a century
> ago.  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.)

>> I don't think it's helpful to suggest that either the language needs
>> to be transformed into a higher level one, just for Print, or that it
>> doesn't need any such features, because decades ago we all seemed to
>> manage to print dates with basic Print.
>
>     "Need" is an exaggeration.  But in any case no-one here
> has suggested either part of that [esp not if you replace "need"
> by "desirable" (with appropriate changes to the grammar)].  It is
> indeed desirable for a modern language to have the ability to
> allocate [and deallocate] off-stack storage and the ability to
> print characters.  Is there any major general-purpose computing
> language of the past sixty years that has not had such abilities?

Plenty don't do such allocations /automatically/.

>     Meanwhile, you're proposing adding a "little language"
> to the language spec "just for Print".  Why is that any better
> than adding "fixed", "float" and "whole" to the library?

Until about 2010 I only had simple Print. If wanted to display something
in hex for example, I had a library function called Hex:

print hex(a)

And that function hex was defined like this (in an older version of my
language):

FUNCTION HEX(n)=
static [1..20]char str
sprintf(^str," %XH",n)
^str
END

Notice it's using C's 'sprintf' to do the work; I can't be having that!
(Yes I can do this easily enough with my own code, but why bother then
it's there ready to use.)

So if I'm having to utilise something from another language (and C at
that), it sounds like somthing I ought to have built-in to mine:

print a:"h"

(The :fmt syntax comes from Pascal.) Inside my library, I do it with
low-level code; C's sprintf is not suitable as there are extra controls.

But also, inside my library, the intermediate string data is much more
easily managed.

> Meanwhile, you're proposing adding a "little language"
> to the language spec "just for Print".

It can be called a 'language' for C-style formats as there is a syntax
involved. (The 'just for Print' comment was about adding advanced
features to the language.)

As I do it, it's more of a style string, as I frequently use within
applications, for controlling GUI elements for example.

It is the x:fmt syntax that is specific to Print, and is really
syntactic sugar:

print x, y:fmt

is equivalent (when x and y have i64 types) to:

m$print_startcon()
m$print_i64_nf(x) # this calls m$print_i64(x, nil)
m$print_i64(y,fmt)
m$print_end()

(The start/end functions provide a print context, eg for output to
console, file, string, and allow for logic to insert spaces /between/
items.)

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

My more recent suggestion would not need any special place for the
string form. Anything to be output could be written directly to wherever
the print function was writing to.

--
James Harris

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.

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.

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

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

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.

--
James Harris

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)

?

I see that you've gone for default formatting so I did the same. I could
(under the suggestion) customise them by putting a format specification
between % and ;. How would you customise the format of X'Image and Y'Image?

--
James Harris

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.

Furthermore, the only use for an output buffer is to make output more
efficient; it's not fundamental.

On a minimal system a print function only has to emit one character at a
time. No buffering. No memory management. For sure, there can be
buffering added on top but that would be for performance reasons.

Whether a buffer is used or not ISTM your schemes imply significant
memory management. There's nothing wrong with that. It's quite normal in
most languages and on most hardware that anyone is likely to use these
days. But I return to my point that it's best not to design output
facilities which need such complexity because one cannot enumerate every
environment in which a language will ever be used.

--
James Harris

On 04/01/2022 00:35, Andy Walker wrote:
> On 02/01/2022 16:06, 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?
>
>     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.

>
> [with whatever syntax, quoting, separators, etc you prefer].  Much
> the same for "read".  Most of the time the default is entirely
> adequate.  If not, then the choice for the language designer is
> either an absurdly complicated syntax that still probably doesn't
> meet some plausible needs, or to provide simple mechanisms that
> allow programmers to roll their own.  Guess which I prefer.

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

>>> 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.
>
>     AIUI, you are designing your own language.  If it doesn't
> have strings, eg as results of procedures, then you have much worse
> problems than designing some transput procedures.  There are lots
> of ways of implementing strings, but they are for the compiler to
> worry about, not the language designer [at least, once you know it
> can be done].

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.

>
>> The form I proposed had no need for dynamic allocations. That's part
>> of the point of it.
>
>     There's no need for "dynamic allocations" merely for transput.
> Most of the early languages that I used didn't have them, but still
> managed to print and read things.  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.

>
>> 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.
>
>     Yes, that's what I thought you meant.  C is thataway -->.
> You call it "simple";  C is one of the simpler languages of this
> type, yet the full spec of "printf" and its friends is horrendous.

I agree. C's printf formats are fine for simple cases. But they don't
scale. That's why I suggested a scheme which was more flexible.

> Build in some version [exact syntax up to you] of
>
>   print "String with ", val, " included"
>
> and you're mostly done.  For the exceptional cases, use a library
> procedure or your own procedure to convert "val" to a suitable
> array of characters, with whatever parameters are appropriate.

a. Where would you store the array of characters?

b. What's wrong with

print "String with %v; included" % val

where v is a suitable format for the type of val.

>
>> 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!)
>
>     Nothing.  How on earth do you think we managed in olden
> times, before we had "dynamic memory"?  [Ans:  by printing each
> character in sequence.]
>

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.

--
James Harris

On 04/01/2022 11:31, Bart wrote:
> On 04/01/2022 00:35, Andy Walker wrote:
>> On 02/01/2022 16:06, 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
>
> If I do this in A68G:
>
>     print(("<",1,">"))
>
> the output is:
>
>     <         +1>

....

>    print val3(f())
>
> where f itself includes a 'print val'.

Two great examples!

--
James Harris

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, is as thread safe as any other call, needs no
dynamic memory management.

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.

Of course, the formatting parameters bring things in the realm of
multiple dispatch:

function Image (X : Printable; Options : Format := Default)
return String;

Combinations of Printable x Format are multiple dispatch.

It is unlikely to support, but in this case it could be replaced by a
variant record for Format. It would lack extensibility, but where is any
in printf? Alternatively to variant record you can make Format having
methods like:

function Base (X : Format) return Number_Base;

The methods would return defaults if not overridden. In both cases the
language must provide good support of aggregates to make format
specifications comfortable.

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

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.

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

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, does not do
printf directly. It usually does some kind of locking when the output
consists of multiple printfs. Consider it an output transaction when
each instance of output is atomic. Of course, character streams have no
place there.

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

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.

And again, that is not the point. The point is that in any decent
language there is no need either in printf mess or print statements.

Because the language abstractions are powerful enough to express
formatting I/O in language terms.

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

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.

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

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

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.

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

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.
>
> And again, that is not the point. The point is that in any decent
> language there is no need either in printf mess or print statements.
>
> Because the language abstractions are powerful enough to express
> formatting I/O in language terms.

But the result is ugly, ungainly code to do a simple task.

Look at the difference when it's done properly:

fprintln "X=#, Y=#", X, Y

Or as I also do it (as "=" displays prints the expression itself before
its value):

println =X, =Y

Back to that Ada, I wanted do this:

Put_Line (X+Y'Image);

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? So I
have to use an intermediate variable: Z := X+Y then do Z'Image.

I think you're not in a position to tell people how to implement Print!
You need to be able to just do this:

println X+Y

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

(2) integer, float etc are usually manipulated by value

Apparently Ada strings have a fixed length. If so, that would make
implementing your ideas simpler; and I can do the same thing in my
lower-level language, but I don't consider that a viable solution.

It would be very constraining if you had to know, in advance, the size
of a string returned from a function for a complex user-type conversion.
Which I guess also means the function has the same limit for all
possible calls.

But Ada also has unbounded strings:

"Unbounded strings are allocated using heap memory, and are deallocated
automatically."

Yeah, so exactly what we've been talking about. Either the language has
that kind of advanced feature, based on the heap, or it uses crude
methods with fixed length strings (which was the problem with Pascal)
which is not really a solution; just the kind of workaround I use already.

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

So

Integer_32'image (X + Y)

> I think you're not in a position to tell people how to implement Print!

I am, just don't.

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

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.

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

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.

> Apparently Ada strings have a fixed length.

Apparently not:

function Get_Line (File : File_Type) return String;

> It would be very constraining if you had to know, in advance, the size
> of a string returned from a function for a complex user-type conversion.

String is an indefinite type, the size of an object is unknown until
run-time.

> Which I guess also means the function has the same limit for all
> possible calls.

Wrong. Indefinite types are returned just same as definite types are, on
the stack, which means memory management policy LIFO.

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.

> 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. If you do that, then
you do something wrong or the language is pool, e.g. does not support
string slices.

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

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.

> So
>
>    Integer_32'image (X + Y)

Yeah, that's much better!

>> I think you're not in a position to tell people how to implement Print!
>
> I am, just don't.

Tell me one thing that Ada can do with its Print scheme that I can't do
more simply and with less typing with mine.

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

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

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.

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

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

>
>> It would be very constraining if you had to know, in advance, the size
>> of a string returned from a function for a complex user-type conversion.
>
> String is an indefinite type, the size of an object is unknown until
> run-time.
>
>> Which I guess also means the function has the same limit for all
>> possible calls.
>
> Wrong. Indefinite types are returned just same as definite types are, on
> the stack, which means memory management policy LIFO.
>
> 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(), what, exactly, is passed to Put_Line(), 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?

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

>> 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 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, clean and portable. What's more, per
the suggestion I made to start this thread it will work with
user-defined types.

You should at least try to understand an idea before you dismiss it! ;-)

(The only way it would become type unsafe would be via such as

format_string = F()
put_line(format_string, X, Y)

and that does not have to be allowed.)

--
James Harris