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
