3 ms·

> it makes it nearly impossible to compile the language You would honestly be surprised what little difference it makes. You can just go through the source cod

> it makes it nearly impossible to compile the language You would honestly be surprised what little difference it makes. You can just go through the source code as you compile it and compile instances of function-like objects with the compiled version. If you imagine a data-type for lists: class List { Object car; Object cdr; }; class Compiled_List inherits List { Object (*call)(List args); } Then you would have function calls compile to: // compiled value of (F . ARGS) if (F is Compiled_List) return F->call(ARGS); else if (F is List) // interpret F This is no slower than the compiled version of a regular function call in any other lisp, since there is also a need to type-check the function there. The real issue is the lack of numbers if you are interested in speed.

lisper 2y ago
That doesn't work because there are only four primitive types: symbols, pairs, characters, and streams. You can't add more. Bel is supposed to be a specification, not an implementation. So pairs are the only compound data type. That is all you have to build more complex stuff out of. Even lists are puns on pairs. So there is no place to hide any adjunct data without violating the spec. This is one of the many reasons that an operational spec is a bad idea. I am as big a fan of Lisp as you can hope to find (just look at my user name) but PG's infatuation with McCarthy's original definition of EVAL is badly misguided. McCarthy's EVAL was NOT a formal spec of anything, it was an illustration that CONS, CAR, CDR, QUOTE and COND were a really good choice of computational primitives because you could write EVAL in a few dozen lines rather than the pages and pages required to do the same thing for a Turing machine.
- James_K 2y ago
  > That is all you have to build more complex stuff out of By this logic you can't add type information to anything because you can only use pairs so there is nowhere to store the type. It's a silly thing to say because it assumes the compiler for the language has to be written in the language. > So there is no place to hide any adjunct data without violating the spec The spec is that you have cons, car, and cdr. You could have a secret third element to some pairs that is only used by the compiler without changing the interface of those functions, and hence without changing the interface of the language as a whole. This is the essence of optimising compilers, making changes to the representation of things without changing how they behave. > PG's infatuation with McCarthy's original definition of EVAL is badly misguided I agree wholeheartedly with this. This entire document is basically just an extended brain-fart but because it came out of a rich guy's brain-ass a bunch of people will treat it like it's serious.
  - lisper 2y ago
    > It's a silly thing to say because it assumes the compiler for the language has to be written in the language. It assumes no such thing. All it assumes is that the compiler has to conform to the specification. > The spec is that you have cons, car, and cdr. And XAR and XDR. And threads. And no compound data types other than mutable pairs. > You could have a secret third element to some pairs that is only used by the compiler without changing the interface of those functions, and hence without changing the interface of the language as a whole. That's right. You could. How would that help? > This entire document is basically just an extended brain-fart OK, so we're basically in violent agreement here. We're just quibbling over the justification.
    - James_K 2y ago
      > That's right. You could. How would that help? I literally just described in code how that could help. Wherever the compiler encounters an instance of a list in the source code that looks like a function, you compile it and put the result in a secret third element. Then, when you have to apply a list, you first check if it has a compiled third element before you do the slower work of interpreting it. Have you ever written a compiler or used one? What I described here is literally just the process of JIT compilation.
      - lisper 2y ago
        JIT compilation only works if functions can't change at run-time, which is true for most languages, but not for Bel.
        James_K 2y ago
        Some fairly simple escape analysis could likely determine that most functions used in practice do not have their bodies assigned.
        lisper 2y ago
        That might work if Bel didn't have threads. But it does, so it doesn't. Also, assigning the body is not the only way to undermine compilation. You can change a function into a non-function (by changing its first or second element) and vice versa. You can change a function's environment. You can change its argument list. You can modify the body of a function while it is being evaluated. You can change anything about a function at any time.

lisper 2y ago

That doesn't work because there are only four primitive types: symbols, pairs, characters, and streams. You can't add more. Bel is supposed to be a specification, not an implementation. So pairs are the only compound data type. That is all you have to build more complex stuff out of. Even lists are puns on pairs. So there is no place to hide any adjunct data without violating the spec. This is one of the many reasons that an operational spec is a bad idea. I am as big a fan of Lisp as you can hope to find (just look at my user name) but PG's infatuation with McCarthy's original definition of EVAL is badly misguided. McCarthy's EVAL was NOT a formal spec of anything, it was an illustration that CONS, CAR, CDR, QUOTE and COND were a really good choice of computational primitives because you could write EVAL in a few dozen lines rather than the pages and pages required to do the same thing for a Turing machine.

James_K 2y ago
> That is all you have to build more complex stuff out of By this logic you can't add type information to anything because you can only use pairs so there is nowhere to store the type. It's a silly thing to say because it assumes the compiler for the language has to be written in the language. > So there is no place to hide any adjunct data without violating the spec The spec is that you have cons, car, and cdr. You could have a secret third element to some pairs that is only used by the compiler without changing the interface of those functions, and hence without changing the interface of the language as a whole. This is the essence of optimising compilers, making changes to the representation of things without changing how they behave. > PG's infatuation with McCarthy's original definition of EVAL is badly misguided I agree wholeheartedly with this. This entire document is basically just an extended brain-fart but because it came out of a rich guy's brain-ass a bunch of people will treat it like it's serious.
- lisper 2y ago
  > It's a silly thing to say because it assumes the compiler for the language has to be written in the language. It assumes no such thing. All it assumes is that the compiler has to conform to the specification. > The spec is that you have cons, car, and cdr. And XAR and XDR. And threads. And no compound data types other than mutable pairs. > You could have a secret third element to some pairs that is only used by the compiler without changing the interface of those functions, and hence without changing the interface of the language as a whole. That's right. You could. How would that help? > This entire document is basically just an extended brain-fart OK, so we're basically in violent agreement here. We're just quibbling over the justification.
  - James_K 2y ago
    > That's right. You could. How would that help? I literally just described in code how that could help. Wherever the compiler encounters an instance of a list in the source code that looks like a function, you compile it and put the result in a secret third element. Then, when you have to apply a list, you first check if it has a compiled third element before you do the slower work of interpreting it. Have you ever written a compiler or used one? What I described here is literally just the process of JIT compilation.
    - lisper 2y ago
      JIT compilation only works if functions can't change at run-time, which is true for most languages, but not for Bel.
      - James_K 2y ago
        Some fairly simple escape analysis could likely determine that most functions used in practice do not have their bodies assigned.
        lisper 2y ago
        That might work if Bel didn't have threads. But it does, so it doesn't. Also, assigning the body is not the only way to undermine compilation. You can change a function into a non-function (by changing its first or second element) and vice versa. You can change a function's environment. You can change its argument list. You can modify the body of a function while it is being evaluated. You can change anything about a function at any time.