I'm really hooked on the parser combinator stuff. And I've made several
attempts to implement them in C. But I'm falling into the known trap of
"Greenspun's 10th". It's so tempting to try to turn C into something else.
Twiddle the syntax with macros. Closures and garbage collection and
tag unions. Typedef-ing the pointer.

How do you dig back out of the hole? Like, have shovel, in a hole, what to do?

I found one possibility by going back to the earliest literature from all
the bibs. ie. Budge, "Recursive Programming Techniques", 1975.
And he seems to be saying you don't have to do all that, if I'm reading it
right. You can do all the combinators and build your parser with
function calls so it looks all nice like a grammar. But these combinator
functions don't actually need to return "the parsers" themselves.
They can just build a data structure and then you just write some
more normal looking C functions to tree traverse up and down it,
right?

Does the same strategy extend to other FP stuff that seems cool?
Can I do all the cool stuff in C without implementing half of Lisp?

On 24/11/2021 03:48, luser droog wrote:
> I'm really hooked on the parser combinator stuff. And I've made several
> attempts to implement them in C. But I'm falling into the known trap of
> "Greenspun's 10th". It's so tempting to try to turn C into something else.
> Twiddle the syntax with macros. Closures and garbage collection and
> tag unions. Typedef-ing the pointer.
>
> How do you dig back out of the hole? Like, have shovel, in a hole, what to do?
>

If you find the code you are trying to write is so far from "normal" or
"idiomatic" C that you are in effect trying to use C as a different
language, then the answer is to use a different language that lets you
write the code the way you want to write it. C is a great language for
some tasks, and so painful as to be practically useless for other tasks.
No one sane uses C for code that involves a great deal of string
manipulation, parsing, and the like unless the code is going to see
massive use and the last drops of performance are important enough to
justify the development time, the unmaintainable results, and the risk
of errors. When you are trying to write code that requires a great deal
of housekeeping, switch to a language that will do the housekeeping for
you so that you can concentrate on the bits that /can't/ be automated.

The choice of language depends on the features you /want/ in the
language (not necessarily what you /need/ - after all, you /can/ write
pretty much anything in C if you spend the effort). It also depends on
available libraries to make life easier, it depends on the languages you
know or can reasonably learn, amongst other things.

And if this is all for fun and interest, then the main concern should be
finding which parts of the whole concept are of most interest to you,
and picking a language that lets you concentrate on that part, and
handles everything lower level automatically. (Unless, of course, the
fun bit for you is implementing hard stuff in C, in which case there is
no wrong C!)

Am 24.11.21 um 09:26 schrieb David Brown:

> And if this is all for fun and interest, then the main concern should be
> finding which parts of the whole concept are of most interest to you,
> and picking a language that lets you concentrate on that part, and
> handles everything lower level automatically.
Note that there are also tools, like lex and yacc, that will handle the
parts that are hard to do in C for you, and can be used together with
your C code for the other tasks.

Philipp Klaus Krause <pkk@spth.de> writes:

> Am 24.11.21 um 09:26 schrieb David Brown:
>
>> And if this is all for fun and interest, then the main concern should be
>> finding which parts of the whole concept are of most interest to you,
>> and picking a language that lets you concentrate on that part, and
>> handles everything lower level automatically.
>
> Note that there are also tools, like lex and yacc, that will handle the
> parts that are hard to do in C for you, and can be used together with
> your C code for the other tasks.

True, but I don't think the objective is to parse anything in articular
but to develop a parsing toolkit based, as closely as C will reasonably
permit, on the combiner model that is popular in functional languages.

--
Ben.

On Thursday, November 25, 2021 at 8:28:56 AM UTC-6, Ben Bacarisse wrote:
> Philipp Klaus Krause <p...@spth.de> writes:
>
> > Am 24.11.21 um 09:26 schrieb David Brown:
> >
> >> And if this is all for fun and interest, then the main concern should be
> >> finding which parts of the whole concept are of most interest to you,
> >> and picking a language that lets you concentrate on that part, and
> >> handles everything lower level automatically.
> >
> > Note that there are also tools, like lex and yacc, that will handle the
> > parts that are hard to do in C for you, and can be used together with
> > your C code for the other tasks.
> True, but I don't think the objective is to parse anything in articular
> but to develop a parsing toolkit based, as closely as C will reasonably
> permit, on the combiner model that is popular in functional languages.
>

Yes, no precise goals beyond that except vague dreams of using this
toolkit to write an LCC for the next millennium. A C compiler so amazingly
concise and readable to invite and facilitate further extensions and
experimentation. But, if I lean too far in the traditional C direction, then
there's already https://github.com/orangeduck/mpc

