On Thursday, January 10, 2019 at 11:45:02 AM UTC-5, gneuner2 wrote: > > > On 1/10/2019 9:14 AM, David K. Storrs wrote: > > On Tuesday, May 22, 2018 at 7:56:21 AM UTC-4, Matthew Flatt wrote: > >> To build paths for a convention other than the current machine's >> convention, you have to work in bytes instead of strings. >> >> (define (bs->p bs) (bytes->path bs 'unix)) >> (build-path/convention-type 'unix (bs->p #"/") (bs->p #"foo") (bs->p >> #"bar")) >> >> Roughly, strings don't work, because they have to be converted to bytes >> using the locale's default encoding. Although strings are allowed for >> the current platform's convention on the assumption that the current >> locale's encoding is the right one, we've avoided building in any >> assumption about the encoding for the other convention. >> >> > Why is this the case? For that matter, why are strings and paths even > separate datatypes? Racket is the only language I've ever seen that does > this, and I can't figure out what the value add is. Especially since most > 'path' functions will accept either paths or strings, it's clear that > Racket *can* do all the relevant things without needing the 'path' type. > Certainly the 'path' type causes a lot of friction when serializing or > persisting. > > > Lisp does it too. The idea, naturally, was code portability: Lisp comes > from a time when there were many competing [and incompatible] machines and > operating systems. Although the world largely has been reduced now to > *nix and Windows, the idea of a portable solution still has attraction. > > Obviously a given path may not be usable on a system having a different > filesystem structure ... that's not the purpose. The purpose is that the > program can locate things and manipulate paths in the same manner using the > same functions on any supported system. > > Having to work with paths is a PITA if you mostly work on one system. But > if a program really needs to be portable, they can save you a lot of grief. > > YMMV, > George >
Hm. I'm not seeing it. Perl, Python, and (ugh) Java can all handle strings for paths and manage them portably. (e.g. Perl will understand that, when on Windows, "/foo/bar" should be equivalent to "\\foo\\bar".) Sure, if you pass "/usr/bin/touch" to a freshly-installed Windows box it will tell you to take a hike because none of the elements of that path exist. That's not the point. If you pass a string that models a path that is valid on a machine then it should work regardless of OS. Granted, Windows is a bit of a special snowflake in that "/foo/bar" is relative to the current drive on Windows but absolute on a Unix box. Still, provided that I manage my expectations correctly and ensure that the necessary file structures exist, I see no reason why it shouldn't work. What, precisely, requires Racket to have separate string, path, and windows-path datatypes? Is it simply historical reasons, or is there an actual reason? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
