- Haskell - Haskell.org

On computable types. I. Typed lambda and type closures
by oleg＠pobox.com 14 Sep '06

14 Sep '06

This is the first message in a series on arbitrary type/kind-level computations in the present-day Haskell, and on using of so computed types to give signatures to terms and to drive the selection of overloaded functions. We can define the type TD N to be the type of a tree fib(N)-level deep, and instantiate the read function for the tree of that type. The type computations are largely expressed in a functional language not too unlike Haskell itself. In this message we present call-by-value lambda-calculus with booleans, naturals and case-discrimination. The distinct feature of our implementation, besides its simplicity, is the primary role of type application rather than that of abstraction. Yet we trivially represent closures and higher-order functions. We use proper names for function arguments (rather than deBruijn indices), and yet we avoid the need for fresh name generation, name comparison, and alpha-conversion. We have no explicit environment and no need to propagate and search it, and yet we can partially apply functions. Our implementation fundamentally relies on the connection between polymorphism and abstraction, and takes the full advantage of the type-lambda implicitly present in Haskell. The reason for the triviality of our code is the typechecker's already doing most of the work need for an implementation of lambda-calculus. Our code is indeed quite simple: its general part has only three lines: instance E (F x) (F x) instance (E y y', A (F x) y' r) => E ((F x) :< y) r instance (E (x :< y) r', E (r' :< z) r) => E ((x :< y) :< z) r The first line says that abstractions evaluate to themselves, the second line executes the redex, and the third recurses to find it. Still, we may (and did) write partial applications, the fixpoint combinator, Fibonacci function, and S and K combinators. Incidentally, the realization of the S combinator again takes three lines, two of which build the closures (partial applications) and the third line executes the familiar S-rule. instance A (F CombS) f (F (CombS,f)) instance A (F (CombS,f)) g (F (CombS,f,g)) instance E (f :< x :< (g :< x)) r => A (F (CombS,f,g)) x r Incidentally, the present code constitutes what seems to be the shortest proof that the type system of Haskell with the undecidable instances extension is indeed Turing-complete. That extension is needed for the fixpoint combinator -- which is present in the system described in Luca Cardelli's 1988 manuscript: http://lucacardelli.name/Papers/PhaseDistinctions.pdf As he wrote, ``Here we have generalized the language of constant expressions to include typed lambda abstraction, application and recursion (because of the latter we do not require compile-time computations to terminate).'' [p9] This message is all the code, which runs in GHC 6.4.1 (it could well run in Hugs; alas, Hugs does not like infix type constructors like :<). > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-undecidable-instances #-} > > module TypeLC where First we define some constants > data HTrue = HTrue > data HFalse = HFalse > data Zero = Zero > data Su a = Su a Indicator for functions, or applicable things: > data F x and the applicator > class A l a b | l a -> b The meaning of |A l a b| is that the application to |a| of an applicable thing denoted by |l| yields |b|. Surprisingly, this already works. Let us define the boolean Not function > data FNot by case analysis: > instance A (F FNot) HTrue HFalse > instance A (F FNot) HFalse HTrue The next function is the boolean And. It takes two arguments, so we have to handle currying now. > data FAnd Applying And to an argument makes a closure, waiting for the second argument. > instance A (F FAnd) x (F (FAnd,x)) When we receive the second argument, we are in the position to produce the result. Again, we use the case analysis. > instance A (F (FAnd,HTrue)) a a > instance A (F (FAnd,HFalse)) a HFalse Commonly, abstraction is held to be `more fundamental', which is reflected in the popular phrase `Lambda-the-Ultimate'. In our system, application is fundamental. An abstraction is a not-yet-applied application -- which is in itself a first-class value. The class A defines the meaning of a function, and an instance of A becomes the definition of a function (clause). We have dealt with simple expressions and applicative things. We now build sequences of applications, and define the corresponding big step semantics. We introduce the syntax for applications: > data f :< x > infixl 1 :< and the big-step evaluation function: > class E a b | a -> b Constants evaluate to themselves > instance E HTrue HTrue > instance E HFalse HFalse > instance E Zero Zero Abstractions are values and so evaluate to themselves > instance E (F x) (F x) Familiar rules for applications > instance (E y y', A (F x) y' r) => E ((F x) :< y) r > instance (E (x :< y) r', E (r' :< z) r) => E ((x :< y) :< z) r Other particular rules > instance E x x' => E (Su x) (Su x') That is all. The rest of the message are the tests. The first one is the type-level equivalent of the following function: testb x = and (not x) (not (not x)) At the type level, it looks not much differently: > type Testb x = > E (F FAnd :< (F FNot :< x) :< (F FNot :< (F FNot :< x))) r => r > testb1_t = undefined :: Testb HTrue > testb1_f = undefined :: Testb HFalse We introduce the applicative fixpoint combinator > data Rec l > instance E (l :< (F (Rec l)) :< x) r => A (F (Rec l)) x r and define the sum of two numerals > fix f = f (fix f) > vsum = fix (\self n m -> case n of 0 -> m > (n+1) -> 1 + (self n m)) At the type level, this looks as follows > data FSum' -- first define the non-recursive function > instance A (F FSum') self (F (FSum',self)) > instance A (F (FSum',self)) n (F (FSum',self,n)) -- build closures > instance A (F (FSum',self,Zero)) m m > instance E (self :< n :< m) r => A (F (FSum',self,(Su n))) m (Su r) > type FSum = Rec (F FSum') -- now we tie up the knot After we define a few sample numerals, we can add them > type N0 = Zero; type N1 = Su N0; type N2 = Su N1; type N3 = Su N2 > (n0 :: N0, n1::N1, n2::N2, n3::N3) = undefined > test_sum :: E (F FSum :< x :< y) r => x -> y -> r > test_sum = undefined > > test_sum_2_3 = test_sum n2 n3 *TypeLC> :t test_sum_2_3 test_sum_2_3 :: Su (Su (Su (Su (Su Zero)))) Finally, the standard test -- Fibonacci > vfib = fix(\self n -> case n of 0 -> 1 > 1 -> 1 > (n+2) -> (self n) + (self (n+1))) > data Fib' > instance A (F Fib') self (F (Fib',self)) -- build closure > instance A (F (Fib',self)) Zero (Su Zero) > instance A (F (Fib',self)) (Su Zero) (Su Zero) > instance E (F FSum :< (self :< n) :< (self :< (Su n))) r > => A (F (Fib',self)) (Su (Su n)) r > type Fib = Rec (F Fib') > test_fib :: E (F Fib :< n) r => n -> r > test_fib = undefined > > test_fib_5 = test_fib (test_sum n3 n2) Finally, we demonstrate that our calculus is combinatorially complete, by writing the S and K combinators > data CombK > instance A (F CombK) a (F (CombK,a)) > instance A (F (CombK,a)) b a > > data CombS > instance A (F CombS) f (F (CombS,f)) > instance A (F (CombS,f)) g (F (CombS,f,g)) > instance E (f :< x :< (g :< x)) r => A (F (CombS,f,g)) x r A few examples: SKK as the identity > type Test_skk x = E (F CombS :< F CombK :< F CombK :< x) r => r > test_skk1 = undefined:: Test_skk HTrue and the representation of numerals in the SK calculus. The expression (F FSum :< Su Zero) is a partial application of the function sum to 1. > type CombZ = F CombS :< F CombK > type CombSu = F CombS :< (F CombS :< (F CombK :< F CombS) :< F CombK) > type CombTwo = CombSu :< (CombSu :< CombZ) > test_ctwo :: E (CombTwo :< (F FSum :< Su Zero) :< Zero) r => r > test_ctwo = undefined We define the instances of Show to be able to show things. We define the instances in a way that the value is not required. > instance Show HTrue where show _ = "HTrue" > instance Show HFalse where show _ = "HFalse" > instance Show Zero where show _ = "N0" > instance Show x => Show (Su x) where > show _ = "N" ++ (show (x+1)) > where ('N':xs) = show (undefined::x) > x = (read xs)

1 0

ANN: SmallCheck 0.1
by Colin Runciman 14 Sep '06

14 Sep '06

SmallCheck: another lightweight testing library in Haskell. Folk-law: if there is any case in which a program fails, there is almost always a simple one. SmallCheck is similar to QuickCheck (Claessen and Hughes 2000-) but instead of a sample of randomly generated values, SmallCheck tests properties for all the finitely many values up to some depth, progressively increasing the depth used. For data values, depth means depth of construction. For functional values, it is a measure combining the depth to which arguments may be evaluated and the depth of possible results. Other possible sales pitches: * write test generators for your own types more easily * be sure any counter-examples found are minimal * write properties using existentials as well as universals * establish complete coverage of a defined test-space * display counter-examples of functional type A new version of SmallCheck can be obtained from: http://www.cs.york.ac.uk/fp/smallcheck0.1.tar The differences from 0.0 are two fixes (space-fault, output buffering), an 'unsafe' but sometimes useful Testable (IO a) instance and additional examples. Comments and suggestions welcome. Colin R

2 2

Re: [Haskell] Re: ANN: Haskell98 termination analyzer (AProVE)
by Stephan Swiderski 12 Sep '06

12 Sep '06

Jim Apple wrote: > On 9/11/06, Neil Mitchell <ndmitchell(a)gmail.com> wrote: > > Can you give any examples of terminating Haskell programs that a human > > can analyse (perhaps with a bit of thought), but that your system > > can't? (I couldn't find any in your paper) > > Euclid's algorithm is mentioned on the web page, if I remember correctly. Unfortunately, we are unable to show the termination of the gcd function as definied in the Hugs Prelude. But we could show the termination of this slightly modified version: igcd :: Int -> Int -> Int igcd x y = igcd' (abs x) (abs y) igcd' :: Int -> Int -> Int igcd' 0 x = x igcd' y 0 = y igcd' (x+1) (y+1) | x > y = igcd' (x-y) (y+1) | otherwise = igcd' (y-x) (x+1) So not only the algorithm itself is important; also the way it is written is sometimes essential for proving termination. Best regards, Stephan

