- Haskell-Cafe - Haskell.org

global variable
by Jose Morais 12 Oct '03

12 Oct '03

Hello, I need a function called, say, newItem, that when first called returns 1, the next time it is called it would return 2, then 3 and so on. How can I achieve this? Thank you

3 2

tuple sections?
by John Meacham 10 Oct '03

10 Oct '03

I vaugly remember using tuple sections at some point, but perhaps I was dreaming because they don't seem to actually exist. I mean something like (,3) meaning \x -> (x,3) (4,,,3) meaning \x y -> (4,x,y,3) were these supported at one point? if they don't exist, is there some reason why not? they seem like an obvious generalization of sections for binary operators like inc = (1 +) John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 1

RE: Using existential types
by Tim Docker 10 Oct '03

10 Oct '03

Thanks for the comments. I think your solution misses one point in my original example... I wrote: > data ColDesc rowv = forall a. > ColDesc (rowv -> a) ([a] -> a) (a -> String) > > calculate :: [rowv] -> ColDesc rowv -> ([String],String) > calculate rs (ColDesc valf sumf fmtf) = > let vals = map valf rs in > (map fmtf vals, (fmtf.sumf) vals) This code only does the (rowv -> a) evaluation once, whereas olegs version: > calculate :: [rowv] -> ColDesc rowv -> ([String],String) > calculate rs (ColDesc fmtf sumf) = (map fmtf rs, sumf rs) does the evaluation (rowv -> a) for each element twice, I think. In a real system, as opposed to my toy example, this computation is expensive, and I don't want to do it more that necessary. Tim

2 1

compiling GHC with MS .Net 2003
by Andreas.Schroeder＠gillardon.de 10 Oct '03

10 Oct '03

Hi all, is it possible to compile ghc with the MS .Net 2003 c compiler? I assume some problems, since the compiling of ghc uses autoconf/configure/make Any idea IF it is possible? Regards, Andreas Schroeder

1 0

AW: Using existential types
by Markus.Schnell＠infineon.com 10 Oct '03

10 Oct '03

Hi Graham, > Instead, I replace the class instances by a single algebraic > data type, > whose members are functions corresponding to OO-style class methods. could you give an example? Thanks, Markus

1 0

Re: constructor name clashes
by Brandon Michael Moore 08 Oct '03

08 Oct '03

On Wed, 8 Oct 2003 Ben_Yu(a)asc.aon.com wrote: > Hi, all. > > I'm a newbie to Haskell so please bear with me if my questions sound silly. > > In coding Haskell, I feel very inconvenient that the name of data > constructors for different types have to be different. > > Also, when declaring named fields of a type, such as > data Data1 = Data1{ok1::Bool} > data Data2 = Data2{ok2::Bool} > the field names for different type also have to be unique. > > Isn't that annoying? Keeping all the names unique is no easy task in my > opinion. Wouldn't it be nice if we can have something similar to structure > fields in C? Or maybe this is already present and I'm just being ignorant? There has been a lot of work on a real record system, but none has made it into GHC. HUGS has TREX, which is based on row variable polymorphism and seems fairly powerful. O'Haskell does something based on subtyping IIRC. The big problem is being expressing functions that add or remove fields from a record. If you are just interested in fetching or setting fields you can use type classes: data A = A Int String --A {foo::Int, bar::String} data B = B Bool --B {foo::Bool} class HasFooField t a | t -> a where foo :: t -> a updateFoo :: t -> a -> t instance HasFooField A Int where foo (A f _) = f updateFoo (A _ b) v = A v b instance HasFooField B Bool where foo (B b) = b updateFoo (B _) v = B v You could probably do something with template haskell that would generate all the instances for you, but you would still need to import the classes from somewhere. $(struct [d[data A = A1 {foo::Int, bar::String} | A2 {foo::Int} ]]) $(struct [d[data B = B {foo::Bool} ]]) There was talk about compiler support for a system like this, and I think the main obstacle is convincing somebody to do it, which mostly means demonstrating that it's useful, because there's no interesting theory here. It also makes code a bit slower, but fields are not that common so it shouldn't be much of an issue. Do we really lose that much to the name overloading restrictions? The only use I can think of for records used as big bags of tagged values is for passing configuration options to complicated libaries, or getting back a bunch of values from something like parsec's token parser generator. This isn't very common, because usually any powerful function in Haskell is build from a layer of smaller functions that made the final function ridiculously easy to write. If this is true for some library, the author can either write gobs of boring option handling code that tries to expose some fraction of this power, or just extend their export list a bit and give the user the primitives to play with themselves. I don't think constructor name clashes come up that often either. There are a few names like Leaf or Empty that you want to use all the time if you are defining trees and things, but that's more playing around with trivial data structures than writing real code. Two cases I've run into are successive program representations in a compiler (everything from raw tokens though Core has an "if"), and using having an exploded representation of a type as the fixpoint of a functior for interesting recursion scheme uses, and a normal version so I can avoid the tagging. It would probably be feasible to figure out which constructor you mean in a function like desugar :: ASTSyntax -> M IntermediateSyntax desugar (IF c t e) = If (f c) (f t) (f e) desugar (ListComprehension head gens) = desugarListComp head gens ... ... But other cases are much harder (and probably much less sensible). How do you infer a type for something like this? f (C x) = case x of (C x) -> case x of (C x) -> case x (C x) -> x I think the typing rules would have to be based on something other than unification and generalization like the rest of the type system, and would probably introduce all sorts of annoying restrictions about how you are allowed to use constructors, or how to resolve the type. Brandon > I know that we can use modules to introduce name spaces. But still, this is > quite cumbersome. > > Thanks! > > Ben. > > > > This message is intended only for the addressee and may contain information > that is confidential or privileged. Unauthorized use is strictly prohibited > and may be unlawful. If you are not the intended recipient, or the person > responsible for delivering to the intended recipient, you should not read, > copy, disclose or otherwise use this message, except for the purpose of > delivery to the addressee. If you have received this email in error, please > delete and advise us immediately. > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > >

