On Sat, Mar 24, 2012 at 12:36 PM, Eli Barzilay <e...@barzilay.org> wrote: > IMO defining `Path-String' in a way that doesn't correspond to > `path-string?' is not a good idea. I'd prefer it if the name was > changed or if the type changes to accurately reflect the predicate.
I this this is a place where we just have to accept that types are less precise than runtime checks. The invariant that the string can't contain #\null and that the path must be for the current system is like the invariant that you can't divide by zero. It's not something we can realistically express in the type, and given that `Path-String' is defined to be (U Path String), and is the type used for functions that consume and produce `path-string?' values, I think `Path-String' is the right name. > > (The latter might be more problematic since it probably implies doing > more checking than done now, and also there's the question of getting > into path-strings for other platforms...) > > > > Yesterday, Sam Tobin-Hochstadt wrote: >> That's true, which is why it has to have a more complex filter than >> you'd expect. But if a value isn't `path-string?', then it is >> definitely not a `Path', and if it *is* `path-string?' then it's >> either a `String' or a `Path'. So we can express an approximation >> of it's behavior in the type. >> >> On Fri, Mar 23, 2012 at 12:09 PM, Eric Dobson <eric.n.dob...@gmail.com> >> wrote: >> > Actually I don't think this is an over sight. The null string is a >> > String. And Path-String is Path U String, but (path-string? >> > (string #\null)) => #f. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! -- sam th sa...@ccs.neu.edu _________________________ Racket Developers list: http://lists.racket-lang.org/dev