1 0

ambiguous (partially defined) type problem / active objects
by Maarten 12 Sep '06

12 Sep '06

Dear all, I'm trying to create active nodes that have a common base part and a user definable custom part, run in their own thread and can communicate/send message to each other. For some reason the compiler complains about an ambiguous type, while I feel, though the type may be partially ambiguous, I'm not using that particular part in related function calls. So in some ways I think there is nothing to complain. Is there a way to resolve this? Are there better/easier solutions to this problem? My solution so far is as follows (see code is below): The active nodes have different types that have a common base state and a changing top state. The base state will be responsible for connection nodes to each other, the top state is user defined. 1. I 'piggy-bag' two State transformers (and IO) onto each other, one with the base state and one with the custom state 2. In their own thread, the top state transformer processes the contents of a list (in which each element is an action) that comes from a channel. 3. The channel is basically the active object and can receive message. 4. Since 'active objects' need to be stored in a list in the base state they are wrapped in a general node data structure (GN) that hides the type of the active object. In this way, actions can be fed to the channel and are executed in the thread and context of the state monad. One can define a changing topstate and add basic functionality to it. This works reasonably well, except that when I store a node into another node (using the base functionality) and later on retrieve it and then want to apply some other suitably typed functions functions using only the base functionality, the compiler complains that the type is ambiguous. However I feel it shouldn't complain, since the functions doesn't use the ambiguous part. Of course the problem is resolved as soon as a function establishes the type. However, in many cases I don't know (and don't want to know the type). Can this be resolved? The code below is unfortunately rather long. Of course it doesn't compile, unless the last comment is removed. If removed it works fine. Any comments and pointers appreciated. Thanks. (I'm quite new to haskell, so I may be missing some obvious things.) Maarten P.S. (Sorry for the long code sample below, but I don't know how to condens is into something smaller, while retaining the relevant properties). {-# OPTIONS -fglasgow-exts -cpp -fallow-undecidable-instances #-} module Main where import Data.Generics import Control.Monad.State import Data.Unique import Control.Concurrent (forkIO, forkOS) import Control.Concurrent.Chan import Control.Concurrent.MVar instance Show Unique where show a = show (hashUnique a) -- default node state; same for all states; nodes are active objects (see below) data DefNodeState = DefNodeState { id::Unique, nodes::ActiveObjects } deriving Show -- make this default state a base state transformer type BaseStateT m = StateT DefNodeState m type BaseStateTIO = BaseStateT IO -- TopStateT with parameterizable state type TopStateT ts a = StateT ts BaseStateTIO a instance Show (TopStateT b ()) where show a = "TopStateT Monad" tsTc = mkTyCon "TopStateT" instance forall ts. (Show ts, Typeable ts) => Typeable1 (StateT ts BaseStateTIO) where typeOf1 _ = mkTyConApp tsTc [] -- hide top state type so we can put them in a list; typeable so it can be cast back data GN = forall o. (Show o,Typeable o) => GN o instance Show (GN) where show (GN o) = "GN " ++ show o gnTc = mkTyCon "GN" instance Typeable GN where typeOf _ = mkTyConApp gnTc [] -- convenience type type ActiveObjects = [GN] -- active objects -- make topstate an active object by putting it in a chan data ActiveObject a = ActiveObject (Chan (TopStateT a ())) -- make active object instance of show instance Show (ActiveObject o) where show o = "ActiveObject Chan StateT" -- make active object typeable activeObjectTc = mkTyCon "ActiveObject" instance Typeable1 ActiveObject where typeOf1 _ = mkTyConApp activeObjectTc [] -- make new active object over some state newActiveObject action state t = do chan <- newChan contents <- getChanContents chan forkIO (start (action contents) state) return (ActiveObject chan) -- send an action if we are not interested in the result send :: forall a . (Typeable a, Show a) => ActiveObject a -> TopStateT a () -> IO () send (ActiveObject chan) act = do writeChan chan act -- sync an action if we are interested in the result sync :: forall a b. (Typeable a, Show a) => ActiveObject a -> TopStateT a b -> IO b sync ao f = do mv <- newEmptyMVar send ao (f' mv) a <- takeMVar mv return a where f' mv = do a <- f lift $ lift $ putMVar mv a class SendSync t where sendM :: forall a. (Typeable a, Show a) => t a -> TopStateT a () -> IO () syncM :: forall a b. (Typeable a, Show a) => t a -> TopStateT a b -> IO b instance SendSync (ActiveObject) where sendM ao m = send ao m syncM ao m = sync ao m {- unforunately doesn't work instance SendSync (GN) where sendM (GN ao) m = sendM ao m syncM (GN ao) m = syncM ao m -} castGN :: forall a. (Show a,Typeable a) => GN -> ActiveObject a castGN (GN o) = mcast o where mcast o = case (cast o) of Nothing -> error "No cast possible" Just a -> a -- some test states for toplevel data TestState = TestState { val::Int } deriving (Show,Typeable) data TestState2 = TestState2 { val2::Int } deriving (Show,Typeable) uid :: forall b. TopStateT b Unique uid = lift $ gets Main.id changeUid :: forall b. Unique -> TopStateT b () changeUid n = do lift $ modify (\s -> s { Main.id = n }) newUid :: forall b. TopStateT b () newUid = do n <- lift $ lift $ newUnique lift $ modify (\s -> s { Main.id = n }) -- add a node to list in basestate addNode :: forall o a. (Typeable a, Show o,Typeable o) => ActiveObject o -> TopStateT a () addNode n = do ns <- lift $ gets nodes lift $ modify (\s -> s { nodes = (GN n):ns }) -- get a node from list in basestate getNode :: forall a o. (Show o,Typeable o) => Integer -> (TopStateT a (ActiveObject o)) getNode i = do ns <- lift $ gets nodes let ao = ns !! (fromInteger i) return (castGN ao) -- action that executes messages send to it action [] = return () action (e:es) = do -- just for testing i <- uid s <- get ns <- lift get lift $ lift $ putStrLn $ "event (" ++ show i ++ "):" ++ " state:" ++ show s ++ " nstate:" ++ show ns -- e action es -- create a new node state with a unique id newNodeState = do u <- newUnique return (DefNodeState u []) -- start evaluation start action state = do ns <- newNodeState execStateT (execStateT action state) ns return () main = do ao <- newActiveObject action (TestState 5) TestState ao2 <- newActiveObject action (TestState2 5) TestState2 -- simple test u1 <- syncM ao (gets val) putStrLn $ "u1:" ++ show u1 -- show complete state r <- syncM ao (get) putStrLn $ show r -- connect ao to ao2 sendM ao (addNode ao2) -- get node back ao2' <- syncM ao (getNode 0) -- get unique id u <- syncM ao2' (uid) putStrLn $ "u:" ++ show (hashUnique u) -- set a new id sendM ao2' (newUid) -- show it u' <- syncM ao2' (uid) putStrLn $ "u':" ++ show (hashUnique u') -- u2 <- syncM ao2' (gets val2) getChar return ()

