janwirth/Any-sets

## Any-sets
SiriusStarr:bird:  12 hours ago
Is there any community consensus on the 14 different Dicts that allow custom types?  Or a comparison of them all?  Not really sure which to go with.


Jan Wirth  12 hours ago
Welcome to the growing elm ecosystem.

jhbrown  12 hours ago
I have a rule of thumb:  if there are >4 implementations of the same concept, you should write your own and then do not publish it.  It’s clearly something that’s easy to implement (thus >4) which implies not much code, so you might as well control the impl instead of picking a lottery ticket.
:heavy_plus_sign:
1


SiriusStarr:bird:  12 hours ago
Or we could get a core implementation!
:joy:
2


SiriusStarr:bird:  12 hours ago
:grin:

SiriusStarr:bird:  12 hours ago
Ok, next joke.
:sweat_smile:
1


SiriusStarr:bird:  12 hours ago
I suppose I should just wrap my own.
:sunglasses:
1


jhbrown  12 hours ago
The only interesting question is whether you’re going to preserve O(log N) performance by embedding a function in the dict representation (violates Elm doctrine but works fine) or if you’re going to accept O(N) in order to keep functions out.

jhbrown  12 hours ago
I mean, the simplest version is just a list of (key, value) pairs.

jfmengels  12 hours ago
If you are (or don't know yet if you will be) comparing these Dicts,  then you can rule out the ones where the "to comparable function" is stored inside the Dict (if you're writing an elm-review rule for instance, there will be these comparisons). It's usually the ones where empty takes a function.
The ones implemented as Lists (no need for a comparable) under the hood are I think slower.
Then you have the ones with a "to comparable function" that you need to pass to the insert function, which are probably faster but maybe less nice to use (but probably worth it?). I guess if you at one point pass the wrong "to comparable function" you will get odd results. (edited)

SiriusStarr:bird:  12 hours ago
I have no reason to compare dicts.

SiriusStarr:bird:  12 hours ago
so should be fine to have functions, but

SiriusStarr:bird:  12 hours ago
sighs

SiriusStarr:bird:  12 hours ago
All the pain and suffering that would be avoided with typeclasses

Shanan Dalton  12 hours ago
I've been using assoc-list and assoc-set.
the readme has a little writeup about various other implementations
https://github.com/pzp1997/assoc-list/tree/1.0.0 (edited)

Ed Kelly  11 hours ago
There's my one, which doesn't contain functions, doesn't require extra arguments, and isn't a list under the hood. But on the other hand it's a bit weird. https://package.elm-lang.org/packages/edkelly303/elm-any-type-collections/latest/

SiriusStarr:bird:  11 hours ago
That was what I was leaning towards, honestly, since I couldn't care less about asset size

jfmengels  11 hours ago
Interesting. I guess the drawback is that you can't dead-code eliminate the unused fields. And that if you somehow pass the wrong interface then you'll have weird results? Definitely an interesting approach
:100:
1


Wolfgang Schuster (wolfadex)  11 hours ago
FWIW, if I find myself wanting this then I just implement @Ed Kelly’s approach myself but only with the functions I need. Essentially I end up with
myConfig =
    { toComparable = \myThing -> ...
    , fromComparable = \comparable -> ...
    }


myDict = AnyDict.singleton myConfig MyThingKey someValue
This allows me to use a similar approach while also being able to use elm-review to eliminate unused functions. If I find that I’m no longer using AnyDict.fromList then I remove it. If I need it back a few weeks later then it takes me at most 2 min to add it back.

SiriusStarr:bird:  11 hours ago
Yep, I'll probably do that and wrap an IntDict

Wolfgang Schuster (wolfadex)  11 hours ago
I usually end up doing the same :smile: though mine’s labeled IdDict and the Id part is handled separately. So I can only pass in Ids

Wolfgang Schuster (wolfadex)  11 hours ago
Then I’m “not aware” of how the keys are comparable

supermario:flag-ua:  11 hours ago
If anyone is interested in writing a summary of the state of affairs for custom dict implementations and the trade offs, that could make a great reference page on Elmcraft!
:heart:
4
:+1:
1