So, I was leaning into the functional side to try to be different.

As a more specific symptom, though. I wrote that C comment remover
with a hefty pinch of lisp-alike gymnastics.

https://codereview.stackexchange.com/questions/254005/removing-c-comments-from-source

And maybe I ought to at least try to re-write it to be more like a normal
C programmer would do it. With a string buffer type or something.
Something other than cons chains.

I really like having the main() code read nicely like a high level pseudocode.
But maybe I can achieve that without the tag unions.

luser droog <luser.droog@gmail.com> writes:

> On Thursday, November 25, 2021 at 8:28:56 AM UTC-6, Ben Bacarisse wrote:
>> Philipp Klaus Krause <p...@spth.de> writes:
>>
>> > Am 24.11.21 um 09:26 schrieb David Brown:
>> >
>> >> And if this is all for fun and interest, then the main concern should be
>> >> finding which parts of the whole concept are of most interest to you,
>> >> and picking a language that lets you concentrate on that part, and
>> >> handles everything lower level automatically.
>> >
>> > Note that there are also tools, like lex and yacc, that will handle the
>> > parts that are hard to do in C for you, and can be used together with
>> > your C code for the other tasks.
>> True, but I don't think the objective is to parse anything in
>> > articular
particular!
>> but to develop a parsing toolkit based, as closely as C will reasonably
>> permit, on the combiner model that is popular in functional
combinator!
>> > languages.

> Yes, no precise goals beyond that except vague dreams of using this
> toolkit to write an LCC for the next millennium. A C compiler so amazingly
> concise and readable to invite and facilitate further extensions and
> experimentation.

C's grammar is not particularly regular. That part will always be a bit
messy.

> But, if I lean too far in the traditional C direction, then
> there's already https://github.com/orangeduck/mpc
>
> So, I was leaning into the functional side to try to be different.

But, since C is resolutely procedural, that's a rather artificial
challenge. A clear, easily modifiable C parser, written in C, does not
have to use mocked-up combinators.

> As a more specific symptom, though. I wrote that C comment remover
> with a hefty pinch of lisp-alike gymnastics.

One person's elegant gymnastics is another person's painful contortions!

> https://codereview.stackexchange.com/questions/254005/removing-c-comments-from-source
>
> And maybe I ought to at least try to re-write it to be more like a
> normal C programmer would do it. With a string buffer type or
> something. Something other than cons chains.
>
> I really like having the main() code read nicely like a high level
> pseudocode. But maybe I can achieve that without the tag unions.

The C I write is influenced by my experience with functional languages
but it's mostly superficial because C does not have the fundamental
types needed.

--
Ben.

luser droog <luser.droog@gmail.com> writes:

[...]

> I found one possibility by going back to the earliest literature
> from all the bibs. ie. Budge, "Recursive Programming Techniques",
> 1975. [...]

Is that Burge?

On Friday, December 10, 2021 at 3:11:52 AM UTC-6, Tim Rentsch wrote:
> luser droog <luser...@gmail.com> writes:
>
> [...]
> > I found one possibility by going back to the earliest literature
> > from all the bibs. ie. Budge, "Recursive Programming Techniques",
> > 1975. [...]
>
> Is that Burge?

Yes, W. H. Burge.

On Tuesday, November 23, 2021 at 9:48:06 PM UTC-5, luser droog wrote:
> .. It's so tempting to try to turn C into something else.
> Twiddle the syntax with macros. ...

One of the "most memorable" (to me "worst" :-) cases where I've seen this done
was a linker called "VAL"... basically mostly done in a "language" not much like C.

You can see it through my "Daves Old Computers" site, go to "Download DOS Widgets"
near the bottom:
http://dunfield.classiccmp.org/dos/index.htm

Then grab VAL_SRC[.ZIP]

and have an "interesting" read!

--
Dave Dunfield ::: "Daves Old Computers" -> Personal

On Friday, December 10, 2021 at 10:11:24 PM UTC-6, dave.d...@gmail.com wrote:
> On Tuesday, November 23, 2021 at 9:48:06 PM UTC-5, luser droog wrote:
> > .. It's so tempting to try to turn C into something else.
> > Twiddle the syntax with macros. ...
>
> One of the "most memorable" (to me "worst" :-) cases where I've seen this done
> was a linker called "VAL"... basically mostly done in a "language" not much like C.
>
> You can see it through my "Daves Old Computers" site, go to "Download DOS Widgets"
> near the bottom:
> http://dunfield.classiccmp.org/dos/index.htm
>
> Then grab VAL_SRC[.ZIP]
>
> and have an "interesting" read!
>

