On Thursday, December 23, 2021 at 5:10:07 PM UTC-6, Guillaume wrote:
> Le 23/12/2021 à 20:37, MitchAlsup a écrit :
> > The only benefit to developers would be some kind of syntactic sugar to make
> > bit fields easier to specify::
> > <
> > a<3:17> = b<9:23>;
> Oh, I perfectly get that, and I agree this notation would be quite nice.
> > Macros seem to fail in that they cannot do syntactic sugar things.
<
> Not this kind, indeed. But the whole question regarding the standard is,
> is it really worth it to make additions to it just for some syntactic
> sugar? This is not the spirit of C.
<
Adding it syntactically into the language would allow the offset and width
to be anything in the range of an integer--imagine a bit field 11,357 bits long
at offset 1,496 into a 29,000-bit container--and the compiler knows what code
to produce. That is: real bit fields.
<
Perhaps this is a job for C++
>
> But in that same vein, I would have a number of other notations I would
> like to have in C. A lot more than just this. Thing is, who knows where
> that would lead the language.

On 12/22/2021 12:24 PM, Tim Rentsch wrote:
<snip>

>
> Not necessarily an answer but an observation: in C no new language
> feature is needed, because C has the C preprocessor. It isn't hard
> to write a macro that does the necessary shifting and masking (and
> these days compilers are mostly smart enough to recognize the common
> patterns and translate them efficiently and in machine-specific
> ways).

The C preprocessor is an invention of the Devil.

It lacks the power of a real macro language like m4, yet has all the
drawbacks of scopeless text substitution.

On Thursday, December 23, 2021 at 7:17:10 PM UTC-6, Ivan Godard wrote:
> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
> <snip>
>
> >
> > Not necessarily an answer but an observation: in C no new language
> > feature is needed, because C has the C preprocessor. It isn't hard
> > to write a macro that does the necessary shifting and masking (and
> > these days compilers are mostly smart enough to recognize the common
> > patterns and translate them efficiently and in machine-specific
> > ways).
>
> The C preprocessor is an invention of the Devil.
>
> It lacks the power of a real macro language like m4, yet has all the
> drawbacks of scopeless text substitution.

Looks like C++ is moving away from macros/preprocessor
And trying to be a respectable language
Stroustrup video from CppCon2021: https://www.youtube.com/watch?v=15QF2q66NhU

Ran across the Zig language recently: https://ziglang.org/
It would make a great HLS language as it wants to be a C replacement
and offers signed and unsigned integers of any bit width up to 65K.
Currently at release 0.9, eg a work in progress

On 12/23/21 5:17 PM, Ivan Godard wrote:
> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
> <snip>
>
>>
>> Not necessarily an answer but an observation:  in C no new language
>> feature is needed, because C has the C preprocessor.  It isn't hard
>> to write a macro that does the necessary shifting and masking (and
>> these days compilers are mostly smart enough to recognize the common
>> patterns and translate them efficiently and in machine-specific
>> ways).
>
> The C preprocessor is an invention of the Devil.
>
> It lacks the power of a real macro language like m4, yet has all the
> drawbacks of scopeless text substitution.

Didn't your Mary language have text-based recursive macros?
Though I have not seen a description of it.

On 12/23/2021 8:48 PM, Bakul Shah wrote:
> On 12/23/21 5:17 PM, Ivan Godard wrote:
>> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
>> <snip>
>>
>>>
>>> Not necessarily an answer but an observation:  in C no new language
>>> feature is needed, because C has the C preprocessor.  It isn't hard
>>> to write a macro that does the necessary shifting and masking (and
>>> these days compilers are mostly smart enough to recognize the common
>>> patterns and translate them efficiently and in machine-specific
>>> ways).
>>
>> The C preprocessor is an invention of the Devil.
>>
>> It lacks the power of a real macro language like m4, yet has all the
>> drawbacks of scopeless text substitution.
>
> Didn't your Mary language have text-based recursive macros?
> Though I have not seen a description of it.

Not text; bound names, like the (25 years later) C++ templates.

On Do 23 Dez 2021 at 16:10, MitchAlsup <MitchAlsup@aol.com> wrote:

> Adding it syntactically into the language would allow the offset and width
> to be anything in the range of an integer--imagine a bit field 11,357 bits long
> at offset 1,496 into a 29,000-bit container--and the compiler knows what code
> to produce. That is: real bit fields.
> <
> Perhaps this is a job for C++

Just gave a look into Common Lisp!

'Andreas

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
><snip>
>
>>
>> Not necessarily an answer but an observation: in C no new language
>> feature is needed, because C has the C preprocessor. It isn't hard
>> to write a macro that does the necessary shifting and masking (and
>> these days compilers are mostly smart enough to recognize the common
>> patterns and translate them efficiently and in machine-specific
>> ways).
>
> The C preprocessor is an invention of the Devil.
>
> It lacks the power of a real macro language like m4, yet has all the
> drawbacks of scopeless text substitution.

You may have worked more with m4 than I have, but I have found it
a rather severe example of hit and miss programming. Change some
quoting, run m4, check against wanted results. Repeat until
success or total frustration is achieved.

On 12/24/2021 6:24 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
>> <snip>
>>
>>>
>>> Not necessarily an answer but an observation: in C no new language
>>> feature is needed, because C has the C preprocessor. It isn't hard
>>> to write a macro that does the necessary shifting and masking (and
>>> these days compilers are mostly smart enough to recognize the common
>>> patterns and translate them efficiently and in machine-specific
>>> ways).
>>
>> The C preprocessor is an invention of the Devil.
>>
>> It lacks the power of a real macro language like m4, yet has all the
>> drawbacks of scopeless text substitution.
>
> You may have worked more with m4 than I have, but I have found it
> a rather severe example of hit and miss programming. Change some
> quoting, run m4, check against wanted results. Repeat until
> success or total frustration is achieved.

I quite agree - macro languages tend to be write-only. But they are true
second-order, and so are very powerful. Conventional languages (absent
things like C++ templates and all of SmallTalk and the like) can only do
second-order by generating new program text and then running that
through the compiler again.

But *any* second-order programming (the program, not the language) is a
non-trivial exercise. Most writers solve the intellectual tractability
problem by writing first order programs in their second order language -
c.f. compiling what might as well have been a C program with a C++
compiler.

Have you ever defined a template that took a template argument?

Le 24/12/2021 à 15:24, Thomas Koenig a écrit :
> Ivan Godard <ivan@millcomputing.com> schrieb:
>> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
>> <snip>
>>
>>>
>>> Not necessarily an answer but an observation: in C no new language
>>> feature is needed, because C has the C preprocessor. It isn't hard
>>> to write a macro that does the necessary shifting and masking (and
>>> these days compilers are mostly smart enough to recognize the common
>>> patterns and translate them efficiently and in machine-specific
>>> ways).
>>
>> The C preprocessor is an invention of the Devil.
>>
>> It lacks the power of a real macro language like m4, yet has all the
>> drawbacks of scopeless text substitution.
>
> You may have worked more with m4 than I have, but I have found it
> a rather severe example of hit and miss programming. Change some
> quoting, run m4, check against wanted results. Repeat until
> success or total frustration is achieved.

Yep. Same experience here. I also once tried replacing the C
preprocessor with M4. After a while, I realized that it was even worse
in terms of readability and ease of use, and not even powerful enough to
justify that.

On 12/24/2021 9:33 AM, Ivan Godard wrote:
> On 12/24/2021 6:24 AM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
>>> <snip>
>>>
>>>>
>>>> Not necessarily an answer but an observation:  in C no new language
>>>> feature is needed, because C has the C preprocessor.  It isn't hard
>>>> to write a macro that does the necessary shifting and masking (and
>>>> these days compilers are mostly smart enough to recognize the common
>>>> patterns and translate them efficiently and in machine-specific
>>>> ways).
>>>
>>> The C preprocessor is an invention of the Devil.
>>>
>>> It lacks the power of a real macro language like m4, yet has all the
>>> drawbacks of scopeless text substitution.
>>
>> You may have worked more with m4 than I have, but I have found it
>> a rather severe example of hit and miss programming.  Change some
>> quoting, run m4, check against wanted results.  Repeat until
>> success or total frustration is achieved.
>
> I quite agree - macro languages tend to be write-only. But they are true
> second-order, and so are very powerful. Conventional languages (absent
> things like C++ templates and all of SmallTalk and the like) can only do
> second-order by generating new program text and then running that
> through the compiler again.
>
> But *any* second-order programming (the program, not the language) is a
> non-trivial exercise. Most writers solve the intellectual tractability
> problem by writing first order programs in their second order language -
> c.f. compiling what might as well have been a C program with a C++
> compiler.
>
> Have you ever defined a template that took a template argument?