1 0

RE: Using existential types
by Tim Docker 08 Oct '03

08 Oct '03

Whilst on existential types, perhaps someone can tell me if this is a valid use: I wish to define a flexible report, consisting of a set of columns. The contents of each column can be defined by mapping a function to a row descriptor, generating a value, and then converting each value to a string. I also wish to present an aggregate value at the bottom of the column defined by another function. It seems that exisistential types are required to get this sort of thing to work. Is there another way? Tim -------------------- data ColDesc rowv = forall a. ColDesc (rowv -> a) ([a] -> a) (a -> String) calculate :: [rowv] -> ColDesc rowv -> ([String],String) calculate rs (ColDesc valf sumf fmtf) = let vals = map valf rs in (map fmtf vals, (fmtf.sumf) vals) rows = ["I","wish","to","define","a","report"] cols = [ ColDesc id (\_ -> "") id, ColDesc length sum show, ColDesc (\s -> length s * length s) maximum show ] values = [ calculate rows col | col <- cols ]

1 0

Using existential types
by Graham Klyne 08 Oct '03

08 Oct '03

I've been trying to use existential types [*] in my code. [*] cf. Glasgow Haskell Compiler (GHC) user guide, section 7.3.12 My experiments have thrown up a couple of questions: 1. forall x introduces x as existential when it appears immediately preceding a datatype constructor declaration, e.g. at -1- below. In position -2-, it appears to signal a universal quantifier. Is this a correct reading of the situation? 2. I have been trying to use existential types to allow an auxiliary type to appear in the implementation of a datatype, and have ended up using one datatype to "wrap" another. Is there a cleaner way? The code below has been adapted from my development code to provide a stand-alone example of the kind of thing I'm trying to do. It runs OK under Hugs. #g -- -- spike-existential.hs -- -- experimenting with existential types -- -- Questions: -- -- 1. forall x introduces x as existential when it appears immediately -- preceding a datatype constructor declaration, e.g. at -1- below. -- In position -2-, it appears to be a universal quantifier. -- ? -- -- 2. Is there cleaner way to hide the datatype vt in the declaration -- of DatatypeVal below, on the basis that I don't really want it to -- be visible outside the inference rules that are specific to this -- datatype, referenced by typeRules If I apply the existential at -- position -1-, an error is reported by Hugs: -- "cannot use selectors with existentially typed components". -- -- The approach I have adopted is to define two datatypes, -- DatatypeVal which is parameterized by expression type and value -- type, and Datatype which wraps a DatatypeVal with the value -- type being an existential. I've yet to work out implementation -- details for the stuff that uses the value type, but I anticipate -- using a constructor function that takes the DatatypeMap value -- as an argument. -- data Expr = Expr String -- Dummy expression type for spike deriving Eq data Ruleset ex = Ruleset ex String -- Dummy ruleset type for spike deriving Eq -- Type Datatype wraps DatatypeVal with an existential, thus -- hiding the value type. Also define access methods for those -- components that don't reference the value type. data Datatype ex = forall vt . Datatype (DatatypeVal ex vt) typeName (Datatype dtv) = tvalName dtv typeSuper (Datatype dtv) = tvalSuper dtv typeRules (Datatype dtv) = tvalRules dtv -- Type DatatypeVal uses a value type (vt) in its implementation. -- See tvalMap; the intent is that an implemenatation of tvalRules, -- and other code may make use of this component. data DatatypeVal ex vt = DatatypeVal {-1- data DatatypeVal ex = forall vt . Datatype -1-} { tvalName :: String , tvalSuper :: [Datatype ex] -- ^ List of datatypes that are each a supertype -- of the current datatype. The value space -- of the current datatype is a subset of the -- value space of each of these datatypes. -- NOTE: these supertypes may be implemented -- using a different value type; e.g. a -- supertype of xsd:integer is xsd:decimal , tvalMap :: {-2- forall vt. -2-} DatatypeMap vt -- ^ Lexical to value mapping, where 'vt' is -- a datatype used within a Haskell program -- to represent and manipulate values in -- the datatype's value space , tvalRules :: Ruleset ex -- ^ A set of named expressions and rules -- that are valid in in any theory that -- recognizes the current datatype. } data DatatypeMap vt = DatatypeMap { mapL2V :: String -> Maybe vt -- ^ Function to map lexical string to -- datatype value. This effectively -- defines the lexical space of the -- datatype to be all strings for which -- yield a value other than Nothing. , mapV2L :: vt -> Maybe String -- ^ Function to map a value to its canonical -- lexical form, if it has such. } datatypevalXsdInteger :: DatatypeVal Expr Integer datatypevalXsdInteger = DatatypeVal { tvalName = "http://www.w3.org/2001/XMLSchema#integer" , tvalSuper = [datatypeXsdInteger] , tvalMap = mapXsdInteger , tvalRules = rulesetXsdInteger } datatypeXsdInteger :: Datatype Expr datatypeXsdInteger = Datatype datatypevalXsdInteger -- |mapXsdInteger contains functions that perform lexical-to-value -- and value-to-canonical-lexical mappings for xsd:integer values -- mapXsdInteger :: DatatypeMap Integer mapXsdInteger = DatatypeMap { -- mapL2V :: String -> Maybe Integer mapL2V = \ s -> case [ x | (x,t) <- reads s, ("","") <- lex t ] of [] -> Nothing is -> Just $ head is -- mapV2L :: Integer -> Maybe String , mapV2L = Just . show } rulesetXsdInteger = Ruleset (Expr "expr") "rules" -- Checkout test1 = typeName datatypeXsdInteger == "http://www.w3.org/2001/XMLSchema#integer" test2 = typeName (head $ typeSuper datatypeXsdInteger) == typeName datatypeXsdInteger test3 = typeRules datatypeXsdInteger == rulesetXsdInteger ------------ Graham Klyne GK(a)NineByNine.org