Wow. Nice example. Goes far beyond the oft cited Bourne shell source.
https://news.ycombinator.com/item?id=22191790
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh

I think my examples aren't actually that extreme. I mostly use macros for
code generation or what I like to call "aggressive factoring". Stuff like
X-Macros and that ugly/beautiful PP_NARG() macro. I do have a soft spot
for implicit int, and hide as many pointers as possible behind macros
(always with some plausible--to me--rationalization, of course).

Relying on implicit int allows this <adjective> macro which lets you
create C functions that look like Lisp (provided you design the rest
of the program to use ints in some crazy manner that they hold all
the various types you need):

#define defun(NAME,ARGS,...) \
int NAME ARGS { IFDEBUG(2, fprintf(stderr, "%s ", __func__)); return __VA_ARGS__; }

(only tested with gcc where it requires --std=gnu99 or --std=c99 and not -pedantic*.)..
(I take that back. I actually use "-Wno-implicit-int -Wno-implicit-function-declaration -g"
and made up the previous parenthetical.)
(Looking at it now, I have second thoughts about the IFDEBUG() macro. That should
probably be a regular "if(){}".)

And those tag-unions. I friggin' love them. It's my hammer. All over this land.

On Friday, December 10, 2021 at 5:02:33 PM UTC-6, luser droog wrote:
> On Friday, December 10, 2021 at 3:11:52 AM UTC-6, Tim Rentsch wrote:
> > luser droog <luser...@gmail.com> writes:
> >
> > [...]
> > > I found one possibility by going back to the earliest literature
> > > from all the bibs. ie. Budge, "Recursive Programming Techniques",
> > > 1975. [...]
> >
> > Is that Burge?
> Yes, W. H. Burge.

It is btw an surprisingly excellent book. It's like a proto-SICP where he
just uses a pure subset of Lisp to start with. I only skimmed the sorting
chapter but I read the other 4 pretty thoroughly.

It's like a compiler textbook in reverse or a language primer that's inside
out. He explains control structures by first showing you how to compile
them into SKI combinators or a stack machine or an SECD machine.

Then, he goes into data structures like lists and trees and streams
and even coroutines. And then a whole chapter on parsers. As I said
upthread the combinators are used to build a tree data structure
representing the language grammar and then various parsing
strategies like top-down, bottom-up left-corner, bottom-up right-corner,

Even the sorting chapter has some neat stuff like how to construct
sorting networks for a fixed number of inputs.

It's a forgotten classic IMO. Or at least I wish I'd found it sooner.
Going on the shelf next to the '62 APL book when I'm done with it.

On 11/12/2021 04:11, Dave Dunfield wrote:
> On Tuesday, November 23, 2021 at 9:48:06 PM UTC-5, luser droog wrote:
>> .. It's so tempting to try to turn C into something else.
>> Twiddle the syntax with macros. ...
>
> One of the "most memorable" (to me "worst" :-) cases where I've seen this done
> was a linker called "VAL"... basically mostly done in a "language" not much like C.
>
> You can see it through my "Daves Old Computers" site, go to "Download DOS Widgets"
> near the bottom:
> http://dunfield.classiccmp.org/dos/index.htm
>
> Then grab VAL_SRC[.ZIP]
>
> and have an "interesting" read!

Some of that is reasonable but this is taking it a bit far:

#define LessThanOrEqualTo <=

Re: Macros generating code

I rarely use macros to generate code "just for looks". I'm a strong
believer in "you should be able to tell much what it does by just
looking at it", and "we all know C -As It Is- fairly well". Don't like
to have to "Second guess" what someone is doing - the name might sound
"obvious" but you still have to know the macro to see "for sure".

That being said, one of my long time favorites is for generating
simple "debug output":

#define Debug(a) //printf a;
#define Debug1(a) printf a;

The reason there are TWO macros it lets me easily turn debug on/off
in any location just by adding or removing a single character '1'.
I can add more similar Macros to control it more by numbered "type"
but I find just the two are usually good enough!

I can remove // from the Debug() definition to enable ALL debug
output.

Use is "close" to printf(), just two levels of brackets and no
ending ';' :

Debug1(("Var1=%u Str1='%s'\n", Var1, Str1))

This "generates":
-----
printf ("Var1=%d Str1='%s'\n", Var1, Str1);
-----

If I change it to "Debug((...))" it generates:
-----

-----

So I can sprinkle LOTS of debug output while "working things out",
easily turn it ALL off for production code, and back on if I have
to work on some aspect of it later!

And no excessive extra lines/stuff (#if's etc.) cluttering up the
code visually!

I'm sure most everyone here has come up with "something similar"
but I'm giving detail as it still might be of benefit to newbies!

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)