FWIW, I did experimentally add the ability to do something sorta like
PHP with the preprocessor in BGBCC; namely that code-generation
functions can be written in a JavaScript style language, and then
invoked as part of the macro expansion process.

Haven't really used it for much thus far as the actual need to do
anything like this is relatively infrequent.

Well, and also it is sorta now possible to compile JS style code in
BGBCC and link it directly with C code, though it is slightly less
dynamic than "true" JS:
Can't run arbitrary code in the toplevel;
No "eval" or similar (this would require an interpreter);
Doesn't automatically coerce strings into other types / ...;
Compiles to conventional native code (no real VM layer);
...

Though, more specifically, it is actually yet another language in the
wider family of "ECMAScript derived languages which constrain semantics
and add optional support for static types". Each language going its own
direction in terms of semantics and features, or which types exist, and
whether said types use camelCase or InitCaps, ...

In this case, it shares the same parser and compiler logic as when
compiling C code, just enabling/disabling some things in areas where the
languages differ.

Dynamic types and lambdas and similar are mostly handled by the runtime
library (dynamically typed code mostly compiles into a mass of function
calls).

There is also no GC in this case, but rather a simpler scheme:
New objects are initially "automatic scope"
If they don't leave the this scope, they remain here;
They are 'deleted' as soon as the function returns.
Assigning to a global location may move them into global scope:
Global Variable;
Array within a global scope;
Object field within a global scope.

Objects which move into the global scope may be manually deleted, but
otherwise do not go away on their own (so, this case is basically a
memory leak).

It is possible this could be extended to a zone system. Zones could be
organized in a tree, where objects either walk up the zone tree, or move
to global if no common zone exists. It would (by extension) be possible
for a program to delete all objects within a given zone.

Note that moving an object to a longer-lived zone will also recursively
apply to any other objects this object points to (objects can only point
to objects within a longer-lived zone).

While reference-counting is also theoretically possible, it has drawbacks:
Hard to get the ref-counting to be "always correct".
A minor mismatch somewhere can lead to the whole system breaking.
Fairly high runtime overhead compared with most other options.
Prone to leak if circular links form.

Could also add a (semi)conservative mark/sweep:
Mostly plays well with C (excluding a few "mostly theoretical" edge cases);
However, adds code bulk and does not play well with real-time systems.

....

According to Ivan Godard <ivan@millcomputing.com>:
>I quite agree - macro languages tend to be write-only. But they are true
>second-order, and so are very powerful. Conventional languages (absent
>things like C++ templates and all of SmallTalk and the like) can only do
>second-order by generating new program text and then running that
>through the compiler again.
>
>But *any* second-order programming (the program, not the language) is a
>non-trivial exercise. Most writers solve the intellectual tractability
>problem by writing first order programs in their second order language -
>c.f. compiling what might as well have been a C program with a C++
>compiler.

That's one of the things that PL/I did well over 50 years ago. The PL/I
preprocessor is a PL/I subset adeqate to do the kind of text
processing that preprocessors need. Considering what a rush job it was,
PL/I was a surprisingly good language.

