I like using this for long strings:

fputs
(
"When an uncleft or a bulkbit wins one or more bernstonebits above\n"
"its own, it takes on a backward lading. When it loses one or\n"
"more, it takes on a forward lading. Such a mote is called a\n"
"*farer*, for that the drag between unlike ladings flits it. When\n"
"bernstonebits flit by themselves, it may be as a bolt of\n"
"lightning, a spark off some faststanding chunk, or the everyday\n"
"flow of bernstoneness through wires.\n",
stdout
);

Of languages that derive ideas from C, only C++ and Python seem to have
kept this. Java, JavaScript and PHP have not, for some reason.

On 25.02.2024 00:05, Lawrence D'Oliveiro wrote:
> I like using this for long strings:
>
> fputs
> (
> "When an uncleft or a bulkbit wins one or more bernstonebits above\n"
> "its own, it takes on a backward lading. When it loses one or\n"
> "more, it takes on a forward lading. Such a mote is called a\n"
> "*farer*, for that the drag between unlike ladings flits it. When\n"
> "bernstonebits flit by themselves, it may be as a bolt of\n"
> "lightning, a spark off some faststanding chunk, or the everyday\n"
> "flow of bernstoneness through wires.\n",
> stdout
> );

I also liked to be able to use this feature _in some cases_ in C++.

Not in the given case, though, where I like to more clearly see the
newlines, so I'd prefer cout << "..." << endl

>
> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.

In Java you have at least the string concatenation operator + which
is, IMO, pretty good for that line structuring across source lines.

