Hacker News Reader

Comment by lisper | Hacker News Reader

Well, it's a noble goal, but fails rather spectacularly right off the bat.

> Bel has four fundamental data types: symbols, pairs, characters, and streams.

The inclusion of streams is already enough to make me go WTF, and the absence of numbers, vectors, and functions as primitives is a big yellow flag. Punning lists as functions is huge blunder because it makes it nearly impossible to compile the language.

View on HN

> I want to be clear about what Bel is and isn't. Although it has a lot more features than McCarthy's 1960 Lisp, it's still only the product of the formal phase. This is not a language you can use to program computers, just as the Lisp in the 1960 paper wasn't. Mainly because, like McCarthy's Lisp, it is not at all concerned with efficiency. When I define append in Bel, I'm saying what append means, not trying to provide an efficient implementation of it.

That doesn't seem to be their goal.

OK, that's a fair point. But punning lists as functions is a still mistake for other reasons. For example, it makes it impossible to tell the difference between a list that is actually intended to be a function, and one that just happens to end up looking like a function by happenstance. It's fine to represent functions as lists, but having functions actually be lists rather than a first-class primitive is a huge mistake. If you're going to do that, you might as well just start with McCarthy's original primitives, or heck, even just the untyped lambda calculus. What is the point of adding characters and streams?

I think one reason to add characters and streams is so you can implement read and print, the R and the P in a Lisp REPL. The original Lisp assumes s-expressions are given, but provides no mechanism for creating them out of characters read from keyboard or printed to screen. Bel is taking the same axiomatic approach of the original Lisp but to a more realistic system.

Similarly, ccc exists so onerr can exist, which exists so saferead can exist, which exists so the REPL can show errors on screen.

That hangs together for me. But I still don't understand the distinction you're making between representing as lists vs being lists.

> so the REPL can show errors on screen