Back in my youth I recall a student PL/I setup that limited the run time
of a program but not the compile time, so some bright bulb wrote a
program that did everything in the preprocessor, generating just a
print statement of the result.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Friday, December 24, 2021 at 1:48:23 PM UTC-6, John Levine wrote:
> According to Ivan Godard <iv...@millcomputing.com>:
> >I quite agree - macro languages tend to be write-only. But they are true
> >second-order, and so are very powerful. Conventional languages (absent
> >things like C++ templates and all of SmallTalk and the like) can only do
> >second-order by generating new program text and then running that
> >through the compiler again.
> >
> >But *any* second-order programming (the program, not the language) is a
> >non-trivial exercise. Most writers solve the intellectual tractability
> >problem by writing first order programs in their second order language -
> >c.f. compiling what might as well have been a C program with a C++
> >compiler.
> That's one of the things that PL/I did well over 50 years ago. The PL/I
> preprocessor is a PL/I subset adeqate to do the kind of text
> processing that preprocessors need. Considering what a rush job it was,
> PL/I was a surprisingly good language.
>
> Back in my youth I recall a student PL/I setup that limited the run time
> of a program but not the compile time, so some bright bulb wrote a
> program that did everything in the preprocessor, generating just a
> print statement of the result.
<
WATFIV was a compile-and-run environment which CMU limited to 1 second of
execution time. We found that if you were "in" a write-statement it only checked
CPU time before and after the write; so, we could run almost arbitrarily long
programs as long as they could be made to execute entirely within a write-
statement !
<
But I have (still) never found a compiler so friendly with debug and warning
messages as PL/C. I once inserted a card deck into the card reader backwards
and the PL/C compiler found all the end-do loops ,... and even crafted meaningful
error and warning messages that made sense to the programmer (not the compiler
writer). If they could do that in 1973 why can't we do that today ?
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On Friday, December 24, 2021 at 1:48:23 PM UTC-6, John Levine wrote:
> According to Ivan Godard <iv...@millcomputing.com>:
> >I quite agree - macro languages tend to be write-only. But they are true
> >second-order, and so are very powerful. Conventional languages (absent
> >things like C++ templates and all of SmallTalk and the like) can only do
> >second-order by generating new program text and then running that
> >through the compiler again.
> >
> >But *any* second-order programming (the program, not the language) is a
> >non-trivial exercise. Most writers solve the intellectual tractability
> >problem by writing first order programs in their second order language -
> >c.f. compiling what might as well have been a C program with a C++
> >compiler.
> That's one of the things that PL/I did well over 50 years ago. The PL/I
> preprocessor is a PL/I subset adeqate to do the kind of text
> processing that preprocessors need. Considering what a rush job it was,
> PL/I was a surprisingly good language.
>
> Back in my youth I recall a student PL/I setup that limited the run time
> of a program but not the compile time, so some bright bulb wrote a
> program that did everything in the preprocessor, generating just a
> print statement of the result.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

At my current level of understanding:
An interesting feature of Zig is that instead of a macro or preprocessor the compiler
will execute at compile time anything the can be computed at compile time
(including type expressions). Thus the language itself is it's own preprocessor.
And like the RTL languages, simplification and reduction is carried as far as possible.

On Friday, December 24, 2021 at 3:29:02 PM UTC-6, JimBrakefield wrote:
> On Friday, December 24, 2021 at 1:48:23 PM UTC-6, John Levine wrote:
> > According to Ivan Godard <iv...@millcomputing.com>:
> > >I quite agree - macro languages tend to be write-only. But they are true
> > >second-order, and so are very powerful. Conventional languages (absent
> > >things like C++ templates and all of SmallTalk and the like) can only do
> > >second-order by generating new program text and then running that
> > >through the compiler again.
> > >
> > >But *any* second-order programming (the program, not the language) is a
> > >non-trivial exercise. Most writers solve the intellectual tractability
> > >problem by writing first order programs in their second order language -
> > >c.f. compiling what might as well have been a C program with a C++
> > >compiler.
> > That's one of the things that PL/I did well over 50 years ago. The PL/I
> > preprocessor is a PL/I subset adeqate to do the kind of text
> > processing that preprocessors need. Considering what a rush job it was,
> > PL/I was a surprisingly good language.
> >
> > Back in my youth I recall a student PL/I setup that limited the run time
> > of a program but not the compile time, so some bright bulb wrote a
> > program that did everything in the preprocessor, generating just a
> > print statement of the result.
> >
> > --
> > Regards,
> > John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> > Please consider the environment before reading this e-mail. https://jl.ly
>
> At my current level of understanding:
> An interesting feature of Zig is that instead of a macro or preprocessor the compiler
> will execute at compile time anything the can be computed at compile time
> (including type expressions). Thus the language itself is it's own preprocessor.
> And like the RTL languages, simplification and reduction is carried as far as possible.
<
If I recall correctly::
<
After compilation. the Mary compiler would start at the front of the <linked> program
and synthetically execute the program as far as possible, changing execution code
back into compile time constants. This was in 1981--how l<lack of> far we have come.

