Ludus should include PEGs as part of Prelude #110
Labels
No Label
accepted
bug
clj
documentation
enhancement
errors
infrastructure
later
next
now
optimization
proposal
question
research
semantics
syntax
ux
vm
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: twc/ludus#110
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
For more sophisticated parsing than ELIZA (i.e. for make-a-LISP), we'll want something beyond the string pattern matching.
Take a cue from Janet and Guile: include PEGs as part of the language, instead of regex.
Take a cue from Janet that a parser is actually itself a data structure.
Consider:
But note that we can't actually do a lisp that way, since that will only match flat S-expressions. We'll need a way to accomplish recursion. So, as with Janet, we can also do mutually recursive and easily labelled parsers by using a dict:
parse
is basically a giant multiclause function/match
form that unpacks a parser using pattern matching and compares it against input.One thing that this requires, I suppose, is rationalizing and finalizing our ways of representing strings as sequences. At current, only strings with valid ASCII chars can be yanked out of strings in this way. Eventually—the same eventually I think we'll have a full-blown PEG in Prelude—we'll have to have some sort of way to work with UTF-8. I have been avoiding that. See: https://faultlore.com/blah/text-hates-you/.
@matt Pinging you here, because one of the cases I'm thinking about for "history of computing by example" is make-a-LISP (cf https://github.com/kanaka/mal). I don't know if that's actually what we want to do, but I do think that Ludus probably does need a builtin parsing tool, and I can't see how regex is the thing.
This may not be the thing, but it's closer to the thing than regex's line noise.
Thoughts?