In Awk (another "C like"), string concatenations have no visible
operators so we can for example write print "Hell" "o " "world"
But since lines have a much more restricted definition you cannot
without line continuation escape spread these strings across many
lines. (It's not too bad to add a terminating '\' where desired.)

As far as you're asking "for some reason", I could just speculate
(and abstain).

Janis

I've used this to make strings with embedded newlines look in the source
file closer to how they'd look on output.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
2017 called, but i couldn't understand what they were saying over all the
screams.

On Sat, 24 Feb 2024 23:05:47 -0000 (UTC), Lawrence D'Oliveiro wrote:

> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.

I’d forgotten to check Perl; it doesn’t have implicit concatenation
either.

On Sun, 25 Feb 2024 17:38:38 +0100, Janis Papanagnou wrote:

> In Java you have at least the string concatenation operator + which is,
> IMO, pretty good for that line structuring across source lines.

Implicit concatenation works well in Python because you also have the
“%” operator overloaded to perform printf-style formatting with a
string. If you had to use “+” then, because that binds less tightly
than “%”, you would have to have parentheses as well, which are
unnecessary with implicit concatenation. E.g.

# depreciation entries
sql.cursor.execute \
(
"insert into payments set when_made = %(when_made)s,"
" description = %(description)s, other_party_name = \"\","
" amount = %(amount)d, kind = \"D\", tax_year = %(tax_year)d"
%
{
"when_made" : end_for_tax_year(tax_year) - 1,
"description" :
sql_string
(
"%s: %s $%s at %d%% from %s"
%
(
entry["description"],
entry["method"],
format_amount(entry["initial_value"]),
entry["rate"],
format_date(entry["when_purchased"]),
)
),
"amount" : - entry["amount"],
"tax_year" : tax_year,
}
)

Or, for added fun, how about parameterizing a format:

num_format = "%%.%dg" % nr_digits
...
for axis in range(3) :
out.write \
(
" (%s, %s),\n"
%
(num_format, num_format)
%
(
min(v.co[axis] for v in the_mesh.vertices),
max(v.co[axis] for v in the_mesh.vertices)
)
)
#end for

On 25/02/2024 20:43, Lawrence D'Oliveiro wrote:
> On Sun, 25 Feb 2024 17:38:38 +0100, Janis Papanagnou wrote:
>
>> In Java you have at least the string concatenation operator + which is,
>> IMO, pretty good for that line structuring across source lines.
>
> Implicit concatenation works well in Python because you also have the
> “%” operator overloaded to perform printf-style formatting with a
> string. If you had to use “+” then, because that binds less tightly
> than “%”,

You mean it binds less tightly than implicit concatenation? So that:

"abc" % "def" "ghi" means "abc" % ("def" "ghi")
"abc" % "def" + "ghi" means ("abc" % "def") "ghi"

> you would have to have parentheses as well, which are
> unnecessary with implicit concatenation. E.g.
>
> # depreciation entries
> sql.cursor.execute \
> (
> "insert into payments set when_made = %(when_made)s,"
> " description = %(description)s, other_party_name = \"\","
> " amount = %(amount)d, kind = \"D\", tax_year = %(tax_year)d"
> %
> {
> "when_made" : end_for_tax_year(tax_year) - 1,
> "description" :
> sql_string
> (
> "%s: %s $%s at %d%% from %s"
> %
> (
> entry["description"],
> entry["method"],
> format_amount(entry["initial_value"]),
> entry["rate"],
> format_date(entry["when_purchased"]),
> )
> ),
> "amount" : - entry["amount"],
> "tax_year" : tax_year,
> }
> )
>
> Or, for added fun, how about parameterizing a format:
>
> num_format = "%%.%dg" % nr_digits
> ...
> for axis in range(3) :
> out.write \
> (
> " (%s, %s),\n"
> %
> (num_format, num_format)
> %
> (
> min(v.co[axis] for v in the_mesh.vertices),
> max(v.co[axis] for v in the_mesh.vertices)
> )
> )
> #end for

Although I can't see it made much difference here. Is this an example of
how bad it can be without implicit concatenation, or is it this
complicated despite that?

Since I can't see any "+" operators between strings, yet what follows
"%" is usually something starting with "(" or "{", not a string constant.

On Sat, 24 Feb 2024 23:05:47 -0000 (UTC), Lawrence D'Oliveiro wrote:
> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.
Java (Text Blocks):
String s = """
multi
line
string""";

JavaScript (Template Literal):
let s = `multi
line
string`;

Still more convenient than C.

PHP? Don't care about PHP, it's shit, not even checking, most likely
some kind of a Perl-ish <<<EOF expression.

--
Kindest regards,
Łukasz 'Mały' Ostrowski.

On Mon, 26 Feb 2024 21:12:39 +0100, Łukasz 'Maly' Ostrowski wrote:

> Java (Text Blocks):
> String s = """
> multi line string""";

Python has those, too. I use them sometimes. Generally I’m not fond of
them, because I think they’re wrongly defined.

> JavaScript (Template Literal):
> let s = `multi line string`;

I think Python has something like that now, too. F-strings?

> Still more convenient than C.

I still like having the choice of implicit concatenation, because then I
fully control what appears in the string.

Tip: I have Emacs macros defined to strip and add the quoting/escaping,
because I find the strings are easier to edit without that.

> PHP? Don't care about PHP, it's shit, not even checking, most likely
> some kind of a Perl-ish <<<EOF expression.

PHP is shit, not because of what it copied from Perl, but from what it
didn’t copy. Nowadays it is trying to copy from Python, and it is making
the same mistake.

The <<EOD construct that Perl has comes from POSIX shells, and it is very
useful in both places. Bash also adds a <<<-construct.

Question: How would you do two separate <<-strings in the same shell
command?

On 2024-02-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> I like using this for long strings:
>
> fputs
> (
> "When an uncleft or a bulkbit wins one or more bernstonebits above\n"
> "its own, it takes on a backward lading. When it loses one or\n"
> "more, it takes on a forward lading. Such a mote is called a\n"
> "*farer*, for that the drag between unlike ladings flits it. When\n"
> "bernstonebits flit by themselves, it may be as a bolt of\n"
> "lightning, a spark off some faststanding chunk, or the everyday\n"
> "flow of bernstoneness through wires.\n",
> stdout
> );
>
> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.

Implicit string catenation means you need punctuation to separate
elements that are not catenated.

It's a nonstarter in Lisp where you want

("ab" "cd" "ef")

to have three elements, not one. So if it worked that way, we would
need

("ab", "cd", "ef")

which is too horrible a price to pay for string literal catenation.

ANSI Lisp just allows line breaks in strings. However, all the white
space is combined into it.

Allow line breaks in string literals means that if you forget to
close a quote, it might not be diagnosed until the end of file!
The strictness of having to close a string in the same line is
worthwhile for diagnosis.

In TXR Lisp, I solved multiple problems with a backslash continuation.

"abc \
def"

encodes the string "abcdef". All unescaped whitespace around the
backslash is deleted. If you want "abc def", you can plant an escaped
space in there:

"abc \ \
def"

or

"abc \
\ def"

Unfortunately, it does mean we have the run of backslashes down the
right side:

"abc \
def \
ghi \
... "

I can live with that.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> I like using this for long strings:
>
> fputs
> (
> "When an uncleft or a bulkbit wins one or more bernstonebits above\n"
> "its own, it takes on a backward lading. When it loses one or\n"
> "more, it takes on a forward lading. Such a mote is called a\n"
> "*farer*, for that the drag between unlike ladings flits it. When\n"
> "bernstonebits flit by themselves, it may be as a bolt of\n"
> "lightning, a spark off some faststanding chunk, or the everyday\n"
> "flow of bernstoneness through wires.\n",
> stdout
> );
>
> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.

Easy solution Lawrence. Why not use something like bin2c:

<https://www.segger.com/free-utilities/bin2c/>

void Usage() {

#include "my_text"

printf("%s\n", my_var);

}

--
:wq
Mike Sanders

On Mon, 26 Feb 2024 22:03:11 -0000 (UTC), Mike Sanders wrote:

> Easy solution Lawrence. Why not use something like bin2c:

My tool for easy editing of such embedded text is the Emacs macros in
multiquote.el, here <https://gitlab.com/ldo/emacs-prefs>.

On 26/02/2024 23:03, Mike Sanders wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> I like using this for long strings:
>>
>> fputs
>> (
>> "When an uncleft or a bulkbit wins one or more bernstonebits above\n"
>> "its own, it takes on a backward lading. When it loses one or\n"
>> "more, it takes on a forward lading. Such a mote is called a\n"
>> "*farer*, for that the drag between unlike ladings flits it. When\n"
>> "bernstonebits flit by themselves, it may be as a bolt of\n"
>> "lightning, a spark off some faststanding chunk, or the everyday\n"
>> "flow of bernstoneness through wires.\n",
>> stdout
>> );
>>
>> Of languages that derive ideas from C, only C++ and Python seem to have
>> kept this. Java, JavaScript and PHP have not, for some reason.
>
> Easy solution Lawrence. Why not use something like bin2c:
>
> <https://www.segger.com/free-utilities/bin2c/>

Because it generates files that have Segger copyright notices stamped on
them? At least, that's how it appears from that web page.

There are lots of open source alternatives that do similar things, with
different variations in the way they generate the output. Or you can
write your own in about 10 lines of Python, which of course makes it a
lot easier to customise to fit your own styles and requirements.

And with C23, we will get #embed, though it is not yet supported by
major tools.

<https://en.cppreference.com/w/c/preprocessor/embed>

On 26.02.2024 21:31, Lawrence D'Oliveiro wrote:
>
> The <<EOD construct that Perl has comes from POSIX shells, and it is very
> useful in both places. Bash also adds a <<<-construct.

Yes, bash adopted the '<<<' "here-strings".

> Question: How would you do two separate <<-strings in the same shell
> command?

Can you give an example what you intend here? (With what semantics?)

Since '<<' is redirecting the here-document text to stdin of the
command you can have only one channel.

Janis

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> My tool for easy editing of such embedded text is the Emacs macros in
> multiquote.el, here <https://gitlab.com/ldo/emacs-prefs>.

Neato-burritto, built his own tool chain, 'atta-boy. Interesting page.

--
:wq
Mike Sanders

David Brown <david.brown@hesbynett.no> wrote:

> Because it generates files that have Segger copyright notices stamped on
> them? At least, that's how it appears from that web page.

Then we build our own...
> There are lots of open source alternatives that do similar things, with
> different variations in the way they generate the output. Or you can
> write your own in about 10 lines of Python, which of course makes it a
> lot easier to customise to fit your own styles and requirements.

Yeah even simpler ways too, sed/awk/etc

> And with C23, we will get #embed, though it is not yet supported by
> major tools.
>
> <https://en.cppreference.com/w/c/preprocessor/embed>

Did not know that was coming down the pike, thanks for sharing the info
David.

--
:wq
Mike Sanders

On 27/02/2024 08:36, David Brown wrote:
> On 26/02/2024 23:03, Mike Sanders wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> I like using this for long strings:
>>>
>>>      fputs
>>>        (
>>>          "When an uncleft or a bulkbit wins one or more bernstonebits
>>> above\n"
>>>          "its own, it takes on a backward lading. When it loses one
>>> or\n"
>>>          "more, it takes on a forward lading. Such a mote is called a\n"
>>>          "*farer*, for that the drag between unlike ladings flits it.
>>> When\n"
>>>          "bernstonebits flit by themselves, it may be as a bolt of\n"
>>>          "lightning, a spark off some faststanding chunk, or the
>>> everyday\n"
>>>          "flow of bernstoneness through wires.\n",
>>>          stdout
>>>        );
>>>
>>> Of languages that derive ideas from C, only C++ and Python seem to have
>>> kept this. Java, JavaScript and PHP have not, for some reason.
>>
>> Easy solution Lawrence. Why not use something like bin2c:
>>
>> <https://www.segger.com/free-utilities/bin2c/>
>
> Because it generates files that have Segger copyright notices stamped on
> them?  At least, that's how it appears from that web page.
>
> There are lots of open source alternatives that do similar things, with
> different variations in the way they generate the output.  Or you can
> write your own in about 10 lines of Python, which of course makes it a
> lot easier to customise to fit your own styles and requirements.
>
> And with C23, we will get #embed, though it is not yet supported by
> major tools.
>
> <https://en.cppreference.com/w/c/preprocessor/embed>

Actually I've had such feature, for text files, for some years in my
older compiler:

#include <stdio.h>

int main(void) {
puts(strinclude(__FILE__));
}

This prints out the contents of this sourcefile. Binary files don't work
because of embedded zeros, but could have been made to.

Some stuff is just very easy to do; other stuff like designator chains
less easy and also less useful.

On Tue, 27 Feb 2024 09:36:38 +0100, David Brown wrote:

> And with C23, we will get #embed, though it is not yet supported by
> major tools.

More and more hacks on the preprocessor. Why not just get rid of it and
replace it with something like m4?

Because then you will discover that string-based macros are inherently an
unmanageable problem.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 27 Feb 2024 09:36:38 +0100, David Brown wrote:
>> And with C23, we will get #embed, though it is not yet supported by
>> major tools.
>
> More and more hacks on the preprocessor. Why not just get rid of it and
> replace it with something like m4?

Because it would invalidate 99% or more of existing C code.

(m4? Seriously?)

> Because then you will discover that string-based macros are inherently an
> unmanageable problem.

The C preprocessor operates on preprocessor tokens, not just strings.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 27/02/2024 20:25, Lawrence D'Oliveiro wrote:
> On Tue, 27 Feb 2024 09:36:38 +0100, David Brown wrote:
>
>> And with C23, we will get #embed, though it is not yet supported by
>> major tools.
>
> More and more hacks on the preprocessor. Why not just get rid of it and
> replace it with something like m4?
>
> Because then you will discover that string-based macros are inherently an
> unmanageable problem.

I hadn't notice that #embed was a preprocessor directive. But that is
not the problem here, it is this:

"The expansion of a #embed directive is a token sequence formed from the
list of integer constant expressions described below."

If a string like "ABC" really is converted to the five tokens 'A' comma
'B' comma 'C', then it's going to make long strings and binary files
inefficient.

Embedding a 100KB file will result in a 100KB bigger executable, but
along the way it may have to generate 200,000 tokens within the
compiler, half of them commas. Which in turn will need to be turned into
100,000 integer expressions.

I would hope that implementations find some way of streamlining that
process, perhaps by turning that 100KB of data directly into a 100KB string.

On 27/02/2024 19:56, bart wrote:
> On 27/02/2024 08:36, David Brown wrote:
>> On 26/02/2024 23:03, Mike Sanders wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> I like using this for long strings:
>>>>
>>>>      fputs
>>>>        (
>>>>          "When an uncleft or a bulkbit wins one or more
>>>> bernstonebits above\n"
>>>>          "its own, it takes on a backward lading. When it loses one
>>>> or\n"
>>>>          "more, it takes on a forward lading. Such a mote is called
>>>> a\n"
>>>>          "*farer*, for that the drag between unlike ladings flits
>>>> it. When\n"
>>>>          "bernstonebits flit by themselves, it may be as a bolt of\n"
>>>>          "lightning, a spark off some faststanding chunk, or the
>>>> everyday\n"
>>>>          "flow of bernstoneness through wires.\n",
>>>>          stdout
>>>>        );
>>>>
>>>> Of languages that derive ideas from C, only C++ and Python seem to have
>>>> kept this. Java, JavaScript and PHP have not, for some reason.
>>>
>>> Easy solution Lawrence. Why not use something like bin2c:
>>>
>>> <https://www.segger.com/free-utilities/bin2c/>
>>
>> Because it generates files that have Segger copyright notices stamped
>> on them?  At least, that's how it appears from that web page.
>>
>> There are lots of open source alternatives that do similar things,
>> with different variations in the way they generate the output.  Or you
>> can write your own in about 10 lines of Python, which of course makes
>> it a lot easier to customise to fit your own styles and requirements.
>>
>> And with C23, we will get #embed, though it is not yet supported by
>> major tools.
>>
>> <https://en.cppreference.com/w/c/preprocessor/embed>
>
> Actually I've had such feature, for text files, for some years in my
> older compiler:
>
>     #include <stdio.h>
>
>     int main(void) {
>         puts(strinclude(__FILE__));
>     }
>
> This prints out the contents of this sourcefile. Binary files don't work
> because of embedded zeros, but could have been made to.
>
> Some stuff is just very easy to do; other stuff like designator chains
> less easy and also less useful.

The #embed pre-processor directive turns the file into a list of integer
constants, one per byte (unless an implementation offers other options).
That makes it a little less convenient for strings than your solution,
but more convenient for data files. There's no harm in supporting both!

On Tue, 27 Feb 2024 23:21:28 +0100, David Brown wrote:

> The #embed pre-processor directive turns the file into a list of integer
> constants, one per byte (unless an implementation offers other options).

What a waste of time.

On Tue, 27 Feb 2024 12:35:35 -0800, Keith Thompson wrote:

> (m4? Seriously?)

Do you know of any more powerful string-based macro processor?

> The C preprocessor operates on preprocessor tokens, not just strings.

Think of “hygienic” macros in the Lisps, and why that is just impossible
in any string-based preprocessor.

On Tue, 27 Feb 2024 13:18:20 +0100, Janis Papanagnou wrote:

> On 26.02.2024 21:31, Lawrence D'Oliveiro wrote:
>>
>> Question: How would you do two separate <<-strings in the same shell
>> command?
>
> Can you give an example what you intend here? (With what semantics?)
>
> Since '<<' is redirecting the here-document text to stdin of the command
> you can have only one channel.

Perl lets you do something like

func(<<EOD1, <<EOD2);
... contents of first string ...
EOD1
... contents of second string ...
EOD2

But this doesn’t work in Bash. However, in a Posix shell, remember you can
specify the number of the file descriptor you want to redirect, e.g.

diff -u /dev/fd/8 /dev/fd/9 8<<'EOD1' 9<<'EOD2'
... contents of first string ...
EOD1
... contents of second string ...
EOD2

Note I add the single quotes to prevent expansion of “$”-sequences within
the strings. (I think this might be needed in Perl, too.)

On 28.02.2024 00:10, Lawrence D'Oliveiro wrote:
> On Tue, 27 Feb 2024 13:18:20 +0100, Janis Papanagnou wrote:
>
>> On 26.02.2024 21:31, Lawrence D'Oliveiro wrote:
>>>
>>> Question: How would you do two separate <<-strings in the same shell
>>> command?
>>
>> Can you give an example what you intend here? (With what semantics?)
>>
>> Since '<<' is redirecting the here-document text to stdin of the command
>> you can have only one channel.
>
> Perl lets you do something like
>
> func(<<EOD1, <<EOD2);
> ... contents of first string ...
> EOD1
> ... contents of second string ...
> EOD2
>
> But this doesn’t work in Bash. However, in a Posix shell, remember you can
> specify the number of the file descriptor you want to redirect, e.g.
>
> diff -u /dev/fd/8 /dev/fd/9 8<<'EOD1' 9<<'EOD2'
> ... contents of first string ...
> EOD1
> ... contents of second string ...
> EOD2
>
> Note I add the single quotes to prevent expansion of “$”-sequences within
> the strings. (I think this might be needed in Perl, too.)

I see. - Yes, you can do that in POSIX shells as well. - Note that I set
F'up-to CUS. And post the response there as a f'up to this post.

Janis

On 2024-02-27, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 27 Feb 2024 23:21:28 +0100, David Brown wrote:
>
>> The #embed pre-processor directive turns the file into a list of integer
>> constants, one per byte (unless an implementation offers other options).
>
> What a waste of time.

Plus easily doable in 1970's Lisp.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca