I've been historically frustrated by the overlap between what I think make nicely regular language features (like TUPLE!, PATH!, and CHAIN!) running up against edges with literal representations.
-
version/1.2would be nice if that could be interpreted as a tuple, but people want to write their decimal representations as1.02etc. -
1:10would be nice as a CHAIN! to represent a range, but people want to write TIME! representations as10:20etc. -
31-Aug-2024/0:36:30-4:00is a DATE!, but sure looks like a PATH!
Ad nauseum.
Because I think version/1.2 has been genenerally the kind of thing that's more important to the domains Rebol is actually good for than math, I've been willing to throw things like DECIMAL! under the bus. So over time I've suggested random things like "&1.02 to represent DECIMAL!". But not only have such ideas been loudly protested, the sigils have become pretty saturated to where everything has a meaning already.
But we do have one little crevice in notational space that isn't too hideous.
Enclosing In `Backticks`
adjusted-value: value / `1.02`
set alarm for `10:20`
[<backdate-post> `31-Aug-2024/0:36:30-4:00`]
set $(coefficient-name) `6.22e23`
[1020 : -304] ; INTEGER! would of course be exempt.
The backticks are about as unobtrusive as this can get.
Having them on the start and end doesn't just make it look more balanced and symmetrical--it also lets the literal interpretation be sandboxed from the rest of the scanning.
This Would Not Bother Me
Quite the contrary, I would be thrilled to see the regularity this would bring to the scanner.
It puts all the quirky exceptions in one place where they can fight amongst themselves, while the real work can proceed.
A Place For Parameterized TRANSCODE?
When you call TRANSCODE it could offer you the ability to specify that file's interpretation of backtick'd portions. This would give you a way to customize things, throwing in your own pecking order for the literals...then using TO INTEGER! and TO DATE! etc as you wish (or after you've picked over it, call some kind of generic TO-VALUE that goes through the default list).
Maybe. I don't know. It's a thought, that constraining these irregularities inside of a box could let that irregular space be what it wanted, while the rest of the scanner would be nailed down.
We could even say there's a mode you can load things in which it doesn't interpret the literals at all. They'd just be LITERAL!.
>> code: transcode/illiterate -{foo: `whatever*you*say`}-
== [foo: `whatever*you*say`]
>> type of second code
== &[literal]
>> as text! second code
== "whatever*you*say"
Doesn't (Necessarily) Stop Use Of Unbackticked Forms
You wouldn't be able to write plain 1.02 and get a TUPLE! that you could translate into a DECIMAL! (error, as an integer in the second slot would be loss of information).
But you could get away with some things. More with something like the FUSED! Proposal
If your notation is LOAD-able, and you're in a dialect context, you could transform what you got.
If people decide it's worth it to them to do transforms on 1.2em to make it `1.2`em that's their dialect's business. But we need to make leading-0s illegal in tuples, so you don't unwittingly lose information.
