Is `let foo = () = foo;` good or bad?

1 points by s-p-n 8 years ago | 3 comments

I'm playing around making a language.

I'm a firm believer that recursion is good, but there's a lot going in in `let foo = () => foo;`.

First, I think `let foo` is interpreted, and `foo` is immediately hoisted, as it will be defined.

Second, the value of foo is known to be a function.

That function code isn't evaluated at all, and here's where I have several thoughts going through my head.

I was wondering, at compile-time, should a language bother checking identifiers? I don't particularly like hoisting and think values should be evaluated before declaration begins to take place. I've always liked recursion, but at the moment I thought: "if I want to do recursion, I shouldn't implement any id-validity checking in functions."

Let's say, let bar = () => foo(); (function() { window.foo = () => console.log("hi"); }()); bar(); // console logs "hi"

So, at compile-time it seems complicated to check for the existence of "foo" in the function "bar". I mean- sure, it's possible- but it seems like a losing battle for a compiler to chase identifiers all around the program, simply to check if they will exist when they are needed.

So I suppose one solution is to just let undefined identifiers slide unchecked until runtime. Another solution is to check as much as possible, unless or until the existence of an identifier could potentially come to being during input.

For example, the compiler could see that an array of links in a search-robot might be built after visiting a url that has n links. Perhaps a function is generated for each link, so the compiler might see `links[i].visit()` and think, "Well, that function 'visit' isn't ever created, but links is an object populated by a resource, and maybe that resource provides the necessary API at runtime to make ..visit() defined." Designing a compiler like that seems.. not simple.

So ya, idk. Thoughts?

TheAsprngHacker 8 years ago |

For identifier validity checking and recursion, you should look into let-rec and its differences from ordinary let. As for API checking, you would probably be using typeclasses or interfaces to specify an API. Even if the individual URL objects do not exist yet, a URL type should exist (at compile-time) that defines what operations are valid. I don’t think that a separate function would need to be generated for each link, but you can build arbitrary operations at runtime with first-class functions.

s-p-n 8 years ago | |

Thanks! I'll look into let-rec, I've never heard of it before :)

Everything in my language is an expression, so I guess you could say every literal in the language is first-class.

I was thinking for i/o, I could use promises. The promise would resolve to whatever type makes sense for that resource- defined either by a library or by the program.

Of course, that brings up "arbitrary operations at runtime". My target after transpiling is JavaScript, which has a wonderful JIT compiler already. I need to learn source mapping and stuff so I can make error-tracing work nicely, as it's simply not possible to catch any possible error at compile-time.

s-p-n 8 years ago | |

Oh I read what letrec was, that is exactly the solution I was looking for! :)