- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] introspection | meta data
by Crypt Master 05 Aug '04

05 Aug '04

>Can you name these fields? If so, haskell has (sorta clumsy) named >records, >and you can select and update fields by name, and you can replace >'setSFField 3 sf x' with 'sf {somefield=x}' I did think of this, but unfortunatly my algorithm cant use names (without hard coding all possible combinations ) > > So what is the general haskell approach to this type of >introspection/meta > > data problem... ? >A C array of pointers maps closest to a MutableArray, which is mostly a >list >with different performance. Unless you're casting pointers, in which case >Dynamic types or the Generic stuff is maybe what you want. Or a redesign >;) I looked at haskell arrays, but since I cant point to an element in my tuple it wont work out. The ANSI C use of arrays is a really simple (but nasty) way to provide a means for me to loop over a fixed struct record. The Generic library looks super, only had time to browse some slides thus far, but will defiantly try understand that. As for a redesign and >Others have given good answers for this, but I suspect you may have chosen >the >wrong data structure... I would be keen on any ideas you have on how to design this in haskell. Learning to think in haskell is after all the goal :-) The example below is trivial and real world, both reasons why I chose to use it. Any comments welcome, none expected :-) Thanks, -- I idea is to perform a search over a number fields in a hierachical fashion where each field can have a wild card. The real world example is printer selection. In a multi-national company all users tend to be on one (or a few) central servers, but require there printouts to come to them locally whereever they are. Users typically range in 1000s and so "by user" defintions are out. Simplified Search fields: Environemnt, Users, Report, Version, Host Printer ---------------------------------------------------------- ---------- The "most" speicific field is host on the right with it becomming more general moving to towards the left. Setup data could choose to override all of report "RPT1" version "Ver1" to Printer "Bobs Printer" *ALL, *ALL, "RPT1", "Ver1", "*ALL", "Bobs Printer" but Simon may be an exception, then a record could be added like so: *ALL, "SIMON", "RPT1", "Ver1", *ALL, "Simons Printer" This record would be found first for simon, but former found found for everyone else. A search starts from fully specific data i.e no wild cards. The basic algortihm I worked out is: 1. Search setup data 2. If no record found 2a: Set current field to most specific field (host in this case) 2b: Toggle current field ( if Wildcard then make it value, if value make it wildcard ) 2c: if current field is *ALL goto 1 above (we stop here to perform a search on the current permutation) 2d: Loop to 2b until no more fields And my haskell working proto type is this: module Main where -- Env User Report Version Host Printer egdata1 = [(("PD7334EU", "*ALL", "*ALL", "*ALL", "*ALL"), "Default Printer"), (("PD7334EU", "USER1", "*ALL", "*ALL", "*ALL"), "User1Printer"), (("PD7334EU", "USER2", "Report1", "Version1", "*ALL"), "User1Report1Printer"), (("PD7334EU", "*ALL", "Report2", "*ALL", "*ALL"), "Report2Printer")] type SearchFilter = (String, String, String, String, String) type Record = (SearchFilter, String) findPrinter :: String -> String -> String -> String -> String -> [Record] -> String findPrinter env user report version host printerdata = findPrinter' sf sf printerdata where sf = (env, user, report, version, host) findPrinter' :: SearchFilter -> SearchFilter -> [Record] -> String findPrinter' ("*ALL", "*ALL", "*ALL", "*ALL", "*ALL") _ _ = "" findPrinter' sf origsf printerdata | printer == "" = findPrinter' (toggle sf origsf 5) origsf printerdata | otherwise = printer where printer = searchPrinter sf printerdata searchPrinter :: SearchFilter -> [Record] -> String searchPrinter _ [] = "" searchPrinter sf ((x,p):xa) | sf == x = p | otherwise = searchPrinter sf xa toggle :: SearchFilter -> SearchFilter -> Int -> SearchFilter toggle sf origsf 0 = sf toggle sf origsf n | newValue == "*ALL" = newSF | otherwise = toggle newSF origsf (n-1) where newValue = toggleField (getSFField n sf) (getSFField n origsf) newSF = setSFField n sf newValue toggleField :: String -> String -> String toggleField "*ALL" x = x toggleField _ _ = "*ALL" getSFField :: Int -> SearchFilter -> String getSFField 1 (x,_,_,_,_) = x getSFField 2 (_,x,_,_,_) = x getSFField 3 (_,_,x,_,_) = x getSFField 4 (_,_,_,x,_) = x getSFField 5 (_,_,_,_,x) = x setSFField :: Int -> SearchFilter -> String -> SearchFilter setSFField 1 (a,b,c,d,e) f = (f,b,c,d,e) setSFField 2 (a,b,c,d,e) f = (a,f,c,d,e) setSFField 3 (a,b,c,d,e) f = (a,b,f,d,e) setSFField 4 (a,b,c,d,e) f = (a,b,c,f,e) setSFField 5 (a,b,c,d,e) f = (a,b,c,d,f) main = putStrLn (findPrinter "PD7334EU" "USER2" "Report2" "Version3" "SomeHost" egdata1) _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

