IRC channel logs

2021-01-16.log

back to list of logs

***rekado_ is now known as rekado
<rekado>bah, thwarted by macros again!
<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>*grandparents
<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…)
<civodul>heheh :-)
<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")
<civodul>hmm isn't this going too far? :-)
<rekado>is it?
<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>let them learn the dot
<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!