1 0

Second CFP: Partial Evaluation and Program Manipulation (PEPM'07)
by Eelco Visser 12 Sep '06

12 Sep '06

---------------------------------------------------------------------- Second Call For Papers ACM SIGPLAN 2007 Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM'07) Nice, France January 15-16, 2007 (Co-located with POPL 2007) http://www.program-transformation.org/PEPM07 ---------------------------------------------------------------------- The PEPM Symposium/Workshop series aims to bring together researchers and practitioners working in the areas of program manipulation, partial evaluation, and program generation. PEPM focuses on techniques, theory, tools, and applications of analysis and manipulation of programs. The 2007 PEPM workshop will be based on a broad interpretation of semantics-based program manipulation and continue last year's successful effort to expand the scope of PEPM significantly beyond the traditionally covered areas of partial evaluation and specialization and include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule- based transformation systems. In addition, the scope of PEPM covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-driven development. In order to reach out to practitioners, a separate category of tool demonstration papers will be solicited. ---------------------------------------------------------------------- Topics of interest for PEPM'07 include, but are not limited to: + Program and model manipulation techniques such as transformations driven by rules, patterns, or analyses, partial evaluation, specialization, slicing, symbolic execution, refactoring, aspect weaving, decompilation, and obfuscation. + Program analysis techniques that are used to drive program/model manipulation such as abstract interpretation, static analysis, binding-time analysis, dynamic analysis, constraint solving, and type systems. + Analysis and transformation for programs/models with advanced features such as objects, generics, ownership types, aspects, reflection, XML type systems, component frameworks, and middleware. + Techniques that treat programs/models as data objects including meta-programming, generative programming, staged computation, and model-driven program generation and transformation. + Application of the above techniques including experimental studies, engineering needed for scalability, and benchmarking. Examples of application domains include legacy program understanding and transformation, domain-specific language implementations, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, resource-limited computation, and security. We especially encourage papers that break new ground including descriptions of how program/model manipulation tools can be integrated into realistic software development processes, descriptions of robust tools capable of effectively handling realistic applications, and new areas of application such as rapidly evolving systems, distributed and web-based programming including middleware manipulation, model-driven development, and on-the-fly program adaptation driven by run-time or statistical analysis. ---------------------------------------------------------------------- Submission Categories and Guidelines Regular research papers must not exceed 10 pages in ACM Proceedings style. Tool demonstration papers must not exceed 4 pages in ACM Proceedings style, and authors will be expected to present a live demonstration of the described tool at the workshop. Suggested topics, evaluation criteria, and writing guidelines for both research tool demonstration papers will be made available on the PEPM'07 web site. Papers should be submitted electronically via the workshop web site. The workshop proceedings will be published in the ACM Digital Library and selected papers will be invited for a journal special issue dedicated to PEPM'07. ---------------------------------------------------------------------- Important Dates + Abstracts due: October 18, 2006 + Submission: October 20, 2006 + Notification: December 1, 2006 + Camera-ready: December 18, 2006 + Workshop: January 15-16, 2007 ----------------------------------------------------------------------- Program Chairs * G. Ramalingam (Microsoft Research, Bangalore) * Eelco Visser (Delft University of Technology, The Netherlands) Program Committee Members * Ras Bodik (University of California, Berkeley, USA) * Albert Cohen (INRIA, France) * Jim Cordy (Queen's University, Canada) * Martin Erwig (Oregon State University, USA) * Bernd Fischer (University of Southampton, UK) * John Hatcliff (Kansas State University, USA) * Jan Heering (CWI, The Netherlands) * Dan Grossman (University of Washington, USA) * Annie Liu (State University of New York at Stony Brook, USA) * Jacques Noyé (École des Mines de Nantes/INRIA, France) * German Puebla (Technical University of Madrid, Spain) * Peter Sestoft (Royal Veterinary and Agricultural University, Denmark) * Yannis Smaragdakis (Georgia Tech, Atlanta, USA) * Walid Taha (Rice University, Houston, USA) -----------------------------------------------------------------------

