It’s usable but cumbersome at this point. I spent a lot of time adding a terminal-based frontend in addition to the love2d one, but I found that since I already have 95% of the benefit of structural editing inside Emacs, plus a ton of stuff I’d never get in my own structural editor (like magit, eshell, ERC) it was really hard to force myself to use my structural editor to write itself and click into the dogfooding magic cycle.
Then once Fennel got a really good LSP server it was basically all over; I realized while it would be much easier to write those features from scratch in a structural editor than in a conventional one, it’s still much harder than just using what other people wrote.
I get really excited when I find other people who are interested in structural editing. The main problem is that it just isn’t feasible to do the work once per language. It’d be like having to write a new web browser for every website!
I’m trying to build the protocols and implementation that will split structural editing into a proper frontend and backend, thus creating the economic conditions that will drive continued investment in this technology by many, many individuals such as yourself working in collaboration.
Yeah, I’m really only interested in doing this for lisps, which means it’s a lot easier. Might be interesting to chat anyway, but Discord is a bit of a red flag for me, sorry. Good luck anyway.
I do email too, or really long lobste.rs threads or whatever. I just use Discord because that’s where the majority of people who actually want to talk hang out. Here’s a non-social link that might give you some idea what this work is about: https://gist.github.com/conartist6/0b252a705c7e715b82b691e4c8b20329
In fact I do have just that! I’ve implemented a tool I called BABLR that is closely related to tree-sitter (and at least as powerful). The common parse result format I came up with I call CSTML, and while I can’t promise the format is completely locked down just yet it has already been through a significant amount of evolution and is capable of doing some real work: https://gist.github.com/conartist6/0b252a705c7e715b82b691e4c8b20329#file-02-parse-result-cstml
You probably will be interested in this: https://www.brics.dk/xsugar/ . This is XSugar. It has similar goals to BABLR, but translates everything to XML. And moreover, it can translate everything back, i. e. it is bidirectorial. And moreover, round-trip property is guaranteed by sophisticated math. Unfortunately, the project is not open source, but source code is available at request. (And as well as I remember, the author sent me a copy.)
I did do a lot of work didn’t I! And you’re quite free to not like it, I’m not offended!
I chose imperative code knowing it came with certain risks, but I like it because it’s strictly more powerful than declarative. For example there are many parsing systems that have declarative means of supporting syntaxes, and I can support every single one of them just by writing the appropriate adapter code to compile out the needed imperative instructions. Even logic programming languages and EBNF parser definitions execute on physical hardware that is imperative.
I have (again) a proof-of-concept that works for Fennel, and it would be very easy to extend to work with Lua modules as well, but you can’t get that far in that ecosystem before you bottom out in C code, and making it work for C libraries is … nearly impossible.
Well, first, this is somewhat similar to https://www.unison-lang.org/ . But functions are identified not by names, but by hash of their content instead.
I am try to create this technology in such a way that it’s a serious threat to replace VSCode, and I would greatly value feedback from anyone who has real-world experience trying to build and use these tools!!
This is the 2nd or 3rd ‘pretty invoice generator’ I’ve seen recently (there’s one advertising on TV). Is this really a market? I mean, 1) who manually creates an invoice outside of the accounting tool they’re using (e.g. Quickbooks) enough that you need a product to do it and 2) who cares that much about super-fancy invoices? I have never once looked at an invoice and said “needs more bling”.
Yeah, I guess it’s a little over the top, but on the other hand I’m always annoyed if I get an invoice where the 2 most important things (IBAN & total amount) are hidden somewhere in light gray text 😩
Google->Invoice Template - 205 million hits. I also don’t need (or want) a web site to format my text. But we’ve already established I’m not the target market.
P.S. - Your link is 404.
people who like to own their accounting tools
I used Quickbooks as an example that people are familiar with, not that it’s the only option. I bet there are tools on plaintextaccounting can do a decent invoice without a separate service.
It’s recommended to post things or comment on things that are not just promotion of your own projects. You have 2 posts and 1 comment, and all 3 are links to your own stuff.
Personally I use a LaTeX workflow to generate my PDF invoices. Dusted it off recently and it still works after 4 years unattended! I didn’t even have the computer I have now when I last used it. Meanwhile I’d never heard of Typst, so I looked it up – first release last year. Will it work in 4 years, unaltered, from an install I make today?
Invoicing is annoying. It’s better when your invoice software doesn’t need to be upgraded/fixed/made compliant.
IDK if Typst will work unaltered in 4 years, but being able to generate beautiful PDFs with a single 33 MB binary instead of several GBs (the size of a LaTeX distrubution, IIRC) is a breath of fresh air.
Ditto re: promotion, but I wouldn’t be so quick to dismiss Typst.
To give a concrete example, here’s a resume template. It cleanly separates structure from data, in contrast to it’s upstream (which FYI has a picture).
While it doesn’t accept YAML, it does reap the benefits of a sharing a homoiconic language across these contexts. But that language– it’s modal! IIRC, the template and config files start in different modes that you basically quasi-quote between as code is interleaved with data. In one mode, smart-quotes are a function call and white-space is embedded in strings. In the other, smart-quotes are automatic and white-space is collapsed. With this, an end-user can declaratively define styling exceptions (as code) into their configuration markup (-down?). They’re passed into the template as rich, box-bounded objects. Feels kinda like if HTML ate CSS’s syntax and box-model instead of stuffing it in a string for later. I’d rank Typst well above average in degrees-of-freedom: you’re more likely to hit a limitation in the template’s API than in the language, and the distance you can push that is pretty impressive.
The Docs are pretty solid. Implementation limits that do exist are clearly still being worked on. Re: longevity I’d like to highlight the work that’s been done on HTML export, and Pandoc support (which both sides have discussed and collaborated on openly and extensively).
Sorry, using Lobster isn’t in my muscle memory yet, but it’s listed on my release checklist 😅
Having a properly working LaTeX installation has definitely given me some headaches. Sure, if that’s done LaTeX is stable. But that’s a big if.
The syntax has been pretty stable over the last releases, and debugging is so much faster with ms compile times. So I’m fairly certain you can get it running in a few minutes in 4 years.
I’ve been pining for what I call a descriptive CLI parser library.
This is in contrast to the prescriptive CLI parser libraries most language ecosystems have a few of. (Prescriptive parser libraries tend to be opinionated, and focus on implementing simple CLI programs.)
A descriptive parser would focus more broadly on situations where you want to build tools that are able to work with arbitrary command-line invocations (to validate/lint/edit/analyze/complete/document etc.).
I imagine it might:
Have affordances for writing parsers quickly, but still be flexible enough to implement all (or nearly all) existing CLIs, even when they do weird conditional/contextual stuff like alter the semantics and format of an option/arg based on the presence or value of other options/args.
Address some problems that non-canonical parsers for a third party’s CLI have to wrestle with, like conflicting implementations of the utility and differences between the same implementation’s arguments as it evolves from version to version. (A decent way to distill this quality is thinking about what you’d need to take an invocation and a version number, and be able to emit an error if the tool version predates the addition of or postdates the removal of an argument present in the invocation.)
Have a language-agnostic expression format so that multiple language ecosystems can all have implementations but share the burden of developing and maintaining parsers for specific utilities.
Support types for args/options, while recognizing that different CLIs can have subtly different semantics for closely-related types (i.e., one CLI may split a “command” passed as an argument before execing it while another may not).
Enable consumers to attach additional functions to validate/rewrite/parse some arguments. Probably by type. (i.e., be able to pass an awk or jq expression to another parser or some validating function).
If I understand correctly, I think this problem can be brute forced …
As in, “just” write down test cases for all the styles of CLI interface you want to handle, and then express them in this new library. That’s the test of whether the library is sufficiently expressive
That’s basically what Oils spec tests do – we just write down everything that’s in shell, and that’s quite a bit bigger than even all CLIs / flag dialects.
I really don’t think there are that many, there’s like
GNU style
Go style
traditional BSD tools, getopt() in C
Docker, NPM, clang, etc.
Many of them do involve arbitrary code, so you need to be able to escape to a real language.
What I think of as the fallacy from the old #shell-autocompletion channel on the Oils Zulip is that everyone wanted it to be purely declarative. But CLI flag parsers have some arbitrary C, arbitrary Python, arbitrary JS, etc.
And that’s good, because good CLIs have custom error messages.
I wrote a proof-of-concept structural editor for Fennel: https://git.sr.ht/~technomancy/anarres
It’s usable but cumbersome at this point. I spent a lot of time adding a terminal-based frontend in addition to the love2d one, but I found that since I already have 95% of the benefit of structural editing inside Emacs, plus a ton of stuff I’d never get in my own structural editor (like magit, eshell, ERC) it was really hard to force myself to use my structural editor to write itself and click into the dogfooding magic cycle.
Then once Fennel got a really good LSP server it was basically all over; I realized while it would be much easier to write those features from scratch in a structural editor than in a conventional one, it’s still much harder than just using what other people wrote.
Hast seen the white whale!
I get really excited when I find other people who are interested in structural editing. The main problem is that it just isn’t feasible to do the work once per language. It’d be like having to write a new web browser for every website!
I’m trying to build the protocols and implementation that will split structural editing into a proper frontend and backend, thus creating the economic conditions that will drive continued investment in this technology by many, many individuals such as yourself working in collaboration.
Please come join the Discord https://discord.gg/NfMNyYN6cX if you’re interested.
Yeah, I’m really only interested in doing this for lisps, which means it’s a lot easier. Might be interesting to chat anyway, but Discord is a bit of a red flag for me, sorry. Good luck anyway.
I do email too, or really long lobste.rs threads or whatever. I just use Discord because that’s where the majority of people who actually want to talk hang out. Here’s a non-social link that might give you some idea what this work is about: https://gist.github.com/conartist6/0b252a705c7e715b82b691e4c8b20329
I think it is possible to create structural editor for all languages at once if you have some format for describing syntax. For example, tree-sitter.
Or, if you want to go deeper than just syntax, i. e. to type system, then this project may be of interest: https://lingo-workbench.dev/ = https://petevilter.me/post/datalog-typechecking/
In fact I do have just that! I’ve implemented a tool I called BABLR that is closely related to tree-sitter (and at least as powerful). The common parse result format I came up with I call CSTML, and while I can’t promise the format is completely locked down just yet it has already been through a significant amount of evolution and is capable of doing some real work: https://gist.github.com/conartist6/0b252a705c7e715b82b691e4c8b20329#file-02-parse-result-cstml
Cool! You did a lot of work!
You probably will be interested in this: https://www.brics.dk/xsugar/ . This is XSugar. It has similar goals to BABLR, but translates everything to XML. And moreover, it can translate everything back, i. e. it is bidirectorial. And moreover, round-trip property is guaranteed by sophisticated math. Unfortunately, the project is not open source, but source code is available at request. (And as well as I remember, the author sent me a copy.)
Unfortunately, I don’t like your BABLR. (I hope you are not offended.) I don’t like it, because you describe languages by imperative code, for example: https://github.com/bablr-lang/language-json/blob/dab4788901970ef09708d105d161bb7ddaa25e64/lib/grammar.js#L78 .
I strongly believe declarative style is always preferred over imperative. Tim Berners-Lee agrees: https://www.w3.org/DesignIssues/Principles.html#PLP . See also https://yosefk.com/blog/code-data-and-interactive-programming.html
I have a white whale: to create something similar to your BABLR, but declarative. And ideally, bidirectorial, similarly to XSugar
I did do a lot of work didn’t I! And you’re quite free to not like it, I’m not offended!
I chose imperative code knowing it came with certain risks, but I like it because it’s strictly more powerful than declarative. For example there are many parsing systems that have declarative means of supporting syntaxes, and I can support every single one of them just by writing the appropriate adapter code to compile out the needed imperative instructions. Even logic programming languages and EBNF parser definitions execute on physical hardware that is imperative.
Since realizing this was unrealistic, probably my next white whale is implementing the ideas in Joe Armstrong’s famous “we need letrec” post: https://erlang.org/pipermail/erlang-questions/2011-May/058768.html
I have (again) a proof-of-concept that works for Fennel, and it would be very easy to extend to work with Lua modules as well, but you can’t get that far in that ecosystem before you bottom out in C code, and making it work for C libraries is … nearly impossible.
Well, first, this is somewhat similar to https://www.unison-lang.org/ . But functions are identified not by names, but by hash of their content instead.
Second, I totally disagree with “We don’t need modules” part. I agree with article ‘Modules Matter Most’ for the Masses
I have something that looks basically exactly the same for JavaScript! Even the choice of color (why did we pick yellow?) 😅 https://syvis.surge.sh/ErZoPhsMTcDvGT9pZswo/
I’m also not sure if there is any real benefit, so I never properly released it …
Come join the BABLR Discord! https://discord.gg/NfMNyYN6cX
I am try to create this technology in such a way that it’s a serious threat to replace VSCode, and I would greatly value feedback from anyone who has real-world experience trying to build and use these tools!!
Also for the record Hazel picked the same color for their structural editor too: https://hazel.org/build/dev/
This is the 2nd or 3rd ‘pretty invoice generator’ I’ve seen recently (there’s one advertising on TV). Is this really a market? I mean, 1) who manually creates an invoice outside of the accounting tool they’re using (e.g. Quickbooks) enough that you need a product to do it and 2) who cares that much about super-fancy invoices? I have never once looked at an invoice and said “needs more bling”.
Google->Invoice Template - 205 million hits. I also don’t need (or want) a web site to format my text. But we’ve already established I’m not the target market.
P.S. - Your link is 404.
I used Quickbooks as an example that people are familiar with, not that it’s the only option. I bet there are tools on plaintextaccounting can do a decent invoice without a separate service.
Yeah…I hate that too.
It’s recommended to post things or comment on things that are not just promotion of your own projects. You have 2 posts and 1 comment, and all 3 are links to your own stuff.
Personally I use a LaTeX workflow to generate my PDF invoices. Dusted it off recently and it still works after 4 years unattended! I didn’t even have the computer I have now when I last used it. Meanwhile I’d never heard of Typst, so I looked it up – first release last year. Will it work in 4 years, unaltered, from an install I make today?
Invoicing is annoying. It’s better when your invoice software doesn’t need to be upgraded/fixed/made compliant.
IDK if Typst will work unaltered in 4 years, but being able to generate beautiful PDFs with a single 33 MB binary instead of several GBs (the size of a LaTeX distrubution, IIRC) is a breath of fresh air.
There’s tectonic, which is similar in that regard. Single package, automatically downloads ctan packages under the hood.
Ditto re: promotion, but I wouldn’t be so quick to dismiss Typst.
To give a concrete example, here’s a resume template. It cleanly separates structure from data, in contrast to it’s upstream (which FYI has a picture).
While it doesn’t accept YAML, it does reap the benefits of a sharing a homoiconic language across these contexts. But that language– it’s modal! IIRC, the template and config files start in different modes that you basically
quasi-quotebetween as code is interleaved with data. In one mode, smart-quotes are a function call and white-space is embedded in strings. In the other, smart-quotes are automatic and white-space is collapsed. With this, an end-user can declaratively define styling exceptions (as code) into their configuration markup (-down?). They’re passed into the template as rich, box-bounded objects. Feels kinda like if HTML ate CSS’s syntax and box-model instead of stuffing it in a string for later. I’d rank Typst well above average in degrees-of-freedom: you’re more likely to hit a limitation in the template’s API than in the language, and the distance you can push that is pretty impressive.The Docs are pretty solid. Implementation limits that do exist are clearly still being worked on. Re: longevity I’d like to highlight the work that’s been done on HTML export, and Pandoc support (which both sides have discussed and collaborated on openly and extensively).
Sorry, using Lobster isn’t in my muscle memory yet, but it’s listed on my release checklist 😅
Having a properly working LaTeX installation has definitely given me some headaches. Sure, if that’s done LaTeX is stable. But that’s a big if.
The syntax has been pretty stable over the last releases, and debugging is so much faster with ms compile times. So I’m fairly certain you can get it running in a few minutes in 4 years.
I’ve been pining for what I call a descriptive CLI parser library.
This is in contrast to the prescriptive CLI parser libraries most language ecosystems have a few of. (Prescriptive parser libraries tend to be opinionated, and focus on implementing simple CLI programs.)
A descriptive parser would focus more broadly on situations where you want to build tools that are able to work with arbitrary command-line invocations (to validate/lint/edit/analyze/complete/document etc.).
I imagine it might:
Have affordances for writing parsers quickly, but still be flexible enough to implement all (or nearly all) existing CLIs, even when they do weird conditional/contextual stuff like alter the semantics and format of an option/arg based on the presence or value of other options/args.
Address some problems that non-canonical parsers for a third party’s CLI have to wrestle with, like conflicting implementations of the utility and differences between the same implementation’s arguments as it evolves from version to version. (A decent way to distill this quality is thinking about what you’d need to take an invocation and a version number, and be able to emit an error if the tool version predates the addition of or postdates the removal of an argument present in the invocation.)
Have a language-agnostic expression format so that multiple language ecosystems can all have implementations but share the burden of developing and maintaining parsers for specific utilities.
Support types for args/options, while recognizing that different CLIs can have subtly different semantics for closely-related types (i.e., one CLI may split a “command” passed as an argument before execing it while another may not).
Enable consumers to attach additional functions to validate/rewrite/parse some arguments. Probably by type. (i.e., be able to pass an awk or jq expression to another parser or some validating function).
If I understand correctly, I think this problem can be brute forced …
As in, “just” write down test cases for all the styles of CLI interface you want to handle, and then express them in this new library. That’s the test of whether the library is sufficiently expressive
That’s basically what Oils spec tests do – we just write down everything that’s in shell, and that’s quite a bit bigger than even all CLIs / flag dialects.
I really don’t think there are that many, there’s like
Many of them do involve arbitrary code, so you need to be able to escape to a real language.
What I think of as the fallacy from the old
#shell-autocompletionchannel on the Oils Zulip is that everyone wanted it to be purely declarative. But CLI flag parsers have some arbitrary C, arbitrary Python, arbitrary JS, etc.And that’s good, because good CLIs have custom error messages.
So it can’t be overly restrictive, as you say
PicoCLI is quite cool, not sure if it fits all your requirements though.
I’m working on something similar!
https://github.com/Airsequel/Oclis