alt Hacker NewsWould it be correct to say that this is basically any valid JS code that describes an object, excluding the use of references and function definitions?
If not, what is the difference, and why was it made to be different?
Replies
bawolff • 12/08/2024
Seems like the escapes are slightly different. No astral unicode escapes (e.g. \u{123456} ). No octal escapes \123
No template literals (backticks)
No regex literals
No octal numbers (0123, 0o123)
No boolean numbers (0b1001)
No big ints (the "n" suffix)
➕ show 1 reply
I've always thought it would be nice to have a language whose spec describes a few different "power levels":
1. Literal values only (objects, arrays, strings, numerics, booleans, maybe datetimes), a la JSON, with standardized semantics
2. Literals, variable definitions and references, pure function definitions, and pure function calls, but prohibiting recursion, such that evaluation is not Turing-complete and any value is guaranteed to be able to be evaluated into its literal form in finite time
3. All of the above plus recursion and impure, side-effectful functions, custom type definitions, etc.
This way, implementing a literal parser in other languages would be comparatively straightforward (much like JSON), since it wouldn't have to support variables or functions, but it would also be possible to define values using variables and pure functions (much like HCL or Nix) and then use the language's own evaluator binary (or perhaps a wrapped FFI library) to safely convert these into literal values that another language can parse, while guaranteeing that evaluation will not have side-effects. It would also leave open the escape hatch of using a "full" Turing-complete language with side-effects and recursion, while ensuring that using that escape hatch is a deliberate choice and not the default.
I'm sure there are a few additional or hybrid levels that could be useful too (2 but with recursion? 1 but with variables?) but this seems like it would be a solid starting point.