1 0

Pajama & Eros; collaborators sought
by Conal Elliott 11 Sep '06

11 Sep '06

I'm looking for collaborators on two projects, as described below. The first project is Pajama, which is a re-implementation of the Pan language and optimizing compiler for image synthesis and manipulation ( http://conal.net/Pan) The Pajama home page is http://conal.net/Pajama, and a new wiki is at http://pajama.conal.net. Pan's use was very limited, because it generated C++ code, ran only on Windows, and depended on Microsoft Visual C++ and a long-obsolete GUI library. In contrast, Pajama generates Java code and therefore runs on several platforms. Pajama-compiled effects don't run quite as fast as Pan-compiled ones, but I believe they run much faster than other functional image implementations. Besides these implementation issues, Pajama also provides a richer approach to spatial interaction and a more general notion of spatial transformation. The second project is Eros and is described in a draft paper ( http://conal.net/papers/Eros) Eros is a prototype system for end-user construction of parameterized computational content. In other words, it is a way to create programs but with the feel of interacting with the running programs. The central idea is that of tangible values, which are values (often functions) combined with user interfaces. I'd particularly love help getting this system to a genuinely user-friendly state and perhaps connect it with Pajama's code generator, to produce web content. If you're interested/curious in Pan or Pajama or other collaborations, please email me and/or grab me next week at HW or ICFP. Questions & comments also welcome. Cheers, - Conal

