Opened 6 years ago

Closed 4 years ago

#155 closed defect (fixed)

Make recursively defined code an explicit error

Reported by: cowan Owned by: alexshinn
Priority: major Milestone:
Component: WG1 - Core Keywords:


Allowing examples like these will make code-walkers (including compilers and interpreters) excessively complicated:

#1=(begin (display #\x) . #1#)

(lambda #2=(a b c #2#) ...)

(+ . #3=(1 2 3 . #3#))

Change History (8)

comment:1 Changed 6 years ago by arcfide

My initial thoughts are, why? We already have non-terminating expansion, and at least one major Scheme implementation handles this by looping forever. I would think that detecting the loop is more expensive than just letting an implementation loop.

Doing this would complicate the expander, and I wonder if this is worth it. What do existing Schemes say about it?

comment:2 Changed 6 years ago by cowan

I'm not proposing that an error be signaled. It's simply that code like the above is incorrect: you can't rely on it doing something in particular, never mind "the obvious thing". That is what "is an error" means in the Scheme standard.

comment:3 Changed 6 years ago by arcfide

Do we really want this to be considered an error at all? I could imagine writing a program that used such a chain, though I cannot think, at the moment why I would do that. My point is basically, does it really hurt anything to let implementation apply a reasonable semantics to it if they can find one? I like unspecified better.

comment:4 Changed 6 years ago by cowan

If it's a meaningful extension in some Schemes, then (as I said) code-walkers have to accommodate it.

comment:5 Changed 6 years ago by arcfide

It is possible to construct this situation in current implementations of R5RS and R6RS, so how do code walkers handle this situation currently? It is trivial to handle this situation in a code walker by not-terminating; is this incorrect behavior? What is the current practice when dealing with these forms today? Do any of them consider this to be an explicit or implicit error situation? Neither R5RS nor R6RS handle this explicitly to my knowledge, is it worth it for us to do so? Why complicate the language with this? I don't think it is worth it and I don't think it buys us anything.

comment:6 Changed 6 years ago by alexshinn

  • Status changed from new to decided

We voted to note this is an error.

comment:7 Changed 6 years ago by alexshinn

  • Status changed from decided to writing

comment:8 Changed 4 years ago by cowan

  • Resolution set to fixed
  • Status changed from writing to closed
Note: See TracTickets for help on using tickets.