5 ms·

> But punning lists as functions is a still mistake for other reasons Formally speaking, you would struggle to do it any other way. If you introduce a type for

> But punning lists as functions is a still mistake for other reasons Formally speaking, you would struggle to do it any other way. If you introduce a type for functions, you need some way to get to it from lists in order for macros to work. Then that totally muddies the definition of eval. You'd basically have to replace it with some "compile" function that turns an expression into a set of lambdas then executes them. One starts to question the need for lists at all at that point, but when you start representing data as lambdas you lose the well-foundedness of lists. Suddenly lambda isn't something you can write down but just an output from "compile". If you wanted to write lambda in terms of lists, they would need be written in terms of lambdas and you end up with an infinitely recursive problem. So lists are never really written down, just constructed by "read" and input to "compile". What you have at that point is no longer lisp, but just a compiler to lambda calculus. I think the lesson here is really that lisp is a convenient syntax but a lousy model for computation. From that regard, saying "I'll do a purely formal lisp" is a mistake. The formal component of lisp is a waste of time and only its practical aspects are useful.

lisper 2y ago
> Formally speaking, you would struggle to do it any other way. Um... why? > If you introduce a type for functions, you need some way to get to it from lists in order for macros to work. Sure. So? That has been a solved problem for over fifty years. > Then that totally muddies the definition of eval. No, it doesn't. There is absolutely no reason that a function has to be represented as a list. The only reason it was represented as a list in McCarthy's original design is because there was nothing else. See here: https://flownet.com/ron/l.py https://flownet.com/ron/l.py for an example of a Lisp interpreter written in Python where functions are represented as Python objects. You will note that the other than being written in Python, the definition of eval is not at all muddled. > I think the lesson here is really that lisp is a convenient syntax but a lousy model for computation. I think you don't know what you're talking about. The syntax has absolutely nothing to do with punning lists. You can pun lists in any language, and it's an equally bad idea in any language.
- James_K 2y ago
  When you mentioned lambda calculus I assumed you meant functions were to be added as a primitive executable type. Then you would logically have lists defined as: (define (cons a b) (lambda (x y) (x a b))) (define nil (lambda (x y) (y))) Which is problematic because you can write down the list-form of a lambda but not the actual value of it. When you suggest the addition of an additional record type to the language because it's good from a software engineering perspective, I think this goes against the idea for this document (that the language should be entirely formal and ignore software engineering considerations). There are all sorts of things you might want types for, but I think the point here is to demonstrate that you can use lists for all of them. > I think you don't know what you're talking about. Rude.
  - lisper 2y ago
    > Which is problematic because you can write down the list-form of a lambda but not the actual value of it. That's not true. Nothing prevents you from defining a serialization format for lambdas. That is in fact what all modern Lisps do. > When you suggest the addition of an additional record type to the language When did I suggest that? Pointing out that Bel doesn't have a record type is not the same as suggesting one should be added. Bel is intended to be a specification, not an implementation. > Rude. Do you think so? I was responding to this: > I think the lesson here is really that lisp is a convenient syntax but a lousy model for computation. Calling Lisp a "lousy model for computation" is not only objectively false -- Lisp is the foundation of all modern programming languages -- it also denigrates the work of hundreds of people over decades. Maybe that's not what you intended. Maybe you are simply ignorant. But I actually thought that mine was a pretty measured response.
    - James_K 2y ago
      > That's not true. Nothing prevents you from defining a serialization format for lambdas. That is in fact what all modern Lisps do. If you have a list defined "al la lambda calculus" as a lambda term, you can't really write it down fully because to do that you'd need to write a lambda and a lambda is written in terms of lists and lists are written in terms of lambda. As an example: (a b) ;; is a shorthand for (a . (b . nil)) ;; and with lists that's where it ends ;; but with lambdas (a . b) ;; is a shorthand for (lambda (f g) (f a b)) ;; is a shorthand for (cons lambda (cons (cons f (cons g nil)) (cons (cons f (cons a (cons b nil)))))) ;; which expands to (lambda (f g) (f 'lambda (lambda (lambda (f g) (f 'f (lambda (f g) (f 'g nil)))) (f (f g) (lambda (f g) (f (lambda (f g) (f 'f (lambda (f g) (f 'a (lambda (f g) (f 'b nil)))))))))))) ;; which is a shorthand for ... You never reach the end of it. > Lisp is the foundation of all modern programming languages Not really. People like to say that lisp had a much greater influence than it actually did. If I called Smalltalk the "foundation of all modern programming languages", you'd instantly see that it isn't true. Lisp was one step taken by some people along one particular path, not the first or the last and hardly the foundation. > it also denigrates the work of hundreds of people over decades No it doesn't. If you think it does then name them. To my knowledge the people researching programming don't use list-based methods of computation because they are too complex and the people implementing programming languages don't use list-based methods of computation because that's not how hardware works. > Maybe you are simply ignorant Maybe you are simply rude.

