From v.dijk.bas at gmail.com Wed Mar 4 02:59:41 2009 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Mar 4 02:48:20 2009 Subject: Field labels that do updates In-Reply-To: <2a43aa3d0902270413g3eced729x8a9e66d27f89459e@mail.gmail.com> References: <2a43aa3d0902270413g3eced729x8a9e66d27f89459e@mail.gmail.com> Message-ID: 2009/2/27 Ramin Honary : > I have written a couple of small, experimental virtual machines in Haskell, > and I always use the State monad with the virtual machine data type as the > state. > ?? data VM a = VM { getAlpha :: Int , getBeta :: String , getGamma :: a } > which is all well and good, but I inevitably end up writing code like this > along with it: > ? ? putAlpha a (VM _ b c) = (VM a b c) > ??? putBeta? b (VM a _ c) = (VM a b c) > ??? putGamma? c (VM a b _) = (VM a b c) > Its useful because you can just create one monadic function that updates the > state and pass one of the "put" functions as a parameter. > ??? updateVM :: (x -> VM a -> VM b) -> x -> State (VM b) () > ??? updateVM? putFunc value = do { state <- get ; put (putFunc value state) > } > > ...some algorithm... > ? ? do updateVM putAlpha 12 > ?????? updateVM putBeta "Hello" > ?????? return somthing > > But writing the "put" functions become tedious for virtual machines with > more fields in their type, especially if you need to add a field to the data > type in the future. Could there be syntactic sugar added to generate a list > of functions that update the fields of a data type? > ?? data VM a = VM { getAlpha/putAlpha :: Int , getBeta/putBeta :: String , > getGamma/putGamma :: a } > Where the slash operator is optional, but if included in the code will cause > the compiler to generate functions of the given names that update those > fields. > > Pros: one more time-saving feature implemented in syntactic sugar. The > optional nature of the slash operator would give users a choice of whether > or not to use it. > Cons: increases complexity of the syntax > > I couldn't find such a suggestion on the mailing list, but something tells > me this idea is too simple to have not been suggested before. Sorry if this > is a redundant feature request. With "updates using field labels" (http://haskell.org/onlinereport/exps.html#record-update) you can write your put* functions as: putAlpha a vm = vm {getAlpha = a} putBeta b vm = vm {getBeta = b} putGamma c vm = vm {getGamma = c} which make them more resilient against changes in the VM datatype. However you still have to write them. There's also a package from Henning Thielemann called "data-accessor" on hackage (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-accessor) that tries to solve this exact problem. I haven't used it myself so I can't say it will solve all your problems. Maybe Henning can clarify. regards, Bas From conal at conal.net Fri Mar 20 14:51:11 2009 From: conal at conal.net (Conal Elliott) Date: Fri Mar 20 14:38:59 2009 Subject: [Proposal] Move most of Control.Monad to Control.Applicative In-Reply-To: <07248FD7-D6FD-4BD1-8C7D-9C30E326585D@gmail.com> References: <07248FD7-D6FD-4BD1-8C7D-9C30E326585D@gmail.com> Message-ID: Also, return, ap, liftM, liftM2, .... Already discussed? On Fri, Jan 30, 2009 at 9:03 AM, Thomas Davie wrote: > Hi, > Most of Control.Monad doesn't actually rely on Monads, but instead > Applicatives. Data.Traversable fixes this in a lot of cases, but it would > be nice to have the 'standard' functions as general as possible. > > My quick reading of Control.Monad says these at least should fall victim to > demotion to applicatives: > > mapA :: (Applicative f) => (a -> f b) -> [a] -> f [b] > mapA_ :: (Applicative f) => (a -> f b) -> [a] -> f () > sequence :: (Applicative f) => [f a] -> f [a] > sequence_ :: (Applicative f) => [f a] -> f () > > filterA :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] > mapAndUnzipA :: (Applicative f) => (a -> f (b,c)) -> [a] -> f ([b], [c]) > zipWithA :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f [c] > zipWithA_ :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f () > replicateA :: (Applicative f) => Int -> f a -> f [a] > replicateA_ :: (Applicative f) => Int -> f a -> f () > > when :: (Applicative f) => Bool -> f () -> f () > unless :: (Applicative f) => Bool -> f () -> f () > > I may have missed some. > > Bob > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090320/d91ea44d/attachment-0001.htm From conal at conal.net Fri Mar 20 15:02:15 2009 From: conal at conal.net (Conal Elliott) Date: Fri Mar 20 14:50:00 2009 Subject: Specific denotations for pure types Message-ID: I just learned on #haskell that Int has implementation/machine-dependent semantics. I'd always assumed that pure (non-imperative) types have specific denotational models, so that for instance the denotation of something of type Int is either bottom or a (smallish) integer. Since precise & simple denotation is at the heart of how I think about programming, and Haskell is my favorite language, I'm startled and disappointed. I knew we didn't have a denotational semantics for Haskell, but I'd previously assumed it was just a matter of working out the details. Has implementation-independent denotation been discussed for Haskell' ? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090320/00ae7892/attachment.htm From barsoap at web.de Fri Mar 20 18:02:22 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Mar 20 17:49:26 2009 Subject: [Proposal] Move most of Control.Monad to Control.Applicative References: <07248FD7-D6FD-4BD1-8C7D-9C30E326585D@gmail.com> Message-ID: <20090320230222.35567b6c@solaris> Conal Elliott wrote: > return > pure! There's the Other Prelude[1], which is enough fun to be taken seriously. [1] http://www.haskell.org/haskellwiki/The_Other_Prelude -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Fri Mar 20 18:17:07 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Mar 20 18:04:10 2009 Subject: Specific denotations for pure types References: Message-ID: <20090320231707.64ced36e@solaris> Conal Elliott wrote: > I'd always assumed that pure (non-imperative) types have > specific denotational models, so that for instance the denotation of > something of type Int is either bottom or a (smallish) integer. > IIRC, Ints provide signed modulo at-least-31 bits arithmetic, which is a clearly defined, but still utterly under-specified semantic. The idea is that if you want to be safe, you can just use Integer and only be bounded by the implementation's address width and swap space (I heard that Integers break at MAX_INT^MAX_INT). The other idea is that Int is a number type small enough to be as fast as possible, which, in practise, means "fits into a register, together with some tag", which excuses Int's existence where Int32 and Int64 are around. I'm all for defaulting to Integer and providing Natural (as an potentially-unbounded alternative to Nat, which'd be one bit wider than Int)... the (usually meagre) performance gains you can get by choosing Int over Integer are worth an explicit type annotation, and with Integer, you get non-modulo semantics, by default. Is that what you want? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From conal at conal.net Fri Mar 20 18:21:08 2009 From: conal at conal.net (Conal Elliott) Date: Fri Mar 20 18:08:54 2009 Subject: [Proposal] Move most of Control.Monad to Control.Applicative In-Reply-To: <20090320230222.35567b6c@solaris> References: <07248FD7-D6FD-4BD1-8C7D-9C30E326585D@gmail.com> <20090320230222.35567b6c@solaris> Message-ID: Exactly. and <*>, liftA, liftA2, ... On Fri, Mar 20, 2009 at 3:02 PM, Achim Schneider wrote: > Conal Elliott wrote: > > > return > > > pure! > > There's the Other Prelude[1], which is enough fun to be taken seriously. > > [1] http://www.haskell.org/haskellwiki/The_Other_Prelude > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090320/61760f8d/attachment.htm From conal at conal.net Fri Mar 20 18:38:24 2009 From: conal at conal.net (Conal Elliott) Date: Fri Mar 20 18:26:09 2009 Subject: Specific denotations for pure types In-Reply-To: <20090320231707.64ced36e@solaris> References: <20090320231707.64ced36e@solaris> Message-ID: What I want is a specific, simple language-defined denotation for Haskell's pure types and for pure expressions having those types. I guess currently the denotation of Int is something like 'MachineInfo -> Z + bottom' rather than the Z+bottom I thought it was. Or, to remove the junk values, some kind of dependent type 'Pi info :: WadOfMachineInfo -> Int info + bottom', vs a type like Z32+bottom. Similarly for other pure (not as pure as I thought) types. Even the denotation of Bool & () are influenced by the denotation of Int, since Bool & () expressions can contain Int expressions. Does the (denotational) semantics of every Haskell type indeed include 'MachineInfo ->' ? - Conal On Fri, Mar 20, 2009 at 3:17 PM, Achim Schneider wrote: > Conal Elliott wrote: > > > I'd always assumed that pure (non-imperative) types have > > specific denotational models, so that for instance the denotation of > > something of type Int is either bottom or a (smallish) integer. > > > IIRC, Ints provide signed modulo at-least-31 bits arithmetic, which is a > clearly defined, but still utterly under-specified semantic. The idea > is that if you want to be safe, you can just use Integer and only be > bounded by the implementation's address width and swap space (I heard > that Integers break at MAX_INT^MAX_INT). The other idea is that Int is > a number type small enough to be as fast as possible, which, in > practise, means "fits into a register, together with some tag", which > excuses Int's existence where Int32 and Int64 are around. > > I'm all for defaulting to Integer and providing Natural (as an > potentially-unbounded alternative to Nat, which'd be one bit wider than > Int)... the (usually meagre) performance gains you can get by choosing > Int over Integer are worth an explicit type annotation, and with > Integer, you get non-modulo semantics, by default. Is that what you > want? > > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090320/0cf5056a/attachment.htm From barsoap at web.de Fri Mar 20 18:51:18 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Mar 20 18:38:19 2009 Subject: Specific denotations for pure types References: <20090320231707.64ced36e@solaris> Message-ID: <20090320235118.3c51403e@solaris> Conal Elliott wrote: > Even the denotation of Bool & () are influenced > by the denotation of Int, since Bool & () expressions can contain Int > expressions. > Now you've lost me... they definitely shouldn't be. Otherwise, I could be equally well coding in C. In my mind, there's somewhere the equivalent of data () = () and data Bool = True | False , which might, of course, be represented using machine-integers, but have ADT semantics. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Fri Mar 20 19:03:52 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Mar 20 18:50:54 2009 Subject: [Proposal] Move most of Control.Monad to Control.Applicative References: <07248FD7-D6FD-4BD1-8C7D-9C30E326585D@gmail.com> <20090320230222.35567b6c@solaris> Message-ID: <20090321000352.5aefcaad@solaris> Conal Elliott wrote: > Exactly. and <*>, liftA, liftA2, ... > I think it's safe to say that there's a general consensus that Functor not being a superclass of Monad is a regrettable historical ward that ought to be fixed... the problem with fixing it is that it opens up a whole can of worms, only starting with whether or not Pointed should be a class by itself: While the Proper Way might be to include all of category-extras in the Prelude, the Proper Way might not at all be the Right Way. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From lennart at augustsson.net Fri Mar 20 19:03:23 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Mar 20 18:51:09 2009 Subject: Specific denotations for pure types In-Reply-To: <20090320231707.64ced36e@solaris> References: <20090320231707.64ced36e@solaris> Message-ID: Int provides minimum of -2^29..2^29-1, and as far as I know the overflow/underflow semantics is implementation dependent. Personally, I try to use Integer, unless I'm forced to use Int. -- Lennart On Fri, Mar 20, 2009 at 11:17 PM, Achim Schneider wrote: > Conal Elliott wrote: > >> I'd always assumed that pure (non-imperative) types have >> specific denotational models, so that for instance the denotation of >> something of type Int is either bottom or a (smallish) integer. >> > IIRC, Ints provide signed modulo at-least-31 bits arithmetic, which is a > clearly defined, but still utterly under-specified semantic. The idea > is that if you want to be safe, you can just use Integer and only be > bounded by the implementation's address width and swap space (I heard > that Integers break at MAX_INT^MAX_INT). The other idea is that Int is > a number type small enough to be as fast as possible, which, in > practise, means "fits into a register, together with some tag", which > excuses Int's existence where Int32 and Int64 are around. > > I'm all for defaulting to Integer and providing Natural (as an > potentially-unbounded alternative to Nat, which'd be one bit wider than > Int)... the (usually meagre) performance gains you can get by choosing > Int over Integer are worth an explicit type annotation, and with > Integer, you get non-modulo semantics, by default. Is that what you > want? > > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From conal at conal.net Fri Mar 20 19:38:26 2009 From: conal at conal.net (Conal Elliott) Date: Fri Mar 20 19:26:11 2009 Subject: Specific denotations for pure types In-Reply-To: <20090320235118.3c51403e@solaris> References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> Message-ID: On Fri, Mar 20, 2009 at 3:51 PM, Achim Schneider wrote: > Conal Elliott wrote: > > > Even the denotation of Bool & () are influenced > > by the denotation of Int, since Bool & () expressions can contain Int > > expressions. > > > Now you've lost me... they definitely shouldn't be. Otherwise, I could > be equally well coding in C. > > In my mind, there's somewhere the equivalent of > > data () = () > > and > > data Bool = True | False > > , which might, of course, be represented using machine-integers, but > have ADT semantics. Consider big :: Int big = 2147483647 dodgy :: Bool dodgy = big + 1 > big oops :: () oops = if dodgy then () else undefined Assuming compositional semantics, the meaning of oops depends on the meaning of dodgy, which depends on the meaning of big+1, which is implementation-dependent. So a semantic domain for Bool and even () would have to include the machine-dependence of Int, so that oops could mean a function from MachineInfo that returns () sometimes and bottom sometimes. If the denotations (semantic domains) for Bool and () didn't include this complexity, they wouldn't be rich enough to capture the machine-dependence of dodgy and oops. (I'm simplifying by saying "MachineInfo" and "machine-dependence", since apparently the semantics is not fully specified even for a given machine. For instance, the number of tag bits could vary from one compiler or compiler-release to another. Also, Lennart mentions that "as far as I know the overflow/underflow semantics is implementation dependent".) - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090320/4f7b9aa9/attachment.htm From barsoap at web.de Fri Mar 20 20:13:46 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Mar 20 20:00:43 2009 Subject: Specific denotations for pure types References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> Message-ID: <20090321011346.37438947@solaris> Conal Elliott wrote: > Consider > big :: Int > big = 2147483647 > dodgy :: Bool > dodgy = big + 1 > big > oops :: () > oops = if dodgy then () else undefined > > Assuming compositional semantics, the meaning of oops depends on the > meaning of dodgy, which depends on the meaning of big+1, which is > implementation-dependent. > yes, but dodgy isn't Bool, it's _a_ Bool. You're worried about the semantics of (>) :: Int -> Int -> Bool, (+) :: Int -> Int -> Int and that forall n > 0 . x + n > x doesn't hold for Int. There are infinitely many ways to get a Bool out of things that don't happen to be Int (not to mention infinitely many ways to get a Bool out of an Int in an architecture-independent manner), which makes me think it's quite err... fundamentalistic to generalise that forall Bool . MachineInfo -> Bool. In fact, if you can prove for a certain Bool that MachineInfo -> ThatBool, you (most likely) just found a bug in the program. Shortly put: All that dodginess is fine with me, as long as it isn't the only way. Defaulting to machine-independent semantics at the expense of performance would be a most sensible thing, and Conal seems to think _way_ too abstractly. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From conal at conal.net Fri Mar 20 20:56:11 2009 From: conal at conal.net (Conal Elliott) Date: Fri Mar 20 20:43:56 2009 Subject: Specific denotations for pure types In-Reply-To: <20090321011346.37438947@solaris> References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <20090321011346.37438947@solaris> Message-ID: > > yes, but dodgy isn't Bool, it's _a_ Bool. Right. dodgy is _a_ Bool, and therefore its meaning is an element of the meaning of Bool. If _any_ element of Bool (e.g. dodgy) has a machine-dependent meaning, then the meaning of Bool itself much have a complex enough structure to contain such an element. - Conal On Fri, Mar 20, 2009 at 5:13 PM, Achim Schneider wrote: > Conal Elliott wrote: > > > Consider > > big :: Int > > big = 2147483647 > > dodgy :: Bool > > dodgy = big + 1 > big > > oops :: () > > oops = if dodgy then () else undefined > > > > Assuming compositional semantics, the meaning of oops depends on the > > meaning of dodgy, which depends on the meaning of big+1, which is > > implementation-dependent. > > > yes, but dodgy isn't Bool, it's _a_ Bool. You're worried about the > semantics of (>) :: Int -> Int -> Bool, (+) :: Int -> Int -> Int and > that forall n > 0 . x + n > x doesn't hold for Int. There are > infinitely many ways to get a Bool out of things that don't happen to > be Int (not to mention infinitely many ways to get a Bool out of an > Int in an architecture-independent manner), which makes me think it's > quite err... fundamentalistic to generalise that forall Bool . > MachineInfo -> Bool. In fact, if you can prove for a certain Bool that > MachineInfo -> ThatBool, you (most likely) just found a bug in the > program. > > Shortly put: All that dodginess is fine with me, as long as it isn't > the only way. Defaulting to machine-independent semantics at the > expense of performance would be a most sensible thing, and Conal > seems to think _way_ too abstractly. > > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090320/08a886a2/attachment.htm From john at repetae.net Fri Mar 20 21:11:59 2009 From: john at repetae.net (John Meacham) Date: Fri Mar 20 20:59:44 2009 Subject: Specific denotations for pure types In-Reply-To: References: Message-ID: <20090321011159.GD11188@sliver.repetae.net> On Fri, Mar 20, 2009 at 12:02:15PM -0700, Conal Elliott wrote: > I just learned on #haskell that Int has implementation/machine-dependent > semantics. I'd always assumed that pure (non-imperative) types have > specific denotational models, so that for instance the denotation of > something of type Int is either bottom or a (smallish) integer. Since > precise & simple denotation is at the heart of how I think about > programming, and Haskell is my favorite language, I'm startled and > disappointed. I knew we didn't have a denotational semantics for Haskell, > but I'd previously assumed it was just a matter of working out the details. in jhc and ghc at least, they are expressed directly in haskell as standard data types with a single unboxed component. > data Int = I Bits32_ Where Bits32_ is a direct unboxed representation of a 32 bit quantity. The data declaration behaves just like any other haskell data declaration and hence follows the same lazy semantics. Of course, this may not help as you perhaps need to define the meaning of the unboxed value inside the Int box, but it at least seperates the 'lazy' aspect of Int from its underlying representation and primitives. John -- John Meacham - ?repetae.net?john? From conal at conal.net Fri Mar 20 21:31:20 2009 From: conal at conal.net (Conal Elliott) Date: Fri Mar 20 21:19:05 2009 Subject: Specific denotations for pure types In-Reply-To: <20090321011159.GD11188@sliver.repetae.net> References: <20090321011159.GD11188@sliver.repetae.net> Message-ID: On Fri, Mar 20, 2009 at 6:11 PM, John Meacham wrote: > On Fri, Mar 20, 2009 at 12:02:15PM -0700, Conal Elliott wrote: > > I just learned on #haskell that Int has implementation/machine-dependent > > semantics. I'd always assumed that pure (non-imperative) types have > > specific denotational models, so that for instance the denotation of > > something of type Int is either bottom or a (smallish) integer. Since > > precise & simple denotation is at the heart of how I think about > > programming, and Haskell is my favorite language, I'm startled and > > disappointed. I knew we didn't have a denotational semantics for > Haskell, > > but I'd previously assumed it was just a matter of working out the > details. > > in jhc and ghc at least, they are expressed directly in haskell as > standard data types with a single unboxed component. > > > data Int = I Bits32_ > > Where Bits32_ is a direct unboxed representation of a 32 bit quantity. The > data > declaration behaves just like any other haskell data declaration and > hence follows the same lazy semantics. Of course, this may not help as you > perhaps need to define the meaning of the unboxed value inside the Int > box, but it at least seperates the 'lazy' aspect of Int from its > underlying representation and primitives. > > John Oh -- not one version of Int for 32-bit execution and another version for 64-bit execution? Seen on #haskell today: > maxBound :: Int > 9223372036854775807 > - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090320/44ce7505/attachment.htm From john at repetae.net Fri Mar 20 22:55:22 2009 From: john at repetae.net (John Meacham) Date: Fri Mar 20 22:43:07 2009 Subject: Specific denotations for pure types In-Reply-To: References: <20090321011159.GD11188@sliver.repetae.net> Message-ID: <20090321025521.GE11188@sliver.repetae.net> On Fri, Mar 20, 2009 at 06:31:20PM -0700, Conal Elliott wrote: > Oh -- not one version of Int for 32-bit execution and another version for > 64-bit execution? Seen on #haskell today: > > > maxBound :: Int > > 9223372036854775807 Yeah, that is actually a difference between jhc and ghc, jhc always uses a 32 bit type for 'Int', while with ghc it follows the machines pointer size. But they do both implement it as a standard haskell data type with a single unboxed component. I used the jhc definition in my message as I couldn't remember the exact way ghc defined it off the top of my head. Although, I don't think any such user visible representation of Int or other basic types should be mandated by the standard, I think it can be useful as a way to express a portable denotational model for understanding what operations on these types mean. John -- John Meacham - ?repetae.net?john? From jon.fairbairn at cl.cam.ac.uk Sat Mar 21 05:49:17 2009 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sat Mar 21 05:37:13 2009 Subject: Specific denotations for pure types References: <20090321011159.GD11188@sliver.repetae.net> Message-ID: Conal Elliott writes: > Oh -- not one version of Int for 32-bit execution and another version for > 64-bit execution?? Seen on #haskell today: > > > maxBound :: Int > ?? 9223372036854775807 I've always been opposed to having Int "built in" (in contrast to having Int32 and Int64 defined in a library somewhere). It's much cleaner to have Integer as the language integer. A reference implementation of Int8 (for brevity!) could be written with (off the top of my head) data Int8 = Int8 !Bool !Bool !Bool !Bool !Bool !Bool !Bool !Bool which would specify the semantics exactly. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From lennart at augustsson.net Sat Mar 21 06:25:18 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat Mar 21 06:13:04 2009 Subject: Specific denotations for pure types In-Reply-To: References: <20090321011159.GD11188@sliver.repetae.net> Message-ID: I now think you've been right all along; Integer should have been the normal numeric type. Of course, Integer is also machine dependent, but you can have larger numbers before everything turns to bottom. The Int type would then be in a implementation dependent library, and would promise the best speed. And for types like Int8, Int16, etc, there should be a number of different types for each of them, because there are at least three different kinds of overflow semantics which are all useful. -- Lennart On Sat, Mar 21, 2009 at 10:49 AM, Jon Fairbairn wrote: > Conal Elliott writes: >> Oh -- not one version of Int for 32-bit execution and another version for >> 64-bit execution?? Seen on #haskell today: >> >> ? > maxBound :: Int >> ? ?? 9223372036854775807 > > I've always been opposed to having Int "built in" (in > contrast to having Int32 and Int64 defined in a library > somewhere). It's much cleaner to have Integer as the > language integer. A reference implementation of Int8 (for > brevity!) could be written with (off the top of my head) > > data Int8 = Int8 !Bool !Bool !Bool !Bool !Bool !Bool !Bool !Bool > > which would specify the semantics exactly. > > -- > J?n Fairbairn ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Jon.Fairbairn@cl.cam.ac.uk > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > From ganesh.sittampalam at credit-suisse.com Sat Mar 21 11:52:41 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sat Mar 21 11:40:47 2009 Subject: Specific denotations for pure types In-Reply-To: References: <20090320231707.64ced36e@solaris><20090320235118.3c51403e@solaris><20090321011346.37438947@solaris> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA95C@ELON17P32001A.csfb.cs-group.com> Are you proposing to ban all implementation-dependent behaviour everywhere in Haskell? (Or perhaps relegate it all to IO?) ________________________________ From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 21 March 2009 00:56 To: Achim Schneider Cc: haskell-prime@haskell.org Subject: Re: Specific denotations for pure types yes, but dodgy isn't Bool, it's _a_ Bool. Right. dodgy is _a_ Bool, and therefore its meaning is an element of the meaning of Bool. If _any_ element of Bool (e.g. dodgy) has a machine-dependent meaning, then the meaning of Bool itself much have a complex enough structure to contain such an element. - Conal On Fri, Mar 20, 2009 at 5:13 PM, Achim Schneider wrote: Conal Elliott wrote: > Consider > big :: Int > big = 2147483647 > dodgy :: Bool > dodgy = big + 1 > big > oops :: () > oops = if dodgy then () else undefined > > Assuming compositional semantics, the meaning of oops depends on the > meaning of dodgy, which depends on the meaning of big+1, which is > implementation-dependent. > yes, but dodgy isn't Bool, it's _a_ Bool. You're worried about the semantics of (>) :: Int -> Int -> Bool, (+) :: Int -> Int -> Int and that forall n > 0 . x + n > x doesn't hold for Int. There are infinitely many ways to get a Bool out of things that don't happen to be Int (not to mention infinitely many ways to get a Bool out of an Int in an architecture-independent manner), which makes me think it's quite err... fundamentalistic to generalise that forall Bool . MachineInfo -> Bool. In fact, if you can prove for a certain Bool that MachineInfo -> ThatBool, you (most likely) just found a bug in the program. Shortly put: All that dodginess is fine with me, as long as it isn't the only way. Defaulting to machine-independent semantics at the expense of performance would be a most sensible thing, and Conal seems to think _way_ too abstractly. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090321/f1058a1d/attachment.htm From conal at conal.net Sat Mar 21 14:15:20 2009 From: conal at conal.net (Conal Elliott) Date: Sat Mar 21 14:03:04 2009 Subject: Specific denotations for pure types In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B01ABA95C@ELON17P32001A.csfb.cs-group.com> References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <20090321011346.37438947@solaris> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95C@ELON17P32001A.csfb.cs-group.com> Message-ID: I'm suggesting that we have well-defined denotations for the pure types in Haskell, and that the various Haskell implementations be expected to implement those denotations. I'm fine with IO continuing to be the (non-denotational) "sin bin" until we find more appealing denotationally-founded replacements. I didn't answer your question as stated because I don't know what you include in "behaviour" for a functional program. I have operational associations with that word. - Conal On Sat, Mar 21, 2009 at 8:52 AM, Sittampalam, Ganesh < ganesh.sittampalam@credit-suisse.com> wrote: > Are you proposing to ban all implementation-dependent behaviour > everywhere in Haskell? (Or perhaps relegate it all to IO?) > > ------------------------------ > *From:* haskell-prime-bounces@haskell.org [mailto: > haskell-prime-bounces@haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 21 March 2009 00:56 > *To:* Achim Schneider > *Cc:* haskell-prime@haskell.org > *Subject:* Re: Specific denotations for pure types > > yes, but dodgy isn't Bool, it's _a_ Bool. > > > Right. dodgy is _a_ Bool, and therefore its meaning is an element of the > meaning of Bool. If _any_ element of Bool (e.g. dodgy) has a > machine-dependent meaning, then the meaning of Bool itself much have a > complex enough structure to contain such an element. > > - Conal > > On Fri, Mar 20, 2009 at 5:13 PM, Achim Schneider wrote: > >> Conal Elliott wrote: >> >> > Consider >> > big :: Int >> > big = 2147483647 >> > dodgy :: Bool >> > dodgy = big + 1 > big >> > oops :: () >> > oops = if dodgy then () else undefined >> > >> > Assuming compositional semantics, the meaning of oops depends on the >> > meaning of dodgy, which depends on the meaning of big+1, which is >> > implementation-dependent. >> > >> yes, but dodgy isn't Bool, it's _a_ Bool. You're worried about the >> semantics of (>) :: Int -> Int -> Bool, (+) :: Int -> Int -> Int and >> that forall n > 0 . x + n > x doesn't hold for Int. There are >> infinitely many ways to get a Bool out of things that don't happen to >> be Int (not to mention infinitely many ways to get a Bool out of an >> Int in an architecture-independent manner), which makes me think it's >> quite err... fundamentalistic to generalise that forall Bool . >> MachineInfo -> Bool. In fact, if you can prove for a certain Bool that >> MachineInfo -> ThatBool, you (most likely) just found a bug in the >> program. >> >> Shortly put: All that dodginess is fine with me, as long as it isn't >> the only way. Defaulting to machine-independent semantics at the >> expense of performance would be a most sensible thing, and Conal >> seems to think _way_ too abstractly. >> >> -- >> (c) this sig last receiving data processing entity. Inspect headers >> for copyright history. All rights reserved. Copying, hiring, renting, >> performance and/or quoting of this signature prohibited. >> >> >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-prime >> > > > > ============================================================================== > Please access the attached hyperlink for an important electronic > communications disclaimer: > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > > ============================================================================== > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090321/033dcbdb/attachment.htm From ganesh.sittampalam at credit-suisse.com Sat Mar 21 14:50:55 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Sat Mar 21 14:38:54 2009 Subject: Specific denotations for pure types In-Reply-To: References: <20090320231707.64ced36e@solaris><20090320235118.3c51403e@solaris><20090321011346.37438947@solaris><16442B752A06A74AB4D9F9A5FF076E4B01ABA95C@ELON17P32001A.csfb.cs-group.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B01ABA95F@ELON17P32001A.csfb.cs-group.com> I'm having trouble understanding the scope of what you're proposing. The Haskell standard defines various pure types, and it seems that you want all those types to be completely defined. But what about types that aren't in the Haskell standard? Are implementations allowed to add their own types too (e.g. Int under a new name) which are machine-dependent? If they do, then you can still make elements of Bool that are machine-dependent. ________________________________ From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 21 March 2009 18:15 To: Sittampalam, Ganesh Cc: Achim Schneider; haskell-prime@haskell.org Subject: Re: Specific denotations for pure types I'm suggesting that we have well-defined denotations for the pure types in Haskell, and that the various Haskell implementations be expected to implement those denotations. I'm fine with IO continuing to be the (non-denotational) "sin bin" until we find more appealing denotationally-founded replacements. I didn't answer your question as stated because I don't know what you include in "behaviour" for a functional program. I have operational associations with that word. - Conal On Sat, Mar 21, 2009 at 8:52 AM, Sittampalam, Ganesh wrote: Are you proposing to ban all implementation-dependent behaviour everywhere in Haskell? (Or perhaps relegate it all to IO?) ________________________________ From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 21 March 2009 00:56 To: Achim Schneider Cc: haskell-prime@haskell.org Subject: Re: Specific denotations for pure types yes, but dodgy isn't Bool, it's _a_ Bool. Right. dodgy is _a_ Bool, and therefore its meaning is an element of the meaning of Bool. If _any_ element of Bool (e.g. dodgy) has a machine-dependent meaning, then the meaning of Bool itself much have a complex enough structure to contain such an element. - Conal On Fri, Mar 20, 2009 at 5:13 PM, Achim Schneider wrote: Conal Elliott wrote: > Consider > big :: Int > big = 2147483647 > dodgy :: Bool > dodgy = big + 1 > big > oops :: () > oops = if dodgy then () else undefined > > Assuming compositional semantics, the meaning of oops depends on the > meaning of dodgy, which depends on the meaning of big+1, which is > implementation-dependent. > yes, but dodgy isn't Bool, it's _a_ Bool. You're worried about the semantics of (>) :: Int -> Int -> Bool, (+) :: Int -> Int -> Int and that forall n > 0 . x + n > x doesn't hold for Int. There are infinitely many ways to get a Bool out of things that don't happen to be Int (not to mention infinitely many ways to get a Bool out of an Int in an architecture-independent manner), which makes me think it's quite err... fundamentalistic to generalise that forall Bool . MachineInfo -> Bool. In fact, if you can prove for a certain Bool that MachineInfo -> ThatBool, you (most likely) just found a bug in the program. Shortly put: All that dodginess is fine with me, as long as it isn't the only way. Defaulting to machine-independent semantics at the expense of performance would be a most sensible thing, and Conal seems to think _way_ too abstractly. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ======================================================================== ====== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ======================================================================== ====== =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090321/1c7b4de2/attachment-0001.htm From barsoap at web.de Sat Mar 21 15:08:34 2009 From: barsoap at web.de (Achim Schneider) Date: Sat Mar 21 14:55:54 2009 Subject: Specific denotations for pure types References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <20090321011346.37438947@solaris> Message-ID: <20090321200834.0d97ab02@solaris> Conal Elliott wrote: > > > > yes, but dodgy isn't Bool, it's _a_ Bool. > > > Right. dodgy is _a_ Bool, and therefore its meaning is an element of > the meaning of Bool. If _any_ element of Bool (e.g. dodgy) has a > machine-dependent meaning, then the meaning of Bool itself much have a > complex enough structure to contain such an element. > Then, yes, every Haskell type depends on whatever any type depends on, and the only way for the denotations not to explode into one's face is to abstract away the fact that an expression forces its context upon its continuation. "MachineInfo ->" can be added by the denotation of function application, there's no need to have it inside Bool's denotation. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From conal at conal.net Sat Mar 21 15:31:02 2009 From: conal at conal.net (Conal Elliott) Date: Sat Mar 21 15:18:45 2009 Subject: Specific denotations for pure types In-Reply-To: <20090321200834.0d97ab02@solaris> References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <20090321011346.37438947@solaris> <20090321200834.0d97ab02@solaris> Message-ID: On Sat, Mar 21, 2009 at 12:08 PM, Achim Schneider wrote: > Conal Elliott wrote: > > > > > > > yes, but dodgy isn't Bool, it's _a_ Bool. > > > > > > Right. dodgy is _a_ Bool, and therefore its meaning is an element of > > the meaning of Bool. If _any_ element of Bool (e.g. dodgy) has a > > machine-dependent meaning, then the meaning of Bool itself much have a > > complex enough structure to contain such an element. > > > Then, yes, every Haskell type depends on whatever any type depends on, > and the only way for the denotations not to explode into one's face is > to abstract away the fact that an expression forces its context upon > its continuation. "MachineInfo ->" can be added by the denotation of > function application, there's no need to have it inside Bool's > denotation. Maybe what you're saying is that the meanings of the strictly boolean building blocks (True, False, &&, ||, not) don't do anything interesting with machine-info. They just pass it along in a totally standard way that can be abstracted out. If so, I agree. And still, dodgy does have type Bool, so the meaning of Bool (the corresponding semantic domain) must have room in it for the meaning of dodgy, i.e., for machine-dependence (and compiler-dependence). The principle I'm assuming is that the meaning of a well-typed expression inhabits the meaning of the expression's type. (BTW, this principle explains what's unsafe about unsafePerformIO.) - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090321/a6e4197a/attachment.htm From jake at pikewerks.com Mon Mar 23 10:54:38 2009 From: jake at pikewerks.com (Jake McArthur) Date: Mon Mar 23 10:42:12 2009 Subject: Specific denotations for pure types In-Reply-To: References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> Message-ID: <49C7A2AE.60005@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Conal Elliott wrote: | Consider | big :: Int | big = 2147483647 | dodgy :: Bool | dodgy = big + 1 > big | oops :: () | oops = if dodgy then () else undefined | | Assuming compositional semantics, the meaning of oops depends on the | meaning of dodgy, which depends on the meaning of big+1, which is | implementation-dependent. So a semantic domain for Bool and even () | would have to include the machine-dependence of Int, so that oops could | mean a function from MachineInfo that returns () sometimes and bottom | sometimes. If the denotations (semantic domains) for Bool and () didn't | include this complexity, they wouldn't be rich enough to capture the | machine-dependence of dodgy and oops. Since Bool's constructors are exported, we can define (>) anywhere, so I don't think it makes sense to consider (>) a part of Bool's semantics, no? - - Jake McArthur -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknHoq4ACgkQye5hVyvIUKkRugCghgh6qNqmpWvD5SQYX/8PzUws 0Y8AoM3qJS5RIzoEFbD2aN1rR6EdJWh9 =ozCQ -----END PGP SIGNATURE----- From conal at conal.net Mon Mar 23 11:54:07 2009 From: conal at conal.net (Conal Elliott) Date: Mon Mar 23 11:41:43 2009 Subject: Specific denotations for pure types In-Reply-To: <49C7A2AE.60005@pikewerks.com> References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <49C7A2AE.60005@pikewerks.com> Message-ID: > > ... so I don't think it makes sense to consider (>) a part of Bool's > semantics, no? A denotational semantic definition for a type (more traditionally, a syntactic category) have two parts: a semantic domain and a collection of *compositional* definitions for the building blocks of that type. ("Compositional" in that a construct is defined strictly in terms of the meanings of its components.) I think you're talking about the latter, while my complexity claim is about the former: What semantic model can we have for Bool, i.e. what is [[Bool]]? The model I'd like in a lazy functional language is the domain containing exactly three elements: true, false, and bottom (with the usual information ordering). Whatever the domain corresponding to Bool is, the denotation of every (well-formed) Bool expression is an element of that domain. The question I'm asking is this: Assuming compositional semantics, can [[Bool]] be this simple & customary three-value domain in the presence of an implementation-dependent [[Int]] (given that Int expressions can play a non-trivial role in Bool expressions)? (Now you might say that Bool is just a data type definition. If so, then rephrase the question in terms of simple data type definitions.) - Conal On Mon, Mar 23, 2009 at 7:54 AM, Jake McArthur wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Conal Elliott wrote: > | Consider > | big :: Int > | big = 2147483647 > | dodgy :: Bool > | dodgy = big + 1 > big > | oops :: () > | oops = if dodgy then () else undefined > | > | Assuming compositional semantics, the meaning of oops depends on the > | meaning of dodgy, which depends on the meaning of big+1, which is > | implementation-dependent. So a semantic domain for Bool and even () > | would have to include the machine-dependence of Int, so that oops could > | mean a function from MachineInfo that returns () sometimes and bottom > | sometimes. If the denotations (semantic domains) for Bool and () didn't > | include this complexity, they wouldn't be rich enough to capture the > | machine-dependence of dodgy and oops. > > Since Bool's constructors are exported, we can define (>) anywhere, so I > don't think it makes sense to consider (>) a part of Bool's semantics, no? > > - - Jake McArthur > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknHoq4ACgkQye5hVyvIUKkRugCghgh6qNqmpWvD5SQYX/8PzUws > 0Y8AoM3qJS5RIzoEFbD2aN1rR6EdJWh9 > =ozCQ > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090323/893bd929/attachment.htm From jake at pikewerks.com Mon Mar 23 12:34:03 2009 From: jake at pikewerks.com (Jake McArthur) Date: Mon Mar 23 12:21:31 2009 Subject: Specific denotations for pure types In-Reply-To: References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <49C7A2AE.60005@pikewerks.com> Message-ID: <49C7B9FB.6090201@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Conal Elliott wrote: | The question I'm asking is this: Assuming compositional semantics, can | [[Bool]] be this simple & customary three-value domain in the presence | of an implementation-dependent [[Int]] (given that Int expressions can | play a non-trivial role in Bool expressions)? As I understand it, your question might be reworded like this: If we can compose values of type (MachineInfo -> Int) to create a value of type (MachineInfo -> Bool), does that mean Bool is dependent on MachineInfo? To simplify the question, I would like to rephrase it further to ask whether the ability to construct any value of type (MachineInfo -> Bool) means that Bool is dependent on MachineInfo. My (uneducated) reaction is that this does not mean that Bool is dependent on MachineInfo any more than the ability to construct a value of type (forall a. a -> Bool) means that Bool is dependent on everything. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknHufsACgkQye5hVyvIUKnahACgq6JZLcSePAJ4RLylPyz3X2DC NwMAoLQilWKYfUf12BJhUle52bP/zM2J =NN7V -----END PGP SIGNATURE----- From conal at conal.net Mon Mar 23 12:39:14 2009 From: conal at conal.net (Conal Elliott) Date: Mon Mar 23 12:26:52 2009 Subject: Specific denotations for pure types In-Reply-To: <49C7B9FB.6090201@pikewerks.com> References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <49C7A2AE.60005@pikewerks.com> <49C7B9FB.6090201@pikewerks.com> Message-ID: Oh! I think there's a misunderstanding here. I'm not talking about MachineInfo as visible in the types. I'm talking about Int itself having a MachineInfo-dependent semantic model (something like MachineInfo -> Z, where MachineInfo, ->, and Z are *semantic* types, not Haskell types). Making my question more specific: Can (>) on Int be given a compositional semantics, i.e. a semantics as [[Int]] -> [[Int]] -> [[Bool]], where [[Int]] = MachineInfo -> Z and [[Bool]] = {bottom,false,true} (with the usual ordering)? - Conal On Mon, Mar 23, 2009 at 9:34 AM, Jake McArthur wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Conal Elliott wrote: > | The question I'm asking is this: Assuming compositional semantics, can > | [[Bool]] be this simple & customary three-value domain in the presence > | of an implementation-dependent [[Int]] (given that Int expressions can > | play a non-trivial role in Bool expressions)? > > As I understand it, your question might be reworded like this: If we can > compose values of type (MachineInfo -> Int) to create a value of type > (MachineInfo -> Bool), does that mean Bool is dependent on MachineInfo? > To simplify the question, I would like to rephrase it further to ask > whether the ability to construct any value of type (MachineInfo -> Bool) > means that Bool is dependent on MachineInfo. My (uneducated) reaction is > that this does not mean that Bool is dependent on MachineInfo any more > than the ability to construct a value of type (forall a. a -> Bool) > means that Bool is dependent on everything. > > - - Jake > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknHufsACgkQye5hVyvIUKnahACgq6JZLcSePAJ4RLylPyz3X2DC > NwMAoLQilWKYfUf12BJhUle52bP/zM2J > =NN7V > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090323/04d0e2d4/attachment-0001.htm From conal at conal.net Mon Mar 23 12:42:16 2009 From: conal at conal.net (Conal Elliott) Date: Mon Mar 23 12:29:58 2009 Subject: Specific denotations for pure types In-Reply-To: References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <49C7A2AE.60005@pikewerks.com> <49C7B9FB.6090201@pikewerks.com> Message-ID: And my own answer is "no". Otherwise, dodgy would have value true, false, or bottom, rather than the value true-or-false-depending-on-the-machine. On Mon, Mar 23, 2009 at 9:39 AM, Conal Elliott wrote: > Oh! I think there's a misunderstanding here. I'm not talking about > MachineInfo as visible in the types. I'm talking about Int itself having a > MachineInfo-dependent semantic model (something like MachineInfo -> Z, where > MachineInfo, ->, and Z are *semantic* types, not Haskell types). > > Making my question more specific: Can (>) on Int be given a compositional > semantics, i.e. a semantics as [[Int]] -> [[Int]] -> [[Bool]], where [[Int]] > = MachineInfo -> Z and [[Bool]] = {bottom,false,true} (with the usual > ordering)? > > - Conal > > > On Mon, Mar 23, 2009 at 9:34 AM, Jake McArthur wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Conal Elliott wrote: >> | The question I'm asking is this: Assuming compositional semantics, can >> | [[Bool]] be this simple & customary three-value domain in the presence >> | of an implementation-dependent [[Int]] (given that Int expressions can >> | play a non-trivial role in Bool expressions)? >> >> As I understand it, your question might be reworded like this: If we can >> compose values of type (MachineInfo -> Int) to create a value of type >> (MachineInfo -> Bool), does that mean Bool is dependent on MachineInfo? >> To simplify the question, I would like to rephrase it further to ask >> whether the ability to construct any value of type (MachineInfo -> Bool) >> means that Bool is dependent on MachineInfo. My (uneducated) reaction is >> that this does not mean that Bool is dependent on MachineInfo any more >> than the ability to construct a value of type (forall a. a -> Bool) >> means that Bool is dependent on everything. >> >> - - Jake >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAknHufsACgkQye5hVyvIUKnahACgq6JZLcSePAJ4RLylPyz3X2DC >> NwMAoLQilWKYfUf12BJhUle52bP/zM2J >> =NN7V >> -----END PGP SIGNATURE----- >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090323/2e9f54d9/attachment.htm From duncan.coutts at worc.ox.ac.uk Tue Mar 24 06:36:19 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Mar 24 06:23:52 2009 Subject: Specific denotations for pure types In-Reply-To: References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <20090321011346.37438947@solaris> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95C@ELON17P32001A.csfb.cs-group.com> Message-ID: <1237890979.22581.205.camel@localhost> On Sat, 2009-03-21 at 11:15 -0700, Conal Elliott wrote: > I'm suggesting that we have well-defined denotations for the pure > types in Haskell, and that the various Haskell implementations be > expected to implement those denotations. > > I'm fine with IO continuing to be the (non-denotational) "sin bin" > until we find more appealing denotationally-founded replacements. > > I didn't answer your question as stated because I don't know what you > include in "behaviour" for a functional program. I have operational > associations with that word. You're right of course, once we have one machine-dependent type then all of them are "infected" even simple things like Bool. The question is what should we do about it, if anything? A certain amount of machine dependent behaviour would seem to be useful. Even machine-dependent Int it's not in the H98 standard, implementations would want to add it as an efficiency extension and then we're back to the same place because one machine-dependent type infects all types. It doesn't even need machine dependent compilers. We've got plenty of libraries that have different "pure" semantics on different platforms. For example System.FilePath has a bunch of pure functions for manipulating file paths. We could construct a similar dodgy :: Bool example using functions from System.FilePath. As, Ganesh said, I'm not sure what we can actually do, unless you want to explain the denotation of everything with an extra (MachineInfo ->) context. Duncan From barsoap at web.de Tue Mar 24 08:36:01 2009 From: barsoap at web.de (Achim Schneider) Date: Tue Mar 24 08:23:50 2009 Subject: Specific denotations for pure types References: <20090320231707.64ced36e@solaris> <20090320235118.3c51403e@solaris> <20090321011346.37438947@solaris> <16442B752A06A74AB4D9F9A5FF076E4B01ABA95C@ELON17P32001A.csfb.cs-group.com> <1237890979.22581.205.camel@localhost> Message-ID: <20090324133601.566fbbdd@solaris> Duncan Coutts wrote: > The question is what should we do about it, if anything? A certain > amount of machine dependent behaviour would seem to be useful. Even > machine-dependent Int it's not in the H98 standard, implementations > would want to add it as an efficiency extension and then we're back to > the same place because one machine-dependent type infects all types. > I think defining a platform-independent core would be useful, not only from an engineering perspective. Having the semantics defined for the bulk of the language is better than having none or an unnecessarily complex one. If you then really want to, you can always instantiate the semantics to the platform you're using, adding Int and friends, but not delving down into the MachineInfo -> realm, which no implementation is going to use, anyway: I've yet to see a Haskell implementation that allows one program to be run across multiple processors of e.g. different bitsizes, and if it existed, it'd most likely limit any sane use to that platform-independent core. Thinking about GPU's, different FPE exception models and all that punk, I guess we'd have CReal as platform-independent, IEEEFloat/IEEEDouble as platform-independent-as-long-as-you-don't-blow-them-up, and Float/Double as not even necessarily providing IEEE semantics. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From bulat.ziganshin at gmail.com Sat Mar 28 04:54:47 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 04:47:08 2009 Subject: One more 'do' pattern Message-ID: <1873567438.20090328115447@gmail.com> Hello haskell-prime, as we know, the following code action x y >>= \v -> do can be shortened to following v <- action x y but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter: for list $ \element -> do ... or bracket createDialog destroyDialog $ \dialog -> do ... what about adding one more 'do' sugar that will allow to move variable name to the left, such as for element in list do or with dialog in bracket createDialog destroyDialog do or just element <-- for list do dialog <-- bracket createDialog destroyDialog do ? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From tom.davie at gmail.com Sat Mar 28 05:05:02 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Mar 28 04:52:30 2009 Subject: One more 'do' pattern In-Reply-To: <1873567438.20090328115447@gmail.com> References: <1873567438.20090328115447@gmail.com> Message-ID: <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> On 28 Mar 2009, at 09:54, Bulat Ziganshin wrote: > Hello haskell-prime, > > as we know, the following code > > action x y >>= \v -> do > > can be shortened to following > > v <- action x y > > > > but there is one more very popular 'do' pattern, with a 'do' block > passed as a parameter: > > for list $ \element -> do > ... > > or > > bracket createDialog destroyDialog $ \dialog -> do > ... > > > what about adding one more 'do' sugar that will allow to move > variable name to the left, such as > > for element in list do > or > with dialog in bracket createDialog destroyDialog do > > or just > > element <-- for list do > dialog <-- bracket createDialog destroyDialog do > > ? In all honesty, I find the idea of adding yet more "imperative" looking stuff to do notation an appalling idea. We already get problems because people read do notation and think it means "execute this in sequence" (see threads about lazy IO not doing what's expected for example). As an aside, while these are merely syntactic sugars, I find the idea of attacking the problem with syntax to be somewhat silly as well. This simply adds a special syntax for another couple of cases that crop up occasionally. What do we do when we have another, and another, and another, do we keep just adding more and more syntax? Bob From bulat.ziganshin at gmail.com Sat Mar 28 05:13:27 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 05:01:10 2009 Subject: One more 'do' pattern In-Reply-To: <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> Message-ID: <227849713.20090328121327@gmail.com> Hello Thomas, Saturday, March 28, 2009, 12:05:02 PM, you wrote: > In all honesty, I find the idea of adding yet more "imperative" > looking stuff to do notation an appalling idea. We already get > problems because people read do notation and think it means "execute > this in sequence" (see threads about lazy IO not doing what's expected > for example). well, people already have problems understanding haskell, not only 'do' statements > As an aside, while these are merely syntactic sugars, I find the idea > of attacking the problem with syntax to be somewhat silly as well. > This simply adds a special syntax for another couple of cases that > crop up occasionally. What do we do when we have another, and > another, and another, do we keep just adding more and more syntax? i'm just making industrial programming, with lots of imperative code and 'do' syntax (compared to imperative languages) is somewhat limited. so, what i want to have is better syntax. i don't have any idea whether semantics can be somewhat improved to fix those shortages -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From tom.davie at gmail.com Sat Mar 28 05:15:37 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Mar 28 05:03:04 2009 Subject: One more 'do' pattern In-Reply-To: <227849713.20090328121327@gmail.com> References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> Message-ID: On 28 Mar 2009, at 10:13, Bulat Ziganshin wrote: > Hello Thomas, > > Saturday, March 28, 2009, 12:05:02 PM, you wrote: > >> In all honesty, I find the idea of adding yet more "imperative" >> looking stuff to do notation an appalling idea. We already get >> problems because people read do notation and think it means "execute >> this in sequence" (see threads about lazy IO not doing what's >> expected >> for example). > > well, people already have problems understanding haskell, not only > 'do' > statements > >> As an aside, while these are merely syntactic sugars, I find the idea >> of attacking the problem with syntax to be somewhat silly as well. >> This simply adds a special syntax for another couple of cases that >> crop up occasionally. What do we do when we have another, and >> another, and another, do we keep just adding more and more syntax? > > i'm just making industrial programming, with lots of imperative code > and 'do' syntax (compared to imperative languages) is somewhat > limited. so, what i want to have is better syntax. i don't have any > idea whether semantics can be somewhat improved to fix those shortages I'm not sure why "industrial programming" means "programming not in a functional style". It certainly doesn't mean that where I work. Bob From bulat.ziganshin at gmail.com Sat Mar 28 05:24:19 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 05:12:06 2009 Subject: One more 'do' pattern In-Reply-To: References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> Message-ID: <1621434314.20090328122419@gmail.com> Hello Thomas, Saturday, March 28, 2009, 12:15:37 PM, you wrote: > I'm not sure why "industrial programming" means "programming not in a > functional style". It certainly doesn't mean that where I work. what kind of problems you are solving? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From tom.davie at gmail.com Sat Mar 28 05:34:05 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Mar 28 05:21:29 2009 Subject: One more 'do' pattern In-Reply-To: <1621434314.20090328122419@gmail.com> References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> <1621434314.20090328122419@gmail.com> Message-ID: <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> On 28 Mar 2009, at 10:24, Bulat Ziganshin wrote: > Hello Thomas, > > Saturday, March 28, 2009, 12:15:37 PM, you wrote: > >> I'm not sure why "industrial programming" means "programming not in a >> functional style". It certainly doesn't mean that where I work. > > what kind of problems you are solving? Large GUI applications doing lots of 3D rendering. Bob From bulat.ziganshin at gmail.com Sat Mar 28 05:38:54 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 05:26:34 2009 Subject: One more 'do' pattern In-Reply-To: <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> <1621434314.20090328122419@gmail.com> <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> Message-ID: <1997689445.20090328123854@gmail.com> Hello Thomas, Saturday, March 28, 2009, 12:34:05 PM, you wrote: >>> I'm not sure why "industrial programming" means "programming not in a >>> functional style". It certainly doesn't mean that where I work. >> >> what kind of problems you are solving? > Large GUI applications doing lots of 3D rendering. and you have written GUI in FP style? with trees, d&d support and so on? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From tom.davie at gmail.com Sat Mar 28 05:41:50 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Mar 28 05:29:16 2009 Subject: One more 'do' pattern In-Reply-To: <1997689445.20090328123854@gmail.com> References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> <1621434314.20090328122419@gmail.com> <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> <1997689445.20090328123854@gmail.com> Message-ID: On 28 Mar 2009, at 10:38, Bulat Ziganshin wrote: > Hello Thomas, > > Saturday, March 28, 2009, 12:34:05 PM, you wrote: > >>>> I'm not sure why "industrial programming" means "programming not >>>> in a >>>> functional style". It certainly doesn't mean that where I work. >>> >>> what kind of problems you are solving? > >> Large GUI applications doing lots of 3D rendering. > > and you have written GUI in FP style? with trees, d&d support and so > on? I haven't, I'm working on a different part of the app ? Peter Verswyvelen has though. Bob From bulat.ziganshin at gmail.com Sat Mar 28 05:52:43 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 05:40:27 2009 Subject: One more 'do' pattern In-Reply-To: References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> <1621434314.20090328122419@gmail.com> <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> <1997689445.20090328123854@gmail.com> Message-ID: <241418341.20090328125243@gmail.com> Hello Thomas, Saturday, March 28, 2009, 12:41:50 PM, you wrote: >> and you have written GUI in FP style? with trees, d&d support and so >> on? > I haven't, I'm working on a different part of the app ? Peter > Verswyvelen has though. :) the problem is that no GUI library except for gtk2hs supports d&d. and i think that no functional GUI library support trees too it's why i asked - you work on functional part of project and FP features are enough for your work. and you think that everything that you personally don't use should be omitted from haskell -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From tom.davie at gmail.com Sat Mar 28 05:55:39 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Mar 28 05:43:04 2009 Subject: One more 'do' pattern In-Reply-To: <241418341.20090328125243@gmail.com> References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> <1621434314.20090328122419@gmail.com> <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> <1997689445.20090328123854@gmail.com> <241418341.20090328125243@gmail.com> Message-ID: <119B6AE8-A2DB-414E-AB8E-BBC506146A6E@gmail.com> On 28 Mar 2009, at 10:52, Bulat Ziganshin wrote: > Hello Thomas, > > Saturday, March 28, 2009, 12:41:50 PM, you wrote: > >>> and you have written GUI in FP style? with trees, d&d support and so >>> on? > >> I haven't, I'm working on a different part of the app ? Peter >> Verswyvelen has though. > > :) the problem is that no GUI library except for gtk2hs supports d&d. > and i think that no functional GUI library support trees too > > it's why i asked - you work on functional part of project and FP > features are enough for your work. and you think that everything that > you personally don't use should be omitted from haskell And we can't possibly have written our own GUI library as part of the project? As it happens, this library binds on to Gtk2Hs, but that's a trivially small amount of code, and even there very little uses do notation. Bob From tom.davie at gmail.com Sat Mar 28 06:04:01 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Mar 28 05:51:25 2009 Subject: One more 'do' pattern In-Reply-To: <241418341.20090328125243@gmail.com> References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> <1621434314.20090328122419@gmail.com> <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> <1997689445.20090328123854@gmail.com> <241418341.20090328125243@gmail.com> Message-ID: On 28 Mar 2009, at 10:52, Bulat Ziganshin wrote: > Hello Thomas, > > Saturday, March 28, 2009, 12:41:50 PM, you wrote: > >>> and you have written GUI in FP style? with trees, d&d support and so >>> on? > >> I haven't, I'm working on a different part of the app ? Peter >> Verswyvelen has though. > > :) the problem is that no GUI library except for gtk2hs supports d&d. > and i think that no functional GUI library support trees too > > it's why i asked - you work on functional part of project and FP > features are enough for your work. and you think that everything that > you personally don't use should be omitted from haskell To get back on topic though... Here's *why* I don't want these specific things I wouldn't use added to haskell: ? The syntax gains very little over the nice consistent syntax we already have ? all you do is move a symbol a little to the left. ? For that small benefit we gain all these disadvantages ? The language gets harder to parse ? We gain more reserved words that we can't use in our programs ? We gain more corner cases that can't be explained simply using the basic rules of how application works in Haskell ? We gain a syntax that even more than previously indicates that things will be executed in order (which is a total lie) ? We encourage people to write code unnecessarily in an imperative style Hope that helps clarify why I'm objecting to this. Bob From bulat.ziganshin at gmail.com Sat Mar 28 06:14:00 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 06:10:34 2009 Subject: One more 'do' pattern In-Reply-To: <119B6AE8-A2DB-414E-AB8E-BBC506146A6E@gmail.com> References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> <1621434314.20090328122419@gmail.com> <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> <1997689445.20090328123854@gmail.com> <241418341.20090328125243@gmail.com> <119B6AE8-A2DB-414E-AB8E-BBC506146A6E@gmail.com> Message-ID: <948564825.20090328131400@gmail.com> Hello Thomas, Saturday, March 28, 2009, 12:55:39 PM, you wrote: > And we can't possibly have written our own GUI library as part of the > project? *you* can. i cannot. instead, i write a lot of code that implements features lacking in gtk2hs generally, i have very opposite positions in Haskell community and outside it some peoples say that i shouldn't use haskell because FP doesn't provide serious advantages over Java. they tend to consider anyone using Haskell as scientist other people say that i shouldn't use haskell if my usage doesn't fall into their idea of how it should be used but i just work. i deliver program to my users and using haskell for some its parts decrease time-to-market. if haskell will improve its 'do' syntax, it will reduce my development costs even more. just for comparison - something like GADT or AT or generics, while cute by itself, cannot help me at all -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sat Mar 28 06:21:00 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 06:10:36 2009 Subject: One more 'do' pattern In-Reply-To: References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> <1621434314.20090328122419@gmail.com> <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> <1997689445.20090328123854@gmail.com> <241418341.20090328125243@gmail.com> Message-ID: <1388276847.20090328132100@gmail.com> Hello Thomas, Saturday, March 28, 2009, 1:04:01 PM, you wrote: > To get back on topic though... Here's *why* I don't want these > specific things I wouldn't use added to haskell: > ? The syntax gains very little over the nice consistent syntax we > already have ? all you do is move a symbol a little to the left. main problem with lack-of-syntax is that we write "variables" at right: action x y >>= \v -> do action x y $ \v -> do another problem is all those funny "$\->do" one need to write > ? We encourage people to write code unnecessarily in an imperative > style i wonder at this argument. we make using 'do' simpler and this is bad thing? :) probably you should argue against invention monads at all - it's Wadler who added imperative features to this pure shine Haskell :D about syntax - i don't mean that i proposed something ideal i just want to figure out here one pattern of 'do' usage which i use quite often. imho, moving variables to the left would be good thing, exact syntax is a matter of debates -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From g9ks157k at acme.softbase.org Sat Mar 28 07:33:46 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sat Mar 28 07:21:48 2009 Subject: One more 'do' pattern In-Reply-To: <241418341.20090328125243@gmail.com> References: <1873567438.20090328115447@gmail.com> <241418341.20090328125243@gmail.com> Message-ID: <200903281233.46881.g9ks157k@acme.softbase.org> Am Samstag, 28. M?rz 2009 10:52 schrieb Bulat Ziganshin: > and i think that no functional GUI library support trees too The development version of Grapefruit already supports list views (and the derived concept of a set view) in a functional style. Tree views can be supported in a similar way. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Sat Mar 28 07:35:09 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sat Mar 28 07:23:09 2009 Subject: One more 'do' pattern In-Reply-To: <119B6AE8-A2DB-414E-AB8E-BBC506146A6E@gmail.com> References: <1873567438.20090328115447@gmail.com> <241418341.20090328125243@gmail.com> <119B6AE8-A2DB-414E-AB8E-BBC506146A6E@gmail.com> Message-ID: <200903281235.09945.g9ks157k@acme.softbase.org> Am Samstag, 28. M?rz 2009 10:55 schrieb Thomas Davie: > And we can't possibly have written our own GUI library as part of the > project? > > As it happens, this library binds on to Gtk2Hs, but that's a trivially > small amount of code, and even there very little uses do notation. And your library supports tree views in a functional way? I?d be interested to know how you do this. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Sat Mar 28 07:37:09 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sat Mar 28 07:25:09 2009 Subject: One more 'do' pattern In-Reply-To: <948564825.20090328131400@gmail.com> References: <1873567438.20090328115447@gmail.com> <119B6AE8-A2DB-414E-AB8E-BBC506146A6E@gmail.com> <948564825.20090328131400@gmail.com> Message-ID: <200903281237.09329.g9ks157k@acme.softbase.org> Am Samstag, 28. M?rz 2009 11:14 schrieb Bulat Ziganshin: > something like GADT or AT or generics, while cute by itself, cannot help me > at all GADTs and ATs help me a lot. There are practical things (like Grapefruit?s record system) that I couldn?t or wouldn?t want to do without these language extensions. Best wishes, Wolfgang From bulat.ziganshin at gmail.com Sat Mar 28 07:53:57 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 07:42:55 2009 Subject: One more 'do' pattern In-Reply-To: <200903281233.46881.g9ks157k@acme.softbase.org> References: <1873567438.20090328115447@gmail.com> <241418341.20090328125243@gmail.com> <200903281233.46881.g9ks157k@acme.softbase.org> Message-ID: <847690403.20090328145357@gmail.com> Hello Wolfgang, Saturday, March 28, 2009, 2:33:46 PM, you wrote: > The development version of Grapefruit already supports list views (and the > derived concept of a set view) in a functional style. Tree views can be > supported in a similar way. of course everything can be supported, but when you just need to do some work it's no more an argument than "everything may be implemented in Turing machine" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sat Mar 28 07:55:17 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 07:42:58 2009 Subject: One more 'do' pattern In-Reply-To: <200903281237.09329.g9ks157k@acme.softbase.org> References: <1873567438.20090328115447@gmail.com> <119B6AE8-A2DB-414E-AB8E-BBC506146A6E@gmail.com> <948564825.20090328131400@gmail.com> <200903281237.09329.g9ks157k@acme.softbase.org> Message-ID: <1465391922.20090328145517@gmail.com> Hello Wolfgang, Saturday, March 28, 2009, 2:37:09 PM, you wrote: > GADTs and ATs help me a lot. There are practical things (like Grapefruit?s > record system) that I couldn?t or wouldn?t want to do without these language > extensions. but not for me. strange, but i don't argue against them just because i don't know how to use them ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From g9ks157k at acme.softbase.org Sat Mar 28 08:03:42 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sat Mar 28 07:51:42 2009 Subject: One more 'do' pattern In-Reply-To: <1465391922.20090328145517@gmail.com> References: <1873567438.20090328115447@gmail.com> <200903281237.09329.g9ks157k@acme.softbase.org> <1465391922.20090328145517@gmail.com> Message-ID: <200903281303.42655.g9ks157k@acme.softbase.org> Am Samstag, 28. M?rz 2009 12:55 schrieb Bulat Ziganshin: > Hello Wolfgang, > > Saturday, March 28, 2009, 2:37:09 PM, you wrote: > > GADTs and ATs help me a lot. There are practical things (like > > Grapefruit?s record system) that I couldn?t or wouldn?t want to do > > without these language extensions. > > but not for me. strange, but i don't argue against them just because i > don't know how to use them ;) I just wanted to mention that they are useful. I didn?t want to claim that you disagree with that view. Best wishes, Wolfgang From tov at ccs.neu.edu Sat Mar 28 13:04:27 2009 From: tov at ccs.neu.edu (Jesse Tov) Date: Sat Mar 28 12:57:27 2009 Subject: One more 'do' pattern In-Reply-To: <1388276847.20090328132100@gmail.com> References: <1873567438.20090328115447@gmail.com> <709D4D0E-FC8C-4899-8C40-B0D0F8CB1199@gmail.com> <227849713.20090328121327@gmail.com> <1621434314.20090328122419@gmail.com> <14855927-5016-4644-BB42-8239CB7914A3@gmail.com> <1997689445.20090328123854@gmail.com> <241418341.20090328125243@gmail.com> <1388276847.20090328132100@gmail.com> Message-ID: Bulat Ziganshin wrote: >> ? The syntax gains very little over the nice consistent syntax we >> already have ? all you do is move a symbol a little to the left. > > action x y >>= \v -> do > action x y $ \v -> do One way to settle this kind of dispute would be a real macro system. Bulat could define and use the desired syntax without modifying the language definition in a way that would disturb others. Template Haskell is great for some things, but it's unsuitable and unsatisfying in a case like this. This is out of scope for Haskell', of course, but it's something the community should consider adding at some point. I've uploaded a package called preprocessor-tools[1] to Hackage that provides very quick-and-dirty syntax extension using a preprocessor. I used it to define a do-notation for parameterized monads, back before GHC supported that. At one point I used it to define syntax for a "continuation let", which binds the "result" of a CPS-style function [2]: clet P = E1 in E === E1 (\P -> E) I think this is what Bulat wants. (Bulat, if you want to try this, let me know and I'll try to resurrect the code.) Cheers, Jesse [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/preprocessor-tools [2] It seems to generalize nicely: clet P1 = E1 ... Pn = En in E === E1 (\P1 -> ... -> En (\Pn -> E) ... ) === flip runCont id $ do P1 <- Cont E1 ... Pn <- Cont En return E From conal at conal.net Sat Mar 28 16:54:55 2009 From: conal at conal.net (Conal Elliott) Date: Sat Mar 28 16:42:16 2009 Subject: One more 'do' pattern In-Reply-To: <1873567438.20090328115447@gmail.com> References: <1873567438.20090328115447@gmail.com> Message-ID: Hi Bulat, Do you have examples of usefulness your sugar for monads besides the one? Since "do" sugar is notation for general monadic programming, I wouldn't want to see it made more complex for the sake of just one monad. - Conal On Sat, Mar 28, 2009 at 1:54 AM, Bulat Ziganshin wrote: > Hello haskell-prime, > > as we know, the following code > > action x y >>= \v -> do > > can be shortened to following > > v <- action x y > > > > but there is one more very popular 'do' pattern, with a 'do' block > passed as a parameter: > > for list $ \element -> do > ... > > or > > bracket createDialog destroyDialog $ \dialog -> do > ... > > > what about adding one more 'do' sugar that will allow to move > variable name to the left, such as > > for element in list do > or > with dialog in bracket createDialog destroyDialog do > > or just > > element <-- for list do > dialog <-- bracket createDialog destroyDialog do > > ? > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090328/2d38ef84/attachment.htm From bulat.ziganshin at gmail.com Sat Mar 28 16:56:56 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 28 16:44:39 2009 Subject: One more 'do' pattern In-Reply-To: References: <1873567438.20090328115447@gmail.com> Message-ID: <1479221867.20090328235656@gmail.com> Hello Conal, Saturday, March 28, 2009, 11:54:55 PM, you wrote: no, i don't use other monads at all > Do you have examples of usefulness your sugar for monads besides > the one?? Since "do" sugar is notation for general monadic > programming, I wouldn't want to see it made more complex for the sake of just one monad. > > ? - Conal > On Sat, Mar 28, 2009 at 1:54 AM, Bulat Ziganshin > wrote: > Hello haskell-prime, > > as we know, the following code > > action x y >>= \v -> do > > can be shortened to following > > v <- action x y > > > > but there is one more very popular 'do' pattern, with a 'do' block > passed as a parameter: > > for list $ \element -> do > ?... > > or > > bracket createDialog destroyDialog $ \dialog -> do > ... > > > what about adding one more 'do' sugar that will allow to move > variable name to the left, such as > > for element in list do > or > with dialog in bracket createDialog destroyDialog do > > or just > > element <-- for list do > dialog <-- bracket createDialog destroyDialog do > > ? > > > -- > Best regards, > ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com