[Haskell-beginners] Beginners Digest, Vol 57, Issue 22

[Mateusz Kowalczyk]

On 15/03/13 13:00, Răzvan Rotaru wrote:
> Thanks for the reply.
> 
> 
> On 15 March 2013 13:00, <beginners-request at haskell.org
> <mailto:beginners-request at haskell.org>> wrote:
> 
>     Perhaps
> 
>     data TextfieldProps = TextId | TextLabel | TextValue
>     -- and similarly for ButtonProps?
> 
>     I confess to not fully understanding the GUI modelling attempted here,
>     which isn't to say that you aren't on the right track.
> 
>     To help you and help us help you better, one approach known to be
>     successful is to sketch out the code (better yet, the type
>     signatures!) of
>     what you'd like to write, e.g. how are TextfieldProps and
>     ButtonProps used?
>     What functions act on them?
> 
>     -- Kim-Ee
> 
> 
> I don't have any code to show you, since I just started trying to write
> the types. I'll try to explain what I'm trying to do.
> 
> So, I want model some GUI widgets. This means I should have type for
> each widget (or a type synomym), holding it's data, or state if you
> like. A textfield must have an id, a label and the entered text as
> value. A button must have an id, a label and a function to call when the
> button is clicked.
> 
> As previously said, records are not an acceptable solution because of
> the name clash of properties, and I don't want to prefix each property
> to avoid this. Next best thing is to use a map to hold the properties. I
> could use strings as keys, in which case my map would look like this
> (written as a list of tuples):
> 
> [ ("id", "name_textfield"), ("label", "Name:"), ("value", "Please enter
> name here ...")]
> 
> but then is no checking for the property names (e.g. if I mispelled
> "id", or I used "onclick" for textfields). I want to find a way to use
> the type system to check these properties. My idea was to use new types
> as keys for these maps. I would then have:
> 
> data TextfieldProperties = Id | Label | Value
> type Textfield = Map TextfieldProperties String
> 
> But then I get into the same name clash, because all widgets have Ids,
> most have labels, etc. And here I got stuck.
> 
> Then, how to create widgets? Record syntax would have been fine, but
> since I'm not using records I would have to write some make-...
> functions, which will receive a list of key value pairs and insert them
> into the map to create the widget. Also here I can put the default
> values of properties (for. example if id is not specified, one is
> generated, or use empty strings for unspecified textfield values).
> 
> How to use widgets? Well there will be functions to draw them on the
> screen. I could use a typeclass here.
> Then their properties must be accessed somehow, and this should be also
> polymorphic of course: I want one function to get the id of a widget, no
> matter of what type. Typeclasses can help here as well.
> Then there would be methods to search the GUI tree for certain
> widgets... you know, standard stuff you would want to do with GUI widgets.
> 
> Currently, my blocking point is how to define the types. And I don't
> want to flatten it all out, and use (Map String String) for any widget.
> I'm missing out on the type system if I do this.
> 
> Cheers,
> Răzvan
> 
> 
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
> 
How about a Widget typeclass that provides the ‘identifier’ function and
all the other ones that all the widgets will have in common?

You could then do something like
> class (Widget a) => LabelWidget a where
>   getLabel :: a -> String
for all widgets that need to have the label functions defined for them.
Granted, that's a lot of instances for a lot of GUI elements but that's
what you get for developing such a large package.

-- 
Mateusz K.