lisper 2y ago

> Formally speaking, you would struggle to do it any other way. Um... why? > If you introduce a type for functions, you need some way to get to it from lists in order for macros to work. Sure. So? That has been a solved problem for over fifty years. > Then that totally muddies the definition of eval. No, it doesn't. There is absolutely no reason that a function has to be represented as a list. The only reason it was represented as a list in McCarthy's original design is because there was nothing else. See here: https://flownet.com/ron/l.py https://flownet.com/ron/l.py for an example of a Lisp interpreter written in Python where functions are represented as Python objects. You will note that the other than being written in Python, the definition of eval is not at all muddled. > I think the lesson here is really that lisp is a convenient syntax but a lousy model for computation. I think you don't know what you're talking about. The syntax has absolutely nothing to do with punning lists. You can pun lists in any language, and it's an equally bad idea in any language.

James_K 2y ago
When you mentioned lambda calculus I assumed you meant functions were to be added as a primitive executable type. Then you would logically have lists defined as: (define (cons a b) (lambda (x y) (x a b))) (define nil (lambda (x y) (y))) Which is problematic because you can write down the list-form of a lambda but not the actual value of it. When you suggest the addition of an additional record type to the language because it's good from a software engineering perspective, I think this goes against the idea for this document (that the language should be entirely formal and ignore software engineering considerations). There are all sorts of things you might want types for, but I think the point here is to demonstrate that you can use lists for all of them. > I think you don't know what you're talking about. Rude.
- lisper 2y ago
  > Which is problematic because you can write down the list-form of a lambda but not the actual value of it. That's not true. Nothing prevents you from defining a serialization format for lambdas. That is in fact what all modern Lisps do. > When you suggest the addition of an additional record type to the language When did I suggest that? Pointing out that Bel doesn't have a record type is not the same as suggesting one should be added. Bel is intended to be a specification, not an implementation. > Rude. Do you think so? I was responding to this: > I think the lesson here is really that lisp is a convenient syntax but a lousy model for computation. Calling Lisp a "lousy model for computation" is not only objectively false -- Lisp is the foundation of all modern programming languages -- it also denigrates the work of hundreds of people over decades. Maybe that's not what you intended. Maybe you are simply ignorant. But I actually thought that mine was a pretty measured response.
  - James_K 2y ago
    > That's not true. Nothing prevents you from defining a serialization format for lambdas. That is in fact what all modern Lisps do. If you have a list defined "al la lambda calculus" as a lambda term, you can't really write it down fully because to do that you'd need to write a lambda and a lambda is written in terms of lists and lists are written in terms of lambda. As an example: (a b) ;; is a shorthand for (a . (b . nil)) ;; and with lists that's where it ends ;; but with lambdas (a . b) ;; is a shorthand for (lambda (f g) (f a b)) ;; is a shorthand for (cons lambda (cons (cons f (cons g nil)) (cons (cons f (cons a (cons b nil)))))) ;; which expands to (lambda (f g) (f 'lambda (lambda (lambda (f g) (f 'f (lambda (f g) (f 'g nil)))) (f (f g) (lambda (f g) (f (lambda (f g) (f 'f (lambda (f g) (f 'a (lambda (f g) (f 'b nil)))))))))))) ;; which is a shorthand for ... You never reach the end of it. > Lisp is the foundation of all modern programming languages Not really. People like to say that lisp had a much greater influence than it actually did. If I called Smalltalk the "foundation of all modern programming languages", you'd instantly see that it isn't true. Lisp was one step taken by some people along one particular path, not the first or the last and hardly the foundation. > it also denigrates the work of hundreds of people over decades No it doesn't. If you think it does then name them. To my knowledge the people researching programming don't use list-based methods of computation because they are too complex and the people implementing programming languages don't use list-based methods of computation because that's not how hardware works. > Maybe you are simply ignorant Maybe you are simply rude.