MitchAlsup <MitchAlsup@aol.com> schrieb:

> But I have (still) never found a compiler so friendly with debug and warning
> messages as PL/C. I once inserted a card deck into the card reader backwards
> and the PL/C compiler found all the end-do loops ,... and even crafted meaningful
> error and warning messages that made sense to the programmer (not the compiler
> writer). If they could do that in 1973 why can't we do that today ?

https://chili-con-spiracy.com/proofreading/ comes to mind.

I've never used PL/C, but Wikipedia states (without source)

# The PL/C compiler had the unusual capability of never failing
# to compile any program, through the use of extensive automatic
# correction of many syntax errors and by converting any remaining
# syntax errors to output statements.

That sounds dubious to me, errors should be reported (in a useful
and friendly manner), but auto-correction... DWIM never really
worked.

Guillaume <message@bottle.org> schrieb:
> Le 24/12/2021 à 15:24, Thomas Koenig a écrit :
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
>>> <snip>
>>>
>>>>
>>>> Not necessarily an answer but an observation: in C no new language
>>>> feature is needed, because C has the C preprocessor. It isn't hard
>>>> to write a macro that does the necessary shifting and masking (and
>>>> these days compilers are mostly smart enough to recognize the common
>>>> patterns and translate them efficiently and in machine-specific
>>>> ways).
>>>
>>> The C preprocessor is an invention of the Devil.
>>>
>>> It lacks the power of a real macro language like m4, yet has all the
>>> drawbacks of scopeless text substitution.
>>
>> You may have worked more with m4 than I have, but I have found it
>> a rather severe example of hit and miss programming. Change some
>> quoting, run m4, check against wanted results. Repeat until
>> success or total frustration is achieved.
>
> Yep. Same experience here. I also once tried replacing the C
> preprocessor with M4. After a while, I realized that it was even worse
> in terms of readability and ease of use, and not even powerful enough to
> justify that.

m4 is Turing-complete, and thus as poweful as anything else in
a computer. For use with C, if your code uses single characters,
using ' as quote character can cause issues unless you learn the
rules carefully. Or, you can use changequote.

I've been dealing with it within two environments: autoconf
configure scripts and the generated libgfortran files. Right now I
am embarked on a project which involves both, and it is heavy going.

On Friday, December 24, 2021 at 4:28:58 PM UTC-6, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > But I have (still) never found a compiler so friendly with debug and warning
> > messages as PL/C. I once inserted a card deck into the card reader backwards
> > and the PL/C compiler found all the end-do loops ,... and even crafted meaningful
> > error and warning messages that made sense to the programmer (not the compiler
> > writer). If they could do that in 1973 why can't we do that today ?
> https://chili-con-spiracy.com/proofreading/ comes to mind.
>
> I've never used PL/C, but Wikipedia states (without source)
>
> # The PL/C compiler had the unusual capability of never failing
> # to compile any program, through the use of extensive automatic
> # correction of many syntax errors and by converting any remaining
> # syntax errors to output statements.
>
> That sounds dubious to me, errors should be reported (in a useful
> and friendly manner), but auto-correction... DWIM never really
> worked.
<
I am not really praising the auto-correction, but the complete diagnostic
of whatever got fed to the compiler. Today's compilers tend to give a
couple of handfuls of error messages, then just quit.
<
Secondarily, the errors were readable to someone never inside of a compiler
before with ASCII pointers to character at which the error was first detected--
not just the line on which the error occurred.

On 12/24/21 1:27 PM, MitchAlsup wrote:
> But I have (still) never found a compiler so friendly with debug and warning
> messages as PL/C. I once inserted a card deck into the card reader backwards
> and the PL/C compiler found all the end-do loops ,... and even crafted meaningful
> error and warning messages that made sense to the programmer (not the compiler
> writer). If they could do that in 1973 why can't we do that today ?

PL/C is what they used to teach programming (at least in some classes)
at USC. But many students were puzzled when they did exactly what the
PL/C compiler said it did to continue compiling their program and
it still didn't work :-)