1 0

ANN: Haskell98 termination analyzer (AProVE)
by Stephan Swiderski 11 Sep '06

11 Sep '06

Dear all, we are pleased to announce the integration of an automatic Haskell98 termination analyzer in the termination tool AProVE [1]. Our tool accepts full Haskell as specified in the Haskell 98 Report and is available through our web interface [2]. USE Our tool checks termination of given start terms w.r.t. a Haskell program. A start term is a Haskell term accepted by the command line of Haskell interpreters like GHCi or Hugs. Moreover, start terms may contain free variables representing arbitrary terminating terms. EXAMPLE For example the start term "take x (repeat y)" can be proved terminating (where "take" and "repeat" are defined in the Haskell prelude). On the other hand, the start term "repeat y" does not terminate, because the function "repeat" generates the infinite list of "y"s. For more details on our approach see [3]. EXPERIMENTS We evaluated our tool on standard libraries (Prelude, List, ...) of the Hugs implementation. In this setting we could show the termination of almost 80 percent of 1281 start terms resulting from these libraries. More details on the evaluation can be found in [4]. FEEDBACK We would be grateful for comments and suggestions on our tool or on our approach. Please send them to: aprove(a)i2.informatik.rwth-aachen.de Stephan Swiderski, Jürgen Giesl, Peter Schneider-Kamp, René Thiemann [1] AProVE home page: http://aprove.informatik.rwth-aachen.de [2] web interface: http://aprove.informatik.rwth-aachen.de/index.asp?subform=termination_proof… [3] RTA06 paper: http://aprove.informatik.rwth-aachen.de/eval/Haskell/RTA06-distribute.ps [4] experimental evaluation: http://aprove.informatik.rwth-aachen.de/eval/Haskell/

