- Haskell-Cafe - Haskell.org

Re: No safety in numbers
by Jon Cast 22 Aug '03

22 Aug '03

Konrad Hinsen <hinsen(a)cnrs-orleans.fr> wrote: > I am trying to write a larger piece of code using only type > constraints for all the numbers, not specific types, in order to be > able to choose the precision as late as possible. Good for you! (I say this in all seriousness.) > This works rather well (something I can't say of many other > languages), but one problem I keep running into is constants. > > Something I need frequently is, for example, the Boltzman constant, > 0.0083144708636327096 in my unit system. I can certainly type > 0.0083144708636327096 everywhere in the code and make things work, > literals have the nice property of being overloaded. But for the sake > of readibility, I prefer to give this beast a name and have the > explicit value only once in my code. So I create a module "Constants" > with something like > > k_B = 0.0083144708636327096 > > The trouble is that k_B then becomes "Double" by default Right. The good old monomorphism rule, I assume. Query: does this rule ever make a programmer's job easier? Beats me. > (or any other type I declare it to be). Right. But: you can declare it to have type Fractional alpha => alpha, which is the same type the constant has in the middle of an expression. <snip> Jon Cast

2 1

Re: Monads and Maybe
by Jon Cast 22 Aug '03

22 Aug '03

Konrad Hinsen <hinsen(a)cnrs-orleans.fr> wrote: > I have been following the recent "Monad tutorial" discussion with > interest, and even read the tutorial, which is a useful addition to > the existing Haskell documentation. So useful in fact that it raises a > question... > > The whole monad mechanism seems to geared towards functions of one > argument, plus eventually state, that get chained together. How about > functions with several arguments? > > As an example, I'll use the Maybe monad. Suppose I want to write code > to handle experimental data, in which there might be missing values. I > might then decide to represent measurements by data of type "Maybe > Double", with missing values represented by "Nothing". I could then go > on to define functions on missing values, which would return "Nothing" > when their argument is "Nothing", and I could string these functions > together via the monad mechanism. Fine. But how would I handle > e.g. addition of two such values? The result should be "Nothing" when > either of its arguments is "Nothing". Is there any mechanism to handle > that? Yes. Many complicated proposals have been made, but there's a straightforward, general mechanism: > addMaybe :: Num alpha => Maybe alpha -> Maybe alpha -> Maybe alpha > addMaybe a b = a >>= \x -> > b >>= \y -> > return (x + y) or > addMaybe a b = do > x <- a > y <- b > return (x + y) (Incidentally, monads in Haskell are specified slightly differently than the Categorical version to enable precisely this sort of pattern.) Jon Cast

2 1

sequencing data structures
by Martin Norbäck 21 Aug '03

21 Aug '03

I want to sequence data structures in an efficient manner, to store them to files and to send them over the network. Simply deriving Show and Read is not very good, because it's space inefficient and read cannot give any output until the whole data structure is parsed. So I thought I should store them in some space efficient format. First problem: how to make them derivable (so that I don't have to write boilerplate class instances for all my data structures). I read the "derivable type classes" paper, but it's not implemented in ghc (only Unit and :+: and :*: are, which is not enough). So how to go about it? Using DrIFT? Template Haskell? Second problem: how should such a format look like? Ideally, I want to be able to write an infinite data structure (at least one containing loops). If that is not possible I want to be able to read as lazily as possible, this means traversing the data structure in breadth first order, so that a cons form can be reached quickly. Does anyone have any thoughts/pointers on this subject? It would surprise me if nobody has had this problem before. Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

5 6

RE: Database interface
by Bayley, Alistair 21 Aug '03

21 Aug '03