introspection | meta data
by Crypt Master 05 Aug '04

05 Aug '04

Hi I recently had to implement an algorthm in C, and found the time to give it a go in Haskell to aid in learning haskell. I found myself "needing" runtime meta information on data types (well tuples which are data (a,b) = (a,b)). Does haskell allow this ? Basically I need to loop over the fields in my record. I came up with functions like this: -- Toggle fields to/from generic value toggle sf origsf 0 = sf toggle sf origsf n | newValue == "*ALL" = newSF | otherwise = toggle newSF origsf (n-1) -- <--------- Loop through fields by No where newValue = toggleField (getSFField n sf) (getSFField n origsf) -- <---- accessor functions newSF = setSFField n sf newValue .... getSFField :: Int -> SearchFilter -> String getSFField 1 (x,_,_,_,_) = x getSFField 2 (_,x,_,_,_) = x .... setSFField :: Int -> SearchFilter -> String -> SearchFilter setSFField 1 (a,b,c,d,e) f = (f,b,c,d,e) setSFField 2 (a,b,c,d,e) f = (a,f,c,d,e) .... The only problem with this is that if I want to add or remove a field, I need to change a lot of code. In most OO lanaguages I could use "reflection" to loop through my fields. In C (which also doesnt have meta data) I got round it by using pointers in an array. To add or remove a field just requires adding or removing a pointer to my array which is one line of code. The only thought I had was of using lists, but the this would mean I loose pattern matching against all values at once which is appealing for calrify of code. So what is the general haskell approach to this type of introspection/meta data problem... ? Thanks, _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

Re: [Haskell-cafe] introspection | meta data
by MR K P SCHUPKE 05 Aug '04

05 Aug '04

>Introspection in Haskell is provided by the Data.Generics module. The difference between the Data.Typeable and HList approach is that Generics use run-time information to make choises, HLists use the type system to make static guarantes. You can actually combine the two quite nicely and end up with statically constrained dynamics (or Stanamics as Ralf calls them) ... That is a dynamic opaque container constrained to contain only a certain group of types statically! Keean.

1 0

Re: [Haskell-cafe] introspection | meta data
by Jon Cast 05 Aug '04

05 Aug '04

