I was looking in List
for a way to join a list of strings together but was surprised it was in Str
. I assumed functions in the standard lib were namespaced with the type they accept as the first argument (which is pretty intuitive to me).
If I understand the reason why it's in Str
it will help me know where to look in the future.
I had the same reaction.
Also in my 2d array library I have a function Array2D.joinWith
that works the same way, it just take two joining strings to join both elements and rows. It feels a bit awkward that my function doesn't mirror the built-ins. I could do Array2D.Str.joinWith
but that didn't seem worth it.
I think it is for reading with intuitive name. List.joinWith
would have nothing to do with strings. It would be for any arbitrary list.
I guess it could be List.joinStrings
but that doesn't feel better to me.
@Brendan Hansknecht there are a lot of functions in List
that only work on Num
(such as List.sum
). I wouldn't want it to be Num.sum
, but you could make the same argument for it.
yeah, fair.
Though I do think joinWith
is too generic of a name to just put in List
. (if it only works for strings)
the Str
module currently depends on List
and not the other way around
it's technically possible to cheat our way into circular dependncies in builtin modules (e.g. for Num.toStr
, since Str
certainly depends on Num
) but I like to minimize that
I don't think it's too bad the way it is. Where would you want the function to live ideally?
@Richard Feldman good to know, I didn't realize it was an internal dependency reason. I suppose it's a balance between an ideal interface and a clean implementation (if List.joinWith would be ideal).
I would expect List.joinWith
to do the same as List.join
but with the specified separator interspersed
yeah same :big_smile:
Last updated: Jul 06 2025 at 12:14 UTC