erlandsona  11 hours ago
@Ed Kelly :thinking_face: I think I like that. @spencer :point_up: what'd you think?
:sunglasses:
1


Peter  2 hours ago
The recently published GWI Elm best practices recommends: turboMaCk/any-dict + turboMaCk/any-set
https://elmlang.slack.com/archives/C0K384K4Y/p1648115929626399
janiczek
Hey folks, I've written this collection of Elm tips&tricks for the company I work for, GWI, and I want to share those with you - perhaps you'll find something you didn't know yet :slightly_smiling_face:
Thanks a million to @lue and @joelq for helping me refine these and giving me some more ideas :slightly_smiling_face:
PDF

GWI Elm best practices.pdf
PDFView PDF in Slack


Thread in news-and-links | Yesterday at 10:58 AM | View message

sebbes  1 hour ago
Storing a function in the dict is fine.... Except if you need to use it in your model in Lamdera :sob:

supermario:flag-ua:  1 hour ago
@sebbes  check out Ed’s package which solves that problem :grinning:

sebbes  1 hour ago
I saw this one... I was a bit concerned with the non-ability to remove unused code, the scarrying Interface type signature, needing a lot of type variables and the unusual way of having a "pseudo-module" (1 concern would have been ok, but this is too much concerns to be ignored IMHO).
I finally picked https://package.elm-lang.org/packages/timo-weike/generic-collections/latest which fundamentally is the same idea (the "interface" being key -> comparable ) and is way simpler to understand.
That said @Ed Kelly, even if I wouldn't use it, it's really good stuff! Did you take inspiration from OCaml modules?
Or we could get a core implementation!
I'd hope this is not a joke... The number of packages trying to solve this issue kinda show there is an actual need for this
:heart:
1


