I think it does not necessarily involve any extensions to the language, it could be only syntactic sugar. You may want the programmer to explicitly opt in with a syntax like:
enum type _NAME_ = _OPT_1_ | _OPT_2_ .... | _OPT_N_ , enumerator = _ENUMERATOR_NAME_ which would desugarize to: enum type _NAME_ = _OPT_1_ | _OPT_2_ .... | _OPT_N_ _ENUMARTOR_NAME_: List _NAME_ _ENUMARTOR_NAME_ = [ _OPT_1_ , _OPT_2 .... , _OPT_N_ ] Note that the above is purely string manipulations... The enum prefix will enforce that the options cannot have additional arguments (or that all have the same arguments)... But maybe that's against Elm's philosophy of not introducing language features that are not used widely (and I have to admit that the enum usage will not likely be very frequent while maintaining a list of values manually is annoying but usually not very time-consuming) I had fun thinking about the possibilities, so I consider this a time well spent even if the idea is forgotten, hope everybody else does not mind ;-) Martin On Wednesday, 26 October 2016 18:47:25 UTC+2, OvermindDL1 wrote: > > That sounds like a typeclass or a HPT, neither of which are in Elm (yet?). > Passing in manual serialization/deserialization functions is easy to do > though. :-) > > On Wednesday, October 26, 2016 at 10:32:18 AM UTC-6, Martin Cerny wrote: >> >> I think this points to a more general use case. I think it would be >> useful to be able to use union types a bit like enums in other languages >> (my background is mostly Java). For example having >> >> type Role = Admin | Moderator | User >> >> it would be cool to get something like: >> >> Role.optionNames == ["Admin", "Moderator", "User"] >> Role.allOptions == [ Admin, Moderator, User ] >> >> Now the 'allOptions' probably could work only when all type constructors >> have the exact same parameters, but I think that use case is not infrequent >> and having to define list of possible options manually is error-prone... >> >> The use case is not only for selects. You may for example need to show >> counts of various types of objects displayed, where the type is given by an >> enum, so iterating through the enum values makes sense. >> >> Just my $0.02. >> >> Martin >> >> On Wednesday, 26 October 2016 02:27:38 UTC+2, Ian Mackenzie wrote: >>> >>> I've been slowly working on a small library >>> <https://github.com/kintail/input-widget> to make working with the >>> basic input widgets like <select> more pleasant to work with - I'd be >>> interested to see what you think. The implementation >>> <https://github.com/kintail/input-widget/blob/master/src/Kintail/InputWidget.elm#L48> >>> handles >>> the mapping between selected index and strongly-typed values; check out >>> examples/ComboBox.elm >>> <https://github.com/kintail/input-widget/blob/master/examples/ComboBox.elm> >>> to >>> see a simple usage example. >>> >>> On Tuesday, 25 October 2016 23:45:26 UTC+11, James Hamilton wrote: >>>> >>>> Hello! >>>> >>>> I suppose this really only applies to instances of <option>, but there >>>> may be other examples. >>>> >>>> When using <option> with <select>, it's necessary to set a value on the >>>> <option> using <value> which accepts a String. However, I usually actually >>>> want to refer to a Type which I have to represent as a String and marshal >>>> it back to its correct type when updating the model. >>>> >>>> Is there a way of doing this using a type, and if not could it be done? >>>> I think it's a reasonable thing to expect to be able to do with an >>>> <option>, but then again I'm pretty new to this so please tell me if I'm >>>> asking for something complicated! >>>> >>>> -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