And how do you formalize the screen? (BTW, this is just speculation on your part. The word "screen" doesn't actually appear anywhere in the article.)

You can't have it both ways. Either you are going to formalize everything, or you're going to punt at some point and yield to practical considerations. And formalizing I/O is particularly hard.

> I still don't understand the distinction you're making between representing as lists vs being lists.

(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

But in modern Lisps you have to EVALUATE this list in order to get a function that you can call. In Scheme:

    ts> (define l '(lambda () #t))                  
    l
    ts> l
    (lambda () #t)
    ts> (l)
    Error: illegal function 
    ts> (define p (eval l))
    p
    ts> p
    #<CLOSURE>
    ts> (p)
    #t
    ts> (procedure? l)
    #f
    ts> (procedure? p)
    #t
    ts> (list? l)
    #t
    ts> (list? p)
    #f

> (lambda () t) is a list.

This is not right, and it's a very basic thing to get wrong. I don't think you understand what you're criticizing.

Even replacing the Bel name, this is not right:

> (fn () t) is a list

You _do_ have to eval it.

    bel> (eval '(fn () t))
    (lit clo nil () t)

I see the returned list as akin to a serialization format. It's an s-expression rather than some opaque representation that can't be printed. That seems nice, more debuggable. I don't see what makes it harder to compile than an opaque representation. You can compile it just fine, you're just carrying around the source code in say a debug segment of the image.

> (BTW, this is just speculation on your part. The word "screen" doesn't actually appear anywhere in the article.)

Look, you asked what the point of streams was. I pointed out what the metacircular source code does with streams.

If someone asks what the purpose of stdout is in Unix, it seems reasonable (and a hoary tradition) to justify it in terms of printing to screen. stdout is about much more than a screen, but "screen" is an easy answer to "why does my program need stdout?"

> I don't think you understand what you're criticizing.

Oh, I'm pretty sure I do.

    Functions are represented using lists. For example, here is a function that takes one argument, and returns that plus 1.
    
    (lit clo nil (x) (+ x 1))
    
    The first element, lit, says that this is a literal object, not to be  evaluated.

What you want in this kind of situation is for those symbols to be internal objects that cannot be written. Or perhaps symbols in a private system package, e.g.:

  (sys:lit sys:clo nil (x) (+ x 1))

No program using symbols in the ordinary namespace will produce this object by accident. It has to use the sys: stuff and when it does that, the language specification can say that it's sticking the proverbial fork into the proverbial toaster.

That doesn't help at all. These symbols don't have to be produced by the reader. All you need to do to get access to these symbols is to call FN once. That gives you a list whose first element is LIT and second element is CLO. So all you need to "stick a fork" in the Bel toaster is to be able to call FN and XAR.

Yes. In a nutshell, the problem is that (consp x) being true does not rule out (functionp x), which it should. (Unless consp is hacked in an unspeakable way.)

In a real implementation, you'd want a new kind of cons cell with a separate type tag so that it fails consp. It's okay if car and cdr like it.

> (consp x) being true does not rule out (functionp x), which it should

Exactly. That's what "punning lists" means.

> It's okay if car and cdr like it.

That's arguable. But the real problem is if XAR and XDR accept it. Functions, however they are implemented, should not be mutable. That way lies madness.

I don't know where the disconnect is, but I'll stop here. The statement you just quoted disagrees with what you said on two occasions before:

> It's fine to represent functions as lists, but having functions actually be lists rather than a first-class primitive is a huge mistake.

> (lambda () t) is a list

You said this would work in Bel:

    (setq l '(lambda () t))
    (l) --> T

This is false even after fixing the Bel names for things.

The disconnect is that PG misuses the word "represented". Functions in Bel are not just represented as lists, they are lists. Specifically, they are lists whose first element is the symbol LIT and whose second element is the symbol CLO. Functions can also be represented as lists that start with the symbol FN.

    You would not ordinarily express a function using its literal representation. Usually you'd say
    
    (fn (x) (+ x 1))
    
    which yields the function above.  [i.e. (lit clo nil (x) (+ x 1))]

So a list that starts with FN represents a function, but it is not a function. It has to be evaluated to produce a function, but the function that it produces is just another list, one which starts with LIT rather than FN.

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

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.

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.

> 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.

Generalizing from the representation of functions to the absence of invariants makes your point crystal clear, thanks.

Why would you need read and print in a language that isn't yet intended to program computers?

You don't need I/O in order to describe input and output in an abstract language. Literals, including quoted lists, are enough to encode input into the program as part of its body. The result of a function can be described using a notation like (+ 2 2) -> 4. It's not actually running so nothing needs to print that.

> 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.

> 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

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.

Rude.

> 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.

> Maybe you are simply ignorant

Maybe you are simply rude.

> If you have a list defined "al la lambda calculus" as a lambda term, you can't really write it down fully

Here is an existence proof that you are wrong about that:

https://flownet.com/ron/lambda-calculus.html

> To my knowledge the people researching programming don't use list-based methods of computation

The ignorance you display here is truly breathtaking.

> Maybe you are simply rude.

Yep, that's possible too.

> 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.

> Now is the time to do that.

Sigh.

https://www.amazon.com/Essentials-Programming-Languages-MIT-...

> they have lambda defined as an axiom

"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.

> https://www.amazon.com/Essentials-Programming-Languages-MIT-...

That is a textbook, not research.

> "They" is me -- I wrote that article.

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.

> That is a textbook, not research.

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

> Be less obnoxious in future

Do you hear yourself?

> Do you hear yourself?

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?

> you presume my ignorance

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.

> No, I presume nothing.

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".

EOPL is not a lisp text book. It is a textbook about programming languages in general. (Which you would know if you had bothered to look at it.)

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?

What would you consider the "average textbook"?

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.

To be honest, as I've read more of the Bel document, I have to say streams and characters feel rather "bolted on", especially since streams only work with binary. It feels like it's trying to straddle both the practical and theoretical, and ends up being a bit of a mess. I appreciate people exploring new concepts, but honestly this doesn't feel that novel.

Perhaps to make it a real programming language that you could use to do stuff?

What part of "This is not a language you can use to program computers" wasn't clear?

The "language" part. In context it seems to refer to the implementation, not the specification. I take it that pg does intend to specify a useful programming language, but not implement it.

> 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.

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.

> 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.

> 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.

> 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.

JIT compilation only works if functions can't change at run-time, which is true for most languages, but not for Bel.

Some fairly simple escape analysis could likely determine that most functions used in practice do not have their bodies assigned.

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.

You can still do escape analysis. You wouldn't even need to be very advanced with it since most code won't do anything close to modifying and expression that's in the process of evaluating.

You clearly don't know what escape analysis is or how it works. Escape analysis applies only to data allocated at run-time. Programs are generally written before they are run (this is the reason that "run-time" is even a thing) and the functions that comprise them in a Bel program are generally globally bound with DEF. Escape analysis doesn't work on globally bound data. It has already escaped before your program even starts to run.

You can look at where a name is used, I say "escape analysis" here because that is the technique closest to what you would be doing. It gets the idea across quite well. At the fundamental level, you are analysing a program to see which parts of it access which values. In this case assessing if a piece code bound to a global variable "escapes" into the rest of the program as data. The objectives and techniques are similar. This is quite clearly possible.

Escape analysis is a well-established term of art:

https://en.wikipedia.org/wiki/Escape_analysis

"In compiler optimization, escape analysis is a method for determining the dynamic scope of pointers..."

In the case of global bindings, there is nothing to analyze. Global bindings do not have dynamic scope, they have global scope. (Duh.)

> This is quite clearly possible.

OK, you believe what you want. But I'll bet you $100 that you can't even write a program that reliably determines whether or not a list is a valid Bel function, let alone one that does "escape analysis" on an entire Bel code base (whatever you think that might actually mean).

Here, I'll get you started:

    (def is-a-function? (l)
      (and (id (car l) 'lit)
           (id (cadr l) 'clo)
           ...

> valid Bel function

What do you mean by this? Can valid functions produce errors? Does a valid function need to halt?

> In the case of global bindings, there is nothing to analyze

A global name will be used in the program text a finite number of times. You can treat each usage as an the creation of a new value and do escape analysis on it. Doing this on all usages of a variable can determine that the none of these values escape and therefore the value cannot be passed to a list mutating function and is safe to optimise.

> What do you mean by this?

Whatever the spec says.

> You can treat each usage as an the creation of a new value

No, you can't, because aliasing.

https://en.wikipedia.org/wiki/Aliasing_(computing)

You really are totally clueless.

That's not an explanation, and quite frankly it's entirely unrelated. You can quite easily guarantee a top-level variable isn't initially aliased by looking at the form that assigned it. In most cases this will be a literal which is a fresh, unaliased value. If the value becomes aliased to more than one name, that means one instance of it escaped, so you will detect that when doing escape analysis. It's really quite simple logic.

> Whatever the spec says.

Well the document does mention a check for validity.

  (def variable? (v)
       (if (atom v)
           (no (literal v))
           (caris v vmark)))
  
  (def valid-special-param? ((t-or-o (o var) (o expr) . rest))
       (and (valid-params? var)
            ;; t parameters must have a type check.
            (or (id t-or-o o) expr)
            (no rest)))
  
  (def valid-params? (p)
       (if (no p) t
           (variable? p) t
           (or (caris p t) (caris p o)) (valid-special-param? p)
           (and (id (type p) 'pair)
                (valid-params? (car p))
                (valid-params? (cdr p)))))
  
  (def valid-top-params? (p)
       (and (no (caris p o)) (valid-params? p)))
  
  (def valid-function? ((o lit) (o clo) (o env) (o params) (o body) . rest)
       (and (id lit 'lit)
            (id clo 'clo)
            ;; Env, a proper list of pairs of symbols and bindings.
            (and (proper env)
                 (all [id (type _) 'pair] env)
                 (all variable? (map car env)))
            (valid-top-params? params)))

I think this should work, but I don't think it's worth $100.

Reply on news.ycombinator.com