> 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.
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.
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.
> 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.
> 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.
> The ignorance you display here is truly breathtaking.
Remember when I said "if you disagree, give me an example of such research"? Now is the time to do that.
> Here is an existence proof that you are wrong about that:
No it isn't. Because they have lambda defined as an axiom. If you define lambda in terms of lists, and lists in terms of lambda, it's pretty trivial to say you have a circular reference on your hands.
"They" is me -- I wrote that article. And no, "they" do not have lambda defined as an axiom. There are no axioms in that article because there are no proofs. It's just a demonstration of how you can do math using lambda calculus, with pairs being built along the way (and ultimately abandoned in favor of Church numerals) along with an actual implementation of a serializer for lambdas called lc-expand. If you don't see how that refutes your claim that "If you have a list defined "al la lambda calculus" as a lambda term, you can't really write it down fully" I'm not going to try to explain it to you. You are apparently beyond my ability to help.
Makes sense. The HTML elements are broken in some of the code snippets by the way. A few of & scattered about the place.
> There are no axioms in that article because there are no proofs.
Google "Curry-Howard correspondence". Computation is defined through axioms; you cannot compute without them.
> You are apparently beyond my ability to help.
I think you are just incapable of reading and processing ideas from other people without insulting them due to some sort of ego-trip where you imagine you are the messiah sent from heaven to educate us poor ingrates about programming when you clearly are not. Be less obnoxious in future and more open to new ideas.
Where do you think textbooks come from? Have you ever looked at a textbook? Have you noticed that textbooks typically include a section called "References" (as this one does)? What do you think that is for?
> The HTML elements are broken in some of the code snippets by the way.
I know. That page was just exported from MS Word. Fixing it is not high on my priority list.
> you cannot compute without them.
What does that have to do with the fact that the article I pointed you to has neither proofs nor axioms in it?
> I think you are just incapable of reading and processing ideas from other people
Yes, and I'm not the one compulsively ending every comment with a jab at the other guy's intelligence.
> What does that have to do with the fact that the article I pointed you to has neither proofs nor axioms in it?
So because you didn't write them down, you think they don't exist?
> as this one does
Quite frankly, I'm not going to spend $77 and wait for shipping to find out what's in the references section of some random text book. It seems like it should be an awful lot easier to find one of these hundreds of people you know.
> because you didn't write them down, you think they don't exist?
No, I just think they are irrelevant to adjudicating your claim that "If you have a list defined "al la lambda calculus" as a lambda term, you can't really write it down fully...". I've refuted you with an actual implementation (which you have obviously not even bothered to look at). The fact that my implementation could be axiomatized has nothing to do with it.
> I'm not going to spend $77 and wait for shipping to find out what's in the references section of some random text book.
EOPL is not "some random text book."
But it doesn't really matter. Pick up any textbook you like on programming languages published in the last 40 years. I'd be surprised if you could find even one that did not reference McCarthy's original Lisp paper.
> which you have obviously not even bothered to look at
Again, you presume my ignorance because the only alternative is that I understand you and still think you are wrong. How do you think I knew about the contents of your article if I didn't read it? Half the reason I noticed the HTML elements is because they gave me a syntax error why I tried to evaluate your code.
> I'd be surprised if you could find even one that did not reference McCarthy's original Lisp paper.
Well that's quite interesting. So the fact that some text books reference one specific paper is proof of thousands of hours of research across hundreds of people, all of whom would be insulted by my claim that lists aren't a very good processing primitive? Honestly, I suspect most of them would agree with me that they're better as syntax. You seem quite obsessed with lambda calculus yourself based on your articles and talks and you utterly despise all the list-based stuff from Del. Given that you always seem to write the lambdas with list syntax, you seem to agree with me in every point. So why are you looking for people to be offended by something that we both seem to believe?
No, I presume nothing. I conclude your ignorance because you continually supply me with evidence for it.
> the fact that some text books reference one specific paper is proof of thousands of hours of research across hundreds of people
No, it is not proof of anything. It is evidence that your claim that "People like to say that lisp had a much greater influence than it actually did" is wrong.
So what is the word for when you say I haven't looked at your website based on no evidence and in the presence of evidence to the contrary? I would say "presume" fits the bill. And that is something. So it does seem that you have presumed something. And that is the exact thing I was saying you presumed. It's a pretty basic fact and it's written down. But you will still dispute it and claim I'm being stupid.
> It is evidence that your claim that "People like to say that lisp had a much greater influence than it actually did" is wrong.
I thought we were discussing the "hundreds of people" that my previous assumption apparently denigrates. But if you want to talk about inflating lisp's reputation, a good example would be talking about how a single paper on list being cited in _lisp_ text-books is evidence that it is "the foundation of all modern programming languages".
Would you say there are properties of this textbook that make it more related to lisp and lisp interpreters than the average textbook, and hence more likely to reference the early material about lisp and lisp interpreters?
Can you really not answer a question that simple? Every textbook has a certain amount of lisp in it. Take the average of all of those amounts (the mean, lets say), and you will get the amount of lisp in the average textbook. This is a substantially smaller amount than the one you just picked. Can you really not work that out of your own accord? Can you think of any definition of the average textbook that means it has as much lisp as the one you just picked out? No. I think you are just being obtuse.
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
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.