[HN Gopher] Show HN: Luna is a Clojure domain specific language ...
___________________________________________________________________
Show HN: Luna is a Clojure domain specific language that translates
to regex
Author : lazyfolder
Score : 45 points
Date : 2021-11-14 15:30 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| acdw wrote:
| makes me think of Emacs's `rx` macro!
| finnh wrote:
| So, basically, AppleScript for regex.
|
| I think this bumps JWZ's problem counter to 3..
| dang wrote:
| " _Don 't be snarky._"
|
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
|
| _Be respectful. Anyone sharing work is making a contribution,
| however modest._
|
| _Instead of "you're doing it wrong", suggest alternatives.
| When someone is learning, help them learn more._
|
| _When something isn 't good, you needn't pretend that it is,
| but don't be gratuitously negative._
|
| https://news.ycombinator.com/showhn.html
| lifthrasiir wrote:
| EDIT: This comment is wrong, I've mistakenly read `(?<=y)x` as
| `(?=y)x` and wrongly determined the key ":after" is incorrect
| when writing this comment.
| eyelidlessness wrote:
| I'm confused. Given a string "foobar", `(?<=foo)bar` should
| match "bar". Or is this implicitly `^(?<=foo)bar$` in Clojure?
| I used to know the answer but it's been several years since
| I've used Clojure.
| lifthrasiir wrote:
| Oops, I've mistakenly thought `(?=foo)bar` when writing that
| comment. Please disregard the parent comment.
| chadrs wrote:
| Kind of reminds me of parser combinators but not extensible.
| Syzygies wrote:
| Yes!
|
| Parser combinators extended to typed trees, with an efficient
| syntax, would be a great basis for a programming language.
| Macros would be a primary application rather than strapped-on
| as they are now in every language.
|
| Another clue that we're watching a planet form, a fundamental
| idea is about to coalesce: Combinators for applying tactics in
| a theorem proving language such as Lean bear an uncanny
| resemblance to parser combinators.
|
| Today, most programmers view verified code as impractical. Huh?
| Is getting hacked, or the wrong answer, practical? In the
| future we'll be able to use the same code to write efficient
| programs, efficient randomized tests, and for program
| verification. It will feel like targeting different
| architectures.
|
| The key idea in type-based theorem proving is "propositions as
| types": One defines a type to state a proposition, then
| demonstrates an instance of that type to prove the proposition.
| Existence is boolean (true or false) which is also the
| coefficient semiring for automata theory in computer science.
| There, one generalizes to arbitrary coefficient rings, and gets
| probability models such as hidden Markov chains as part of the
| same theory. How does one generalize "propositions as types" to
| arbitrary coefficients? Does this subsume random testing? The
| parallel here is that one wants a valid instance of a type to
| prove a theorem, and a probability distribution on valid
| instances of a (far simpler) type for random testing.
|
| Anyone designing a language in this decade should look to
| program verification and theorem proving for the deepest
| influences.
|
| The Hitchhiker's Guide to Logical Verification
| https://github.com/blanchette/logical_verification_2020/raw/...
|
| Benjamin Pierce: Backtracking Generators for Random Testing
| https://www.youtube.com/watch?v=dfZ94N0hS4I&t=489s
|
| Homotopy Type Theory https://homotopytypetheory.org/book/
| dash2 wrote:
| I'm not totally convinced by these English-like regex languages.
| Regex itself seems like a reasonable language:
|
| [a-z] means a to z
|
| x* means 0 or more xs
|
| ...
|
| The problem is that
|
| a) whitespace is significant, so long regexes start to become
| unreadable
|
| b) no easy way to nest regexes
|
| Perl 6/Raku seemed to solve this by making whitespace meaningless
| by default and allowing regexes to be nested into other regexes
| or entire "grammars".
| lf-non wrote:
| Completely agree. For js, xregexp [1] is a really nice long
| standing library that brings in these kind of enhancements and
| makes regular expressions a lot more readable.
|
| [1] https://xregexp.com
| amenod wrote:
| This. Also, I try to:
|
| - use only those regex features that are cross-platform (cross-
| engine?)
|
| - avoid `\w` and similar (what is word?) and instead use
| explicit rules (`[a-zA-Z]+`)
|
| - use [] instead of backslashes when escaping (`[(]` instead of
| `\\(`) - especially useful with double/triple escaping
|
| - never use long regexes (there is always a better way)
|
| I never understood why people are afraid of regular
| expressions.
|
| That said, there are some performance/security implications
| wrt. backtracking that one should be aware of [0].
|
| [0] https://javascript.info/regexp-catastrophic-backtracking
| fiddlerwoaroof wrote:
| \w and "<" and ">" are useful in regular expressions for
| programming source code because you can define them to match
| the character set of the programming language's identifiers.
| CJefferson wrote:
| My personal irritation is I often want thing like [],() or + as
| the thing I'm searching for, and then after escaping things get
| really unreadable.
| askonomm wrote:
| I like to think of DSL's for regex as a good way for people who
| don't have time to master regex itself, or are beginners, to
| actually use regex. Been doing programming for about 10 years and
| only fairly recently took the time to properly learn regex, but
| could've definitely benefitted from a DSL way before that. Good
| job Abhinav!
| coltnz wrote:
| My approach was simpler, provide some composability.
| ;compiled at run time (re/or #"a" (re-pattern "b"))
| => #"(a|b)a" ;compiled at macro time (re/or #"a"
| (re/and #"b")) => #"(a|(b))"
|
| https://github.com/coltnz/re-ext
| fnordsensei wrote:
| There's also Regal: https://github.com/lambdaisland/regal
___________________________________________________________________
(page generated 2021-11-14 23:01 UTC)