At my tedious glacial pace, I have rewritten my parser library
for the umpteen-plus-one'th time only to stall out at an earlier
step than where I stalled out the last time around.
On Wednesday, September 7, 2022 at 4:01:04 PM UTC-5, luser droog wrote:
At my tedious glacial pace, I have rewritten my parser librarySorry for the noise. I'm prematurely optimizing, aren't I? The function
for the umpteen-plus-one'th time only to stall out at an earlier
step than where I stalled out the last time around.
that works just fine and is already reasonably short and readable is
just fine for now. Folding and iotas will probably be a fun idea to try --
on the next rewrite. On to possibly important problems....
[It occurred to me that if you want to write in a functional language style, doing it in C is really painful. -John]
C is a nice small imperative language. It's fine for expressing those
kinds of semantics. The C preprocessor is both simple and powerful, but it doesn't change the nature of C. You cannot really do "compilation" in the
C preprocessor.
:
PL/I does have a powerful preprocessor, though I don't know so many
actually using its power. It even has preprocessor procedures, if you
need them.
:
On a related note, I have heard stories from C++ compiler
implementors about the various template libraries that have been created which attempt to do "Turing machine" style (NP-complete) computations via types and parameters, where the users wonder why the compilation process takes much longer than running the resultant program.
While I hate being extremely pessimistic, you are going in absolutely the wrong direction.
If you want a functional language, use one. Don't try to turn C into a functional language. Even if you succeed, you will have made a mess that
no one (probably not even you) will actually understand.
I say that from experience. Early on in writing Yacc++, we did macros that allowed us to write object-oriented C, which had C++-like semantics (ala 1986, pre-templates, pre STL, etc.) with nice ABC (abstract base classes, plus some inheritance and polymorphism). It worked. However, it was a challenge to understand. Our wisest move was at 2.0 rewriting everything
in C++ and not trying to have a "C" layer with similar functionality. The code was an order-of-magnitude simpler and even making a translation that
did C# was relatively trivial from that code.
C is a nice small imperative language. It's fine for expressing those
kinds of semantics. The C preprocessor is both simple and powerful, but it doesn't change the nature of C. You cannot really do "compilation" in the
C preprocessor. And, if you really want a parser combinator library, you
want it to do some compilation. Otherwise, you have just masked the fact
that you are doing hand-written recursive descent. And, if you want to do hand-written recursive descent, do it. Don't put lipstick on a pig and
take it to the opera.
There is a reason your attempts are failing.
You don't have good closures or co-routines in C.
You cannot get them easily. You cannot really
interact well with the function stack in C.
And, your efforts to put the
state behind pointers, while necessary only get you part of the way there.
So, if you are lucky, you will have something that looks like a parser combinator language, but which actually has either
- broken semantics (i.e. cases that don't work properly and don't warn you that they don't)
or
- is very complicated.
On Monday, September 12, 2022 at 2:46:47 PM UTC-5, christoph...@compiler-resources.com wrote:
And, your efforts to put theThat's also true. For the present case, I'll also need to dynamically allocate
state behind pointers, while necessary only get you part of the way there.
integer objects and keep them in the environment for the calling
function which is one of these closures, a suspension function that converts the first element of a stream and returns a list with a suspension in the cdr.
That's the only way I'll get row and column counters to exist on a per-file basis.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 58:24:35 |
Calls: | 6,712 |
Files: | 12,243 |
Messages: | 5,355,631 |