6 9

Lazy IO and 'safe' uses of 'unsafePerformIO'
by Matthias Mann 08 Oct '03

08 Oct '03

Recently, there has been some discussion on this list about ongoing research on the role of unsafePerformIO, lazy IO and evaluation strategies. Within our research group at JWG-University Frankfurt some work has been done concerning the development of a non-deterministic call-by-need lambda calculus FUNDIO as a semantic basis for HasFuse, a modified implementation of the Glasgow Haskell Compiler which compiles Haskell programs using 'unsafePerformIO' in a 'safe' way, i.e. deploys only those optimizations that have been proven correct w.r.t. FUNDIO. In this context, experience with GHC's implementation has shown up that if compiled with ghc -O0 -fno-do-lambda-eta-expansion while avoiding INLINE-pragmas, 'most' uses of unsafePerfomIO are 'safe' in the sense of FUNDIO's contextual equivalence. For further details, downloads of papers and sources, please refer to the project WWW page http://www.ki.informatik.uni-frankfurt.de/research/diamond The results of FUNDIO show how evaluation may be interleaved with direct-call IO. In particular not only (\xs -> let z = length xs in "Hello World\n") _|_ = "Hello World\n" is a valid equation in FUNDIO, but also for an arbitrary expression t which may involve direct-call IO the equation (\xs -> let z = length xs in "Hello World\n") t = "Hello World\n" holds. Furthermore, the investigations indicate that some kind of optimistic evaluation is possible, i.e. the expression t above could be evaluated as long as no IO in t is executed. Hence, a demand-driven style for IO could be achieved. Matthias Mann JWG-University Frankfurt

1 0

odd interactions (was: IO behaves oddly if used nested)
by C.Reinke 07 Oct '03

