August 2007 - Haskell-Cafe

When is waitForProcess not necessary?
by Dave Bayer 03 Aug '07

03 Aug '07

If one is calling runInteractiveCommand for a "sure-thing" returning a small amount of output (say, "ls" for a modest directory"), is it necessary to call waitForProcess? My waitForProcess calls came under scrutiny when I tried to GHC profile a threaded process, which isn't possible. It turns out that my programs run faster if they don't call waitForProcess, and it sure seems empirically that they never fail to run correctly. It would seem to me that in a lazy language, later code wouldn't presume it was looking at an entire string until the actual EOF came through, completing the string. So at the end of a program, with nothing else to do but wait, why not wait "implicitly" rather than via an explicit call to waitForProcess? What am I missing? (I've searched this forum; an interesting example is runCommand in http://happs.org/HAppS/src/HAppS/Util/Common.hs but I'm asking why this isn't overkill in my scenario. I'm actually calling Markdown.pl on tiny files (source code of lengths a human would read), and it is certainly sluggish enough to be a fair test.)

6 8

Re: RE [Haskell-cafe] Monad Description For Imperative
by Greg Meredith 03 Aug '07

03 Aug '07

Haskellians, i am delighted to see vigorous exchange that actually resulted in change of positions. i confess i was going to give up, but glad others stepped into the breach. This is yet another indication of what an unusual community this is. Best wishes, --greg Date: Fri, 3 Aug 2007 13:43:32 +1200 From: ok <ok(a)cs.otago.ac.nz> Subject: Re: RE [Haskell-cafe] Monad Description For Imperative To: haskell-cafe Cafe <haskell-cafe(a)haskell.org> Message-ID: <8575BD1C-2113-4D48-A3D4-BDFF41238BB9(a)cs.otago.ac.nz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I asked "How is IO a functor"? On 3 Aug 2007, at 11:50 am, Dan Piponi wrote: > IO is a fully paid up Monad in the categorical sense. The category is > the category whose objects are types and whose arrows are functions > between those types. IO is a functor. The object a maps to IO a. An > arrow f::a->b maps to (>>= return . f)::IO a -> IO b and that can be > used to make IO an instance of Functor. The natural transforms eta and > mu are called return and join. Please go over this again, but slowly this time. You have convinced me, but I'd like to understand the details a little better. I see that any type constructor TC :: * -> * is halfway to being a functor on this category of types. It acts on the objects in the obvious way, so the next step is to see about the arrows. If f :: a -> b then we want TC f :: TC a -> TC b such that TC (f . g) = TC f . TC g and TC (id::a->a) = id :: TC a -> TC a Now this is precisely the Haskell Functor class, so TC is the object part and fmap is the arrow part. You say that (>>= return . f) can be used to make [a Monad] an instance of Functor. Try it... by golly it's true. I see: fmap f = (>>= return . f). So why *aren't* Monads already set up using the type class machinery to always *be* Functors in Haskell? Isn't it bound to confuse people if monads are functors but Monads are not Functors? This is especially puzzling because Maybe, [], and IO already *are* Functors, but the way this is done makes it look accidental, not like the fundamental property of Monads it apparently is. (By the way, I note that the on-line documentation for Control.Monad glosses >>= as "Sequentially composes two actions...".) -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com

1 0

Re: [Haskell-cafe] Re: monad subexpressions
by Mirko Rahn 03 Aug '07

03 Aug '07

>>> rewrite *p++=*q++ in haskell? >> *p = *(p+1) ; *q = *(q+1) > If that's true then GCC has gone insane, because they are completely different. Of course you are right, I just observed at the wrong place..., sorry for that. > Though, as any C programmer knows, you really should be using > memcpy() I like to hear that you would reject it either. /BR -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

1 0

GHC, GLUT and OS X
by Paul L 03 Aug '07

03 Aug '07

I'm trying to get cross platform GLUT/OpenGL program to run, but even the simplest code hang on OS X with GHC 6.6 or GHC 6.6.1 import Graphics.UI.GLUT import Graphics.Rendering.OpenGL main = do getArgsAndInitialize createAWindow "Hello window" mainLoop createAWindow windowName = do createWindow windowName displayCallback $= clear [ColorBuffer] Has anyone been successful at getting GLUT to work on OS X? Regards, Paul L

3 5

Re: RE [Haskell-cafe] Monad Description For Imperative
by Greg Meredith 03 Aug '07

03 Aug '07

Ok, You wrote But please, let's keep one foot in the real world if possible. > Monads were invented to solve the "how do I do imperative programming > in a pure functional language" problem. > This is more than a little revisionist. Monads have been the subject of mathematical study before people had an inkling that they might apply to problems in computer science. Moggi didn't invent them, but noticed that they might have an application to issues of composition in computation. It is really intriguing that they do such a remarkable job of organizing notions of update and were not invented with this application in mind. So, revising history thus would be a real loss. Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com

4 5

positive Int
by brad clawsie 03 Aug '07

03 Aug '07

as far as i know, the haskell standard does not define a basic Int type that is limited to positive numbers. would a type of this kind not potentially allow us to make stronger verification statements about certain functions? for example, 'length' returns an Int, but in reality it must always return a value 0 or greater. a potential counter-argument would be the need to possibly redefine Ord etc for this more narrow type...

8 9

Re: [Haskell-cafe] ANNOUNCE: Dimensional 0.6 -- Statically checked physical dimensions
by Björn Buckwalter 02 Aug '07

02 Aug '07

David Roundy wrote: > On Thu, Aug 02, 2007 at 10:27:47PM +0200, Björn Buckwalter wrote: > > I am also assuming that the CGS system would not be employed when > > working with temperature, amount or luminosity. This is evident in > > the below type signatures where I have assumed zero extent in the > > temperature, amount and luminosity dimensions. If this is incorrect > > I would appreciate pointers to the CGS representation of these > > dimensions. > > > > Please correct and inform me if my assumptions are wrong! > > The temperature units are the same in CGS as in MKS (Kelvin). Which implies that CGS is applicable to temperatures... what is the (conventional) dimension of temperature in CGS? Is it the same as for Energy (L^2 M^1 T^-2)? > > This is a very rudimentary implementation. To make it more practical > > a significant number of quantities and units, in particularly those > > commonly used with the CGS, would need to be added. In the mean > > time all units defined for the SI can be used with the CGS by > > applying 'fromSI' to quantities defined from the SI units. > > > > If anyone is willing to add quantities/units (or other enhancements) > > I will happily to accept patches. Personally I do not expect to use > > this module and therefore do not intend to invest much more time > > in it. If the module has other users I might reconsider. > > > > And of course, another direction of future work is to define > > additional systems (e.g. natural, relativistic) using this module > > as a template. I imagine this should be fairly straight forward. > > When atomic units are implemented, this could be useful for me... but alas > I very seldom use Haskell for physics, and the effort to learn these > modules seems unlikely to pay off soon. :( Learning to use the modules should require little effort. Learning enough to implement the atomic system of units would require significant effort though. Unfortunately I don't see myself implementing atomic units, at lease not anytime soon. Thanks, Bjorn

1 0

ANNOUNCE: Dimensional 0.6 -- Statically checked physical dimensions
by Björn Buckwalter 02 Aug '07

02 Aug '07

Dear all, I am pleased to announce version 0.6 of the Dimensional library. Dimensional is a library providing data types for performing arithmetic with physical quantities and units. Information about the physical dimensions of the quantities/units is embedded in their types and the validity of operations is verified by the type checker at compile time. The boxing and unboxing of numerical values as quantities is done by multiplication and division with units. The library is designed to, as far as is practical, enforce/encourage best practices [1] of unit usage. Noteworthy changes/additions since the previous formal announcement (version 0.4) are: - All quantities and SI units from [1] have been added. - A Prelude replacement with the SI units and dimensional operators (+, *, ^...) is provided for convenience. - Interface to Data.Time using 'fromDiffTime' and 'toDiffTime'. - Phantom type tags make extended dimensions safer. - Experimental CGS units with type safe conversions to/from SI. See appended literate Haskell module for details. Additional information and code is available from the project web site [3]. Thank you, Bjorn Buckwalter [1] http://physics.nist.gov/Pubs/SP811/ [2] http://www.haskell.org/pipermail/haskell/2007-May/019496.html [3] http://code.google.com/p/dimensional/ ~~~~~~~~~~ BEGIN 'Buckwalter/Dimensional/CGS.lhs' ~~~~~~~~~~ Buckwalter.Dimensional.CGS -- CGS system of units Bjorn Buckwalter, bjorn.buckwalter(a)gmail.com License: BSD3 *** EXPERIMENTAL *** = Introduction = This module was prompted by an email from Chuck Blake[1]. He asked if the Dimensional library could support other systems of units than SI, in particular systems such as the centimeter-gram-second (CGS) system where fractional exponents of dimensions occur. He also wondered whether it was possible to convert quantities between different systems while statically ensuring that a given conversion was valid. In this module we show that we can in a straight forward manner support systems with rational exponents, provided that the rationals that may be encountered are known a priori. As an example we provide a rudimentary implementation of the CGS system. We also show that we can indeed statically prohibit invalid conversions between different systems. = Caveats = I'm ignorantly assuming that when working with the CGS (or MKS) system you will only (meaningfully?) encounter half-exponents and only of the length and mass dimensions. Of course, in other systems other rational exponents may be encountered. I am also assuming that the CGS system would not be employed when working with temperature, amount or luminosity. This is evident in the below type signatures where I have assumed zero extent in the temperature, amount and luminosity dimensions. If this is incorrect I would appreciate pointers to the CGS representation of these dimensions. Please correct and inform me if my assumptions are wrong! = Preliminaries = > {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-} > module Buckwalter.Dimensional.CGS where > import Prelude ( undefined, Num, Fractional, Floating, Show, recip, Double ) > import qualified Prelude > import Buckwalter.Dimensional hiding ( DLength, DMass, DTime, DElectricCurrent ) > import Buckwalter.Dimensional.Quantities as SIQ > import qualified Buckwalter.Dimensional.SIUnits as SI > import qualified Buckwalter.NumType as N > import Buckwalter.NumType ( Neg2, Neg1, Zero, Pos, Pos1, Pos2, Pos3, NumType ) > import Buckwalter.NumType ( neg2, neg1, zero, pos1, pos2, pos3 ) > import Data.Maybe (catMaybes) = Dimensions = Analogously with the SI we collect the base dimensions of the CGS system in the data type 'CGSDim'. > data CGSDim lh mh t In the above 'lh' and 'mh' represent the number of half-exponents of length and mass respectively while 't' represents the number of whole-exponents. The base dimensions illustrate this. > type DLength = CGSDim Pos2 Zero Zero > type DMass = CGSDim Zero Pos2 Zero > type DTime = CGSDim Zero Zero Pos1 We add a few non-base dimensions for the sake of example. Charge is particularly interesting as it illustrates the need for half-exponents as described in [2]. > type DElectricCurrent = CGSDim Pos3 Pos1 Neg2 > type DCharge = CGSDim Pos3 Pos1 Neg1 = 'Mul', 'Div', 'Pow' and 'Root' instances = The 'Mul', 'Div', 'Pow' and 'Root' instances are strictly analogous with the SI. > instance ( N.Sum lh lh' lh'' > , N.Sum mh mh' mh'' > , N.Sum t t' t'' ) => Mul (CGSDim lh mh t) > (CGSDim lh' mh' t') > (CGSDim lh'' mh'' t'') > instance ( N.Sum lh lh' lh'' > , N.Sum mh mh' mh'' > , N.Sum t t' t'' ) => Div (CGSDim lh'' mh'' t'') > (CGSDim lh' mh' t') > (CGSDim lh mh t) > instance ( N.Mul lh x lh' > , N.Mul mh x mh' > , N.Mul t x t' ) => Pow (CGSDim lh mh t) x > (CGSDim lh' mh' t') > instance ( N.Div lh x lh' > , N.Div mh x mh' > , N.Div t x t' ) => Root (CGSDim lh mh t) x > (CGSDim lh' mh' t') = Units = We define the base units of the system. By defining 'meter' with a "scale" of 100 we get a scale of one for 'centi meter'. > meter :: Num a => Unit DLength a > meter = Dimensional 100 > gram :: Num a => Unit DMass a > gram = Dimensional 1 > second :: Num a => Unit DTime a > second = Dimensional 1 We continue by defining the CGS equivalents of the other base SI units. Actually we limit ourselves to 'ampere' since I am not sure if or how the SI base dimensions other than current are expressed in CGS. > ampere :: Floating a => Unit DElectricCurrent a > ampere = prefix (recip 3.33564e-10) ((SI.centi meter ^ pos3) ^/ pos2 * gram ^/ pos2 * second ^ neg2) We also define the preferred CGS unit for charge. > franklin :: Floating a => Unit DCharge a -- Also known as "esu". > franklin = gram ^/ pos2 * (SI.centi meter ^ pos3) ^/ pos2 / second = Conversion from SI = At some point we may wish to convert an SI quantity to a CGS quantity or vice versa. In order to convert a 'Quantity' from the SI system to the CGS system we use the strategy of dividing the quantity by the SI base unit and multiplying the resulting number (sans dimension) by the equivalent CGS unit. To realize this strategy we must be able to obtain the SI base unit and the equivalent CGS unit for a given quantity. We start with the SI unit since it is trivial. > unit_SI :: Num a => Quantity (Dim l m t i th n j) a -> Unit (Dim l m t i th n j) a > unit_SI _ = Dimensional 1 (Perhaps the above function would be better defined in another module.) Obtaining the CGS unit corresponding to the SI base unit of a Quantity isn't quite as trivial. The function body itself is straight-forward enough, the hairy part is the type signature. > unit_CGS :: forall a l m t i l2 m2 il it l' m' t'. > ( Floating a > , N.Mul Zero l Zero, N.Mul Pos2 l l2 > , N.Mul Zero m Zero, N.Mul Pos2 m m2 > , N.Mul Zero t Zero, N.Mul Pos1 t t > , N.Sum l2 Zero l2 > , N.Sum Zero m2 m2, N.Sum m2 Zero m2 > , N.Sum Zero t t > , N.Mul Pos3 i il > , N.Mul Pos1 i i > , N.Mul Neg2 i it > , N.Sum l2 il l' > , N.Sum m2 i m' > , N.Sum t it t' > ) => Quantity (Dim l m t i Zero Zero Zero) a -> Unit (CGSDim l' m' t') a > unit_CGS _ = meter ^ (undefined :: l) > * SI.kilo gram ^ (undefined :: m) > * second ^ (undefined :: t) > * ampere ^ (undefined :: i) Note that since the base dimensions of the CGS are a subset of those of the SI the mapping of types from SI to CGS is unambiguous. Also note that complex as the type signature may be producing it is a mostly mechanical process. With the above two functions we can define the function that converts a unit from the SI. We omit the type signature since it is hairy but can be readily inferred. > fromSI x = x /~ unit_SI x *~ unit_CGS x = Conversion to SI = We use the same strategy to convert from CGS to SI. However, when converting from CGS to SI there may be several valid SI dimensionalities for any given CGS dimensionality. We will handle this ambiguity by requiring the user to specify the desired type (except when it is inferable) of the resulting quantity. For example: ] toSI (3.2 *~ centi meter) :: Length Double In order to do this we must employ lexically scoped type variables and provide the hairy type signature for the 'toSI' function. > toSI :: forall a l m t i l2 m2 il it l' m' t'. > ( Floating a > , N.Mul Zero l Zero, N.Mul Pos2 l l2 > , N.Mul Zero m Zero, N.Mul Pos2 m m2 > , N.Mul Zero t Zero, N.Mul Pos1 t t > , N.Sum l2 Zero l2 > , N.Sum Zero m2 m2, N.Sum m2 Zero m2 > , N.Sum Zero t t > , N.Mul Pos3 i il > , N.Mul Pos1 i i > , N.Mul Neg2 i it > , N.Sum l2 il l' > , N.Sum m2 i m' > , N.Sum t it t' > ) => Quantity (CGSDim l' m' t') a -> Quantity (Dim l m t i Zero Zero Zero) a > toSI x = x /~ unit_CGS (undefined :: Quantity (Dim l m t i Zero Zero Zero) a) > *~ unit_SI (undefined :: Quantity (Dim l m t i Zero Zero Zero) a) Again, the type signature is complex but deriving it is a mechanical process. = 'Show' instance = We round off by writing 'Show' instance for 'CGSDim' analogous to that of 'Dim'. Out of laziness we use the notation "sqrt(cm)" to represent halves of integral dimensions. Nothing is technically keeping us from doing a better job here. > instance forall lh mh t. > ( NumType lh > , NumType mh > , NumType t > ) => Show (CGSDim lh mh t) where > show _ = (Prelude.unwords Prelude.. catMaybes) > [ dimUnit "sqrt(cm)" (undefined :: lh) > , dimUnit "sqrt(g)" (undefined :: mh) > , dimUnit "s" (undefined :: t) > ] = Examples = Let us try the Coulomb attraction example from [2]. We start by performing the calculation in the SI. > q_si = 1.6021773e-19 *~ SI.coulomb -- Elementary charge in SI. > r_si = 0.1 *~ SI.nano SI.meter -- Distance in SI > f_si = q_si ^ pos2 / (_4 * pi * e0 * r_si ^ pos2) > where > e0 = 8.8541878e-12 *~ (SI.ampere * SI.second / (SI.volt * SI.meter)) The same calculation in the CGS system. > q_cgs = fromSI q_si -- Elementary charge in CGS. > r_cgs = fromSI r_si -- Distance in CGS > f_cgs = q_cgs ^ pos2 / r_cgs ^ pos2 Inspecting the values in GHCi shows us that the results are consistent (within reasonable accuracy) with [2]. *Buckwalter.Dimensional.CGS> f_si 2.3070794737101255e-8 m kg s^-2 *Buckwalter.Dimensional.CGS> f_cgs 2.30708078598602e-3 sqrt(cm)^2 sqrt(g)^2 s^-2 To convert from CGS to SI we must specify the type of the SI 'Quantity'. > f_si' = toSI f_cgs :: SIQ.Force Double *Buckwalter.Dimensional.CGS> f_si' 2.3070807859860202e-8 m kg s^-2 We follow up with another conversion example demonstrating the ambiguity in the conversion from CGS to SI. > c = 1 *~ SI.farad -- A SI capacitance. > c_cgs = fromSI c -- Capacitance has dimensionality L in CGS. > c' = toSI c_cgs :: SIQ.Capacitance Double > c'' = toSI c_cgs :: Length Double *Buckwalter.Dimensional.CGS> c 1.0 m^-2 kg^-1 s^4 A^2 *Buckwalter.Dimensional.CGS> c_cgs 8.98755691740885e11 sqrt(cm)^2 *Buckwalter.Dimensional.CGS> c' 1.0 m^-2 kg^-1 s^4 A^2 *Buckwalter.Dimensional.CGS> c'' 8.98755691740885e9 m = Future work = This is a very rudimentary implementation. To make it more practical a significant number of quantities and units, in particularly those commonly used with the CGS, would need to be added. In the mean time all units defined for the SI can be used with the CGS by applying 'fromSI' to quantities defined from the SI units. If anyone is willing to add quantities/units (or other enhancements) I will happily to accept patches. Personally I do not expect to use this module and therefore do not intend to invest much more time in it. If the module has other users I might reconsider. And of course, another direction of future work is to define additional systems (e.g. natural, relativistic) using this module as a template. I imagine this should be fairly straight forward. = References = [1] http://code.google.com/p/dimensional/wiki/ChuckBlake20070611 [2] http://www.tf.uni-kiel.de/matwis/amat/mw1_ge/kap_2/basics/b2_1_14.html ~~~~~~~~~~ END 'Buckwalter/Dimensional/CGS.lhs' ~~~~~~~~~~

2 1

Primitive Recursive Algebraic Types
by Alexteslin 02 Aug '07

02 Aug '07

Hi, I am doing some simple exercises about recursive algebraic types and this particular exercise asks to define a function which counts the number of operators in an expression. I defined the function below, but i am not sure if on the second line changing from "evalLength (Lit n) = n" to "(Lit n) = 0" is the right solution. although the function produces correct result. data Expr = Lit Int | Add Expr Expr | Sub Expr Expr deriving (Eq, Show) evalLength :: Expr -> Int evalLength (Lit n) = 0 evalLength (Add e1 e2) = 1 + (evalLength e1) + (evalLength e2) evalLength (Sub e1 e2) = 1 + (evalLength e1) - (evalLength e2) Thank you -- View this message in context: http://www.nabble.com/Primitive-Recursive-Algebraic-Types-tf4207521.html#a1… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 2

Re: [Haskell] ANN: encoding-0.1 release
by Duncan Coutts 02 Aug '07

02 Aug '07

On Thu, 2007-08-02 at 18:44 +0200, Wolfgang Jeltsch wrote: > Am Donnerstag, 2. August 2007 12:22 schrieb Henning Günther: > > […] > > > ISO 8859-* (alias latin-*) > > Not every ISO-8859-* encoding is a Latin-* encoding. > > > […] > > Wouldn’t it be good to use some already existing library like iconv or do you > think, this is not feasible (because you want to support lazyness, for > example)? Yes, I was talking to Henning about this. I've got an iconv binding[1] that use lazy bytestrings (so it does support lazyness of course) and is pretty quick. Henning has been thinking much more about what the appropriate api should be, I've just got: type Encoding = String convert :: Encoding -> Encoding -> Lazy.ByteString -> Lazy.ByteString so we might be able to use iconv underneath (if it's available). Duncan [1] darcs get http://haskell.org/~duncan/iconv/

1 0