4 ms·

In Bel you have to eval (fn (x) (+ x 1)) before you can call it. Do you agree? Following your terms in https://news.ycombinator.com/item?id=40409467 https://new

In Bel you have to eval (fn (x) (+ x 1)) before you can call it. Do you agree? Following your terms in https://news.ycombinator.com/item?id=40409467 https://news.ycombinator.com/item?id=40409467, in this respect Bel feels like a modern lisp. In other words, this quoted passage of yours is not correct: (lambda () t) is a list. In McCarthy's original lisp, as in Bel, this list IS a function. This would work: (setq l '(lambda () t)) (l) --> T This would not work in Bel.

lisper 2y ago
Yes, that's right, but you have missed the point. In McCarthy's Lisp, functions were lists whose first element was the symbol LAMBDA. In Bel, functions are lists whose first element is LIT and whose second element is CLO. But the details of what is in those lists is irrelevant. The point is, in both langauges, functions are lists. You can call CAR on a function and get a result. In McCarthy's Lisp, that result will be LAMBDA and in Bel it will be LIT. If you call CAR on a function in a modern Lisp you will get an error. ? (car (lambda () t)) > Error: The value #<Anonymous Function #x302000E7B61F> is not of the expected type LIST. Contrast with: ? (car '(lambda () t)) LAMBDA In addition, there is a special form in BEL called FN which, when evaluated, produces a function, i.e. a list whose first element is LIT and whose second element is CLO. McCarthy's original lisp had no such function. The special handling of functions, i.e. lists starting with LAMBDA, was hard-coded into the definition of EVAL. But that is also an irrelevant detail.
- akkartik 2y ago
  Ok, I think we're past the misunderstanding now. I don't understand why this makes it hard to compile Bel. Application code won't check the first two elements of the list to determine if a term is a function. Instead it will say ((isa 'function) ___). It seems fine that a program using the former approach will run slower.
  - lisper 2y ago
    > I don't understand why this makes it hard to compile Bel. Because Bel is supposed to be a specification, not an implementation. And if you specify that functions are lists then you are no longer free to implement them in a way that does not preserve the illusion that they are lists. Worse, in Bel, lists are mutable. That makes reasoning about programs nearly impossible. Every time you call CONS (which in Bel is spelled JOIN for some reason) you may or may not be producing a function. Every time you mutate a pair you may or may not be creating a function, or destroying one, or changing a function's environment. There is not and cannot be any barrier between the mutable and the immutable in Bel. It is not possible to add a data type that guarantees invariants. Mutable pairs are all you have to build with, and so whatever you build, not matter how carefully you design it, the rug can get pulled out from under you at any time by an errant call to XAR or XDR.
    - akkartik 2y ago
      Generalizing from the representation of functions to the absence of invariants makes your point crystal clear, thanks.

lisper 2y ago

Yes, that's right, but you have missed the point. In McCarthy's Lisp, functions were lists whose first element was the symbol LAMBDA. In Bel, functions are lists whose first element is LIT and whose second element is CLO. But the details of what is in those lists is irrelevant. The point is, in both langauges, functions are lists. You can call CAR on a function and get a result. In McCarthy's Lisp, that result will be LAMBDA and in Bel it will be LIT. If you call CAR on a function in a modern Lisp you will get an error. ? (car (lambda () t)) > Error: The value #<Anonymous Function #x302000E7B61F> is not of the expected type LIST. Contrast with: ? (car '(lambda () t)) LAMBDA In addition, there is a special form in BEL called FN which, when evaluated, produces a function, i.e. a list whose first element is LIT and whose second element is CLO. McCarthy's original lisp had no such function. The special handling of functions, i.e. lists starting with LAMBDA, was hard-coded into the definition of EVAL. But that is also an irrelevant detail.

akkartik 2y ago
Ok, I think we're past the misunderstanding now. I don't understand why this makes it hard to compile Bel. Application code won't check the first two elements of the list to determine if a term is a function. Instead it will say ((isa 'function) ___). It seems fine that a program using the former approach will run slower.
- lisper 2y ago
  > I don't understand why this makes it hard to compile Bel. Because Bel is supposed to be a specification, not an implementation. And if you specify that functions are lists then you are no longer free to implement them in a way that does not preserve the illusion that they are lists. Worse, in Bel, lists are mutable. That makes reasoning about programs nearly impossible. Every time you call CONS (which in Bel is spelled JOIN for some reason) you may or may not be producing a function. Every time you mutate a pair you may or may not be creating a function, or destroying one, or changing a function's environment. There is not and cannot be any barrier between the mutable and the immutable in Bel. It is not possible to add a data type that guarantees invariants. Mutable pairs are all you have to build with, and so whatever you build, not matter how carefully you design it, the rug can get pulled out from under you at any time by an errant call to XAR or XDR.
  - akkartik 2y ago
    Generalizing from the representation of functions to the absence of invariants makes your point crystal clear, thanks.