07 Oct '03

[moved to haskell-cafe] > The odd is in the conceptual explanation. If I give a description > of some f x = y function in Haskell I expect that some program f x > is reduced to y and the result is given back (possibly printed). A > good story to sell to students. > > This is almost everywhere the case except for the IO monad. indeed. Although, for the benefit of your students, you'll want to separate printing and reduction, even in the first case. The important thing to realise here (and to pass on to your students) is that input/output-interactions and functional program reductions are two conceptually very different things, and that this difference is independent of which of the many functional I/O systems you use. So you can not use the functional reduction explanation for I/O as well. Once upon a long ago, I had to add IO to a purely functional reduction system as part of my PhD work, and to clarify things for myself, I tried to express the various available functional I/O systems in the common framework of transformation rules (program reduces to program, state transforms into state). The difference then simply became one of context-free versus context-sensitive transformations. [summarised in chapter 3 of my old thesis http://www.cs.kent.ac.uk/people/staff/cr3/publications/phd.html perhaps you can find some useful suggestions there?] The differences between character streams, request/response streams, result continuations, monadic I/O, or even uniqueness-typed environment passing are merely differences in how the context-free functional program reductions are embedded in a context-sensitive environment of I/O devices. They each have their pros&cons (the chapter tries to outline a logical development between the systems), and they all try to embed functional reductions into their I/O context in such a way that doing I/O does not look too foreign. So, each of the functional I/O systems lets you play down the difference between context-sensitive input/output and functional reductions to some extent, but in each of the systems, you quickly run into trouble if you try to take the similarities too far. > 3* Hmm, feels like math, looks like math, ahah! is math! > (designers and thinkers) Making the distinction between context-free and context-sensitive transformations explicit should help your group 3, as it gives them an operational semantics view of what their programs mean, and what they are supposed to do. > from what they expect. The usual questions of group 3: > > * Why is an IO a evaluated if I am not interested in it's result? > (opposite to the f x = y lazy behavior) main is evaluated because you asked the system to run its value (the whole IO a, not the a-typed result returned by running it). > * Why is in the putStr "hello world" example Hello World not shown? > (opposite to expected f x = y eval-first-then-show behavior) implementation deficiency. a more complete implementation might permit you to show intermediate steps in the program+device state transformation: program || device context =============================================== putStr ("hello "++"world") || <nothing here> -context-free reductions-->* putStr "hello world" || <nothing here> -context-sensitive interaction--> return () || "hello world" Just before the interaction, "hello world" is part of the program, so a step-by-step implementation might show it (you couldn't show it without implementation help, as the IO type is abstract), but after the interaction, the string has moved from the program to the device context in which it the program is running. The string appears on some output device, the implementation could show you return () as the final value of your program (the reduction system I was working with did so). > * Why is in the IO (IO ()) example the inner IO () not evaluated? (somewhat > opposite to expected f (f x) behavior - I personally wonder if it is even > sound in a category theoretical setting) urgh,please.. categories do not need a theory about everything [ducks quickly;] first: in an expression of type IO (IO ()), there is not necessarily an inner IO (). Evaluating the expression, and running the result, will fail or return an IO (), but that might not even exist beforehand (that's just the good old no String in IO String). second: the inner IO () returned by running the outer IO (IO ()) is not evaluated unless needed, and it won't be needed unless run. To run any IO a-typed expression, the current monadic I/O system requires it to be placed at the boundary between your functional program and the I/O context it is running in, i.e., it has to be part of the sequence of IO-operations that make up the value of main. Until it gets run this way, it's just an expression that could evaluate to an IO-script that could be run. > * ...Lots of other questions... better than individual answers is a simple conceptual model that allows the students to answer such questions (and any others they might run into). > Hmm, have to finish this email now - time constraints. I guess the short > story just is: IO monads == sometimes bad conceptual story to sell. no. and especially not to that group of students. but for this group, you can't brush the difficulties under the carpet, as you can with the other groups (and Haskell's I/O system and sugar were designed to be easy on the first two groups). you have to give them something more to wrap their minds around. > A nice (old) idea would be to represent IO as programs which are > interpreted by some _outside_ RTS in a given manner, and leave the > Haskell language clean. That is a valid operational semantics, if you get the interleaving right. That it isn't the most efficient implementation shouldn't matter in a functional programming introduction. > (It might even be a good idea with respect to the compiler > implementation since it removes checking against unsafe IO > behavior from the compiler -- just a thought) Simpler implementation is often not more efficient implementation. Hth, Claus

2 1