This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Source for ticket #49

cc


    

changetime

2011-01-24 06:40:58

component

WG1 - Core

description

There are code which uses tricks to report <undefined> values, like this one:
(if #f #f)   

Some cleaner mechanism has to be proposed for returning <undefined> values. 

id

49

keywords


    

milestone


    

owner

medernac

priority

minor

reporter

medernac

resolution

wontfix

severity


    

status

closed

summary

undefined values

time

2010-04-14 20:04:29

type

defect

Changes

Change at time 2011-01-24 06:40:58

author

cowan

field

comment

newvalue

WG1 voted not to have an undefined-value API.

oldvalue

4

raw-time

1295822458000000

ticket

49

time

2011-01-24 06:40:58

Change at time 2011-01-24 06:40:58

author

cowan

field

resolution

newvalue

wontfix

oldvalue


    

raw-time

1295822458000000

ticket

49

time

2011-01-24 06:40:58

Change at time 2011-01-24 06:40:58

author

cowan

field

status

newvalue

closed

oldvalue

assigned

raw-time

1295822458000000

ticket

49

time

2011-01-24 06:40:58

Change at time 2010-04-22 15:04:58

author

medernac

field

comment

newvalue

I agree that the best would be to standardize "void", at least I known that Chicken, Gambit, Guile and STklos implementations have it.

Then we must make sure that forms returning unspecified/undefined values returns (void).

oldvalue

3

raw-time

1271923498000000

ticket

49

time

2010-04-22 15:04:58

Change at time 2010-04-21 07:09:41

author

arcfide

field

comment

newvalue

Yes, there is a difference, but I think this is talking specifically about unspecified values. I would say that the VOID thunk is as good as any for a procedure that explicitly returns an unspecified value. This is different than something like what is filled in a vector. You don't want to force vectors to contain any sort of data, because this could be a very serious performance problem. It's much better to let them be filled with whatever the implementation wants to fill it at the time. The 2-argument version of that function should be used when you want to guarantee something about the contents: (make-vector k #f). It's not dangerous to have these values be unreliable, because they'll still be something, even if you can't predict what they will be. It will not cause Scheme to crash, and it should not. And yes, there is a big difference between an undefined or unspecified value and an unbound variable. A variable that is unbound has a specific name, but no bindings, whereas an unspecified value may have a specific single representation, but it probably is bound to very few names, or locations, if any.

oldvalue

2

raw-time

1271808581000000

ticket

49

time

2010-04-21 07:09:41

Change at time 2010-04-19 14:30:28

author

medernac

field

comment

newvalue

Let it be clearer:

I know there are a proposed mechanism in R6RS with exceptions, however there are cases where a specific "undefined" value are to be returned. 
For instance when an empty vector is created (make-vector k), depending on the implementation different Schemes give different values inside the vector cells, this is dangerous if these values are used and cannot be identified as "undefined" values.

Question: Is there a difference between unbound variable and a variable with undefined value ? to me yes, because the unbound variable is not allocated, whereas a variable with undefined value is allocated.

oldvalue

1

raw-time

1271662228000000

ticket

49

time

2010-04-19 14:30:28

Change at time 2010-04-19 14:30:28

author

medernac

field

owner

newvalue

medernac

oldvalue

alexshinn

raw-time

1271662228000000

ticket

49

time

2010-04-19 14:30:28

Change at time 2010-04-19 14:30:28

author

medernac

field

status

newvalue

assigned

oldvalue

new

raw-time

1271662228000000

ticket

49

time

2010-04-19 14:30:28