[racket-dev] Oversight in type for path-string?

On Sat, Mar 24, 2012 at 12:36 PM, Eli Barzilay <eli at 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.dobson at 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
samth at ccs.neu.edu