The macro languages of Scheme and Common Lisp are quite powerful.
CL's much more so than Scheme's. But these languages are not very
popular.

On 12/24/21 1:29 PM, JimBrakefield wrote:
> At my current level of understanding:
> An interesting feature of Zig is that instead of a macro or preprocessor the compiler
> will execute at compile time anything the can be computed at compile time
> (including type expressions). Thus the language itself is it's own preprocessor.
> And like the RTL languages, simplification and reduction is carried as far as possible.

The "V" language also does this. But this is not the same as decent
macro processing. Scheme/CL macros allow you to abstract away details
very nicely but for that to work, there needs to a language syntax model
the macros can access. This is much simpler in S-expr languages since
the AST *is* the concrete syntax (more or less)!

On 12/24/2021 3:52 PM, Bakul Shah wrote:
> On 12/24/21 1:29 PM, JimBrakefield wrote:
>> At my current level of understanding:
>> An interesting feature of Zig is that instead of a macro or
>> preprocessor the compiler
>> will execute at compile time anything the can be computed at compile time
>> (including type expressions).  Thus the language itself is it's own
>> preprocessor.
>> And like the RTL languages, simplification and reduction is carried as
>> far as possible.
>
> The "V" language also does this. But this is not the same as decent
> macro processing. Scheme/CL macros allow you to abstract away details
> very nicely but for that to work, there needs to a language syntax model
> the macros can access. This is much simpler in S-expr languages since
> the AST *is* the concrete syntax (more or less)!

SmallTalk had the execution context accessible and mutable by the
running program, including during translation. Rarely used but immensely
powerful. I once did a co-routine system where "visit" severed the call
stack in the middle and rehooked it to the top of the call stack of the
visitee.

But second order usage is hard to grok. Unfortunately, reality is second
order. Probably has to be, or it wouldn't be real. That's an example.

On Fr 24 Dez 2021 at 15:48, Bakul Shah <bakul@iitbombay.org> wrote:

> The macro languages of Scheme and Common Lisp are quite powerful.
This is true.

> CL's much more so than Scheme's.
That is not so. Theoretically (and practically) thet are on the same
level, but Scheme has several different macro systems - even a hygienic
one.

>But these languages are not very popular.
Unfortunately, that's true.

Happy Xmas,

'Andreas

On 12/25/21 12:11 AM, Andreas Eder wrote:
> On Fr 24 Dez 2021 at 15:48, Bakul Shah <bakul@iitbombay.org> wrote:
>
>> The macro languages of Scheme and Common Lisp are quite powerful.
> This is true.
>
>> CL's much more so than Scheme's.
> That is not so. Theoretically (and practically) thet are on the same
> level, but Scheme has several different macro systems - even a hygienic
> one.

Note that I am not an expert in this area but everything I
have read so far says CL macros are more powerful than
Scheme's. Scheme's are *safer* but less powerful. See for
instance
https://letoverlambda.com/index.cl/guest/chap3.html#sec_4
where the author says:
Hygienic macros are, in the best of situations, a beginner's
safety guard-rail; in the worst of situations they form an
electric fence, trapping their victims in a sanitised,
capture-safe prison. Furthermore, recent research has shown
that hygienic macro systems like those specified by various
Scheme revisions can still be vulnerable to many interesting
capture problems

Mind you, I vastly prefer Scheme purely for aesthetics and
simplicity reasons. Not that it matters since I never wrote
Scheme or CL code for a living.

>> But these languages are not very popular.
> Unfortunately, that's true.

Yup. Very unfortunate.

>
> Happy Xmas,
>
> 'Andreas
>

On Sa 25 Dez 2021 at 01:42, Bakul Shah <bakul@iitbombay.org> wrote:

