xiaq

Elvish author here, seems like I missed the annual posting of Elvish to HN this time :)

> Later, it will be a rejection of the insurance claim for a kid's life-saving surgery.

According to this article, it's been happening for a while now: https://www.statnews.com/2023/03/13/medicare-advantage-plans...

Such old urban places would just be car-free in the Netherlands (sometimes with limited access for delivery and emergency vehicles), a trend fortunately becoming popular in other European cities now.

The “urban” in the title is a bit misleading, this intersection is definitely more suburban, or on the boundary of an urban center. (Or rather, the author has a different definition of urban - in my definition cities like den Bosch are really just a small medieval urban core surrounded by continuous medium-density suburban neighborhoods.)

I would love to see the diff between the hand-rolled recursive-descent parser and the ANTLR syntax!

I certainly feel the amount of boilerplate in my hand-rolled recursive-descent parser is manageable. Of course it's not as succinct as an EBNF grammar:

- For example, you have to write an actual loop (with "for" and looping conditions) instead of just * for repetition

- The Go formatter demands a newline in most control flows

- Go is also not the most succinct language in general

So you do end up with many more lines of code. But at the end of the day, the structure of each parsing function is remarkably similar to a production rule, and for simpler ones I can mentally map between them pretty easily, with the added benefit of being able to insert code anywhere if I need something beyond old-school context-free parsing.

Yeah, ultimately there's an element of personal taste at play.

The authoritative tone of "how to write ..." is meant in jest, but obviously by doing that I risk being misunderstood. A more accurate title would be "how I wrote ...", but it's slightly boring and I was trying hard to get my talk proposal accepted you see :)

History entries are kept indefinitely.

FWIW, I've just added this instruction to https://elv.sh/get/default-shell.html#vim-/-neovim

Did you set your login shell to Elvish? Vim unfortunately relies on your shell being a POSIX shell, but you can fix that with "set shell=/bin/sh" in your rc file.

Thanks, I appreciate the comment the appreciation :)

Thanks! Glad that the talk is working as a marketing pitch for Elvish :)

Thanks! Murex talk when??? :)

Thanks for your question and glad that you enjoyed it!

Right, I may have forgot to mention that lexerless parsers are somewhat unusual.

I didn't have much time in the talk to go into the reason, so here it is:

- You'll need a more complex lexer to parse a shell-like syntax. For example, one common thing you do with lexers is get rid of whitespaces, but shell syntax is whitespace sensitive: "a$x" and "a $x" (double quotes not part of the code) are different things: the first is a single word containing a string concatenation, the second is two separate words.

- If your parser backtracks a lot, lexing can improve performance: you're not going back characters, only tokens (and there are fewer tokens than characters). Elvish's parser doesn't backtrack. (It does use lookahead fairly liberally.)

Having a lexerless parser does mean that you have to constantly deal with whitespaces in every place though, and it can get a bit annoying. But personally I like the conceptual simplicity and not having to deal with silly tokens like LBRACE, LPAREN, PIPE.

I have not used parser generators enough to comment about the benefits of using them compared to writing a parser by hand. The handwritten one works well so far :)

I gave a talk about the design: https://www.youtube.com/watch?v=wrl9foNXdgM

As the sibling comment mentioned, you can find documentation on Elvish itself on the website https://elv.sh. There are tutorials and (not 100% but fairly complete) reference documents.

I don't have a version with captions, sorry. You can find the slidedeck at https://github.com/elves/elvish/blob/master/website/slides/2...

The remaining 8% mostly falls into the following categories:

- Code that use OS functionalities that are cumbersome to mock in tests

- Code paths that are triggered relatively rarely and I was simply too lazy to add tests for them

Nothing is impossible to cover, but for whatever reason it was too much work for me when I wrote the code.

However, it's worth mentioning that I only settled on the transcript test pattern fairly recently, and if I were to rewrite or refactor some of the untested code today I would add tests for them, because the cost of adding tests has been lowered considerably. So Elvish's test coverage is still increasing slowly as the cost of testing decreases.

Hey, it's my talk, AMA :)

If you're interested in Elvish, you may also be interested in the talk on its design - https://www.youtube.com/watch?v=wrl9foNXdgM

Look for “POSIX” on https://justine.lol/cosmo3/

That seems to be a bad translation, the original text means something like “sharpen something fully and it won’t last so long” (presumably due to it being more brittle). The text (like the rest of Tao Te Ching) is pretty vague and doesn’t actually refer to knives, so it could also be read metaphorically.

Oh, I definitely didn't read your entire comment as negative, just the way you used "elvishism". Elvish definitely has its quirks! But I hope you'll find it a compelling package overall :)

> In case there are no jpg files in the working directory, Bash will put the pattern itself (*.jpg) into the $x variable. You need to explicitly check that the file in the variable actually exists before working on it.

Indeed that's one thing Elvish has better defaults that I forgot to mention in https://elv.sh/learn/scripting-case-studies.html#jpg-to-png...., and now I've added that, thanks :)

> Elvish visibly leans into this to try to have a consistent syntax. Sometimes the similarities go deeper, too; IIRC, its number types are inspired by Scheme, for example.

Yes! Similarity to Lisp is very much a deliberate design choice and I feel happy every time a Lisper picks that up :)

I believe Elvish has also contributed a novel solution to the Lisp-1/Lisp-2 divide by making the space of command names equivalent to the subspace of variable names with a suffix - the command "foo" is equivalent to the variable "$foo~" and vice versa. (There's a bit more twist than that - the command "foo" can also resolve to the external command named "foo", but then that's represented by the "$e:foo~" variable.)

Ha it's just a typo.

It wasn't directly borrowed from any other language (https://news.ycombinator.com/item?id=40317577) but there's definitely something nice about the syntax that causes multiple languages to use it.

Elvish predates Nushell by quite a few years BTW :)

Thank you for the compliment!

I take your comment as implying that https://elv.sh is nice, clean and elegant, and thank you for the compliment :)

I can't speak for other people, but I made it on my own and don't have any formal training in design.

With the risk of stating the obvious, you first have to realize that as a developer you can make a reasonably clean-looking website on your own. There are just a few basic ingredients: fonts, spacing, positioning, background shades, and rounded corners. You can do all of these from CSS and there is a lot of good resources for CSS today.

After that it's studying other websites, replicating the style you like, and a lot of trial and error. You can do a lot of experiments from the browser's dev tool before committing them into the stylesheet too. But at the end of the day, you have to put in some time. The layout of the current homepage was redone just a few months back and it took me (IIRC) 3 days to tweak everything to my satisfaction.

Yes! I haven't been using it as my daily driver for almost 10 years now.

There are detailed instructions on how to get it and use it as your default shell in https://elv.sh/get/.

While I don't agree with most of your analysis - in particular for the second example, I'd invite you to read its explainer that goes into much more depth (https://elv.sh/learn/scripting-case-studies.html#update-serv...) - I think you might be more interested in the Oil Shell project, which is trying to chart a smooth upgrade path from bash: https://www.oilshell.org

I think we simply can't say for sure which path is better for the future of shells, and I'm quite excited by the fact that different projects are exploring different directions. I will just stick to the path I find best and won't try to convert you :)

Ha, no problem. The number syntax is documented in https://elv.sh/ref/language.html#number

It was inspired by browsers' location bar - the name (location mode) and the default ^L binding are a nod to browsers too.

These days browsers will often suggest results from search engines but back then (at least in Firefox?) it was just history and bookmarks.