***rekado_ is now known as rekado
<rekado>Arne showed me where I was mistaken. <rekado>since the ugliness is mostly with string-append when actually I’d much rather have something specific for file names I guess I can avoid the problem with a macro. <rekado>so you’d say ‘file’ instead of ‘string-append’ and it would take care of concatenating the arguments (that may be wrapped across lines) and normalizing the resulting string. <zimoun>rekado: ’file’ seems a good keyword improve the readibility IMHO. *zimoun AFK because he is building a snowman ;-) <rekado>zimoun: go, build the whole snow family! <rekado>when I was visiting my grand parents in Sweden one day we built a life-sized polar bear. Hard to see on the photos, because it’s a white bear on a white background. <rekado>I always wanted to provide a ‘file’ helper, but there’s a complication with variables <rekado>if you modeled it after Python’s os.path.join, then (file "foo" "bar" "baz") would become ‘./foo/bar/baz’, but how would you build a file where only *part* of a directory is variable? <rekado>Python uses format strings for that, but I find this ugly in Scheme. <rekado>the ‘file’ macro could expect ‘/’ to be provided to indicate directory separators, but with all the string quotes this may be a little noisy <rekado>like (file / "foo" / "bar" / "baz_" type "." extension) <rekado>I already have ‘expand’, which returns a list of file names (strings) from all combinations of list variables. <rekado>e.g. (expand "baz_" (list "foo" "bar") "." (list "txt" "org")) would give you (list "baz_foo.txt" "baz_foo.org" "baz_bar.txt" "baz_bar.org") <rekado>I wonder if there’s a good-looking way to combine them. <rekado>(it’s so hypocritical of me to be labouring over syntax when I tell people in my FOSDEM talk that syntax is the least interesting of things to discuss…) <zimoun>wow! real-size of a bear, ambitious snow project. :-) <zimoun>rekado: Without painting the bikeshed with syntax. What do you mean by issue with (file “foo” “bar” “baz”) returning “foo/bar/baz”? Because / is the sepaator in the filesystem. I mean (file / “foo” / “bar” / “baz”) returning “/foo/bar/baz”) seems redundant. <rekado>take this as an example: (file "home" "zimoun" something ".txt") <rekado>every component must be a directory or a complete file name <rekado>it cannot be a partial file name. <rekado>so you’d need to do something like: (file "home" "zimoun" (string-append something ".txt")) or (file "home" "zimoun" (format #f "~a.txt" something)) <rekado>what I propose is (file / "home" / "zimoun" / something ".txt") <rekado>compare this with Python’s os.path.join("home", "zimoun", "{something}.txt") <rekado>this can also be combined with “expand”, so that list components are expanded to multiple files <rekado>(files / "home" / (list "zimoun" "rekado") / "projects" / a (list ".txt" ".jpg")) <rekado>for a defined as “foo” => (list "/home/zimoun/projects/foo.txt" "/home/zimoun/projects/foo.jpg" "/home/rekado/projects/foo.txt" "/home/rekado/projects/foo.jpg") <rekado>I think it’s convenient to specify files in a way that is consistent without exposing the underlying representation too much <rekado>string-append is odd, and having to take care of adding a slash (or removing it) is a nuisance <rekado>in pigx-rnaseq I see a bunch of definitions of base directory names and they are all inconsistent: some end on a slash, others don’t. <rekado>when treating files as strings you need to take care of adding a slash when combining file and directory name <rekado>the “file” constructor would take care of all of this <rekado>but … I must say that I’m not sure about implementing it as a macro <rekado>I guess I can’t insulate the users from a fundamental design decision in wisp <rekado>still, “file” could replace the instances of “expand” and “string-append” <rekado>so I think that’s still worth doing ***civodul` is now known as civoudl
***civoudl is now known as civodul
<civodul>rekado: oh right, not having to deal with slashes is good <civodul>making it a macro with / as a literal is what's more surprising to me :-) <civodul>but anyway, if the end result is more readable and reliable for this use case, that's great!