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 -- 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.
