Hacker News Reader

Comment by pveierland | Hacker News Reader

The syntax is of course attractive (coming from Rust), and I'd love to replace more of my posix scripts with something saner. I struggle understanding whether the utility of having language literals for IP addresses, IP prefixes, and AS numbers is worth it though [0]. It seems like the confusion added by having custom built-ins like this for one particular domain, in addition to the unclear scoping (what could later also deserve being a language literal), combined with special-case errors as famous in e.g. the YAML Norway problem, makes it seem like such features are better left as some general extension / macro / library capability.

Nix is a language with built-in support for URI literals typed as strings [1], which is a source of confusion and edge-cases, and I believe the feature is now discouraged in general use.

[0] https://roto.docs.nlnetlabs.nl/en/stable/reference/language_...

[1] https://nix.dev/manual/nix/2.34/language/string-literals

View on HN

Hi! Author here. We are actually planning on removing those literals and allowing applications to extend Roto with their own literals [0]. They should do so with care of course, because indeed adding more literals adds some edge cases. Most applications should be able to get by without any special literals though.

[0]: https://codeberg.org/NLnetLabs/roto/pulls/358

Nice! That sounds like a good change. I'll try to dive a bit deeper through docs once I find some time :)

Have you considered collecting all the literals into domains, but ship them by default?

I could, for example, imagine using roto in some of my current work on svg and visuals generation. In which case I'd be greatly helped with literals like "colors", "vec2", "angle" etc. I'd imagine that as long as other literals which I don't need, like an IP address, aren't in the way, it's still greatly beneficial to have a large lib to pick and choose from, around.

Good suggestion! We haven't done that because there's only one domain at the moment but going forward that could be useful.

That makes a lot of sense to me. The implementation feels odd to me, though. If I’m reading it right, I type in literals normally and then all these hooks decide whether they want to change what I’ve typed in? It feels like I have to remember the custom literals I have installed to make sure I don’t accidentally conform to some spec and end up with a custom literal instead of the string I wanted.

Something like EDN readers seem saner to me where I wrap the value in something that denotes the function to use to parse the value. If I do “192.168.1.0/24” I get a string literal, if I do #cidr{192.168.1.0/24} then it hands the value off to the cidr custom literal.

That’s my 2 cents, I hate when things implicitly modify my literals.

That's kind of right, but they are adding new literals, not changing existing ones. The hooks are for the lexer and they can decide what syntax they accept. The syntax it defines would be a parse error if the hook is not used. But, indeed, this can be misused by accepting too much though, for instance when an IP addr also accepts a float. So the hook needs to be a bit careful.

The `#cidr{...}` syntax would work but then it wouldn't be much more convenient than just constructing the value with normal functions, I think.

7 years of python -> rust here.

https://github.com/py2many/static-python-skill/blob/main/ass...

Reply on news.ycombinator.com