Ed Kelly  23 minutes ago
Thanks! I think I must have known about OCaml modules in the back of my mind somewhere, but I've never actually used OCaml. In general I think this "record of functions" pattern is interesting, although I guess it's not a common API in Elm packages. (edited)
	SiriusStarr:bird: 12 hours ago
	Is there any community consensus on the 14 different Dicts that allow custom types? Or a comparison of them all? Not really sure which to go with.






	Jan Wirth 12 hours ago
	Welcome to the growing elm ecosystem.

	jhbrown 12 hours ago
	I have a rule of thumb: if there are >4 implementations of the same concept, you should write your own and then do not publish it. It’s clearly something that’s easy to implement (thus >4) which implies not much code, so you might as well control the impl instead of picking a lottery ticket.
	:heavy_plus_sign:
	1


	SiriusStarr:bird: 12 hours ago
	Or we could get a core implementation!
	:joy:
	2


	SiriusStarr:bird: 12 hours ago
	:grin:

	SiriusStarr:bird: 12 hours ago
	Ok, next joke.
	:sweat_smile:
	1


	SiriusStarr:bird: 12 hours ago
	I suppose I should just wrap my own.
	:sunglasses:
	1


	jhbrown 12 hours ago
	The only interesting question is whether you’re going to preserve O(log N) performance by embedding a function in the dict representation (violates Elm doctrine but works fine) or if you’re going to accept O(N) in order to keep functions out.

	jhbrown 12 hours ago
	I mean, the simplest version is just a list of (key, value) pairs.

	jfmengels 12 hours ago
	If you are (or don't know yet if you will be) comparing these Dicts, then you can rule out the ones where the "to comparable function" is stored inside the Dict (if you're writing an elm-review rule for instance, there will be these comparisons). It's usually the ones where empty takes a function.
	The ones implemented as Lists (no need for a comparable) under the hood are I think slower.
	Then you have the ones with a "to comparable function" that you need to pass to the insert function, which are probably faster but maybe less nice to use (but probably worth it?). I guess if you at one point pass the wrong "to comparable function" you will get odd results. (edited)

	SiriusStarr:bird: 12 hours ago
	I have no reason to compare dicts.

	SiriusStarr:bird: 12 hours ago
	so should be fine to have functions, but

	SiriusStarr:bird: 12 hours ago
	sighs

	SiriusStarr:bird: 12 hours ago
	All the pain and suffering that would be avoided with typeclasses

	Shanan Dalton 12 hours ago
	I've been using assoc-list and assoc-set.
	the readme has a little writeup about various other implementations
	https://github.com/pzp1997/assoc-list/tree/1.0.0 (edited)

	Ed Kelly 11 hours ago
	There's my one, which doesn't contain functions, doesn't require extra arguments, and isn't a list under the hood. But on the other hand it's a bit weird. https://package.elm-lang.org/packages/edkelly303/elm-any-type-collections/latest/

	SiriusStarr:bird: 11 hours ago
	That was what I was leaning towards, honestly, since I couldn't care less about asset size

	jfmengels 11 hours ago
	Interesting. I guess the drawback is that you can't dead-code eliminate the unused fields. And that if you somehow pass the wrong interface then you'll have weird results? Definitely an interesting approach
	:100:
	1


	Wolfgang Schuster (wolfadex) 11 hours ago
	FWIW, if I find myself wanting this then I just implement @Ed Kelly’s approach myself but only with the functions I need. Essentially I end up with
	myConfig =
	{ toComparable = \myThing -> ...
	, fromComparable = \comparable -> ...
	}


	myDict = AnyDict.singleton myConfig MyThingKey someValue
	This allows me to use a similar approach while also being able to use elm-review to eliminate unused functions. If I find that I’m no longer using AnyDict.fromList then I remove it. If I need it back a few weeks later then it takes me at most 2 min to add it back.

	SiriusStarr:bird: 11 hours ago
	Yep, I'll probably do that and wrap an IntDict

	Wolfgang Schuster (wolfadex) 11 hours ago
	I usually end up doing the same :smile: though mine’s labeled IdDict and the Id part is handled separately. So I can only pass in Ids

	Wolfgang Schuster (wolfadex) 11 hours ago
	Then I’m “not aware” of how the keys are comparable

	supermario:flag-ua: 11 hours ago
	If anyone is interested in writing a summary of the state of affairs for custom dict implementations and the trade offs, that could make a great reference page on Elmcraft!
	:heart:
	4
	:+1:
	1


	erlandsona 11 hours ago
	@Ed Kelly :thinking_face: I think I like that. @spencer :point_up: what'd you think?
	:sunglasses:
	1


	Peter 2 hours ago
	The recently published GWI Elm best practices recommends: turboMaCk/any-dict + turboMaCk/any-set
	https://elmlang.slack.com/archives/C0K384K4Y/p1648115929626399
	janiczek
	Hey folks, I've written this collection of Elm tips&tricks for the company I work for, GWI, and I want to share those with you - perhaps you'll find something you didn't know yet :slightly_smiling_face:
	Thanks a million to @lue and @joelq for helping me refine these and giving me some more ideas :slightly_smiling_face:
	PDF

	GWI Elm best practices.pdf
	PDFView PDF in Slack


	Thread in news-and-links \| Yesterday at 10:58 AM \| View message

	sebbes 1 hour ago
	Storing a function in the dict is fine.... Except if you need to use it in your model in Lamdera :sob:

	supermario:flag-ua: 1 hour ago
	@sebbes check out Ed’s package which solves that problem :grinning:

	sebbes 1 hour ago
	I saw this one... I was a bit concerned with the non-ability to remove unused code, the scarrying Interface type signature, needing a lot of type variables and the unusual way of having a "pseudo-module" (1 concern would have been ok, but this is too much concerns to be ignored IMHO).
	I finally picked https://package.elm-lang.org/packages/timo-weike/generic-collections/latest which fundamentally is the same idea (the "interface" being key -> comparable ) and is way simpler to understand.
	That said @Ed Kelly, even if I wouldn't use it, it's really good stuff! Did you take inspiration from OCaml modules?
	Or we could get a core implementation!
	I'd hope this is not a joke... The number of packages trying to solve this issue kinda show there is an actual need for this
	:heart:
	1


	Ed Kelly 23 minutes ago
	Thanks! I think I must have known about OCaml modules in the back of my mind somewhere, but I've never actually used OCaml. In general I think this "record of functions" pattern is interesting, although I guess it's not a common API in Elm packages. (edited)