> From: Tim Docker [mailto:timd@macquarie.com.au] > > > It also has the benefit that the function you pass to doquery can > make > > other calls to doquery, without mucking up the 'current row' state. > > There would be one current row per Cursor, not one per Process. > > Is it normal or common to support multiple simultaneous queries on > a single DB connection? Depends on what you mean by "multiple simultaneous queries". A single query is usually synchronous w.r.t. returning a cursor i.e. you issue the query and get back a cursor in an atomic operation, and then you can do other things while you fetch rows from the cursor. If you need to have two SQL statements running at the same time (two big inserts or updates, say) then you usually need two sessions. It probably depends on the API, but some (Oracle, I believe) will allow you to open multiple sessions with the same connection. In a single session you could open a number of cursors (in any order), interleave fetches (in any order), and then close the cursors (in any order). So you could have: - a number of Connections (perhaps to different servers/databases), where - each Connection has one or more Sessions, and - each Session has zero or more Cursors (and one current Transaction). My session model and terminology are probably quite Oracle specific, but I hope it's reasonably clear. ***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************

1 0

RE: Database interface
by Tim Docker 21 Aug '03

21 Aug '03

Tom Pledger writes: > By the way, how does the a in a -> b -> IO (b, Bool) work? > It looks like it has something to do with the current row. Does > doquery have to accommodate any possible substitution for a ? I fired this off without thinking about it too much, and looking at the prelude type signatures for fold. The list being folded over is implied by the DB query, is accessible through the IO monad. Hence a parameter is not required. It would really be: doquery :: Process -> String -> b -> (b -> IO (b,Bool)) -> IO b > I don't have a preference, but offer this view of the options: > > With an exception, "Stop, and return the last b you saw." > With a boolean, "Stop, and return this b." I think I like the behavior where, when the bool in the tuple is true, the b in the tuple is immediately returned from the query. Exceptions would be propagated to the caller of doquery without modification (but with appropriate cleanups). One thing that I am unsure about is whether the column value accessing functions that I specified before stringv :: Process -> CInt -> IO String doublev :: Process -> CInt -> IO Double intv :: Process -> CInt -> IO Int should return actions in the IO monad as above, or instead should be in some other DBQuery monad, that trivially extends the IO monad, but is only valid inside the doquery call. This would have the benefit of restricting the column access functions to inside a query via the type system. I'd also probably use a typeclass to specify a single colv function. ie: class DBCol a where colv :: DBQuery a instance DBCol String where... instance DBCol Double where... doquery :: Process -> String -> b -> (b -> DBQuery (b,Bool)) -> IO b Any comments? Tim

2 1

Re: "let" vs. "where"
by Hamilton Richards 21 Aug '03

21 Aug '03

At 7:42 AM +0200 8/20/03, Jan Scheffczyk wrote: >Hi Andrew, > >> let x = expensiveComputation foo in x + x >> >> I would certainly hope that expensiveComputation wasn't called twice, >> and even though the language doesn't guarantee it, I have already >> written code that assumed it. > >I always thought that there is a tiny difference between "let" and "where": >Using "let" "expensiveComputation foo" might be computed twice (depending on >the compiler?). >But using: > > x + x > where x = expensiveComputation foo > >should compute the value for x only once. >Therefore, I always try to use "where" for common subexpressions. > >Please correct me if I'm wrong here. The reserved word "let" introduces an expression (a "let-expression"), but there's no such thing as a "where-expression". The reserved word "where" can be used only in definitions. For example, 3 + ((x + x) where x = expensiveComputation foo) is invalid syntax, whereas 3 + let x = expensiveComputation foo in x + x is OK. And here's a use of "where" in a definition: let z = x + x where x = 2 in z*5 That could have been written using only "let": let z = let x = 2 in x + x where x = 2 in z*5 Watch out for the Hugs 98 command line-- it allows z*5 where z = x + x where x = 2 but that's not a truly valid expression, because you can't embed it in a larger expression: 2 + (z*5 where z = x + x where x = 2) is properly identified as a syntax error. Regards, --Ham -- ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138 Austin, Texas 78712-1188 ham(a)cs.utexas.edu hrichrds(a)swbell.net ------------------------------------------------------------------

1 0

More type design questions
by Konrad Hinsen 20 Aug '03

20 Aug '03

