by c0nstantine on 2/7/25, 4:18 PM with 102 comments
I wanted to do this for a very long time. It is more of a sketch or prototype. I'd really appreciate your feedback!
by danielparks on 2/7/25, 5:29 PM
I found the operator precedence unnatural, and it looks like a lot of other folks in this thread did too. I would naturally assume `cat:dog` would be equivalent to `(cat):(dog)` rather than `ca(t:d)og`.
by languagehacker on 2/7/25, 9:31 PM
I remember a Finnish researcher from PARC coming to one of my classes at UT to show how you can use FSTs for handling Finnish morphology, which is, on its face, quite a feat.
by Lanzaa on 2/7/25, 8:55 PM
https://gitlab.com/rosie-pattern-language/rosie/-/blob/maste...
by froh on 2/7/25, 5:39 PM
anyhow
wrt syntax, are you sure you want ':' to bind stronger than concatenation 'ab' ?
by layer8 on 2/7/25, 7:42 PM
More generally speaking, since regular expressions effectively define a parse tree on their matches, being able to perform more general transformations of those trees would be useful.
by crazygringo on 2/7/25, 4:54 PM
The entire purpose of this project seems to hinge on this assertion, but there isn't a single example.
I don't understand what makes regex unnatural for editing? What is meant by editing? Why do people struggle with groups?
There are lots of examples of the syntax for this project, but why is it better than regular regex?
If there were a few examples showing "here's the vanilla regex version, here's my version, here's why my version makes this easier" I might be able to understand this project.
by wfn on 2/7/25, 5:50 PM
My only quick comment is - the link to `theory.pdf` in README is broken (your pdf is in docs/ dir, so just need to change the url to include docs/).
by zoogeny on 2/7/25, 5:48 PM
Why not just disallow this? I understand it would make the grammar more difficult to specify - but I don't see any good reason to keep it.
by groby_b on 2/7/25, 9:04 PM
I.e - why is trre "(cat):(dog)" an improvement over s/cat/dog? What's the improvement of "(x:)or" over s/xor/or? And so on. Pretty much all the examples match (at least in my head) to relatively easy regexps.
I think the core advantage, if there is one, would be in group logic, so maybe the examples should lean into that - even before explaining the basics. I'd explain why it's actually a better choice before explaining the full syntax, or hello-world use cases.
For the caesar cipher example, it screams for a "apply this in reverse" - it's a pretty common request for a lot of text replacements, but it's super clear with this one. (Because programmer brain immediately screams "why express logic twice")
I don't know if it's useful (yet), but I think it's great you're trying to explore alternatives to a long-established status quo. (Caveat: That usually means there's a good chance it won't land. But it's still great to see an exploration)
by andrewla on 2/7/25, 5:01 PM
$ echo 'cat' | trre 'c:da:ot:g'
dog
Feels strange. What is happening here; the grammar says TRRE <- TRRE* TRRE|TRRE TRRE.TRRE
TRRE <- REGEX REGEX:REGEX
What is the parse tree here? Why is "c" not being replaced with "da"? Or why isn't c being removed and "da" being replaced by "ot"?I do like the idea of having a search/replace semantic that is more intuitive than grouping operators; back in MS-DOS days you could do "ren .log .txt" and this would work which feels bananas to my modern bash-minded way of thinking, but it's very obvious looking at this what it is supposed to do.
by i3oi3 on 2/7/25, 4:29 PM
$ echo 'cat dog' | trre 'c:bat|d:hog' bat hog
$ echo '' | trre ':a*' # <- do NOT do this dog
$ echo '' | trre ':(repeat-10-times){10}' dog
by skykooler on 2/7/25, 11:53 PM
echo "regular expressions" | ./trre "[a:A-z:a]"
REGULAR EXPRESSIONS
In fact, "[a:A-z:x]" seems to do the same thing as "[a:A-z:Z]" for all x.by larodi on 2/7/25, 6:57 PM
This, combined with probabilistic approach can be even more interesting. Probabilistic approaches regexes exist since 70s if memory serves right.
by kemiller on 2/8/25, 12:38 AM
by synthc on 2/7/25, 10:57 PM
by sabellito on 2/7/25, 5:46 PM
by jll29 on 2/7/25, 9:31 PM
The Xerox FST book https://press.uchicago.edu/ucp/books/book/distributed/F/bo36... (Xerox XRCE's finite-state-tools comprising the compilers lexc, xfst and twolc, the languages they compile and the formal language finite state transducers describe including linguistic applications)
The XFST book https://press.uchicago.edu/ucp/books/book/distributed/F/bo36...
FOMA: the open source clone https://fomafst.github.io/
FOMA: the paper (Holden, M. (2009) Proc. EACL) https://aclanthology.org/E09-2008.pdf
FOMA: the open source clone https://fomafst.github.io/
FOMA: the paper (Holden, M. (2009) Proc. EACL) https://aclanthology.org/E09-2008.pdf
by MathMonkeyMan on 2/7/25, 9:38 PM
$ echo 'cat' | trre 'c:da:ot:g'
dog
Why?Elsewhere, the readme says that ":" is "non-associative", and I had a look at the language grammar but haven't figured out how to parse a sequence of ":".
by mordechai9000 on 2/7/25, 4:48 PM
by YeGoblynQueenne on 2/8/25, 1:29 AM
by kazinator on 2/7/25, 7:19 PM
You could port this to like V7 Unix from 1979 or earlier; why didn't they get this idea? :)
Tools like sed build a transducer around the whole automaton: s/this/that/g.
by aqueueaqueue on 2/8/25, 10:04 AM
This is a common modus operandi for me in VS Code.
by the_arun on 2/7/25, 4:27 PM
> cat
I got lost here.
by layer8 on 2/7/25, 7:21 PM
by simlevesque on 2/7/25, 6:51 PM
make && sh test.sh
cc -std=c99 -Wall -Wextra -Wpedantic -o2 trre_nft.c -o trre
cc -std=c99 -Wall -Wextra -Wpedantic -o2 trre_dft.c -o trre_dft
test.sh: 14: Syntax error: "(" unexpected
Using bash fixed it.Then I ran one of the generator examples:
echo '' | trre -g ':(0|1){,3}?'
And I got this error: ./trre: invalid option -- 'g'
Usage: ./trre [-d] [-m] expr [file]
by ngruhn on 2/8/25, 12:56 AM
by agumonkey on 2/7/25, 9:20 PM
by metadat on 2/7/25, 6:11 PM
Trre seems like an arbitrarily different version of `sed -e /a/b/ ..`. This method of search and replace is essentially ported everywhere else, from awk to vim to IntelliJ, and has always gotten the job done adequately and feels as natural as anything else I've learned.
Am I missing something?
p.s I just realized I've been regex'ing heavily for 21 (!) years now, time flies.
by BFPQVZ on 2/7/25, 6:08 PM
by teknopaul on 2/7/25, 6:08 PM
Adding a new char to be escaped seems like another annoyance.
I try to avoid tools that make the hard bit harder, and the easy bit easier
by pmarreck on 2/7/25, 7:38 PM