7 6

parallel programming support
by Niall Dalton 11 Sep '06

11 Sep '06

Hi, Its been a long time since I attempted cluster programming with Haskell. Browsing around the older and research projects suggests that they are not currently usable with recent GHC (6.5+) - be that gph or existing mpi bindings. Is anyone actively using Haskell for cluster programming and could recommend any particular set of tools? GHC's smp support within a node and binding to mpi between nodes seems the most practical way forward. Thanks, niall

1 0

putStr is not evaluated in the correct order
by Andreas S 10 Sep '06

10 Sep '06

Hello, i've got a newbie question to ask. I'd like to ask for user input in the same line as the prompt. I found this example on the web main = do putStr "Who are you? " name <- getLine putStrLn ("Hello, " ++ name) This works find in ghci, but the compiled code (ghc 6.4.2) executes getLine first before executing putStr. Instead of: Who are you? myself Hello, myself I got: myself Who are you? Hello, myself I'm new with haskell, so I can't be too sure about this, but it seems from putStr implementation in Prelude, putStr should be executed first. Why are they different? And if they are suppose to be different, then how to put prompt and input on the same line for the compiled code? Thank you in advance -andre

7 7

Proposal: unification of style of function/data/type/class definitions
by Bulat Ziganshin 10 Sep '06

