[terts]

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

[berkes]

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.

[terts]

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

[everforward]

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.

[terts]

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.

[pveierland]

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