Crypt Master <cryptmaster(a)hotmail.com> wrote: > I recently had to implement an algorthm in C, and found the time to > give it a go in Haskell to aid in learning haskell. > > I found myself "needing" runtime meta information on data types (well > tuples which are data (a,b) = (a,b)). Does haskell allow this ? <snip absolutely normal example> > So what is the general haskell approach to this type of > introspection/meta data problem... ? Introspection in Haskell is provided by the Data.Generics module. Try `deriving Data' and go wild (everybody else has). Jon Cast

1 0

Re: [Haskell-cafe] introspection | meta data
by MR K P SCHUPKE 05 Aug '04

05 Aug '04

>In most OO lanaguages I could use "reflection" to loop through my fields. You could try a heterogeneous list, see: http://homepages.cwi.nl/~ralf/HList/ Keean/ ,.

1 0

Re: [Haskell-cafe] Re: humor
by Jon Cast 05 Aug '04

05 Aug '04

Sean Perry <sean.perry(a)intransa.com> wrote: > Jon Cast wrote: > > > > Obviously you haven't realized the great beauty of $. You cannot like $ > > to much. foldr should be defined as follows: > > > > foldr f z [] = id $ z > > foldr f z (x:xn) = (f $ x) $ foldr f z xn > > > > etc. :) > > Am I to assume there is some sarcasm here? Hope so (-: > > (Sorry, still new to the list, learning the idioms and mannerisms) Yes. Much sarcasm (which I considered appropriate given the official subject). And one :) Jon Cast

1 0

Re: [Haskell-cafe] Re: exceptions vs. Either
by MR K P SCHUPKE 05 Aug '04

05 Aug '04

>specify that a sort function (say) returns an ordered list Fistly this is already possible in Haskell - see Oleg, Ralf and My paper: @misc{KLS04, author = "Oleg Kiselyov and Ralf L{\"a}mmel and Keean Schupke", title = "{Strongly typed heterogeneous collections}", booktitle = "{ACM SIGPLAN Workshop on Haskell}", year = 2004, month = sep, publisher = "ACM Press", notes = "To appear" } http://homepages.cwi.nl/~ralf/HList/ Here we show constrained heterogeneous lists (but you can also constrain the type in the list to turn it into a homogeneous list) that includes the ability to impose ordering constraints... Writing the constraint classes is a little involved but using it is as simple as: sort :: (HList l,HOrderedList l') => l -> l' and supposing you dont like having to write the complete type, you can use: ordered :: HOrderedList l => l -> l ordered = id then you can use this in a function with no type given: sort = ordered . sort' So my point is this can be added to haskell _without_ breaking any existing functionality - it is not either/or it is both/and! Keean.

1 0

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 05 Aug '04

05 Aug '04

>f (case xs of (x:_) -> x; [] -> error "whoops") -- direct style Yup, this is how I do it... I never use head! I like to pass failures back up to the level where some kind of sensible error message can be generated. In your example the error is no better than with 'head' - the point is a Nothing can be 'caught' outside of an IO monad. I would suggest using the type system as I said earlier so: toNonEmptyList :: [a] -> Maybe (NonEmpty a) toNonEmptyList (a0:_) = Just (NonEmpty a) toNonEmptyList _ = Nothing Then redefine head: head :: NonEmpty a -> a head (NonEmpty (a0:_)) = a0 Keean/

3 2

exceptions vs. Either
by Evan LaForge 04 Aug '04

04 Aug '04

Exceptions are convenient in that you can rely on libraries throwing them instead of prechecking for valid values yourself (for instance, why check that the argument to Char.digitToInt is valid if digitToInt does so already), and you don't have to modify a lot of function signatures. Unfortunately, in the face of lazy evaluation, they can get thrown in unexpected places. Even with Exception.evaluate, or code which is already explicitly sequenced in the IO monad, like "t <- Exception.evaluate (map Char.digitToInt ['a'..'g'])" an exception will only be thrown when you inspect the last element of 't'. (digitToInt confusingly accepts hex "digits"---shouldn't it be "higitToInt" then?). So it seems to me that if you are, say, checking input, the options are to handle exceptions from the checking code but expect them to come from the processing code, or decorate all checking code with Rights and Lefts. Problems with the first option are that checking code could also trigger some exceptions, and Prelude functions throw undescriptive errors like "user error" or low level ones like "refuted pattern match" and catching them over the entire program means you could stifle a lot of real errors. This implies that you have to make specific exceptions and convert Prelude and library exceptions into yours as low down as possible, which is cluttering but maybe not as cluttering as Either. Problems with the second option are many of the problems that lead to us wanting exceptions in the first place. Using Either seems much simpler and functional-friendly. So then, in what contexts are exceptions appropriate in haskell?

9 12

Re: [Haskell-cafe] exceptions vs. Either
by MR K P SCHUPKE 04 Aug '04

04 Aug '04

>No, I don't think so. I only want the bug to be reported I think preventing the bug using the type system if possible is a good idea... something that should be encouraged! >and not a "corner case" that should be "handled". So if the list depends on user input is not the empty list a corner case of the function on user input? >write small leaf functions like these with an implicit file/line This is a good idea - If I have given the impression I am opposed to it then I have not expressed myself very well. I just think where this can be avoided using the type system in the first place is an even better idea. Design by contract is the way forward for large complex systems, and where that contract can be expressed using the type system is a selling point for Haskell in such applications. >It seems difficult to generalize this, though. Again for read you can use "reads"... Sven Panne said: "reads" is probably what you are looking for: Prelude> (reads :: ReadS Integer) "" [] Prelude> (reads :: ReadS Integer) "a" [] Prelude> (reads :: ReadS Integer) "2" [(2,"")] Prelude> (reads :: ReadS Integer) "123blah" [(123,"blah")] Keean.

1 0