10 Sep '06

Hello haskell, we can consider functions as value-to-value mappings, 'type' definitions as type-to-type mappings, 'data' and 'class' as type-to-value mappings but their syntax are different. functions has the most convenient syntax: f patterns_for_parameters | guards = result we can improve readability of various declarations by using the same scheme: class Monad m | Functor m, Monoid m where ... instance Monad (WriterT m) | Monad m where ... data EncodedStream m h | Monad m, Stream m h = ... sequence :: [m a] -> m [a] | Monad m By moving "guards" to the right side we will get more readable definitions where most important information (type/class name and shape of parameters) are written first and less important after Even more unification can be applied to GADT-style definitions and definitions of type/data families. The following is a well-known GADT example rewritten in "functional" style: data Expr t = If (Expr Bool) (Expr t) (Expr t) Expr Int = Lit Int Expr Bool | Eq t = Eq (Expr t) (Expr t) And next is the example of type function which selects optimal array representation depending on type of its elements: type Arr Bool = BitVector Arr u | Unboxed u = UArray u Arr (a,b) = (Arr a, Arr b) Arr a = Array a where Unboxed is a class whose instances are unboxable types. We can also allow to use as guards partial type functions, i.e. functions that defined only for subset of type parameters: type SeqElem [a] = a SeqElem (Sequence a) = a SeqElem (Array a) = a data Collection c | SeqElem c = Coll c In general, any type-level computation can use: * in patterns - any type constructors declared in 'data' statements and their saturated synonyms * in guards - classes (and partial type functions) * at the right side - any type constructors and type functions declared with data/type statements, including associated types/type synonyms Please note that ordinal functions dispatch (via pattern-matching) on the data constructors which appear at the right side of 'data' definitions while type-level computations dispatch (again via pattern-matching) on type constructors which appears on left side of the same 'data' definitions ps: although this idea seems more appropriate for haskell' committee, i propose to use it just now, starting from implementation of different syntax for GADTs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 4