Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Beginners Digest, Vol 57, Issue 22 (R?zvan Rotaru)
2. Re: Beginners Digest, Vol 57, Issue 22 (Mateusz Kowalczyk)
3. Beginners Code - Comments on Style (Heinrich Ody)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Mar 2013 15:00:44 +0200
From: R?zvan Rotaru <[email protected]>
Subject: Re: [Haskell-beginners] Beginners Digest, Vol 57, Issue 22
To: [email protected]
Message-ID:
<cap33cnb_okkabr0rog1-o3ygho5murkk2ga6xuyfst1icf5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the reply.
On 15 March 2013 13:00, <[email protected]> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130315/4c5da489/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 15 Mar 2013 14:00:16 +0000
From: Mateusz Kowalczyk <[email protected]>
Subject: Re: [Haskell-beginners] Beginners Digest, Vol 57, Issue 22
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 15/03/13 13:00, R?zvan Rotaru wrote:
> Thanks for the reply.
>
>
> On 15 March 2013 13:00, <[email protected]
> <mailto:[email protected]>> 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
> [email protected]
> 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.
------------------------------
Message: 3
Date: Sat, 16 Mar 2013 11:25:18 +0100
From: Heinrich Ody <[email protected]>
Subject: [Haskell-beginners] Beginners Code - Comments on Style
To: [email protected]
Message-ID:
<camc+g-nwwzugnoxxj6xwmbvti+bct+rttutcyptuw1vhfm6...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I'm trying to learn Haskell by writing a library for automata functions. So
far I finished some functions that I use to calculate the union and
intersection of 2 automata for the case of finite words.
I wonder if somebody is willing to give comments on the code? For example
how I could write a function to be nicer, better to understand etc.
Please note that I don't know monads yet.
Thanks for your time! Below is my code (I left out some functions to make
it shorter)
Greetings,
Heinrich
------------------ Code
import Text.Show.Functions
import qualified Data.List as List
import Data.Maybe
import Prelude hiding (init)
-- b is the type for the alphabet.
-- Meaning of the parameters are (States, Alphabet, InitStates,
Trans.Function, FinalStates)
data NFA l = NFA [State] [l] [State] [(State, l, State)] [State]
instance Show l => Show (NFA l) where
show (NFA states alphabet init delta final) =
"States: " ++ show states ++ "\n" ++
"Alphabet: " ++ show alphabet ++ "\n" ++
"Init: " ++ show init ++ "\n" ++
"Delta: " ++ show delta ++ "\n" ++
"Final: " ++ show final
data State = I Integer
| S [State]
deriving Eq
instance Show State where
show (I i) = show i
show (S xs) = show xs
-- Advance all states in the set by one step, for the given input letter
setTransition :: Eq l => [(State, l, State)] -> [State] -> l -> [State]
setTransition delta xs l = [s' | (s, l', s') <- delta, s `List.elem` xs, l'
== l]
-- naivly test whether a given word is accepted
-- for this we forward propagate the current state sets on our input word
-- we assume the automaton is complete
isAccepted :: Eq l => NFA l -> [l] -> Maybe Bool
isAccepted (NFA states alphabet init delta final) word
= if (List.nub word) `subset` alphabet
then let f xs sigma = setTransition delta xs sigma
in Just (((/= []) . (List.intersect final) . (List.foldl f
init)) word)
else Nothing
-- makes an automaton complete s.t. for each pair in (States x Alphabet) a
the transition function returns a state.
-- For this a sink state is added to States which is the result of all
previously unassigned pairs in (States x Alphabet).
-- This function keeps DFA deterministc. It adds the sinkstate, but it will
be unreachable.
makeComplete :: Eq l => NFA l -> NFA l
makeComplete (NFA states alphabet init delta final) =
NFA (e:states) alphabet init (unassigned `List.union` delta) final
where
-- e is a new state, whose integer value does not occur in
states
e = I ((minState states) -1)
r = ([e] `List.union` states) `times` alphabet
unassigned = [(s,l,e) | (s,l) <- r, (s,l) `List.notElem` (map
proj3' delta)]
-- checks if 1st parameter is (non-strict) subset of 2nd parameter
-- Assumes that there are no duplicates
subset :: Eq l => [l] -> [l] -> Bool
subset xs ys = (xs List.\\ ys) == []
-- comparision of lists where index of elements is ignored
-- Assumes that there are no duplicates
seteq :: Eq l => [l] -> [l] -> Bool
seteq xs ys = (xs List.\\ ys) == (ys List.\\ xs)
-- cartesian product going from states to states
stateTimes :: [State] -> [State] -> [State]
stateTimes xs ys = [ S [x,y] | x <- xs, y <- ys]
-- Normal cartesian product
times :: [a] -> [b] -> [(a,b)]
times xs ys = [(x,y) | x <- xs, y <- ys]
-- Normal cartesian product for three lists
times3 :: [a] -> [b] -> [c] -> [(a,b,c)]
times3 xs ys zs = [(x,y,z) | x <- xs, y <- ys, z <- zs]
-- removes the last element from the tuple
proj3' :: (a,b,c) -> (a,b)
proj3' (x,y,z) = (x,y)
-- adds the 2nd parameter as last element of the input tupple
addToTuple :: (a,b) -> c -> (a,b,c)
addToTuple (x,y) z = (x,y,z)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130316/49abe4bb/attachment-0001.htm>
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 57, Issue 23
*****************************************