> On 12/25/21 12:11 AM, Andreas Eder wrote:
>> On Fr 24 Dez 2021 at 15:48, Bakul Shah <bakul@iitbombay.org> wrote:
>>
>>> The macro languages of Scheme and Common Lisp are quite powerful.
>> This is true.
>>
>>> CL's much more so than Scheme's.
>> That is not so. Theoretically (and practically) thet are on the same
>> level, but Scheme has several different macro systems - even a hygienic
>> one.
>
> Note that I am not an expert in this area but everything I
> have read so far says CL macros are more powerful than
> Scheme's. Scheme's are *safer* but less powerful. See for
> instance
> https://letoverlambda.com/index.cl/guest/chap3.html#sec_4
> where the author says:
> Hygienic macros are, in the best of situations, a beginner's
> safety guard-rail; in the worst of situations they form an
> electric fence, trapping their victims in a sanitised,
> capture-safe prison. Furthermore, recent research has shown
> that hygienic macro systems like those specified by various
> Scheme revisions can still be vulnerable to many interesting
> capture problems

The problem with Scheme is, that there are different standards (RxRS for
x from 5 to 7) but in a scheme that supports syntax-case zou can define
CL's defmacro and some implementations already have it (maybe under yhe
name of define-macro).

For more about that topic you should read
https://stackoverflow.com/questions/19664993/is-it-possible-to-implement-common-lisps-macro-system-in-scheme

That should clarify the point better than I could here.

'Andreas

Ivan Godard <ivan@millcomputing.com> writes:
>I quite agree - macro languages tend to be write-only. But they are true
>second-order, and so are very powerful. Conventional languages (absent
>things like C++ templates and all of SmallTalk and the like) can only do
>second-order by generating new program text and then running that
>through the compiler again.

Most interactive languages are "the like", because it's something the
system has to implement anyway. Some offer just a string-based
interface, some also provide access to other levels. Lisp's
S-Expressions have been mentioned.

>But *any* second-order programming (the program, not the language) is a
>non-trivial exercise.

It seems to me that, like all programming, it's a matter of the amount
of exercise. If you program rarely, any programming is a non-trivial
exercise. If you second-order program rarely, every second-order
program is a non-trivial exercise. I have seen cases where a
second-order Forth program was simpler than a single-level program for
the same problem (but am too lazy to search for it right now). And
yet, some of the work I have done in recent times has been for
facilitating single-level programming (in particular, by adding
closures), but I have also added features for making second-order
programming easier.

>Most writers solve the intellectual tractability
>problem by writing first order programs in their second order language -

If these languages are different (as in C++ and C), that's of course a
particular hurdle that makes the whole thing much harder and less
trivial.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>
>> But I have (still) never found a compiler so friendly with debug and warning
>> messages as PL/C. I once inserted a card deck into the card reader backwards
>> and the PL/C compiler found all the end-do loops ,... and even crafted meaningful
>> error and warning messages that made sense to the programmer (not the compiler
>> writer). If they could do that in 1973 why can't we do that today ?
>
> https://chili-con-spiracy.com/proofreading/ comes to mind.
>
> I've never used PL/C, but Wikipedia states (without source)
>
> # The PL/C compiler had the unusual capability of never failing
> # to compile any program, through the use of extensive automatic
> # correction of many syntax errors and by converting any remaining
> # syntax errors to output statements.
>
> That sounds dubious to me, errors should be reported (in a useful
> and friendly manner), but auto-correction... DWIM never really
> worked.

About 25 or so years ago I wrote an LALR(1) table generator and parser
with autocorrect. Autocorrect worked quite well.

Autocorrect was 'a thing' back when compiles were so expensive,
batch jobs on time share systems with minutes to hours turn around,
that you wanted to correct as many errors as possible for each run.

Autocorrect would replace, insert, or delete multiple tokens to discover
the lowest cost repair sequence and had configurable limits on number of
valid tokens after a repair to shift to declare a repair valid,
and a time limit to spend looking for better repairs.

It used a breadth-first search to discover any repair,
which sets an upper limit for repair costs,
then burrows down depth-first to discover better repairs,
fetching ahead tokens in the input stream validating future sequences too.

Parser was a deferred reduction parser so it could step backwards
one reduction and try to replace,insert,delete in earlier sequences.

It can't create identifiers so repairing a syntax error by inserting
an Identifier can lead to a semantic error later, but the inserted
tokens were marked so their semantic error messages can be suppressed.
But it could plow through syntax errors and keep compiling.

I've given it C, Java and Ada syntaxes and tested it by pounding
on the keyboard. It would spit out correct syntax.