4 ms·

Would 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,

by brap 2y ago

Would 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?

bawolff 2y ago
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)
- brap 2y ago
  Most of these things seem like missing features that would fit right in. Except for maybe template strings which could contain references to template functions
zanecodes 2y ago
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.
- alexisread 2y ago
  Agree, and this could be related to the libs you import (adding abilities), or the traits you specify (restricting).
- lmm 2y ago
  You might like the Noether programming language design https://github.com/noether-lang/noether/blob/4115cdb3f472360495a265940c0753053517297f/doc/presentations/StrangeLoop/noetherj.pdf https://github.com/noether-lang/noether/blob/4115cdb3f472360... , although I don't know if it'll ever be actually implemented.

by brap 2y ago

bawolff 2y ago

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)

brap 2y ago
Most of these things seem like missing features that would fit right in. Except for maybe template strings which could contain references to template functions

zanecodes 2y ago

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.

alexisread 2y ago
Agree, and this could be related to the libs you import (adding abilities), or the traits you specify (restricting).
lmm 2y ago
You might like the Noether programming language design https://github.com/noether-lang/noether/blob/4115cdb3f472360495a265940c0753053517297f/doc/presentations/StrangeLoop/noetherj.pdf https://github.com/noether-lang/noether/blob/4115cdb3f472360... , although I don't know if it'll ever be actually implemented.