Not really. But if you make UNREAD in Snap, or Python, or maybe Lisp, I might understand it.
Oh! Here you go:
<-----
P.S. Yeah, I could have made TEXT OBJECT FROM return a dispatch procedure with methods inside, I know.
aww two sides one coin
i reinvented it before due to danielthebanana4 wanting a dpla parser
a parse class
coded in js or python
but not snap
thats bad
because im using pointers
it disobeys snap's higher order functions
You could write a purely functional one, in which case each call to READ, PEEK, or UNREAD would report a freshly allocated text object, and each text object could include a third item which would be the most recently read character, so the user could easily extract it.
yes but it would be harder
anyways im working on it now
Is JOIN CHAR TEXT supposed to be JOIN CHAR ITEM 1 OF TEXT?
Anyways, with a few adjustments to get rid of script variables in blocks, I got it working: here.
Oh oops. Yeah, sorry.
I'm going to attempt this.
Edit: I got some progress done, but it still doesn't quite work. Can you see what's wrong in it? Here are a couple script pics of it not working:
I decided your code was too complicated to read, because you don't totally believe in recursion, so I rewrote it:
https://snap.berkeley.edu/snap/snap.html#present:Username=bh&ProjectName=parse%20λ
The procedures I replaced have names like BH PARSE CALL etc. so that your versions are still there for comparison.
I'm not sure the list structure I report is exactly how you want it, but if not, that part's easy to change; just replace the calls to LIST with whatever format you want.
It's exactly what I need! I did change it a bit, but just to WARP everything.
I vaguely recall Jens saying that reporters are automatically warped, but I could be wrong about that.
The places with error messages should really only show the still-unread part of the text. And I think there are some redundant calls to SKIP WHITESPACE. And maybe you want to check that the text buffer is empty at the end, or maybe you want to allow another expression on the same text line.
But isn't it awesome how little code you need if you just believe that PARSE λ EXPR and PARSE CALL will do their jobs correctly? And also, you see why I wanted that text-buffer feature, right? Because when you see an open paren, you have to make two recursive calls to PARSE EXPR, and the second one won't work unless you're keeping track of how far into the line you are.
Maybe, but the (λnumber.λf.λx.(f ((number f) x)) λx.λy.y) takes maybe half a second to a second, unless it's WARPed, in which case it's virtually instantaneous.
I wonder if a general parser can be made, i.e. you give it something to parse and some way of parsing it, then it parses the thing to parse using the way of parsing it...
(that's too many "parse"s in one sentence.)
Yes. Look up "parser generator."
The Wikipedia article redirects to "compiler-compiler" which seems to be right.
Yeah. "Parser generator" is a better name for it, though, because it doesn't make an entire compiler. It does the syntax part of the compiler, but you have to specify the semantics for each syntactic unit.
The Wikipedia article says:
The most common type of compiler-compiler is more precisely called a parser generator. They only handle syntactic analysis.
Oh, cool, good for Wikipedia. I wonder if my colleague Paul Hilfinger, from whom I learned to say "parser generator," wrote that part of the article. :~)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.