Continuing in my quest to understand type design in Haskell, here's another episode that leaves me scratching my head: module Foo where class Vect v a where (<+>) :: Floating a => v a -> v a -> v a data Vector a = Vector a a a instance Vect Vector a where (<+>) (Vector x1 y1 z1) (Vector x2 y2 z2) = Vector (x1+x2) (y1+y2) (z1+z2) instance Vect [Vector a] a where (<+>) l1 l2 = zipWith (<+>) l1 l2 The problem is the last instance declaration. Hugs says "Illegal type in class constraint", which is not very explicit (which class constraint?). GHCI is a bit more verbose: Kind error: Expecting kind `* -> *', but `[Vector a]' has kind `*' When checking kinds in `Vect [Vector a] a' In the instance declaration for `Vect [Vector a] a' I have vague memories of seeing mentioned the concept of "kind", but I can't remember where. Any help would be appreciated! Konrad.

6 10

Tuples or Record
by Frederic BELLOC 19 Aug '03

19 Aug '03

Hello, When I have started my project, I use a Tuples but i would know if it is possible to create a record such C or Ocaml provide. I mean creating a structure where variables are accessible by a '.' or something like that. -- BELLOC Frederic EPITA 2005 STUDENT C, socks and sun !

3 2

New Haskell and FPO merchandise available
by K. Fritz Ruehr 19 Aug '03

19 Aug '03

Newly-designed Haskell, FP and related merchandise (mostly T-shirts) are now available at the URLs below. I didn't receive many specific requests on logo/product combinations from my last post, so I have tried to pick and choose as best I can (I've included at least men's and women's white T-shirts, in two styles for the women, for all the new designs I used). It may be difficult to get items in time for ICFP in Uppsala, for which I apologize. On the other hand, the actual physical products are as yet untested (i.e., for print quality), so perhaps it is just as well if I manage to get some samples to wear to the conference: that way you may have a chance to see them "live" before you buy. Note that all items are provided at cost, i.e., I get no profit, although CafePress does. Almost all shirts have extra material on the back side: it turns out that no premium is charged for this, so I tried to give the best value for the money (exceptions include the "new logo" baby doll shirt, the "classy" logo golf shirt, all of the "dysfunctional programming" shirts and the Generic Haskell shirts; Pancito back-side art should be up soon). Certainly if there are any logos from the original set you would like turned into a product, or any other variations, let me know by return mail (see <http://www.willamette.edu/~fruehr/logos/intro.html>). -- Fritz Ruehr PS: Thanks to all who made such encouraging comments on the designs, and also to Andrew Cooke for the Pancito artwork. ---------------------- * Original haskell.org logo (Pan image on back): <http://www.cafeshops.com/haskell> * New Haskell logo (words on front, circle back): <http://www.cafeshops.com/haskellnewlogo> * Haskell "purity" logo (w/ "Pure Fun" on back): <http://www.cafeshops.com/purehaskell> * Alternate "classy" logo (feature list on back): <http://www.cafeshops.com/classyhaskell> * Dysfunctional programming (nothing on back): <http://www.cafeshops.com/dysfunc> * Strong, static types (typing judgement on back): <http://www.cafeshops.com/statictypes> * HOT [higher-order typed] (lambda on back): <http://www.cafeshops.com/highordertyped> * Do it in a Monad (monad laws on back): <http://www.cafeshops.com/doitmonad> * Generic Haskell logo (no back as yet): <http://www.cafeshops.com/generichaskell> * Pancito "bugs" artwork (no back *yet*): <http://www.cafeshops.com/pancito>

2 1

Updated monad tutorial
by Jeff Newbern 18 Aug '03

18 Aug '03

Hello, I would like to thank everyone for their feedback on the monad tutorial I posted earlier. Based on that feedback, I have expanded and corrected the tutorial at www.nomaware.com/monads/html/index.html The primary changes are: - vastly expanded section on monad transformers - additional examples of monad transformers, including multiple transformers in a stack - added examples for liftM, guard, ap and msum - consistent use of "action" in IO monad "computation" in all others - made language more precise when discussing the IO type constructor - fixed typos, cleaned up some code in examples I am sufficiently pleased with this version to call it 1.0, but I still welcome any and all feedback. Thanks, Jeff Newbern -- Jeff Newbern <jnewbern(a)nomaware.com> Nomaware, Inc.

1 0