From silvio.frischi at gmail.com Sat Aug 1 02:36:55 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sat, 01 Aug 2015 04:36:55 +0200 Subject: [Haskell-cafe] Why is the no tuple syntax for sum types In-Reply-To: References: <55BA3C26.5010105@gmail.com> Message-ID: <55BC30C7.8070608@gmail.com> > For sum types you need a way to construct them and pattern match them. > Without a way to _name_ them, it would probably look like this: > > showError :: (Result | Error3 | Error8) -> String > showError (result ||) = "no error" > showError (| error3 |) = "error3: " ++ show error3 > showError (|| error8 |) = "error8: " ++ show error8 > > It's not the most readable code, so I'd generally avoid using it for > anything greater than 3 (same applies to tuples). I doubt that functions usually cause more than one or two different errors. Unless you count undefined, asyncronous ... But you don't want those in your type anyway (too verbose). > > It also suffers the same flaw as tuples: no way to extend them easily. > Imagine adding a new error: you have to edit _all_ of the patterns: > > showError :: (Result | Error3 | Error8 | Error11 ) -> String > showError (result |||) = "no error" > showError (| error3 ||) = "error3: " ++ show error3 > showError (|| error8 |) = "error8: " ++ show error8 > showError (||| error11 ) = "error11: " ++ show error11 > > Extensible records and variants might be able to solve these problems, > but that's a rabbit-hole of its own though. > Yes of course, but wouldn't you still agree that tuples are useful. So would sum tuples be. Additionally, tuple like structures can easily be simulated using type operators data a :' b = a :' b However, the pattern matching for even a 3-way sum type using Either will be a nightmare. And I see no way of simulating this without using Template Haskell. type ... a = a `Either` Int `Either` Char Left (Right int) ??? or Right (Left int) ??? Silvio From will.yager at gmail.com Sat Aug 1 03:56:48 2015 From: will.yager at gmail.com (William Yager) Date: Fri, 31 Jul 2015 20:56:48 -0700 Subject: [Haskell-cafe] Freeze/thaw fusion Message-ID: Has anyone done any research into fusing operations that involve thawing some data, mutating it, and then freezing it again? Data.Vector does something similar; it turns vectors into streams, operates on the streams, and then turns them back into vectors. It can fuse these operations by removing intermediate However, I've done a bit of preliminary work on a fusion system that works on operations of the form runST $ do x' <- thaw x foo x' freeze x' and yields promising results in some cases. This could be useful for data structures that aren't stream-able, but suffer from lots of unnecessary freezing and unfreezing. This seems like the sort of thing that someone would have already done, so I wanted to check if anyone knew of any previous work on this. Cheers, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanche at math.ntnu.no Sat Aug 1 07:32:06 2015 From: hanche at math.ntnu.no (Harald Hanche-Olsen) Date: Sat, 01 Aug 2015 09:32:06 +0200 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: Haskell Platform 7.10.2 In-Reply-To: References: <55BB206F.2090400@math.ntnu.no> Message-ID: <55BC75F6.9000107@math.ntnu.no> Brandon Allbery wrote: > On Fri, Jul 31, 2015 at 3:14 AM, Harald Hanche-Olsen > > wrote: >[?] > If I have understood correctly, in the upcoming OS X 10.11 [?] Uh, 11.0, I mean. > So perhaps the installer should be changed to install the binaries > elsewhere, such as /usr/local/bin? > > Mostly correct. I would argue against /usr/local though [?] Good point. > Many third party packages already use /opt, e.g. /opt/haskell or > /opt/haskell-platform. (See for example XQuartz or calibre.) Given the current use of /Library/Haskell, /opt/haskell seems the more consistent choice. ? Harald From goodingm at gmail.com Sat Aug 1 14:40:36 2015 From: goodingm at gmail.com (htebalaka) Date: Sat, 1 Aug 2015 07:40:36 -0700 (MST) Subject: [Haskell-cafe] Why is the no tuple syntax for sum types In-Reply-To: <55BC30C7.8070608@gmail.com> References: <55BA3C26.5010105@gmail.com> <55BC30C7.8070608@gmail.com> Message-ID: <1438440036193-5814758.post@n5.nabble.com> FWIW there's already a somewhat extensible way to do this with singletons, as shown here http://lpaste.net/137724. Could be made somewhat nicer with pattern synonyms as well. It does at least solver the pattern matching issue of nested Eithers. Silvio Frischknecht wrote >> For sum types you need a way to construct them and pattern match them. >> Without a way to _name_ them, it would probably look like this: >> >> showError :: (Result | Error3 | Error8) -> String >> showError (result ||) = "no error" >> showError (| error3 |) = "error3: " ++ show error3 >> showError (|| error8 |) = "error8: " ++ show error8 >> >> It's not the most readable code, so I'd generally avoid using it for >> anything greater than 3 (same applies to tuples). > > I doubt that functions usually cause more than one or two different > errors. Unless you count undefined, asyncronous ... But you don't want > those in your type anyway (too verbose). > >> >> It also suffers the same flaw as tuples: no way to extend them easily. >> Imagine adding a new error: you have to edit _all_ of the patterns: >> >> showError :: (Result | Error3 | Error8 | Error11 ) -> String >> showError (result |||) = "no error" >> showError (| error3 ||) = "error3: " ++ show error3 >> showError (|| error8 |) = "error8: " ++ show error8 >> showError (||| error11 ) = "error11: " ++ show error11 >> >> Extensible records and variants might be able to solve these problems, >> but that's a rabbit-hole of its own though. >> > > Yes of course, but wouldn't you still agree that tuples are useful. So > would sum tuples be. > > Additionally, tuple like structures can easily be simulated using type > operators > > data a :' b = a :' b > > However, the pattern matching for even a 3-way sum type using Either > will be a nightmare. And I see no way of simulating this without using > Template Haskell. > > type ... a = a `Either` Int `Either` Char > > Left (Right int) ??? > > or > > Right (Left int) ??? > > Silvio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/Why-is-the-no-tuple-syntax-for-sum-types-tp5814499p5814758.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From goodingm at gmail.com Sat Aug 1 15:25:16 2015 From: goodingm at gmail.com (htebalaka) Date: Sat, 1 Aug 2015 08:25:16 -0700 (MST) Subject: [Haskell-cafe] Type error depending on scope of pattern matching Message-ID: <1438442716770-5814762.post@n5.nabble.com> I'm curious if anyone can tell me why moving the pattern matching in these two examples makes it fail to compile, and what can be done to resolve the same issue in either of the latter two examples. As far as I can tell these should be equivalent. Unfortunately the solution used in the first examples won't work in the later ones due to the existential quantification. I've been asking on #haskell for a few days but haven't been able to find anyone who knows what the issue is. Code is available here: http://lpaste.net/137586 -- View this message in context: http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From amindfv at gmail.com Sat Aug 1 19:18:57 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 1 Aug 2015 15:18:57 -0400 Subject: [Haskell-cafe] Type error depending on scope of pattern matching In-Reply-To: <1438442716770-5814762.post@n5.nabble.com> References: <1438442716770-5814762.post@n5.nabble.com> Message-ID: You'll probably get more responses if you paste the code inline. tom El Aug 1, 2015, a las 11:25, htebalaka escribi?: > I'm curious if anyone can tell me why moving the pattern matching in these > two examples makes it fail to compile, and what can be done to resolve the > same issue in either of the latter two examples. As far as I can tell these > should be equivalent. Unfortunately the solution used in the first examples > won't work in the later ones due to the existential quantification. I've > been asking on #haskell for a few days but haven't been able to find anyone > who knows what the issue is. > > Code is available here: http://lpaste.net/137586 > > > > -- > View this message in context: http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From goodingm at gmail.com Sun Aug 2 00:05:24 2015 From: goodingm at gmail.com (htebalaka) Date: Sat, 1 Aug 2015 17:05:24 -0700 (MST) Subject: [Haskell-cafe] Type error depending on scope of pattern matching In-Reply-To: References: <1438442716770-5814762.post@n5.nabble.com> Message-ID: <1438473924808-5814778.post@n5.nabble.com> Alright. The first two examples show the issue and a fix for it; the last two have the same issue but existential quantification prevents the fix. grad has type "(Num a, Traversable t) => (forall s. Reifies s Tape => t (Reverse s a) -> Reverse s a) -> t a -> t a", and I'm basically trying to supply a function to it, either by being polymorphic over all Num (of which Reverse s a is an instance), or by providing the specific 'Reifies s Tape => ...' type, neither of which are working. amindfv wrote > You'll probably get more responses if you paste the code inline. > > tom > > El Aug 1, 2015, a las 11:25, htebalaka < > goodingm@ > > escribi?: > >> I'm curious if anyone can tell me why moving the pattern matching in >> these >> two examples makes it fail to compile, and what can be done to resolve >> the >> same issue in either of the latter two examples. As far as I can tell >> these >> should be equivalent. Unfortunately the solution used in the first >> examples >> won't work in the later ones due to the existential quantification. I've >> been asking on #haskell for a few days but haven't been able to find >> anyone >> who knows what the issue is. >> >> Code is available here: http://lpaste.net/137586 >> <http://lpaste.net/137586> >> >> >> >> -- >> View this message in context: >> http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762.html >> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >> _______________________________________________ >> Haskell-Cafe mailing list >> > Haskell-Cafe@ >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762p5814778.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From electreg at list.ru Sun Aug 2 12:09:08 2015 From: electreg at list.ru (=?UTF-8?B?QWxleGV5IEVnb3Jvdg==?=) Date: Sun, 02 Aug 2015 15:09:08 +0300 Subject: [Haskell-cafe] =?utf-8?q?atomicity_and_visibility_of_readIORef_/_?= =?utf-8?q?writeIORef?= Message-ID: <1438517348.564714747@f226.i.mail.ru> Hello haskellers, is there any guarantees of atomicity and visibility of read-write operations on IORefs, like Java have for volatile variables? From kane at kane.cx Sun Aug 2 12:34:13 2015 From: kane at kane.cx (David Kraeutmann) Date: Sun, 2 Aug 2015 14:34:13 +0200 Subject: [Haskell-cafe] atomicity and visibility of readIORef / writeIORef In-Reply-To: <1438517348.564714747@f226.i.mail.ru> References: <1438517348.564714747@f226.i.mail.ru> Message-ID: <55BE0E45.1060806@kane.cx> Check https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-IORef.html: "An atomicModifyIORef is never observed to take place ahead of any earlier (in program order) IORef operations, or after any later IORef operations." There are atomic variants of write/modifyIORef which place an appropriate memory barrier so that race conditions (like in the example on the bottom of the page) can't happen. On 8/2/2015 2:09 PM, Alexey Egorov wrote: > Hello haskellers, > > is there any guarantees of atomicity and visibility of read-write operations on IORefs, like Java have for volatile variables? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4291 bytes Desc: S/MIME Cryptographic Signature URL: From corentin.dupont at gmail.com Mon Aug 3 11:02:05 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Mon, 3 Aug 2015 13:02:05 +0200 Subject: [Haskell-cafe] happstack-authenticate 2 Message-ID: Hello, I'm a bit confused about the routeAuthenticate and authenticateState bits in the new happstack-authenticate. It seems that I have to do this in the beginning of my application: (_, routeAuthenticate, authenticateState) <- liftIO $ initAuthentication Nothing (const $ return True) [ initPassword "http://localhost:8000/#resetPassword" "example.org" , initOpenId] Where this should be done? In the main? If possible I'd prefer to delay it because my main is web-agnotic. Where should I store those two values? Should I put them in my monad stack (I have a StateT)? Is the routeAuthenticate really necessary? It looks a bit cumbersome to carry it around everywhere in the states. Thanks, Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2haskell at pkturner.org Mon Aug 3 11:44:39 2015 From: 2haskell at pkturner.org (Scott Turner) Date: Mon, 03 Aug 2015 07:44:39 -0400 Subject: [Haskell-cafe] Why is the no tuple syntax for sum types In-Reply-To: References: <55BA3C26.5010105@gmail.com> Message-ID: <55BF5427.2050407@pkturner.org> On 2015-07-31 18:44, Phil Ruffwind wrote: > For sum types you need a way to construct them and pattern match them. > Without a way to _name_ them, it would probably look like this: > > showError :: (Result | Error3 | Error8) -> String > showError (result ||) = "no error" > showError (| error3 |) = "error3: " ++ show error3 > showError (|| error8 |) = "error8: " ++ show error8 > > It's not the most readable code, so I'd generally avoid using it for > anything greater than 3 (same applies to tuples). This approach misses the essence of sum type tuples, which is positional. It needs to be something like showError :: (Result | Error3 | Error) -> String showError = case of result -> "no error" | error3 -> "error3: " ++ show error3 | error3 -> "error8: " ++ show error8 This is just to illustrate the overall structure that's needed. I don't think think the above "|" syntax would ever fit into Haskell, because it would be confused with pattern guards. From eir at cis.upenn.edu Mon Aug 3 11:52:27 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 3 Aug 2015 07:52:27 -0400 Subject: [Haskell-cafe] Type error depending on scope of pattern matching In-Reply-To: <1438473924808-5814778.post@n5.nabble.com> References: <1438442716770-5814762.post@n5.nabble.com> <1438473924808-5814778.post@n5.nabble.com> Message-ID: <4DACCFDD-5521-4A84-8F56-27BE6D0B7DBE@cis.upenn.edu> And what's Reverse? I happen to know Reifies. But you'll also get a better (and more likely) answer if you reduce dependencies. Richard On Aug 1, 2015, at 8:05 PM, htebalaka wrote: > Alright. The first two examples show the issue and a fix for it; the last two > have the same issue but existential quantification prevents the fix. > > grad has type "(Num a, Traversable t) => (forall s. Reifies s Tape => t > (Reverse s a) -> Reverse s a) -> t a -> t a", and I'm basically trying to > supply a function to it, either by being polymorphic over all Num (of which > Reverse s a is an instance), or by providing the specific 'Reifies s Tape => > ...' type, neither of which are working. > > > > > amindfv wrote >> You'll probably get more responses if you paste the code inline. >> >> tom >> >> El Aug 1, 2015, a las 11:25, htebalaka < > >> goodingm@ > >> > escribi?: >> >>> I'm curious if anyone can tell me why moving the pattern matching in >>> these >>> two examples makes it fail to compile, and what can be done to resolve >>> the >>> same issue in either of the latter two examples. As far as I can tell >>> these >>> should be equivalent. Unfortunately the solution used in the first >>> examples >>> won't work in the later ones due to the existential quantification. I've >>> been asking on #haskell for a few days but haven't been able to find >>> anyone >>> who knows what the issue is. >>> >>> Code is available here: http://lpaste.net/137586 >>> <http://lpaste.net/137586> >>> >>> >>> >>> -- >>> View this message in context: >>> http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762.html >>> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> > >> Haskell-Cafe@ > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> _______________________________________________ >> Haskell-Cafe mailing list > >> Haskell-Cafe@ > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > -- > View this message in context: http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762p5814778.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From jake.mcarthur at gmail.com Mon Aug 3 12:27:41 2015 From: jake.mcarthur at gmail.com (Jake McArthur) Date: Mon, 03 Aug 2015 12:27:41 +0000 Subject: [Haskell-cafe] Freeze/thaw fusion In-Reply-To: References: Message-ID: Vector also does something like what your are describing. I think the phrase to google for is "array recycling". On 11:56PM, Fri, Jul 31, 2015 William Yager wrote: > Has anyone done any research into fusing operations that involve thawing > some data, mutating it, and then freezing it again? > > Data.Vector does something similar; it turns vectors into streams, > operates on the streams, and then turns them back into vectors. It can fuse > these operations by removing intermediate However, I've done a bit of > preliminary work on a fusion system that works on operations of the form > > runST $ do > x' <- thaw x > foo x' > freeze x' > > and yields promising results in some cases. This could be useful for data > structures that aren't stream-able, but suffer from lots of unnecessary > freezing and unfreezing. > > This seems like the sort of thing that someone would have already done, so > I wanted to check if anyone knew of any previous work on this. > > Cheers, > Will > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zemyla at gmail.com Mon Aug 3 14:04:46 2015 From: zemyla at gmail.com (Zemyla) Date: Mon, 3 Aug 2015 09:04:46 -0500 Subject: [Haskell-cafe] Different forms for RandomT? In-Reply-To: <55BA698D.9090806@ro-che.info> References: <55BA698D.9090806@ro-che.info> Message-ID: It occurs to me that this would be best done by a specific method, like: interleaveRandom :: (Monad m, RandomGen g) => StateT g m a -> StateT g m a interleaveRandom (StateT m) = StateT $ \g -> let (gl, gr) = split g in liftM (\p -> (fst p, gr)) $ m gl It'd act like unsafeInterleaveIO and unsafeInterleaveST, but it'd be safe, and you would know when it actually was splitting. On Jul 30, 2015 1:15 PM, "Roman Cheplyaka" wrote: > On 30/07/15 20:38, Zemyla wrote: > > Normally, a monad transformer to provide a random number generator would > > be of the form StateT g, where g is a RandomGen. But I've seen some > > libraries (like QuickCheck) define their RandomT as: > > > > newtype RandomT g m a = RandomT { runRandomT :: g -> m a } > > > > with their monadic bind operation defined as > > > > (RandomT m) >>= f = RandomT $ \g -> let (ga, gb) = split g in m ga >>= > > (\a -> runRandomT (f a) gb) > > > > and return and fail as in ReaderT. > > > > Can someone describe the advantages and disadvantages of doing RandomT > > this way? I mean, if your generator has a subpar split operation (and > > most do), this will obviously exacerbate any problems with it. > > tf-random addresses this. > > > Does it give any comparable advantages? > > It doesn't introduce data dependencies. Let's say you generate a random > binary tree. With the split approach, you can take the right subtree > without evaluating the left one. > > Roman > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at iankduncan.com Mon Aug 3 14:18:38 2015 From: ian at iankduncan.com (Ian Duncan) Date: Mon, 3 Aug 2015 10:18:38 -0400 Subject: [Haskell-cafe] Freeze/thaw fusion In-Reply-To: References: Message-ID: On August 3, 2015 at 8:28:02 AM, Jake McArthur (jake.mcarthur at gmail.com) wrote: Vector also does something like what your are describing. I think the phrase to google for is "array recycling". On 11:56PM, Fri, Jul 31, 2015?William Yager wrote: Has anyone done any research into fusing operations that involve thawing some data, mutating it, and then freezing it again? Data.Vector does something similar; it turns vectors into streams, operates on the streams, and then turns them back into vectors. It can fuse these operations by removing intermediate ?However, I've done a bit of preliminary work on a fusion system that works on operations of the form? ? ? runST $ do? ? ? ? ? x' <- thaw x ? ? ? ? foo x' ? ? ? ? freeze x' and yields promising results in some cases. This could be useful for data structures that aren't stream-able, but suffer from lots of unnecessary freezing and unfreezing.? This seems like the sort of thing that someone would have already done, so I wanted to check if anyone knew of any previous work on this. Cheers, Will _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________? Haskell-Cafe mailing list? Haskell-Cafe at haskell.org? http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe? I?d be interested in knowing about the preliminary work you?re doing here. I?ve got a port of Clojure?s persistent vectors (pvector for short) in development right now, and I?m working on figuring out how to batch consecutive pure modifications of a pvector into doing cheaper operations on the mutable version before converting it into the immutable version again. Here are the operations scenarios that I?m especially interested in optimizing this way: {- each of these requires cloning a 32-element array. optimizing consecutive snocs is important because fromList is defined as (foldl' snoc empty) -} update1 :: Vector a -> Int -> a -> Vector a snoc :: Vector a -> a -> Vector a unsnoc :: Vector a -> Maybe (a, Vector a) {- requires cloning <= N/32 arrays, where N is length of update batch -} update :: Vector a -> Vector (Int, a) -> Vector a {- would be nice to preallocate a fully-sized pvector for consecutive concats. for example (\vs -> foldr concat empty vs) -} concat :: Vector a -> Vector a -> Vector a I only just started working on freeze/thaw fusion myself, so I haven?t gotten far at all. One trick that I?ve got in place in the transient structure to make this cheaper though is how I track modifications of the persistent vector. The immutable version is represented like so: data Node a = Leaf !(Array a) {- Array here from primitive package -} | Branch !(Array (Node a)) | EmptyNode data Vector a = Vector { vCount :: !Int , vShift :: !Int , vRoot :: !(Node a) , vTail :: !(Array a) , vTailCount :: !Int } And then here?s the transient version: data TransientNode s a = UneditedLeaf !(Array a) | UneditedBranch !(Array (Node a)) | EditedLeaf !(MutableArray s a) | EditedBranch !(MutableArray s (TransientNode s a)) | EmptyTransientNode data TransientVector s a = TransientVector { tvCount :: !Int , tvShift :: !Int , tvRoot :: !(TransientNode s a) , tvTail :: !(MutableArray s a) , tvTailEdited :: !Bool , tvTailCount :: !Int } When the persistent version is converted to the transient version, the data structure tracks which children have been modified over the course of operations on the transient structure. So, when the mutable version is converted back into the persistent version, any of the underlying arrays which haven?t been touched are still shared with any of the other live pvectors that are referencing them. That?s not specifically relevant to fusion, but it does make it quite cheap to go roundtrip from persistent->transient->persistent again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at iankduncan.com Mon Aug 3 14:22:49 2015 From: ian at iankduncan.com (Ian Duncan) Date: Mon, 3 Aug 2015 10:22:49 -0400 Subject: [Haskell-cafe] Freeze/thaw fusion In-Reply-To: References: Message-ID: On Mon, Aug 3, 2015 at 10:18 AM, Ian Duncan wrote: > On August 3, 2015 at 8:28:02 AM, Jake McArthur (jake.mcarthur at gmail.com) > wrote: > > Vector also does something like what your are describing. I think the phrase > to google for is "array recycling". > > > On 11:56PM, Fri, Jul 31, 2015 William Yager wrote: >> >> Has anyone done any research into fusing operations that involve thawing >> some data, mutating it, and then freezing it again? >> >> Data.Vector does something similar; it turns vectors into streams, >> operates on the streams, and then turns them back into vectors. It can fuse >> these operations by removing intermediate However, I've done a bit of >> preliminary work on a fusion system that works on operations of the form >> >> runST $ do >> x' <- thaw x >> foo x' >> freeze x' >> >> and yields promising results in some cases. This could be useful for data >> structures that aren't stream-able, but suffer from lots of unnecessary >> freezing and unfreezing. >> >> This seems like the sort of thing that someone would have already done, so >> I wanted to check if anyone knew of any previous work on this. >> >> Cheers, >> Will >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Sorry, I know I already sent this once, but it looks like the formatting got a little weird, so for anyone who couldn't read it before, I'll try this again: I?d be interested in knowing about the preliminary work you?re doing here. I?ve got a port of Clojure?s persistent vectors (pvector for short) in development right now, and I?m working on figuring out how to batch consecutive pure modifications of a pvector into doing cheaper operations on the mutable version before converting it into the immutable version again. Here are the operations scenarios that I?m especially interested in optimizing this way: {- each of these requires cloning a 32-element array. optimizing consecutive snocs is important because fromList is defined as (foldl' snoc empty) -} update1 :: Vector a -> Int -> a -> Vector a snoc :: Vector a -> a -> Vector a unsnoc :: Vector a -> Maybe (a, Vector a) {- requires cloning <= N/32 arrays, where N is length of update batch -} update :: Vector a -> Vector (Int, a) -> Vector a {- would be nice to preallocate a fully-sized pvector for consecutive concats. for example (\vs -> foldr concat empty vs) -} concat :: Vector a -> Vector a -> Vector a I only just started working on freeze/thaw fusion myself, so I haven?t gotten far at all. One trick that I?ve got in place in the transient structure to make this cheaper though is how I track modifications of the persistent vector. The immutable version is represented like so: data Node a = Leaf !(Array a) {- Array here from primitive package -} | Branch !(Array (Node a)) | EmptyNode data Vector a = Vector { vCount :: !Int , vShift :: !Int , vRoot :: !(Node a) , vTail :: !(Array a) , vTailCount :: !Int } And then here?s the transient version: data TransientNode s a = UneditedLeaf !(Array a) | UneditedBranch !(Array (Node a)) | EditedLeaf !(MutableArray s a) | EditedBranch !(MutableArray s (TransientNode s a)) | EmptyTransientNode data TransientVector s a = TransientVector { tvCount :: !Int , tvShift :: !Int , tvRoot :: !(TransientNode s a) , tvTail :: !(MutableArray s a) , tvTailEdited :: !Bool , tvTailCount :: !Int } When the persistent version is converted to the transient version, the data structure tracks which children have been modified over the course of operations on the transient structure. So, when the mutable version is converted back into the persistent version, any of the underlying arrays which haven?t been touched are still shared with any of the other live pvectors that are referencing them. From zemyla at gmail.com Mon Aug 3 15:02:25 2015 From: zemyla at gmail.com (Zemyla) Date: Mon, 3 Aug 2015 10:02:25 -0500 Subject: [Haskell-cafe] Typeclassable typeclass? In-Reply-To: References: Message-ID: I apologize if this has been discussed and dismissed before, but I figured with Typeable being made entirely automatic by GHC, this might have a shot at working. What if there were a typeclass called Typeclassable, whose definition would be: class (Typeable a) => Typeclassable a where typeClass :: (Typeable c) => proxy c -> proxy' a -> ((c a) => b) -> b -> b So, for a simple example, you might have: nubT :: (Typeclassable a, Eq a) => [a] -> [a] nubT ls = typeClass (Proxy :: Proxy Ord) ls (nubOrd ls) (nub ls) where nubOrd is a suitable implementation of nub that requires Ord a. Basically, my first thought for the implementation of Typeclassable is that it contains all the dictionaries for a in a hashtable, and searches through them with the typeRep of c. So: 1) Can this be implemented with GHC as it is now? 2) Could this be implemented at all with any reasonable amount of work? 3) Should this be implemented? Would the benefits outweigh the costs? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgorin at dc.uba.ar Mon Aug 3 15:09:10 2015 From: dgorin at dc.uba.ar (=?UTF-8?Q?Daniel_Gor=C3=ADn?=) Date: Mon, 03 Aug 2015 16:09:10 +0100 Subject: [Haskell-cafe] Different forms for RandomT? In-Reply-To: References: <55BA698D.9090806@ro-che.info> Message-ID: > Normally, a monad transformer to provide a random number generator > would be of the form StateT g, where g is a RandomGen. But I've seen > some libraries (like QuickCheck) define their RandomT as: > > newtype RandomT g m a = RandomT { runRandomT :: g -> m a } > > with their monadic bind operation defined as > > (RandomT m) >>= f = RandomT $ \g -> let (ga, gb) = split g in m ga >>= > (\a -> runRandomT (f a) gb) > > and return and fail as in ReaderT. > > Can someone describe the advantages and disadvantages of doing RandomT > this way? I mean, if your generator has a subpar split operation (and > most do), this will obviously exacerbate any problems > with it. Does > it give any comparable advantages? > A disadvantage is that it is too easy to end up with a monad that doesn?t respect the monad laws. For example, in the following, we expect ver_1 and ver_2 to be the same computation and yet their outputs differs... > import System.Random > > newtype RandomT g m a = RandomT { runRandomT :: g -> m a } > > instance (Monad m, RandomGen g) => Monad (RandomT g m) where > return = RandomT . const . return > (RandomT m) >>= f = RandomT $ \g -> > let (ga, gb) = split g > in m ga >>= (\a -> runRandomT (f a) gb) > > sample :: (RandomGen g, Monad m) => RandomT g m Int > sample = RandomT $ \g -> return (fst $ next g) > > main :: IO () > main = do > let probe m = runRandomT m (mkStdGen 42) > res_1 <- probe ver_1 > res_2 <- probe ver_2 > print (res_1,res_2) > where > ver_1 = sample > ver_2 = return () >> sample It is because of this that QuickCheck warns that "Gen is only morally a monad: two generators that are supposed to be equal will give the same probability distribution, but they might be different as functions from random number seeds to values.? [1]. You rarely notice this when using quickcheck... except perhaps if you are trying to debug or refactor a complex generator, and then good luck with that! [1] https://hackage.haskell.org/package/QuickCheck-2.8.1/docs/Test-QuickCheck-Gen-Unsafe.html From sean at functionaljobs.com Mon Aug 3 16:00:02 2015 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 3 Aug 2015 12:00:02 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <55bf900456dd2@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: OCaml server-side developer at Ahrefs Research http://functionaljobs.com/jobs/8827-ocaml-server-side-developer-at-ahrefs-research Cheers, Sean Murphy FunctionalJobs.com From goodingm at gmail.com Mon Aug 3 16:43:55 2015 From: goodingm at gmail.com (htebalaka) Date: Mon, 3 Aug 2015 09:43:55 -0700 (MST) Subject: [Haskell-cafe] Type error depending on scope of pattern matching In-Reply-To: <4DACCFDD-5521-4A84-8F56-27BE6D0B7DBE@cis.upenn.edu> References: <1438442716770-5814762.post@n5.nabble.com> <1438473924808-5814778.post@n5.nabble.com> <4DACCFDD-5521-4A84-8F56-27BE6D0B7DBE@cis.upenn.edu> Message-ID: <1438620235871-5814897.post@n5.nabble.com> I managed to remove the Data.Reflection and Numeric.AD dependency entirely. In this case, Reverse is just a newtyped Num with a phantom variable added. Still, the same issue occurs. In one case the type gets defaulted to Integer if I try to pass a "forall a. Num a => t a -> a" to grad (which has type "Num a, Traversable t => (forall s. t (Reverse s a) -> Reverse s a) -> t a -> t a"). Then it complains that Integer isn't Reverse s a, and won't compile. In the other where I try to specifically pass the a value with type "forall s. t (Reverse s a) -> Reverse s a" it think the type variable would escape its scope, but I don't see why it should, or how to prevent that in the "doesnt3" example. I have no idea how to apply the fix used in the first two examples to the later two, or why it should even be necessary. -- View this message in context: http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762p5814897.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From kane at kane.cx Mon Aug 3 17:03:15 2015 From: kane at kane.cx (David Kraeutmann) Date: Mon, 3 Aug 2015 19:03:15 +0200 Subject: [Haskell-cafe] Type error depending on scope of pattern matching In-Reply-To: <1438620235871-5814897.post@n5.nabble.com> References: <1438442716770-5814762.post@n5.nabble.com> <1438473924808-5814778.post@n5.nabble.com> <4DACCFDD-5521-4A84-8F56-27BE6D0B7DBE@cis.upenn.edu> <1438620235871-5814897.post@n5.nabble.com> Message-ID: <55BF9ED3.1070608@kane.cx> I guess that pattern matching on (P f) removes the universal quantification you placed on it and it just defaults to Integer. Seems to be related to https://ghc.haskell.org/trac/ghc/ticket/10450. On 8/3/2015 6:43 PM, htebalaka wrote: > I managed to remove the Data.Reflection and Numeric.AD dependency entirely. > In this case, Reverse is just a newtyped Num with a phantom variable added. > Still, the same issue occurs. In one case the type gets defaulted to Integer > if I try to pass a "forall a. Num a => t a -> a" to grad (which has type > "Num a, Traversable t => (forall s. t (Reverse s a) -> Reverse s a) -> t a > -> t a"). Then it complains that Integer isn't Reverse s a, and won't > compile. > > In the other where I try to specifically pass the a value with type "forall > s. t (Reverse s a) -> Reverse s a" it think the type variable would escape > its scope, but I don't see why it should, or how to prevent that in the > "doesnt3" example. > > I have no idea how to apply the fix used in the first two examples to the > later two, or why it should even be necessary. > > > > > > -- > View this message in context: http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762p5814897.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4291 bytes Desc: S/MIME Cryptographic Signature URL: From goodingm at gmail.com Mon Aug 3 18:30:27 2015 From: goodingm at gmail.com (htebalaka) Date: Mon, 3 Aug 2015 11:30:27 -0700 (MST) Subject: [Haskell-cafe] Type error depending on scope of pattern matching In-Reply-To: <55BF9ED3.1070608@kane.cx> References: <1438442716770-5814762.post@n5.nabble.com> <1438473924808-5814778.post@n5.nabble.com> <4DACCFDD-5521-4A84-8F56-27BE6D0B7DBE@cis.upenn.edu> <1438620235871-5814897.post@n5.nabble.com> <55BF9ED3.1070608@kane.cx> Message-ID: <1438626627505-5814910.post@n5.nabble.com> Yeah, that seems to be the issue, but pattern matching with let doesn't seem to work well with existentials, (GHC's brain explodes, and informs me to use a case statement), so the fix there doesn't seem to work either :( David Kraeutmann wrote > I guess that pattern matching on (P f) removes the universal > quantification you placed on it and it just defaults to Integer. Seems to > be related to https://ghc.haskell.org/trac/ghc/ticket/10450. > > On 8/3/2015 6:43 PM, htebalaka wrote: >> I managed to remove the Data.Reflection and Numeric.AD dependency >> entirely. >> In this case, Reverse is just a newtyped Num with a phantom variable >> added. >> Still, the same issue occurs. In one case the type gets defaulted to >> Integer >> if I try to pass a "forall a. Num a => t a -> a" to grad (which has type >> "Num a, Traversable t => (forall s. t (Reverse s a) -> Reverse s a) -> t >> a >> -> t a"). Then it complains that Integer isn't Reverse s a, and won't >> compile. >> >> In the other where I try to specifically pass the a value with type >> "forall >> s. t (Reverse s a) -> Reverse s a" it think the type variable would >> escape >> its scope, but I don't see why it should, or how to prevent that in the >> "doesnt3" example. >> >> I have no idea how to apply the fix used in the first two examples to the >> later two, or why it should even be necessary. >> >> >> >> >> >> -- >> View this message in context: >> http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762p5814897.html >> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >> _______________________________________________ >> Haskell-Cafe mailing list >> > Haskell-Cafe@ >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > smime.p7s (5K) > <http://haskell.1045720.n5.nabble.com/attachment/5814903/0/smime.p7s> -- View this message in context: http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762p5814910.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From goodingm at gmail.com Mon Aug 3 18:30:43 2015 From: goodingm at gmail.com (htebalaka) Date: Mon, 3 Aug 2015 11:30:43 -0700 (MST) Subject: [Haskell-cafe] Type error depending on scope of pattern matching In-Reply-To: <55BF9ED3.1070608@kane.cx> References: <1438442716770-5814762.post@n5.nabble.com> <1438473924808-5814778.post@n5.nabble.com> <4DACCFDD-5521-4A84-8F56-27BE6D0B7DBE@cis.upenn.edu> <1438620235871-5814897.post@n5.nabble.com> <55BF9ED3.1070608@kane.cx> Message-ID: <1438626643335-5814912.post@n5.nabble.com> Yeah, that seems to be the issue, but pattern matching with let doesn't seem to work well with existentials, (GHC's brain explodes, and informs me to use a case statement), so the fix there doesn't seem to work either :( David Kraeutmann wrote > I guess that pattern matching on (P f) removes the universal > quantification you placed on it and it just defaults to Integer. Seems to > be related to https://ghc.haskell.org/trac/ghc/ticket/10450. > > On 8/3/2015 6:43 PM, htebalaka wrote: >> I managed to remove the Data.Reflection and Numeric.AD dependency >> entirely. >> In this case, Reverse is just a newtyped Num with a phantom variable >> added. >> Still, the same issue occurs. In one case the type gets defaulted to >> Integer >> if I try to pass a "forall a. Num a => t a -> a" to grad (which has type >> "Num a, Traversable t => (forall s. t (Reverse s a) -> Reverse s a) -> t >> a >> -> t a"). Then it complains that Integer isn't Reverse s a, and won't >> compile. >> >> In the other where I try to specifically pass the a value with type >> "forall >> s. t (Reverse s a) -> Reverse s a" it think the type variable would >> escape >> its scope, but I don't see why it should, or how to prevent that in the >> "doesnt3" example. >> >> I have no idea how to apply the fix used in the first two examples to the >> later two, or why it should even be necessary. >> >> >> >> >> >> -- >> View this message in context: >> http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762p5814897.html >> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. >> _______________________________________________ >> Haskell-Cafe mailing list >> > Haskell-Cafe@ >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > smime.p7s (5K) > <http://haskell.1045720.n5.nabble.com/attachment/5814903/0/smime.p7s> -- View this message in context: http://haskell.1045720.n5.nabble.com/Type-error-depending-on-scope-of-pattern-matching-tp5814762p5814912.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From mc.schroeder at gmail.com Mon Aug 3 18:47:34 2015 From: mc.schroeder at gmail.com (=?UTF-8?Q?Michael_Schr=C3=B6der?=) Date: Mon, 3 Aug 2015 20:47:34 +0200 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: Async exceptions are now masked during the finalizer. Thanks again, David! In addition to my GHC fork [1], I?ve now also made a patch file [2], which should apply cleanly on any recent version of HEAD. Apparently it?s rather tricky to initialise a GitHub-cloned GHC fork, as I?ve discovered. The patch file should make it easier to play around with the extension. [1] https://github.com/mcschroeder/ghc [2] https://gist.github.com/mcschroeder/921eb3d50b2576a3e552 Cheers, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Aug 3 22:04:55 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 3 Aug 2015 18:04:55 -0400 Subject: [Haskell-cafe] Typeclassable typeclass? In-Reply-To: References: Message-ID: <2777C51B-92A1-457E-AE20-6B28230BC2B8@cis.upenn.edu> On Aug 3, 2015, at 11:02 AM, Zemyla wrote: > So: > 1) Can this be implemented with GHC as it is now? > No. > 2) Could this be implemented at all with any reasonable amount of work? > Depends on how reasonable you are. :) The problem is that this would require all of the instance tables and lookup machinery to be available at runtime. Currently, that stuff is around only at compile time. So this would be a big change. > 3) Should this be implemented? Would the benefits outweigh the costs? > I have a better idea of the costs than of the benefits here. The costs are non-trivial, to be sure. What are the benefits? It is an interesting idea, though! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Mon Aug 3 22:07:46 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 4 Aug 2015 10:07:46 +1200 Subject: [Haskell-cafe] Why is the no tuple syntax for sum types In-Reply-To: <55BF5427.2050407@pkturner.org> References: <55BA3C26.5010105@gmail.com> <55BF5427.2050407@pkturner.org> Message-ID: I'm a little puzzled by all of this, having learned ML before there was such a thing as Standard ML. Anonymous sums, with inl, inr, outl, outr and so on are one thing I was very happy to see the back of. This sudden enthusiasm for them strikes me as being like a sudden enthusiasm for punched cards, paper tape, or PL/I. From will.yager at gmail.com Tue Aug 4 04:01:20 2015 From: will.yager at gmail.com (William Yager) Date: Mon, 3 Aug 2015 21:01:20 -0700 Subject: [Haskell-cafe] Freeze/thaw fusion In-Reply-To: References: Message-ID: On Mon, Aug 3, 2015 at 7:18 AM, Ian Duncan wrote: > I?d be interested in knowing about the preliminary work you?re doing here. > The approach I've tested so far is boiled down into this (rather contrived) example: https://gist.github.com/wyager/df1809badc7c6a75cd5f Without optimization, each add1 adds about 0.37 seconds. With optimization, each add1 adds about 0.16 seconds. That's over twice as fast! Of course, this is very much a "lab environment". I suspect you might be able to make the rewrite rules better with a few tricks, but I haven't gotten around to testing them yet. --Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at n-heptane.com Tue Aug 4 04:20:19 2015 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Mon, 3 Aug 2015 23:20:19 -0500 Subject: [Haskell-cafe] happstack-authenticate 2 In-Reply-To: References: Message-ID: Hello, The tough problem that happstack-authenticate faces is that it has to be application agnostic. It doesn't really know much at all about how your application handles routing, how it deals with initializing and cleaning up database connections, etc. So, it all it can do is provide you with the functions you will need to initialize, route, and shutdown the authentication stuff. routeAuthentication is absolutely necessary -- how else would requests get routed to the authentication library? The authenticateState is provided in case you do want direct access to it, and so that you can pass it to routeAuthenticate. But you don't really need to carry it around everywhere -- you need only pass it to your routing layer. https://github.com/Happstack/happstack-authenticate/blob/master/demo/Main.hs You can see there that it passes the routeAuthentication function into a the 'implSite' in the routing monad. But the values are not stored in State or anything. In the example, everything is done in main :: IO (), because that is pretty much all the application does. In clckwrks, things are deferred until much later. In fact, the authentication layer in clckwrks is implemented as a clckwrks plugin. So, it does not initialize the authentication until it gets around to initializing the plugins: https://github.com/clckwrks/clckwrks/blob/master/Clckwrks/Authenticate/Plugin.hs - jeremy On Mon, Aug 3, 2015 at 6:02 AM, Corentin Dupont wrote: > Hello, > > I'm a bit confused about the routeAuthenticate and authenticateState bits > in the new happstack-authenticate. > > It seems that I have to do this in the beginning of my application: > > (_, routeAuthenticate, authenticateState) <- > liftIO $ initAuthentication Nothing (const $ return True) > [ initPassword "http://localhost:8000/#resetPassword" "example.org > " > , initOpenId] > > Where this should be done? In the main? If possible I'd prefer to delay it > because my main is web-agnotic. > Where should I store those two values? Should I put them in my monad stack > (I have a StateT)? > Is the routeAuthenticate really necessary? It looks a bit cumbersome to > carry it around everywhere in the states. > > Thanks, > Corentin > > -- > You received this message because you are subscribed to the Google Groups > "HAppS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to happs+unsubscribe at googlegroups.com. > To post to this group, send email to happs at googlegroups.com. > Visit this group at http://groups.google.com/group/happs. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From komendantskaya at gmail.com Tue Aug 4 09:29:46 2015 From: komendantskaya at gmail.com (Ekaterina Komendantskaya) Date: Tue, 4 Aug 2015 10:29:46 +0100 Subject: [Haskell-cafe] 2 PhD studentships in Computer Science at the University of Dundee Message-ID: Hello, School of Sciences and Engineering, University of Dundee, advertises two PhD studentships in the area of Computer Science. Applicants interested in Programming languages, Logic and Automated/Interactive theorem proving are encouraged. Further details are available here: https://docs.google.com/document/d/1ggi4S2DBS1IqB3fqyFBkKbrArYJRUiOybIfW7VdkG1w/edit?usp=sharing Best regards, Katya Ekaterina Komendantskaya Senior Lecturer, Head of PhD Studies Room 1.04, Queen Mother Building School of Computing, University of Dundee Scotland, DD14HN Tel: (+44) 01382384820 -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Tue Aug 4 10:51:13 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 4 Aug 2015 12:51:13 +0200 Subject: [Haskell-cafe] happstack-authenticate 2 In-Reply-To: References: Message-ID: I need to store authenticateState in the state because I use it latter to retrieve the user ID, name and email. So I created a new layer in my state structure to store both authenticateState and routeAuthentication. On Tue, Aug 4, 2015 at 6:20 AM, Jeremy Shaw wrote: > Hello, > > The tough problem that happstack-authenticate faces is that it has to be > application agnostic. It doesn't really know much at all about how your > application handles routing, how it deals with initializing and cleaning up > database connections, etc. So, it all it can do is provide you with the > functions you will need to initialize, route, and shutdown the > authentication stuff. > > routeAuthentication is absolutely necessary -- how else would requests get > routed to the authentication library? > > The authenticateState is provided in case you do want direct access to it, > and so that you can pass it to routeAuthenticate. But you don't really need > to carry it around everywhere -- you need only pass it to your routing > layer. > > > https://github.com/Happstack/happstack-authenticate/blob/master/demo/Main.hs > > You can see there that it passes the routeAuthentication function into a > the 'implSite' in the routing monad. But the values are not stored in State > or anything. > > In the example, everything is done in main :: IO (), because that is > pretty much all the application does. > > In clckwrks, things are deferred until much later. In fact, the > authentication layer in clckwrks is implemented as a clckwrks plugin. So, > it does not initialize the authentication until it gets around to > initializing the plugins: > > > https://github.com/clckwrks/clckwrks/blob/master/Clckwrks/Authenticate/Plugin.hs > > - jeremy > > On Mon, Aug 3, 2015 at 6:02 AM, Corentin Dupont > wrote: > >> Hello, >> >> I'm a bit confused about the routeAuthenticate and authenticateState >> bits in the new happstack-authenticate. >> >> It seems that I have to do this in the beginning of my application: >> >> (_, routeAuthenticate, authenticateState) <- >> liftIO $ initAuthentication Nothing (const $ return True) >> [ initPassword "http://localhost:8000/#resetPassword" " >> example.org" >> , initOpenId] >> >> Where this should be done? In the main? If possible I'd prefer to delay >> it because my main is web-agnotic. >> Where should I store those two values? Should I put them in my monad >> stack (I have a StateT)? >> Is the routeAuthenticate really necessary? It looks a bit cumbersome to >> carry it around everywhere in the states. >> >> Thanks, >> Corentin >> >> -- >> You received this message because you are subscribed to the Google Groups >> "HAppS" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to happs+unsubscribe at googlegroups.com. >> To post to this group, send email to happs at googlegroups.com. >> Visit this group at http://groups.google.com/group/happs. >> For more options, visit https://groups.google.com/d/optout. >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Tue Aug 4 14:38:43 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Tue, 4 Aug 2015 15:38:43 +0100 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: Ah, apologies, I missed this the first time around. Glad it helped. Cheers, David On 31 July 2015 at 19:12, Michael Schr?der wrote: > Ah, of course you're right, I forgot that masking /= completely > uninterruptible. And yes, it does seem like the finalizer needs to be > masked by default, in order to prevent the kind of race condition you > describe. Should be an easy change. Thanks for pointing that out! > > On 31 July 2015 at 15:06, David Turner > wrote: > >> Hi Michael, >> >> I wholeheartedly agreed that timeout n $ atomicallyWithIO ... is >> important, but that would generally work even if the finalizer ran masked >> wouldn't it? Most actions that block are interruptible. >> >> Put another way, I'd be interested to see how you could make serialize safe >> without this. Something like this: >> >> serialize :: [Operation d] -> DatabaseHandle d -> IO () >> serialize ops (DatabaseHandle _ h) = >> withMVar h (\h -> forM_ ops $ B.hPut h . runPut . safePut) >> `onException` >> magicalFileRollback h >> >> (ignoring the tedious implementation of magicalFileRollback) doesn't >> look quite right as if you got an async exception in the tiny window >> between onException exiting and serialize exiting then the STM >> transaction would roll back but the file wouldn't. I'm not convinced I >> totally understand async exceptions so if you (or anyone else) can point >> out why this works I'd be very grateful. >> >> Cheers, >> >> David >> >> >> >> >> On 31 July 2015 at 13:18, Michael Schr?der >> wrote: >> >>> Hi David, I appreciate your interest in my thesis! >>> >>> A finalizer which has non-atomic real-world effects needs to be quite >>>> careful about undoing those effects when exceptions are thrown. [...] If >>>> some of those B.hPut calls succeed but then one fails (e.g. the disk >>>> is full) then the transaction will be rolled back, but the on-disk state >>>> will be left partially written. >>>> >>> >>> Yes, you are absolutely right! The example application lacks some of the >>> safeguards one would expect in a production-ready system. It was intended >>> to be more of a demonstration of how easily one can in principle build a >>> database-like system on top of STM using finalizers. It still requires some >>> engineering effort to make it entirely safe and practical. I should have >>> documented this better?or just gone the extra mile and actually made it >>> safe! >>> >>> >>>> Even if the finalizer did include exception handling to deal with this >>>> situation, what happens with asynchronous exceptions? Does the finalizer >>>> run with async exceptions masked? >>>> >>> >>> The finalizer does not run with async exceptions masked and you're right >>> that one needs to be careful about how to deal with side-effects & async >>> exceptions & cleanup within the finalizer?just like with any kind of I/O, >>> really. In the TX example code, serialize should probably use >>> withMVarMasked instead of withMVar. But I don't think the finalizer >>> should run with async exceptions masked by default. There are uses cases >>> where you really do want the finalizer to be interruptible from another >>> thread, e.g. if you want to be able to timeout the whole transaction (STM >>> part + finalizer part, as in: timeout n $ atomicallyWithIO ...) >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acowley at seas.upenn.edu Tue Aug 4 16:22:07 2015 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Tue, 4 Aug 2015 12:22:07 -0400 Subject: [Haskell-cafe] Freeze/thaw fusion In-Reply-To: References: Message-ID: Back in 2010 I did some work to leverage freeze/thaw fusion in computer vision pipelines for a project at work. The aim was to speed up compositional style so that "foo . bar . baz" would be bracketed by a single thaw/freeze rather than a bracket around each function. The code lives on in my HOpenCV fork at , with the ugly fusing rewrites all here . I briefly spoke about the way this works at the NYHUG a while back. The relevant part of the video starts about 27 minutes in . Anthony On Fri, Jul 31, 2015 at 11:56 PM, William Yager wrote: > Has anyone done any research into fusing operations that involve thawing > some data, mutating it, and then freezing it again? > > Data.Vector does something similar; it turns vectors into streams, operates > on the streams, and then turns them back into vectors. It can fuse these > operations by removing intermediate However, I've done a bit of preliminary > work on a fusion system that works on operations of the form > > runST $ do > x' <- thaw x > foo x' > freeze x' > > and yields promising results in some cases. This could be useful for data > structures that aren't stream-able, but suffer from lots of unnecessary > freezing and unfreezing. > > This seems like the sort of thing that someone would have already done, so I > wanted to check if anyone knew of any previous work on this. > > Cheers, > Will > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From vogt.adam at gmail.com Tue Aug 4 20:02:32 2015 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 4 Aug 2015 16:02:32 -0400 Subject: [Haskell-cafe] Typeclassable typeclass? In-Reply-To: References: Message-ID: I think the same result could be done with template haskell, but probably some cases might not end up working the way they should. For example, what happens if the instance declaration needed is at the end of the file, what happens if we make c ~ Typeclassable [to use your name]? I have an incomplete sketch at I have a feeling that Typeclassable / IsInstance raises the same objections that OverlappingInstances does, since my TH code depends on that extension. Regards, Adam On Mon, Aug 3, 2015 at 11:02 AM, Zemyla wrote: > > I apologize if this has been discussed and dismissed before, but I figured with Typeable being made entirely automatic by GHC, this might have a shot at working. > > What if there were a typeclass called Typeclassable, whose definition would be: > > class (Typeable a) => Typeclassable a where > typeClass :: (Typeable c) => proxy c -> proxy' a -> ((c a) => b) -> b -> b > > So, for a simple example, you might have: > nubT :: (Typeclassable a, Eq a) => [a] -> [a] > nubT ls = typeClass (Proxy :: Proxy Ord) ls (nubOrd ls) (nub ls) > > where nubOrd is a suitable implementation of nub that requires Ord a. > > Basically, my first thought for the implementation of Typeclassable is that it contains all the dictionaries for a in a hashtable, and searches through them with the typeRep of c. > > So: > 1) Can this be implemented with GHC as it is now? > 2) Could this be implemented at all with any reasonable amount of work? > 3) Should this be implemented? Would the benefits outweigh the costs? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Tue Aug 4 20:51:36 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 4 Aug 2015 13:51:36 -0700 Subject: [Haskell-cafe] ANNOUNCE: Haskell Platform 7.10.2-a In-Reply-To: References: Message-ID: As promised in the Haskell Platform 7.10.2 announcement, we have now release Haskell Platform 7.10.2-a. The only changes from 7.10.2 are: text-1.2.1.3 - to work around the issue with text literals in GHC 7.10.2 fgl-5.5.2.1 - this release changes no APIs, but fixes builds with older GHCs Available, as always, from: https://www.haskell.org/platform/ - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From omari at smileystation.com Tue Aug 4 21:06:47 2015 From: omari at smileystation.com (Omari Norman) Date: Tue, 4 Aug 2015 17:06:47 -0400 Subject: [Haskell-cafe] ANNOUNCE: Haskell Platform 7.10.2-a In-Reply-To: References: Message-ID: Hi Mark, Thanks for all your hard work on Haskell Platform and for keeping it up to date. The webpage for Linux is recommending that people use distribution repositories. For instance, if I click Debian, it says something like "great news! Platform is in your repo. Type sudo apt-get install haskell-platform". I think this is bad advice. Most distribution packages will be out of date. Debian Stable is going to be hideously out of date. Maybe this issue has already been discussed? Offhand I can think of a few other solutions, but none of them are good. That's the nature of trying to tell someone how to install something on "Linux" when really there are dozens of different unique systems and architectures. I just think that an unvarnished "use your package manager" is not the best advice. Maybe add a disclaimer of "your repo might be old; use 'Generic' to get the latest"? For similar reasons I think it's bad advice to say under "Generic" "you should use one of the distribution-specific options listed on the right if possible." As a Debian Stable user, if I were interested in Platform at all I think I would be much better off avoiding the old one that's in the repository. Thanks, Omari On Tue, Aug 4, 2015 at 4:51 PM, Mark Lentczner wrote: > As promised in the Haskell Platform 7.10.2 announcement, we have now > release Haskell Platform 7.10.2-a. The only changes from 7.10.2 are: > > text-1.2.1.3 - to work around the issue with text literals in GHC 7.10.2 > fgl-5.5.2.1 - this release changes no APIs, but fixes builds with older > GHCs > > > Available, as always, from: https://www.haskell.org/platform/ > > - Mark > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Tue Aug 4 21:27:40 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 4 Aug 2015 14:27:40 -0700 Subject: [Haskell-cafe] ANNOUNCE: Haskell Platform 7.10.2-a In-Reply-To: References: Message-ID: I agree that the Linux text should be updated. I've shared this with the HP web team, and we'll try to update it in the next day or two. -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvio.frischi at gmail.com Wed Aug 5 09:13:17 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Wed, 05 Aug 2015 11:13:17 +0200 Subject: [Haskell-cafe] Why is the no tuple syntax for sum types In-Reply-To: References: <55BA3C26.5010105@gmail.com> <55BF5427.2050407@pkturner.org> Message-ID: <55C1D3AD.7010303@gmail.com> @Scott Turner This actually works surprisingly well with Either showError :: (Result `Either` Error3 `Either` Error) -> String showError = `mapSum3` (result -> "no error" ,error3 -> "error3: " ++ show error3 ,error3 -> "error8: " ++ show error8 ) mapSum3 :: (x `Either` y `Either` z) -> (x->a,y->a,z->a) -> a But sum tuples would look cooler still :) > I'm a little puzzled by all of this, having learned ML before there > was such a thing as Standard ML. Anonymous sums, with inl, inr, outl, > outr and so on are one thing I was very happy to see the back of. > This sudden enthusiasm for them strikes me as being like a sudden > enthusiasm for punched cards, paper tape, or PL/I. Either (and to some lesser extent Maybe) are an anonymous sum type and it is used all the time. I'm just saying it does not have the ideal syntax. P.S. The (a||) really conflicts with operators but (a;;) might actually still be possible. From ollie at ocharles.org.uk Wed Aug 5 10:28:38 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 5 Aug 2015 11:28:38 +0100 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings Message-ID: Hi all, I'm sure this has come up before, but a quick bit of Googling didn't reveal any prior discussions (if you known any, let me know), so I'm kicking off a new discussion. I find myself wanting to be able to say something like: foo = ... where import Something.Specific The result would be to import the contents of Something.Specific into the scope of foo and its other where bindings, but not import into the rest of the module that foo is defined in. As a motivating example, I'm currently working on building some HTML in Haskell, and the amount of symbols that come into scope is huge, when you have a DSL for both CSS and HTML - the real pain point being that you get symbols that often conflict. Here's an example of something that doesn't type-check currently image = img [ width 50, style [ width (px 50) ] ] width here is both a symbol in the HTML DSL and the CSS DSL, but to get this to type check I need to write something like image = img [ HTML.width 50, style [ CSS.width (CSS.px 50) ] ] That's not particularly bad here, the really pain is repeatedly having to do this for every single symbol I'm using. I'd prefer to be able to write image = let css = let import CSS in [ width (px 50) ] in let import HTML in img [ width 50, style css ] This is a little bit of a contrived rewrite, but hopefully it shows you what I'd like to be able to do. Please don't fixate too much on this example, it's only intended to illustrate the idea. When defining a large amount of inline styles I think this pays off - I import once to bring all the symbols I need into scope, rather than having to qualify every symbol. In reality, it will lead to me writing code like: myDocument = html where html = div [ style containerStyle ] [ div [ style rowStyle ] "Hello" , div [ style rowStyle ] "World!" ] where import HTML containerStyle = [ backgroundColor ..., padding ..., margin ... ] where import CSS rowStyle = [ backgroundColor ..., padding ..., margin ... ] where import CSS At present the suggestion is a syntax error, so I'm hoping that part won't be too controversial. Thoughts? *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Wed Aug 5 10:43:22 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Wed, 5 Aug 2015 11:43:22 +0100 Subject: [Haskell-cafe] Waiting for async exception (and nothing else) Message-ID: Hi, Is there an elegant way to have a thread wait for an async exception but nothing else? I tend to do something like forever $ threadDelay 1000000000 but this seems like a bit of a hack. Waiting on an otherwise-unused MVar or doing 'atomically retry' don't work because GHC kills them off straight away. The context is when using an API that only has a 'withMyThingy' wrapper and no explicit openMyThingy and closeMyThingy alternatives. Perhaps that's an API problem and the only way to work around this is with something a bit hacky? Cheers, -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Wed Aug 5 11:34:22 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Wed, 05 Aug 2015 14:34:22 +0300 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: Message-ID: <1438774462.2064.16.camel@gmail.com> Hello, Haskell definitely needs better namespace story, so +1. On Wed, 2015-08-05 at 11:28 +0100, Oliver Charles wrote: > Hi all, > > I'm sure this has come up before, but a quick bit of Googling didn't > reveal > any prior discussions (if you known any, let me know), so I'm kicking > off a > new discussion. Probably this blog post will be interesting for you: http://blog.haskell-exists.com/yuras/posts/namespaces-modules-qualified -imports-and-a-constant-pain.html > > I find myself wanting to be able to say something like: > > foo = ... > where import Something.Specific Then GHC will need to parse all the source code in order to build dependency tree. Also people may want to build dependency tree in their minds too, it is easier with global imports (in the module header.) What about the next: -- In the module header: import qualified Something.Specific as Specific ... -- Somewhere else: foo = ... where import Specific -- Note: importing by module alias Thanks, Yuras > > The result would be to import the contents of Something.Specific into > the > scope of foo and its other where bindings, but not import into the > rest of > the module that foo is defined in. As a motivating example, I'm > currently > working on building some HTML in Haskell, and the amount of symbols > that > come into scope is huge, when you have a DSL for both CSS and HTML - > the > real pain point being that you get symbols that often conflict. > > Here's an example of something that doesn't type-check currently > > image = > img [ width 50, style [ width (px 50) ] ] > > width here is both a symbol in the HTML DSL and the CSS DSL, but to > get > this to type check I need to write something like > > image = > img [ HTML.width 50, style [ CSS.width (CSS.px 50) ] ] > > That's not particularly bad here, the really pain is repeatedly > having to > do this for every single symbol I'm using. I'd prefer to be able to > write > > image = > let css = let import CSS in [ width (px 50) ] > in let import HTML in img [ width 50, style css ] > > This is a little bit of a contrived rewrite, but hopefully it shows > you > what I'd like to be able to do. Please don't fixate too much on this > example, it's only intended to illustrate the idea. When defining a > large > amount of inline styles I think this pays off - I import once to > bring all > the symbols I need into scope, rather than having to qualify every > symbol. > > In reality, it will lead to me writing code like: > > myDocument = html > where html = > div [ style containerStyle ] > [ div [ style rowStyle ] "Hello" > , div [ style rowStyle ] "World!" ] > where import HTML > containerStyle = > [ backgroundColor ..., padding ..., margin ... ] > where import CSS > rowStyle = > [ backgroundColor ..., padding ..., margin ... ] > where import CSS > > At present the suggestion is a syntax error, so I'm hoping that part > won't > be too controversial. > > Thoughts? > *ocharles* From ollie at ocharles.org.uk Wed Aug 5 11:39:42 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 05 Aug 2015 11:39:42 +0000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: <1438774462.2064.16.camel@gmail.com> References: <1438774462.2064.16.camel@gmail.com> Message-ID: On Wed, Aug 5, 2015 at 12:34 PM Yuras Shumovich wrote: > > I find myself wanting to be able to say something like: > > > > foo = ... > > where import Something.Specific > > Then GHC will need to parse all the source code in order to build > dependency tree. Also people may want to build dependency tree in their > minds too, it is easier with global imports (in the module header.) > What about the next: > > -- In the module header: > import qualified Something.Specific as Specific > ... > -- Somewhere else: > foo = ... > where import Specific -- Note: importing by module alias > I would rather we are able to use exactly the same features as global imports to reduce the cognitive burden of knowing what you can and can't do. If those responsible for GHC tell me that what I want is unrealistic then maybe we'll have to compromise, but right now I would rather not add limitations. *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From eleventynine at gmail.com Wed Aug 5 12:59:54 2015 From: eleventynine at gmail.com (Mike Ledger) Date: Wed, 5 Aug 2015 05:59:54 -0700 (PDT) Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <1438774462.2064.16.camel@gmail.com> Message-ID: <63a20f41-057e-4521-b1e3-0be4424aba01@googlegroups.com> This would be really handy to have. You could also have import "blocks", like import Foo in { ... } Where {...} is a new layout block, I guess. On Wednesday, August 5, 2015 at 9:40:00 PM UTC+10, Oliver Charles wrote: > > On Wed, Aug 5, 2015 at 12:34 PM Yuras Shumovich > wrote: > >> > I find myself wanting to be able to say something like: >> > >> > foo = ... >> > where import Something.Specific >> >> Then GHC will need to parse all the source code in order to build >> dependency tree. Also people may want to build dependency tree in their >> minds too, it is easier with global imports (in the module header.) >> What about the next: >> >> -- In the module header: >> import qualified Something.Specific as Specific >> ... >> -- Somewhere else: >> foo = ... >> where import Specific -- Note: importing by module alias >> > > I would rather we are able to use exactly the same features as global > imports to reduce the cognitive burden of knowing what you can and can't > do. If those responsible for GHC tell me that what I want is unrealistic > then maybe we'll have to compromise, but right now I would rather not add > limitations. > > *ocharles* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Aug 5 13:32:52 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 5 Aug 2015 09:32:52 -0400 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: Message-ID: On Wed, Aug 5, 2015 at 6:28 AM, Oliver Charles wrote: > I find myself wanting to be able to say something like: > > foo = ... > where import Something.Specific > > The result would be to import the contents of Something.Specific into the > scope of foo and its other where bindings, but not import into the rest of > the module that foo is defined in. As a motivating example, I'm currently > working on building some HTML in Haskell, and the amount of symbols that > come into scope is huge, when you have a DSL for both CSS and HTML - the > real pain point being that you get symbols that often conflict. > The biggest problem with this is the question of instances. The typechecker requires that all instances be global; otherwise you can break invariants. (Consider what happens if a different Ord instance is in scope in that part of the program.) I wonder if this use case can be addressed by a different mechanism (extension), though: import qualified Something.Specific {- ... -} foo = ... where using Something.Specific -- names would be unqualified in this scope -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Aug 5 14:15:43 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 5 Aug 2015 15:15:43 +0100 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <1438774462.2064.16.camel@gmail.com> <63a20f41-057e-4521-b1e3-0be4424aba01@googlegroups.com> Message-ID: On Wed, Aug 5, 2015 at 3:12 PM Moritz Kiefer wrote: > Am Mittwoch, 5. August 2015 14:59:54 UTC+2 schrieb Mike Ledger: >> >> This would be really handy to have. You could also have import "blocks", >> like >> >> import Foo in { >> ... >> } >> >> Where {...} is a new layout block, I guess. >> > Is *let* not exactly this block feature? > Indeed, in my post I use let bindings to achieve this: let import CSS in [ width (px 50) ] You could also add other local bindings to your scope: let import CSS sizeInPx = px 50 in [ width sizePx, height sizeInPx ] (Note that just like let the other bindings have access to the symbols that were imported) *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.cameron at covenanteyes.com Wed Aug 5 14:19:31 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Wed, 5 Aug 2015 14:19:31 +0000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <1438774462.2064.16.camel@gmail.com> <63a20f41-057e-4521-b1e3-0be4424aba01@googlegroups.com> Message-ID: +1 on the idea. I wonder if full-blown ?import? is overkill for the desired effect. Many languages simply allow you to de-qualify a namespace within a smaller scope. I?m thinking of C++ at the moment: { using namespace std; ? } I think this would be preferable because it would still require that a module declare its ?import dependencies? in a known place. I?m imagining chaos from large source files with several dozen import dependencies, but only a few of them defined in the ?normal? place. That said, there is syntactical boon from re-using the ?import? keyword. Yet I don?t think it?s a stretch to make inlined imports be constrained by the module?s imports. It?s a simple compiler error: ?Foo cannot be imported inline because it is not imported by the module?. With or without the constraint, this would be an excellent feature. Elliot P.S. Now, about placing multiple modules in the same file?. From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Oliver Charles Sent: Wednesday, August 5, 2015 10:16 AM To: Moritz Kiefer; Haskell-cafe Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Syntax extension - adding import support to let/where bindings On Wed, Aug 5, 2015 at 3:12 PM Moritz Kiefer > wrote: Am Mittwoch, 5. August 2015 14:59:54 UTC+2 schrieb Mike Ledger: This would be really handy to have. You could also have import "blocks", like import Foo in { ... } Where {...} is a new layout block, I guess. Is let not exactly this block feature? Indeed, in my post I use let bindings to achieve this: let import CSS in [ width (px 50) ] You could also add other local bindings to your scope: let import CSS sizeInPx = px 50 in [ width sizePx, height sizeInPx ] (Note that just like let the other bindings have access to the symbols that were imported) ocharles -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Aug 5 14:20:21 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 5 Aug 2015 15:20:21 +0100 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: Message-ID: On Wed, Aug 5, 2015 at 2:32 PM, Brandon Allbery wrote: > The biggest problem with this is the question of instances. The > typechecker requires that all instances be global; otherwise you can break > invariants. (Consider what happens if a different Ord instance is in scope > in that part of the program.) > > I wonder if this use case can be addressed by a different mechanism > (extension), though: > > import qualified Something.Specific > {- ... -} > foo = ... > where using Something.Specific -- names would be unqualified in this > scope > This is a good point. I hadn't considered that, but I wouldn't want to be importing instances - only symbols (types, type families, top level definitions). If we use import and rule out instance importing, then we might have to improve the error messages about missing instances. For example, No instance for (Eq Foo) In the expression: foo == foo In an equation for ?it?: it = foo == foo Note: an instance was found in Foo, but this must be imported at the module level. Obviously the wording is open for discussion, but the idea is that GHC could be aware of the instances, find them, but refuse to use them. Questionable whether we want this, but it's an idea. using could also work, at the cost of taking up another keyword (and a potentially useful keyword, as using has meaning in other languages that we may ultimately find ourselves wanting in Haskell). *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Wed Aug 5 14:38:44 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Wed, 5 Aug 2015 10:38:44 -0400 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: Message-ID: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> A couple syntactic concerns (assuming there's a sane semantics with eg typeclass instances): - This seems essentially like name shadowing, which is a source of confusion and therefore bugs (-Wall warns about it) - This makes me unable to see what a module imports by looking at the import statements at the top of a file - It seems like using "H.width" and "C.width" isn't very costly Tom El Aug 5, 2015, a las 6:28, Oliver Charles escribi?: > Hi all, > > I'm sure this has come up before, but a quick bit of Googling didn't reveal any prior discussions (if you known any, let me know), so I'm kicking off a new discussion. > > I find myself wanting to be able to say something like: > > foo = ... > where import Something.Specific > > The result would be to import the contents of Something.Specific into the scope of foo and its other where bindings, but not import into the rest of the module that foo is defined in. As a motivating example, I'm currently working on building some HTML in Haskell, and the amount of symbols that come into scope is huge, when you have a DSL for both CSS and HTML - the real pain point being that you get symbols that often conflict. > > Here's an example of something that doesn't type-check currently > > image = > img [ width 50, style [ width (px 50) ] ] > > width here is both a symbol in the HTML DSL and the CSS DSL, but to get this to type check I need to write something like > > image = > img [ HTML.width 50, style [ CSS.width (CSS.px 50) ] ] > > That's not particularly bad here, the really pain is repeatedly having to do this for every single symbol I'm using. I'd prefer to be able to write > > image = > let css = let import CSS in [ width (px 50) ] > in let import HTML in img [ width 50, style css ] > > This is a little bit of a contrived rewrite, but hopefully it shows you what I'd like to be able to do. Please don't fixate too much on this example, it's only intended to illustrate the idea. When defining a large amount of inline styles I think this pays off - I import once to bring all the symbols I need into scope, rather than having to qualify every symbol. > > In reality, it will lead to me writing code like: > > myDocument = html > where html = > div [ style containerStyle ] > [ div [ style rowStyle ] "Hello" > , div [ style rowStyle ] "World!" ] > where import HTML > containerStyle = > [ backgroundColor ..., padding ..., margin ... ] > where import CSS > rowStyle = > [ backgroundColor ..., padding ..., margin ... ] > where import CSS > > At present the suggestion is a syntax error, so I'm hoping that part won't be too controversial. > > Thoughts? > ocharles > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Aug 5 14:49:21 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 5 Aug 2015 15:49:21 +0100 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: On Wed, Aug 5, 2015 at 3:38 PM wrote: > A couple syntactic concerns (assuming there's a sane semantics with eg > typeclass instances): > > - This seems essentially like name shadowing, which is a source of > confusion and therefore bugs (-Wall warns about it) > It would be the same as normal name resolution. For example, right now you can do foo = id True where id a = a foo.hs:2:9: Warning: This binding for ?id? shadows the existing binding imported from ?Prelude? at foo.hs:1:1 (and originally defined in ?GHC.Base?) Prelude.id was introduced in a higher scope, so the definition shadows it. If you do this foo = id True where import Prelude (id) id a = a Then that should fail with "Ambiguous occurrence 'id'". If importing would shadow a top-level definition, then that should probably trigger a warning. E.g., import Prelude hiding (id) id a = a foo = id True where import Prelude (id) Would warn that the import shadows the top-level definition of id (which is the same behavior as if you declared another id in the where clauses for foo). > - This makes me unable to see what a module imports by looking at the > import statements at the top of a file > Correct. But it does not make it impossible for a tool to determine what imports are available. This is also proposed as an extension, so of course if you don't want to use it, you wouldn't have to. > - It seems like using "H.width" and "C.width" isn't very costly > In practice I use a lot more than just two symbols. The point is the repeated qualification quickly introduces more noise and obscures the intent of the code. It also introduces a disconnect in the code - where did H come from? Time to jump all the way to the top of the file to find out. Of course, under my proposal it *could* be even harder to find out where H came from, but that is a decision that the (code) author decided on - and there are already many ways we *could* make Haskell unreadable. *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Wed Aug 5 15:06:02 2015 From: trebla at vex.net (Albert Y. C. Lai) Date: Wed, 05 Aug 2015 11:06:02 -0400 Subject: [Haskell-cafe] Why is the no tuple syntax for sum types In-Reply-To: References: <55BA3C26.5010105@gmail.com> <55BF5427.2050407@pkturner.org> Message-ID: <55C2265A.8070307@vex.net> On 2015-08-03 06:07 PM, Richard A. O'Keefe wrote: > This sudden enthusiasm for them strikes me as being like > a sudden enthusiasm for punched cards, paper tape, or PL/I. Oh! Punch cards can represent sum types (use different hole positions to indicate different variants), and tapes can represent tuple types! On the bright side, I haven't found a use of PL/I. From qdunkan at gmail.com Wed Aug 5 16:43:22 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 5 Aug 2015 09:43:22 -0700 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: > In practice I use a lot more than just two symbols. The point is the > repeated qualification quickly introduces more noise and obscures the intent > of the code. Well, qualification is only necessary for the symbols that conflict, right? It seems to me that if you want an EDSL with a certain prelude, you have to make sure the prelude symbols are all distinct. If you want to compose two DSLs, then you could make a third prelude that imports the other two, but renames colliding symbols. Unless there are many collisions... in which case, maybe don't define your EDSLs like that in the first place? Currently if you want to figure out all imports you parse the top of the file and can stop at the first definition. But with this feature you have to parse the whole file and thus understand all haskell grammar, including all extensions in use. I'd have to give up on my fast deps chaser and switch to slow ghc -M... which is maybe the right way anyway, I don't know. Ok, to be fair, I wouldn't, because I could choose to not use that feature, but in *theory* :) And while "you don't have to use it" is always brought up, it seems to me the more successful the feature is the more likely you do have to use it. On the other hand, lots of languages have a "local open" feature like this. I think many of them make you first import the module, and then you can "open" it in a local scope. This would address both my "parse the whole file for imports" objection and the "what about instances", because module importing would be unchanged. From ollie at ocharles.org.uk Wed Aug 5 16:55:52 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 05 Aug 2015 16:55:52 +0000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: On Wed, Aug 5, 2015 at 5:43 PM Evan Laforge wrote: > > In practice I use a lot more than just two symbols. The point is the > > repeated qualification quickly introduces more noise and obscures the > intent > > of the code. > > Well, qualification is only necessary for the symbols that conflict, > right? It seems to me that if you want an EDSL with a certain > prelude, you have to make sure the prelude symbols are all distinct. > If you want to compose two DSLs, then you could make a third prelude > that imports the other two, but renames colliding symbols. > At this point I am working for the compiler (and in this case doing a lot of work!), but it should be the other way round - this makes me sad. Unless there are many collisions... in which case, maybe don't define > your EDSLs like that in the first place? > My EDSLs for HTML and CSS are meant to reflect those actual languages as closely as possible. If I start renaming things just to "fit in" with other symbols, then I've started adding burden on my users. Also, let's not forget this proposal is useful for more than just EDSLs, so lets not get too caught up on that - for example, one might wish to import Data.Text.Lazy or Data.Text in different locations depending on what they are working with. There are many packages out there with conflicting symbols that have fairly "localised" use sites, but at a granularity of a top-level definition rather than a module. Currently if you want to figure out all imports you parse the top of > the file and can stop at the first definition. But with this feature > you have to parse the whole file and thus understand all haskell > grammar, including all extensions in use. I'd have to give up on my > fast deps chaser and switch to slow ghc -M... which is maybe the right > way anyway, I don't know. > > Ok, to be fair, I wouldn't, because I could choose to not use that > feature, but in *theory* :) And while "you don't have to use it" is > always brought up, it seems to me the more successful the feature is > the more likely you do have to use it. > It makes me sad if we can't progress the language on the grounds that people's attempts at parsing the source code themselves would break. If you want to know all the imports, then we should be providing this information through tools for people to consume. On the other hand, lots of languages have a "local open" feature like > this. I think many of them make you first import the module, and then > you can "open" it in a local scope. This would address both my "parse > the whole file for imports" objection and the "what about instances", > because module importing would be unchanged. > Indeed, this could be a path forward. I'm not really familiar with any languages that do this, could you link to some examples of how this works in other languages? *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Wed Aug 5 17:08:22 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 5 Aug 2015 10:08:22 -0700 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: On Wed, Aug 5, 2015 at 9:55 AM, Oliver Charles wrote: > It makes me sad if we can't progress the language on the grounds that > people's attempts at parsing the source code themselves would break. If you > want to know all the imports, then we should be providing this information > through tools for people to consume. It's not whether or not there's a tool, there already is. It's that the tool must be more complicated. For example, we can get imports from haskell-src-exts but it has bugs, it can be out of date, and it's slower. Or ghc -M... which doesn't have those problems. So maybe it's not really a serious objection. >> On the other hand, lots of languages have a "local open" feature like >> this. I think many of them make you first import the module, and then >> you can "open" it in a local scope. This would address both my "parse >> the whole file for imports" objection and the "what about instances", >> because module importing would be unchanged. > > Indeed, this could be a path forward. I'm not really familiar with any > languages that do this, could you link to some examples of how this works in > other languages? I was thinking of agda.. though it's only from memory so I could be wrong. Or perhaps it was cayenne... one of those dependently typed languages models modules as records, and then has syntax to dequalify record access. Rust has a full-on nested module system, but I seem to recall you have to declare a link dependency on an external crate ("import"), and then separately import the symbols from it ("use"). From alan.zimm at gmail.com Wed Aug 5 17:11:34 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 5 Aug 2015 19:11:34 +0200 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: This seems to show the syntax in agda https://code.google.com/p/agda/issues/detail?id=1077 -- M.agda ------------ open import Relation.Binary using (Setoid; module Setoid) open import Data.Nat using (?) h : ? h = 0 module M {? ?=} (A : Setoid ? ?=) where open Setoid A f : Carrier ? ? f _ = 0 module _ (B : Set) where g : B ? ? g _ = 0 ----------------------------------------- I think the "open Setoid A" is the effect you are looking for Alan On Wed, Aug 5, 2015 at 7:08 PM, Evan Laforge wrote: > On Wed, Aug 5, 2015 at 9:55 AM, Oliver Charles > wrote: > > It makes me sad if we can't progress the language on the grounds that > > people's attempts at parsing the source code themselves would break. If > you > > want to know all the imports, then we should be providing this > information > > through tools for people to consume. > > It's not whether or not there's a tool, there already is. It's that > the tool must be more complicated. For example, we can get imports > from haskell-src-exts but it has bugs, it can be out of date, and it's > slower. Or ghc -M... which doesn't have those problems. So maybe > it's not really a serious objection. > > >> On the other hand, lots of languages have a "local open" feature like > >> this. I think many of them make you first import the module, and then > >> you can "open" it in a local scope. This would address both my "parse > >> the whole file for imports" objection and the "what about instances", > >> because module importing would be unchanged. > > > > Indeed, this could be a path forward. I'm not really familiar with any > > languages that do this, could you link to some examples of how this > works in > > other languages? > > I was thinking of agda.. though it's only from memory so I could be > wrong. Or perhaps it was cayenne... one of those dependently typed > languages models modules as records, and then has syntax to dequalify > record access. Rust has a full-on nested module system, but I seem to > recall you have to declare a link dependency on an external crate > ("import"), and then separately import the symbols from it ("use"). > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eleventynine at gmail.com Wed Aug 5 17:18:15 2015 From: eleventynine at gmail.com (Mike Ledger) Date: Thu, 6 Aug 2015 03:18:15 +1000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <1438774462.2064.16.camel@gmail.com> <63a20f41-057e-4521-b1e3-0be4424aba01@googlegroups.com> Message-ID: I meant that as a top-level syntactic thing, to avoid writing "import CSS" in the let/where blocks, for multiple top-level definitions that use the same import. Just premature bikeshed :-) On 06/08/2015 12:15 AM, "Oliver Charles" wrote: > On Wed, Aug 5, 2015 at 3:12 PM Moritz Kiefer > wrote: > >> Am Mittwoch, 5. August 2015 14:59:54 UTC+2 schrieb Mike Ledger: >>> >>> This would be really handy to have. You could also have import "blocks", >>> like >>> >>> import Foo in { >>> ... >>> } >>> >>> Where {...} is a new layout block, I guess. >>> >> Is *let* not exactly this block feature? >> > > Indeed, in my post I use let bindings to achieve this: > > let import CSS in [ width (px 50) ] > > You could also add other local bindings to your scope: > > let import CSS > sizeInPx = px 50 > in [ width sizePx, height sizeInPx ] > > (Note that just like let the other bindings have access to the symbols > that were imported) > > *ocharles* > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregmainland at gmail.com Wed Aug 5 17:18:15 2015 From: gregmainland at gmail.com (Greg Horn) Date: Wed, 05 Aug 2015 17:18:15 +0000 Subject: [Haskell-cafe] ambiguous module name Network.URI In-Reply-To: <559d2f54.c966ca0a.cbabd.3aa6@mx.google.com> References: <001201d0b961$db632ae0$922980a0$@lijbrandt.nl> <559d2f54.c966ca0a.cbabd.3aa6@mx.google.com> Message-ID: Sorry I'm late to the party, -XPackageImports is the solution to this issue: https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/syntax-extns.html#idp23827600 On Wed, Jul 8, 2015 at 7:10 AM Christopher Reichert wrote: > > > On Wed, Jul 08 2015, "Kees Bleijenberg" > wrote: > > Thanks Christopher, > > > > > > -----Oorspronkelijk bericht----- > > > > Check out the Hackage page for network-uri: > > https://hackage.haskell.org/package/network-uri > > > > The parseURI function is in the version of network you are using already > so > > there is no need to import modules from network-uri. > > > > ---------------------------------------- > > > > If I remove the import of Network-URI and leave the import Network.Http > and > > use parseURI, ghc complains: not in scope parseURI. > > Do I have to change someting in the packages? > > > > You should leave the import of Network.URI. Are you trying to build a > cabal project? Did you install the network-uri package yourself? > > > If you're creating a cabal project try adding: > > build-depends: network-uri < 2.6, network < 2.6 > > Otherwise, can you describe the install steps you are taking? > > > Kees > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- > Christopher Reichert > irc: creichert > gpg: C81D 18C8 862A 3618 1376 FFA5 6BFC A992 9955 929B > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Wed Aug 5 17:19:47 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 05 Aug 2015 17:19:47 +0000 Subject: [Haskell-cafe] Fwd: Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: Arg. Didn't send this to the list. ---------- Forwarded message --------- From: Mike Meyer Date: Wed, Aug 5, 2015 at 12:16 PM Subject: Re: [Haskell-cafe] Syntax extension - adding import support to let/where bindings To: Evan Laforge On Wed, Aug 5, 2015 at 11:43 AM Evan Laforge wrote: > And while "you don't have to use it" is > always brought up, it seems to me the more successful the feature is > the more likely you do have to use it. > "You don't have to use it" is a canard, and that argument needs to be killed whenever and wherever it arises. Sure, I don't have to use it. But the tools I use have to support it, so it'll make them bigger and slower, so I'm paying the price for "it" even if I don't use it. If I'm on a team, I probably have to either waste time arguing with other people to get them not to use it, or at least explain why I didn't use it. And that latter will come up every time I share code with other people, which we do want to encourage people to do. And that brings us to the real issue of why "You don't have to use it" is simply false. Reusing other people's code is a critical part of any software development environment. If they use, I have to understand it in order to understand their code. Even more than I have to in order to explain why I don't use it. So, no matter what I think of some feature, if it exists, the tools I use will almost certainly have to support it, and I'll have to understand the feature well enough to decipher code that uses it, and probably defend my decision not to use it. I don't see that this is in any way less of a burden on me than if I chose to use it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Wed Aug 5 17:31:12 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 05 Aug 2015 17:31:12 +0000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: On Wed, Aug 5, 2015 at 12:12 PM Alan & Kim Zimmerman wrote: > This seems to show the syntax in agda > > https://code.google.com/p/agda/issues/detail?id=1077 > > -- M.agda ------------ > open import Relation.Binary using (Setoid; module Setoid) > open import Data.Nat using (?) > > h : ? > h = 0 > > module M {? ?=} (A : Setoid ? ?=) > where > open Setoid A > > f : Carrier ? ? > f _ = 0 > > module _ (B : Set) where > g : B ? ? > g _ = 0 > > If this is going to go into a local block of some kind, how many names are you going to use from A? How much extra work does this save over something like: import qualified Relation.Binary as Setoid ... ... where f = Setoid.f g = Setoid.g -- and whatever other names you need from Setoid. Personally, I'm not a big fan of unqualified imports - I've spent to much time trying to figure out where some variable came from in a module that just imported everything unqualified. So I'm willing to trade a little extra work now to make sure every name not from the Prelude shows up in the imports lis in order to save time every time I have to figure it out again later. I think the idea of having local imports is a win, as it means finding names is faster, as they'll be right there, instead of having to go to the imports list at the top of the page. But if I have to import the module qualified, and then pull the names I want out locally (which I will do), it's not clear that this provides a significant advantage over what we already have. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.cameron at covenanteyes.com Wed Aug 5 17:46:07 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Wed, 5 Aug 2015 17:46:07 +0000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: <758f1a84d1794041b707f1ac172307f9@HQWS-EXMB-01.main.covenanteyes.com> My initial attempt seems to have failed: +1 on the idea. I wonder if full-blown ?import? is overkill for the desired effect. Many languages simply allow you to de-qualify a namespace within a smaller scope. I?m thinking of C++ at the moment: { using namespace std; ? } I think this would be preferable because it would still require that a module declare its ?import dependencies? in a known place. I?m imagining chaos from large source files with several dozen import dependencies, but only a few of them defined in the ?normal? place. Not to mention this would solve some of the worries about tooling, etc. That said, there is syntactical boon from re-using the ?import? keyword. Yet I don?t think it?s a stretch to make inlined imports be constrained by the module?s imports. It?s a simple compiler error: ?Foo cannot be imported inline because it is not imported by the module?. With or without the constraint, this would be an excellent feature. Elliot From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Oliver Charles Sent: Wednesday, August 5, 2015 12:56 PM To: Evan Laforge Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Syntax extension - adding import support to let/where bindings On Wed, Aug 5, 2015 at 5:43 PM Evan Laforge > wrote: > In practice I use a lot more than just two symbols. The point is the > repeated qualification quickly introduces more noise and obscures the intent > of the code. Well, qualification is only necessary for the symbols that conflict, right? It seems to me that if you want an EDSL with a certain prelude, you have to make sure the prelude symbols are all distinct. If you want to compose two DSLs, then you could make a third prelude that imports the other two, but renames colliding symbols. At this point I am working for the compiler (and in this case doing a lot of work!), but it should be the other way round - this makes me sad. Unless there are many collisions... in which case, maybe don't define your EDSLs like that in the first place? My EDSLs for HTML and CSS are meant to reflect those actual languages as closely as possible. If I start renaming things just to "fit in" with other symbols, then I've started adding burden on my users. Also, let's not forget this proposal is useful for more than just EDSLs, so lets not get too caught up on that - for example, one might wish to import Data.Text.Lazy or Data.Text in different locations depending on what they are working with. There are many packages out there with conflicting symbols that have fairly "localised" use sites, but at a granularity of a top-level definition rather than a module. Currently if you want to figure out all imports you parse the top of the file and can stop at the first definition. But with this feature you have to parse the whole file and thus understand all haskell grammar, including all extensions in use. I'd have to give up on my fast deps chaser and switch to slow ghc -M... which is maybe the right way anyway, I don't know. Ok, to be fair, I wouldn't, because I could choose to not use that feature, but in *theory* :) And while "you don't have to use it" is always brought up, it seems to me the more successful the feature is the more likely you do have to use it. It makes me sad if we can't progress the language on the grounds that people's attempts at parsing the source code themselves would break. If you want to know all the imports, then we should be providing this information through tools for people to consume. On the other hand, lots of languages have a "local open" feature like this. I think many of them make you first import the module, and then you can "open" it in a local scope. This would address both my "parse the whole file for imports" objection and the "what about instances", because module importing would be unchanged. Indeed, this could be a path forward. I'm not really familiar with any languages that do this, could you link to some examples of how this works in other languages? ocharles -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Wed Aug 5 18:11:44 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Wed, 5 Aug 2015 11:11:44 -0700 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: <758f1a84d1794041b707f1ac172307f9@HQWS-EXMB-01.main.covenanteyes.com> References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> <758f1a84d1794041b707f1ac172307f9@HQWS-EXMB-01.main.covenanteyes.com> Message-ID: If you want a direct experience report, I've written a fair amount of OCaml which supports pretty much exactly this feature[1]: let open List in ... They even have a weird concise version of the syntax: List.(...) This is quite useful in practice, and doesn't seem to cause any problems. However, OCaml has different norms around external modules, so it might not translate to Haskell the same way. In OCaml, every module is automatically imported qualified. There's no list of import statements at the top. Importing ("opening") a module is equivalent to an *unqualified* import in Haskell and happens rarely. Moreover, it can appear in any part of the file. In practice this doesn't seem to be a problem, but that could be because nobody's depending on having all the imports conveniently declared up-front. Personally, I think this trade-off is perfectly acceptable: I'd rather have life be better for programmers and worse for tools than vice-versa. OCaml also doesn't have typeclasses or the open world assumption which would lead to confusing behavior one way or another. With all that in mind, OCaml's feature feels closer to Elliot's suggestion: it's more about locally *dequalifying* a module than importing it. Doing just that also fits better with Haskell's current import and typeclass system. However, I'm not sure how to design a local dequalifying statement in a way that's not confusing. [1]: http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual021.html#toc77 On Wed, Aug 5, 2015 at 10:46 AM, Elliot Cameron < elliot.cameron at covenanteyes.com> wrote: > My initial attempt seems to have failed: > > > > +1 on the idea. > > > > I wonder if full-blown ?import? is overkill for the desired effect. Many > languages simply allow you to de-qualify a namespace within a smaller > scope. I?m thinking of C++ at the moment: { using namespace std; ? } > > > > I think this would be preferable because it would still require that a > module declare its ?import dependencies? in a known place. I?m imagining > chaos from large source files with several dozen import dependencies, but > only a few of them defined in the ?normal? place. Not to mention this would > solve some of the worries about tooling, etc. > > > > That said, there is syntactical boon from re-using the ?import? keyword. > Yet I don?t think it?s a stretch to make inlined imports be constrained by > the module?s imports. It?s a simple compiler error: ?Foo cannot be imported > inline because it is not imported by the module?. > > > > With or without the constraint, this would be an excellent feature. > > > > Elliot > > > > > > *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On Behalf > Of *Oliver Charles > *Sent:* Wednesday, August 5, 2015 12:56 PM > *To:* Evan Laforge > *Cc:* Haskell Cafe > *Subject:* Re: [Haskell-cafe] Syntax extension - adding import support to > let/where bindings > > > > > > On Wed, Aug 5, 2015 at 5:43 PM Evan Laforge wrote: > > > In practice I use a lot more than just two symbols. The point is the > > repeated qualification quickly introduces more noise and obscures the > intent > > of the code. > > Well, qualification is only necessary for the symbols that conflict, > right? It seems to me that if you want an EDSL with a certain > prelude, you have to make sure the prelude symbols are all distinct. > If you want to compose two DSLs, then you could make a third prelude > that imports the other two, but renames colliding symbols. > > > > At this point I am working for the compiler (and in this case doing a lot > of work!), but it should be the other way round - this makes me sad. > > > > Unless there are many collisions... in which case, maybe don't define > your EDSLs like that in the first place? > > > > My EDSLs for HTML and CSS are meant to reflect those actual languages as > closely as possible. If I start renaming things just to "fit in" with other > symbols, then I've started adding burden on my users. > > > > Also, let's not forget this proposal is useful for more than just EDSLs, > so lets not get too caught up on that - for example, one might wish to > import Data.Text.Lazy or Data.Text in different locations depending on what > they are working with. There are many packages out there with conflicting > symbols that have fairly "localised" use sites, but at a granularity of a > top-level definition rather than a module. > > > > Currently if you want to figure out all imports you parse the top of > the file and can stop at the first definition. But with this feature > you have to parse the whole file and thus understand all haskell > grammar, including all extensions in use. I'd have to give up on my > fast deps chaser and switch to slow ghc -M... which is maybe the right > way anyway, I don't know. > > Ok, to be fair, I wouldn't, because I could choose to not use that > feature, but in *theory* :) And while "you don't have to use it" is > always brought up, it seems to me the more successful the feature is > the more likely you do have to use it. > > > > It makes me sad if we can't progress the language on the grounds that > people's attempts at parsing the source code themselves would break. If you > want to know all the imports, then we should be providing this information > through tools for people to consume. > > > > On the other hand, lots of languages have a "local open" feature like > this. I think many of them make you first import the module, and then > you can "open" it in a local scope. This would address both my "parse > the whole file for imports" objection and the "what about instances", > because module importing would be unchanged. > > > > Indeed, this could be a path forward. I'm not really familiar with any > languages that do this, could you link to some examples of how this works > in other languages? > > > > *ocharles* > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Aug 5 19:42:15 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 5 Aug 2015 20:42:15 +0100 Subject: [Haskell-cafe] Fwd: Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: <20150805194215.GC5332@weber> On Wed, Aug 05, 2015 at 05:19:47PM +0000, Mike Meyer wrote: > On Wed, Aug 5, 2015 at 11:43 AM Evan Laforge wrote: > > And while "you don't have to use it" is > > always brought up, it seems to me the more successful the feature is > > the more likely you do have to use it. > > "You don't have to use it" is a canard, and that argument needs to be > killed whenever and wherever it arises. > > Sure, I don't have to use it. But [...] Very much agreed, and thank you for making this argument (although I also like Ollie's suggestion). Tom From ollie at ocharles.org.uk Wed Aug 5 20:17:28 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 05 Aug 2015 20:17:28 +0000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: On Wed, Aug 5, 2015 at 6:08 PM Evan Laforge wrote: > On Wed, Aug 5, 2015 at 9:55 AM, Oliver Charles > wrote: > > It makes me sad if we can't progress the language on the grounds that > > people's attempts at parsing the source code themselves would break. If > you > > want to know all the imports, then we should be providing this > information > > through tools for people to consume. > > It's not whether or not there's a tool, there already is. It's that > the tool must be more complicated. For example, we can get imports > from haskell-src-exts but it has bugs, it can be out of date, and it's > slower. Or ghc -M... which doesn't have those problems. So maybe > it's not really a serious objection. > This is a problem that shouldn't even exist. If you want a tool that supports GHC's extensions then we should be *using GHC* - it is a library after all. haskell-src has a need to exist as a non-GHC-dependent parser, and that's great - but for parsing GHC specific code we should be able to just use GHC. The fact that that isn't the case right now is a failing on our parts, but one that we seem to be actively fixing (c.f. ghc-exactprint). >> On the other hand, lots of languages have a "local open" feature like > >> this. I think many of them make you first import the module, and then > >> you can "open" it in a local scope. This would address both my "parse > >> the whole file for imports" objection and the "what about instances", > >> because module importing would be unchanged. > > > > Indeed, this could be a path forward. I'm not really familiar with any > > languages that do this, could you link to some examples of how this > works in > > other languages? > > I was thinking of agda.. though it's only from memory so I could be > wrong. Or perhaps it was cayenne... one of those dependently typed > languages models modules as records, and then has syntax to dequalify > record access. Rust has a full-on nested module system, but I seem to > recall you have to declare a link dependency on an external crate > ("import"), and then separately import the symbols from it ("use"). > Indeed, Agda does have stuff like that - though it does require more syntax. It is a pretty sophisticated import system, though . *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Aug 5 20:20:28 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 05 Aug 2015 20:20:28 +0000 Subject: [Haskell-cafe] Fwd: Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> Message-ID: > > On Wed, Aug 5, 2015 at 11:43 AM Evan Laforge wrote: > >> And while "you don't have to use it" is >> always brought up, it seems to me the more successful the feature is >> the more likely you do have to use it. >> > > "You don't have to use it" is a canard, and that argument needs to be > killed whenever and wherever it arises. > > Sure, I don't have to use it. But the tools I use have to support it, so > it'll make them bigger and slower, so I'm paying the price for "it" even if > I don't use it. If I'm on a team, I probably have to either waste time > arguing with other people to get them not to use it, or at least explain > why I didn't use it. And that latter will come up every time I share code > with other people, which we do want to encourage people to do. > > And that brings us to the real issue of why "You don't have to use it" is > simply false. Reusing other people's code is a critical part of any > software development environment. If they use, I have to understand it in > order to understand their code. Even more than I have to in order to > explain why I don't use it. > > So, no matter what I think of some feature, if it exists, the tools I use > will almost certainly have to support it, and I'll have to understand the > feature well enough to decipher code that uses it, and probably defend my > decision not to use it. I don't see that this is in any way less of a > burden on me than if I chose to use it. > Ok, these are solid arguments - my apologies for throwing that one out there. The only part I disagree with is: > Reusing other people's code is a critical part of any software development environment. If they use, I have to understand it in order to understand their code. Even more than I have to in order to explain why I don't use it. You only have to understand it if either the extension leaks out into the public API, or you are working on that code rather than simply using that code. In this case, this extension should only impact the latter. But still, I can't argue with the other points - thanks for bringing this up. *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Aug 5 20:24:37 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 05 Aug 2015 20:24:37 +0000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> <758f1a84d1794041b707f1ac172307f9@HQWS-EXMB-01.main.covenanteyes.com> Message-ID: On Wed, Aug 5, 2015 at 7:12 PM Tikhon Jelvis wrote: > If you want a direct experience report, I've written a fair amount of > OCaml which supports pretty much exactly this feature[1]: > > let open List in ... > > They even have a weird concise version of the syntax: > > List.(...) > > This is quite useful in practice, and doesn't seem to cause any problems. > However, OCaml has different norms around external modules, so it might not > translate to Haskell the same way. > > In OCaml, every module is automatically imported qualified. There's no > list of import statements at the top. Importing ("opening") a module is > equivalent to an *unqualified* import in Haskell and happens rarely. > Moreover, it can appear in any part of the file. In practice this doesn't > seem to be a problem, but that could be because nobody's depending on > having all the imports conveniently declared up-front. Personally, I think > this trade-off is perfectly acceptable: I'd rather have life be better for > programmers and worse for tools than vice-versa. > > OCaml also doesn't have typeclasses or the open world assumption which > would lead to confusing behavior one way or another. > Thanks for providing another perspective! It's good to hear other languages are successfully employing this idea. With all that in mind, OCaml's feature feels closer to Elliot's suggestion: > it's more about locally *dequalifying* a module than importing it. Doing > just that also fits better with Haskell's current import and typeclass > system. However, I'm not sure how to design a local dequalifying statement > in a way that's not confusing. > Indeed, having import stay at the top level to always bring type class instances in followed by the option of "opening" an import later is certainly more elegant and less hacky than what I'm proposing. I think this route will have to require a new keyword though, but we can establish those details later. I'm leaning more towards this idea now. Let's see what others think. *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed Aug 5 20:29:21 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 05 Aug 2015 13:29:21 -0700 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: Message-ID: <1438806318-sup-9062@sabre> Hello Oliver, This should be a relatively straightforward extension to the renamer. But like others have mentioned, you should still be required to import anything you're going to use locally at the top-level. This requirement makes it clear how instance visibility and dependency analysis should be done. Plus, you probably want this anyway: import qualified My.Qualified.DSL.CSS as CSS ... where import CSS The suggested semantics are that 'import M' is a new form of binding (so it is valid in let statements and other situations), which takes every identifier which is qualified with M and makes them available unqualified. As far as taste wise, I'm not sure how much I like or dislike this syntactic feature. But it should not be difficult to implement. Edward Excerpts from Oliver Charles's message of 2015-08-05 03:28:38 -0700: > Hi all, > > I'm sure this has come up before, but a quick bit of Googling didn't reveal > any prior discussions (if you known any, let me know), so I'm kicking off a > new discussion. > > I find myself wanting to be able to say something like: > > foo = ... > where import Something.Specific > > The result would be to import the contents of Something.Specific into the > scope of foo and its other where bindings, but not import into the rest of > the module that foo is defined in. As a motivating example, I'm currently > working on building some HTML in Haskell, and the amount of symbols that > come into scope is huge, when you have a DSL for both CSS and HTML - the > real pain point being that you get symbols that often conflict. > > Here's an example of something that doesn't type-check currently > > image = > img [ width 50, style [ width (px 50) ] ] > > width here is both a symbol in the HTML DSL and the CSS DSL, but to get > this to type check I need to write something like > > image = > img [ HTML.width 50, style [ CSS.width (CSS.px 50) ] ] > > That's not particularly bad here, the really pain is repeatedly having to > do this for every single symbol I'm using. I'd prefer to be able to write > > image = > let css = let import CSS in [ width (px 50) ] > in let import HTML in img [ width 50, style css ] > > This is a little bit of a contrived rewrite, but hopefully it shows you > what I'd like to be able to do. Please don't fixate too much on this > example, it's only intended to illustrate the idea. When defining a large > amount of inline styles I think this pays off - I import once to bring all > the symbols I need into scope, rather than having to qualify every symbol. > > In reality, it will lead to me writing code like: > > myDocument = html > where html = > div [ style containerStyle ] > [ div [ style rowStyle ] "Hello" > , div [ style rowStyle ] "World!" ] > where import HTML > containerStyle = > [ backgroundColor ..., padding ..., margin ... ] > where import CSS > rowStyle = > [ backgroundColor ..., padding ..., margin ... ] > where import CSS > > At present the suggestion is a syntax error, so I'm hoping that part won't > be too controversial. > > Thoughts? > *ocharles* From sumit.sahrawat.apm13 at iitbhu.ac.in Wed Aug 5 21:24:52 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Thu, 6 Aug 2015 02:54:52 +0530 Subject: [Haskell-cafe] =?utf-8?q?=5BHaskell-beginners=5D_How_would_I_incr?= =?utf-8?q?ement_or_otherwise_change_a_value_in_a_record_with_?= =?utf-8?b?4oCcU2ltb24tbmVzc+KAnQ==?= In-Reply-To: References: Message-ID: More suitable for the haskell-cafe. Routing. On 6 August 2015 at 02:52, Michael Litchard wrote: > > The below code is from this tutorial http://dev.stephendiehl.com/hask/ > > it illustrates very well how to operate on values from records with > "Simon-ness" (illustrated below). What I am struggling with is how to > modify values inside records with "Simon-ness", say incrementing "age". I > keep thinking it has to do with the way Label is defined with the > constructor Get. Could I add another constructor Put? > > {-# LANGUAGE DataKinds #-}{-# LANGUAGE KindSignatures #-}{-# LANGUAGE MultiParamTypeClasses #-}{-# LANGUAGE FunctionalDependencies #-}{-# LANGUAGE FlexibleInstances #-}{-# LANGUAGE FlexibleContexts #-}{-# LANGUAGE StandaloneDeriving #-}{-# LANGUAGE ExistentialQuantification #-}{-# LANGUAGE ConstraintKinds #-} > > import GHC.TypeLits > newtype Field (n :: Symbol) v = Field { unField :: v } deriving Show > data Person1 = Person1 > { _age :: Field "age" Int > , _name :: Field "name" String > } > data Person2 = Person2 > { _age' :: Field "age" Int > , _name' :: Field "name" String > , _lib' :: Field "lib" String > } > deriving instance Show Person1deriving instance Show Person2 > data Label (l :: Symbol) = Get > class Has a l b | a l -> b where > from :: a -> Label l -> b > instance Has Person1 "age" Int where > from (Person1 a _) _ = unField a > instance Has Person1 "name" String where > from (Person1 _ a) _ = unField a > instance Has Person2 "age" Int where > from (Person2 a _ _) _ = unField a > instance Has Person2 "name" String where > from (Person2 _ a _) _ = unField a > > age :: Has a "age" b => a -> b > age pnt = from pnt (Get :: Label "age") > > name :: Has a "name" b => a -> b > name pnt = from pnt (Get :: Label "name") > -- Parameterized constraint kind for "Simon-ness" of a record.type Simon a = (Has a "name" String, Has a "age" Int) > > spj :: Person1 > spj = Person1 (Field 56) (Field "Simon Peyton Jones") > > smarlow :: Person2 > smarlow = Person2 (Field 38) (Field "Simon Marlow") (Field "rts") > > > catNames :: (Simon a, Simon b) => a -> b -> String > catNames a b = name a ++ name b > > addAges :: (Simon a, Simon b) => a -> b -> Int > addAges a b = age a + age b > > > names :: String > names = name smarlow ++ "," ++ name spj-- "Simon Marlow,Simon Peyton Jones" > > ages :: Int > ages = age spj + age smarlow-- 94 > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles at voleon.com Wed Aug 5 21:48:04 2015 From: charles at voleon.com (Charles Weitzer) Date: Wed, 5 Aug 2015 21:48:04 +0000 Subject: [Haskell-cafe] Voleon Capital Management Hiring Senior Software Engineer Message-ID: Voleon Capital Management LP is a startup quantitative hedge fund located in Berkeley, California. We would like to hire a senior software engineer as soon as possible. Voleon's founders previously worked together at one of the most successful quantitative hedge funds in the world. Our CEO has a PhD in Computer Science from Stanford and has been CEO and founder of a successful Internet infrastructure startup. Our Chief Investment Officer has a PhD in Statistics from Berkeley. Voleon's team includes PhD's from leading departments in statistics, computer science, and mathematics. We have made several unpublished advances in the field of machine learning and in other areas as well. Here is our formal job description: ********************************************************** * Senior Software Engineer * Technology-driven investment firm employing cutting-edge statistical machine learning techniques seeks an exceptionally capable software engineer. You will architect and implement new production trading systems, machine learning infrastructure, data integration pipelines, and large-scale storage systems. The firm researches and deploys systematic trading strategies designed to generate attractive returns without being dependent on the performance of the overall market. Join a team of under 30 people that includes a Berkeley statistics professor as well as over ten PhD's from Berkeley, Chicago, CMU, Princeton, Stanford, and UCLA, led by the founder and CEO of a successful Internet infrastructure technology firm. The firm's offices are walking distance from BART and the UC Berkeley campus in downtown Berkeley, California. We have a casual and collegial office environment, weekly catered lunches, and competitive benefits packages. We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems, and delivering complex projects on time. You should preferably have experience designing and implementing fault-tolerant distributed systems. Experience with building large-scale data infrastructure, stream processing systems, or latency-sensitive programs is a bonus. We are growing rapidly. Willingness to take initiative and a gritty determination to productize are essential. Required experience: - developing with C/C++/Python/Go in a Linux environment with a focus on performance, concurrency, and correctness. - experience with a functional programming language (Haskell, OCaml, Erlang) - working in TCP/IP networking, multi-threading, and server development. - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP, SNMP, etc.). - architecting and designing highly available systems. - architecting and designing large-scale data management infrastructure. - working in large codebases and building modular, manageable code. Preferred experience: - debugging and performance profiling, including the use of tools such as strace, valgrind, gdb, tcpdump, etc. - working with build and test automation tools. - working with well-defined change management processes. - diagnosing RDBMS performance problems, exploiting indexing, using EXPLAIN PLAN, optimizing at the code layer, etc. - working with messaging queues (RabbitMQ, Redis, etc.) as well as distributed caching systems. Interest in financial applications is essential, but experience in finance is not a primary factor in our hiring. Benefits and compensation are highly competitive. ********************************************************** The above job description is just a starting point in terms of possible duties and seniority. We can be very flexible for the right person. If you are interested or if you know of anyone who might be interested, let me know the best way to get in touch and we can discuss details. Thank you, Charles Weitzer Senior Recruiter Voleon Capital Management LP Charles at Voleon.com Office: 510.704.9870 x 7012 Mobile: (510) 558-9182 www.Voleon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlatko.basic at gmail.com Thu Aug 6 05:19:21 2015 From: vlatko.basic at gmail.com (Vlatko Basic) Date: Thu, 6 Aug 2015 07:19:21 +0200 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> <758f1a84d1794041b707f1ac172307f9@HQWS-EXMB-01.main.covenanteyes.com> Message-ID: <55C2EE59.90201@gmail.com> An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Thu Aug 6 07:48:47 2015 From: voldermort at hotmail.com (Jeremy) Date: Thu, 6 Aug 2015 00:48:47 -0700 (MST) Subject: [Haskell-cafe] Where is Haskell Weekly News syndicated? In-Reply-To: References: <1426087518070-5766854.post@n5.nabble.com> <1426408319367-5767017.post@n5.nabble.com> <20150315145524.GA73677@inanna.trygub.com> <1434614959662-5811671.post@n5.nabble.com> <1434629971980-5811691.post@n5.nabble.com> <1437377283118-5813708.post@n5.nabble.com> Message-ID: <1438847327308-5815145.post@n5.nabble.com> Kim-Ee Yeoh wrote > Yes. You'll find out why in the latest issue out soon. Soon is taking its time :-) -- View this message in context: http://haskell.1045720.n5.nabble.com/Where-is-Haskell-Weekly-News-syndicated-tp5766854p5815145.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From ky3 at atamo.com Thu Aug 6 09:01:54 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Thu, 6 Aug 2015 16:01:54 +0700 Subject: [Haskell-cafe] Where is Haskell Weekly News syndicated? In-Reply-To: <1438847327308-5815145.post@n5.nabble.com> References: <1426087518070-5766854.post@n5.nabble.com> <1426408319367-5767017.post@n5.nabble.com> <20150315145524.GA73677@inanna.trygub.com> <1434614959662-5811671.post@n5.nabble.com> <1434629971980-5811691.post@n5.nabble.com> <1437377283118-5813708.post@n5.nabble.com> <1438847327308-5815145.post@n5.nabble.com> Message-ID: On Thu, Aug 6, 2015 at 2:48 PM, Jeremy wrote: > Soon is taking its time :-) I appreciate my loyal readers, every single one of them. It'll be out in the next 2 days. And there'll be a nice surprise :) -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.brockman at gmail.com Sun Aug 2 14:56:05 2015 From: mikael.brockman at gmail.com (mikael.brockman at gmail.com) Date: Sun, 02 Aug 2015 16:56:05 +0200 Subject: [Haskell-cafe] Annotated ASTs, and the tension between Bound, Free, and Cofree... References: <20150729155618.GD3872@weber> Message-ID: <87wpxd3fju.fsf@gmail.com> Tom Ellis writes: > Or if you want *every* subterm annotated then how about > > newtype Expr f a = Expr { unExpr :: Free (ExprF (Compose f Expr)) a } Merijn, if you get something like this working, I'd be interested to see some of your code, since I too tripped over a similar problem when looking for a nice way to represent annotated ASTs with bound. Having a good solution seems like it would be widely useful. -- Mikael Brockman From mikael.brockman at gmail.com Thu Aug 6 10:16:51 2015 From: mikael.brockman at gmail.com (mikael.brockman at gmail.com) Date: Thu, 06 Aug 2015 12:16:51 +0200 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings References: <1438806318-sup-9062@sabre> Message-ID: <87r3ngiuwc.fsf@gmail.com> "Edward Z. Yang" writes: > This should be a relatively straightforward extension to the renamer. > But like others have mentioned, you should still be required to import > anything you're going to use locally at the top-level. This requirement > makes it clear how instance visibility and dependency analysis should be > done. Plus, you probably want this anyway: > > import qualified My.Qualified.DSL.CSS as CSS > > ... where import CSS > I'm strongly in favor of something like this proposal. Single-letter names for qualified modules seems to indicate the problem. Also, operators. Qualified operators are very ugly; unqualified operators are very confusing; explicit operator imports are tedious. So, I would love this, for example: | let import LensOperators in | (x ^%+ y <<++~ z) ^_^ k I'm often torn between unqualified and qualified imports. Qualified references are noisy and scary; unqualified references are hard to track. Block-level imports clarify references without noise. So, +1! -- Mikael Brockman From pkogan at gmail.com Thu Aug 6 11:30:59 2015 From: pkogan at gmail.com (Pavel Kogan) Date: Thu, 6 Aug 2015 12:30:59 +0100 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> <758f1a84d1794041b707f1ac172307f9@HQWS-EXMB-01.main.covenanteyes.com> Message-ID: If taking this route, how about using unqualified as a keyword? This also suggests an extension - using qualified to locally "close" a globally unqualified import. So, something like this: html = let qualified Prelude unqualified HTML in head $ ... This makes it clearer that what's going on is renaming rather than importing, and avoids implicit name shadowing. Pavel On 5 August 2015 at 21:24, Oliver Charles wrote: > On Wed, Aug 5, 2015 at 7:12 PM Tikhon Jelvis wrote: > >> If you want a direct experience report, I've written a fair amount of >> OCaml which supports pretty much exactly this feature[1]: >> >> let open List in ... >> >> They even have a weird concise version of the syntax: >> >> List.(...) >> >> This is quite useful in practice, and doesn't seem to cause any problems. >> However, OCaml has different norms around external modules, so it might not >> translate to Haskell the same way. >> >> In OCaml, every module is automatically imported qualified. There's no >> list of import statements at the top. Importing ("opening") a module is >> equivalent to an *unqualified* import in Haskell and happens rarely. >> Moreover, it can appear in any part of the file. In practice this doesn't >> seem to be a problem, but that could be because nobody's depending on >> having all the imports conveniently declared up-front. Personally, I think >> this trade-off is perfectly acceptable: I'd rather have life be better for >> programmers and worse for tools than vice-versa. >> >> OCaml also doesn't have typeclasses or the open world assumption which >> would lead to confusing behavior one way or another. >> > > Thanks for providing another perspective! It's good to hear other > languages are successfully employing this idea. > > With all that in mind, OCaml's feature feels closer to Elliot's >> suggestion: it's more about locally *dequalifying* a module than importing >> it. Doing just that also fits better with Haskell's current import and >> typeclass system. However, I'm not sure how to design a local dequalifying >> statement in a way that's not confusing. >> > > Indeed, having import stay at the top level to always bring type class > instances in followed by the option of "opening" an import later is > certainly more elegant and less hacky than what I'm proposing. I think this > route will have to require a new keyword though, but we can establish those > details later. I'm leaning more towards this idea now. Let's see what > others think. > > > *ocharles* > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From meditans at gmail.com Thu Aug 6 20:33:22 2015 From: meditans at gmail.com (Carlo Nucera) Date: Thu, 6 Aug 2015 22:33:22 +0200 Subject: [Haskell-cafe] Library for package preprocessing Message-ID: Hi all, I'm writing a tool to analyze source code of a package, which uses haskell-src-extra. As copied from hackage, libraries may contain some extra stuff (for example, cpp directives). What is the modern way to preprocess the package (configuring for the environment, running the cpp ecc) to obtain code which is guaranteed to be parsed by haskell-src-extra? Ideally I'd like to leave most of the logic for this part outside of the package. Could you point me towards some libraries doing a similar thing? Best regards From palotai.robin at gmail.com Thu Aug 6 20:53:33 2015 From: palotai.robin at gmail.com (Robin Palotai) Date: Thu, 06 Aug 2015 20:53:33 +0000 Subject: [Haskell-cafe] Waiting for async exception (and nothing else) In-Reply-To: References: Message-ID: You can make a stable name for the MVar which will prevent the rts from collecting it. Google it, there was a thread about this with Simon Marlow. Robin On Wed, Aug 5, 2015, 12:43 PM David Turner wrote: > Hi, > > Is there an elegant way to have a thread wait for an async exception but > nothing else? I tend to do something like > > forever $ threadDelay 1000000000 > > but this seems like a bit of a hack. Waiting on an otherwise-unused MVar > or doing 'atomically retry' don't work because GHC kills them off straight > away. > > The context is when using an API that only has a 'withMyThingy' wrapper > and no explicit openMyThingy and closeMyThingy alternatives. Perhaps that's > an API problem and the only way to work around this is with something a bit > hacky? > > Cheers, > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu Aug 6 21:50:14 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 6 Aug 2015 23:50:14 +0200 Subject: [Haskell-cafe] Library for package preprocessing In-Reply-To: References: Message-ID: Hi Carlo, If a library uses CPP then there two things you have to be aware of. 1. The library could include macros (such as MIN_VERSION_...) which are generated by cabal. The macro file is generated by "cabal configure", placed in "dist/" and called cabal_macros.h. 2. The file can also have #includes, where to find these files is also specified by in the cabal file. Both of these are annoying to deal with because they require additional contextual knowledge not present in the source file. As a result most tooling asks the user to provide information about the location of the cabal_macros.h file and includes directory. Hlint is a good example to look at if you want to see how a library which uses haskell-src-exts deals with CPP. I think it also provides an endpoint parseModuleEx[1] which does the preprocessing for you. It has two strategies, the first is to simply strip all lines with start with # and attempt to parse the file. This is surprisingly effective as most uses of CPP are quite simple. It also has built in support for running cpphs as a library but the user must say where the specific cpp files (cabal_macros.h etc) are. Directly using GHC can in fact be a bit easier in this regard as it has support for all the preprocessor steps. ghc-exactprint exposes a parser which you might find useful[1]. As for other preprocessing, I'm not sure what else you specifically want to know about but I might be able to help if you're more specific. Matt [1]: https://hackage.haskell.org/package/hlint-1.9.21/docs/Language-Haskell-HLint3.html#v:parseModuleEx [2]: https://hackage.haskell.org/package/ghc-exactprint-0.3.1/docs/Language-Haskell-GHC-ExactPrint-Parsers.html#v:parseModuleWithCpp On Thu, Aug 6, 2015 at 10:33 PM, Carlo Nucera wrote: > Hi all, I'm writing a tool to analyze source code of a package, which uses > haskell-src-extra. As copied from hackage, libraries may contain some extra > stuff (for example, cpp directives). What is the modern way to preprocess the > package (configuring for the environment, running the cpp ecc) to obtain code > which is guaranteed to be parsed by haskell-src-extra? > > Ideally I'd like to leave most of the logic for this part outside of the > package. Could you point me towards some libraries doing a similar thing? > > Best regards > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From jeffbrown.the at gmail.com Thu Aug 6 22:29:59 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 6 Aug 2015 15:29:59 -0700 Subject: [Haskell-cafe] FGL: The cost and propoer way of changing the label at a node. Message-ID: Is changing the label at a node O(N)? The only way I can think of to do it is with a map, like the following -- which works, but seems like its speed must be linear in the number of nodes of the graph: > :m Data.Graph.Inductive.Example Data.Graph.Inductive.Graph > let f c@(adjIn, node, lab, adjOut) = case node of {1 -> (adjIn, node, 'b', adjOut); _ -> c} > loop mkGraph [(1,'a')] [(1,1,())] > gmap f loop mkGraph [(1,'b')] [(1,1,())] > Is that in fact the right way? Am I somehow missing the point of FGL if I have to do a lot of that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Thu Aug 6 22:41:41 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 7 Aug 2015 08:41:41 +1000 Subject: [Haskell-cafe] FGL: The cost and propoer way of changing the label at a node. In-Reply-To: References: Message-ID: The easiest way of changing the label of one node is to obtain its Context using `match`, and update the label in the Context and then put it back in the graph with (&). Ignoring log factors (which are from the graph implementations, not the FGL model) this ends up being O(|degree of node|). On 7 August 2015 at 08:29, Jeffrey Brown wrote: > Is changing the label at a node O(N)? > > The only way I can think of to do it is with a map, like the following -- > which works, but seems like its speed must be linear in the number of nodes > of the graph: > >> :m Data.Graph.Inductive.Example Data.Graph.Inductive.Graph >> let f c@(adjIn, node, lab, adjOut) = case node of {1 -> (adjIn, node, 'b', >> adjOut); _ -> c} >> loop > mkGraph [(1,'a')] [(1,1,())] >> gmap f loop > mkGraph [(1,'b')] [(1,1,())] >> > > Is that in fact the right way? Am I somehow missing the point of FGL if I > have to do a lot of that? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ok at cs.otago.ac.nz Thu Aug 6 23:39:26 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 7 Aug 2015 11:39:26 +1200 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: Message-ID: <5B04BE1D-551F-427E-8FD9-2B6B34CD4F05@cs.otago.ac.nz> On 5/08/2015, at 10:28 pm, Oliver Charles wrote: > That's not particularly bad here, the really pain is repeatedly having to do this for every single symbol I'm using. I'd prefer to be able to write > > image = > let css = let import CSS in [ width (px 50) ] > in let import HTML in img [ width 50, style css ] This is very like the 'open' directive in SML. The SML version would be something like val image = let val css = let open CSS in [width (px 50)] end in let open HTML in img [width 50, style css] end end So there's prior art. From ollie at ocharles.org.uk Fri Aug 7 08:25:18 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 07 Aug 2015 08:25:18 +0000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: <1438806318-sup-9062@sabre> References: <1438806318-sup-9062@sabre> Message-ID: On Wed, Aug 5, 2015 at 9:29 PM Edward Z. Yang wrote: > Hello Oliver, > > This should be a relatively straightforward extension to the renamer. > This is good news! Someone on Reddit mentioned something that hasn't come up here yet - what happens with Template Haskell and quasiquoters? Does the renamer fire before that stage is reached? I don't see any reason that you couldn't import TH "macros" locally, as you can any other top-level definition, unless there's a limitation in GHC. One other point that hasn't been mentioned yet, but was implicit with my original proposal of having the full power of import - should we be able to hide names in a local context? That is, should I be able to do let import Prelude hiding (div) import HTML in div "Hello, World!" My guess is that now that we're heading towards a syntax extension where we can open/unqualify a qualified import this is probably not on the table, but I thought I should raise it first before starting to work on a more formal proposal. *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Fri Aug 7 08:26:54 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 07 Aug 2015 08:26:54 +0000 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: <55C2EE59.90201@gmail.com> References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> <758f1a84d1794041b707f1ac172307f9@HQWS-EXMB-01.main.covenanteyes.com> <55C2EE59.90201@gmail.com> Message-ID: On Thu, Aug 6, 2015 at 6:19 AM Vlatko Basic wrote: > The old Turbo Pascal keyword "with" (used for records) popped up in my > mind. > It's rather clear for namespace resolution and would look something like > this: > > with Data.ByteString $ do > map f ... > > with Prelude $ do > map f ... > > or more explicit > > withImport Data.ByteString $ do > .... > One problem with this is that it forces an ordering on statements. Sometimes you might want to push the imports to the side, by moving them to a where clause, rather than a let binding. I'm hoping that whatever we propose would allow you to do this. That's why I think the syntax construct needs to be something that appears at the time of doing bindings. *ocharles* -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Aug 7 15:16:43 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 7 Aug 2015 11:16:43 -0400 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> <758f1a84d1794041b707f1ac172307f9@HQWS-EXMB-01.main.covenanteyes.com> <55C2EE59.90201@gmail.com> Message-ID: <478A29C1-D9E2-4140-94B7-A178F7A5D372@cis.upenn.edu> This all seems to be solidifying nicely. From my perspective, I didn't really like the original proposal, but am now in favor of where it has evolved -- with all imports declared at the top, and then adding `import ...` to the syntax of local declarations. I'm not sure where the trouble around instances comes from in this idea, though. Even if a module is imported qualified, all of its instances are available anywhere, and I don't see that changing here. As Edward said, this would just be a small change in the renamer. Is it time to make a wiki page and post a feature request? I think so. Thanks! Richard On Aug 7, 2015, at 4:26 AM, Oliver Charles wrote: > On Thu, Aug 6, 2015 at 6:19 AM Vlatko Basic wrote: > The old Turbo Pascal keyword "with" (used for records) popped up in my mind. > It's rather clear for namespace resolution and would look something like this: > > with Data.ByteString $ do > map f ... > > with Prelude $ do > map f ... > > or more explicit > > withImport Data.ByteString $ do > .... > > One problem with this is that it forces an ordering on statements. Sometimes you might want to push the imports to the side, by moving them to a where clause, rather than a let binding. I'm hoping that whatever we propose would allow you to do this. That's why I think the syntax construct needs to be something that appears at the time of doing bindings. > > ocharles > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Aug 7 15:41:55 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 7 Aug 2015 11:41:55 -0400 Subject: [Haskell-cafe] Syntax extension - adding import support to let/where bindings In-Reply-To: <478A29C1-D9E2-4140-94B7-A178F7A5D372@cis.upenn.edu> References: <37243244-F660-45E1-8965-1FF072D1AA14@gmail.com> <758f1a84d1794041b707f1ac172307f9@HQWS-EXMB-01.main.covenanteyes.com> <55C2EE59.90201@gmail.com> <478A29C1-D9E2-4140-94B7-A178F7A5D372@cis.upenn.edu> Message-ID: On Fri, Aug 7, 2015 at 11:16 AM, Richard Eisenberg wrote: > This all seems to be solidifying nicely. From my perspective, I didn't > really like the original proposal, but am now in favor of where it has > evolved -- with all imports declared at the top, and then adding `import > ...` to the syntax of local declarations. I'm not sure where the trouble > around instances comes from in this idea, though. Even if a module is > imported qualified, all of its instances are available anywhere, and I > don't see that changing here. As Edward said, this would just be a small > change in the renamer. The initial request wanted the import to actually be done in in the restricted scope; keeping the actual qualified import at the top and removing the qualification in the inner scope came later. That initial version has problems for instances; the later revision does not. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Fri Aug 7 16:22:33 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Fri, 7 Aug 2015 17:22:33 +0100 Subject: [Haskell-cafe] Waiting for async exception (and nothing else) In-Reply-To: References: Message-ID: Hi Robin, Thanks for the pointer. I can't find the thread in question after a bit of googling, but suspect you mean using System.Mem.StableName? From the docs, Stable names are reclaimed by the runtime system when they are no longer > needed. which seems like it's not going to work. It does point me towards the related Foreign.StablePtr which seems like it should do what I want. Cheers, David On 6 August 2015 at 21:53, Robin Palotai wrote: > You can make a stable name for the MVar which will prevent the rts from > collecting it. Google it, there was a thread about this with Simon Marlow. > > Robin > > On Wed, Aug 5, 2015, 12:43 PM David Turner > wrote: > >> Hi, >> >> Is there an elegant way to have a thread wait for an async exception but >> nothing else? I tend to do something like >> >> forever $ threadDelay 1000000000 >> >> but this seems like a bit of a hack. Waiting on an otherwise-unused MVar >> or doing 'atomically retry' don't work because GHC kills them off straight >> away. >> >> The context is when using an API that only has a 'withMyThingy' wrapper >> and no explicit openMyThingy and closeMyThingy alternatives. Perhaps that's >> an API problem and the only way to work around this is with something a bit >> hacky? >> >> Cheers, >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Fri Aug 7 16:31:07 2015 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 7 Aug 2015 18:31:07 +0200 Subject: [Haskell-cafe] "cabal sdist" oddity Message-ID: Cabal from HEAD started to issue the warning "Warning: Cannot run preprocessors. Run 'configure' command first." when running "cabal sdist" after a "cabal install", see e.g. https://travis-ci.org/haskell-opengl/OpenGL/jobs/74581138#L264. Previous versions didn't do this, see e.g. https://travis-ci.org/haskell-opengl/OpenGL/jobs/74581137#L264. Somehow the warning doesn't make sense, because the package has obviously been built before, so configuration must have happened, too. Is this a new bug in Cabal? Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Fri Aug 7 16:41:59 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 7 Aug 2015 19:41:59 +0300 Subject: [Haskell-cafe] "cabal sdist" oddity In-Reply-To: References: Message-ID: <55C4DFD7.8080001@ro-che.info> On 07/08/15 19:31, Sven Panne wrote: > Cabal from HEAD started to issue the warning > > "Warning: Cannot run preprocessors. Run 'configure' command first." > > when running "cabal sdist" after a "cabal install", see e.g. > https://travis-ci.org/haskell-opengl/OpenGL/jobs/74581138#L264. Previous > versions didn't do this, see > e.g. https://travis-ci.org/haskell-opengl/OpenGL/jobs/74581137#L264. > Somehow the warning doesn't make sense, because the package has > obviously been built before, so configuration must have happened, too. > > Is this a new bug in Cabal? As a guess, configuration may have happened in a different dist directory (like, if you were using sandboxes). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From svenpanne at gmail.com Fri Aug 7 17:34:06 2015 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 7 Aug 2015 19:34:06 +0200 Subject: [Haskell-cafe] "cabal sdist" oddity In-Reply-To: <55C4DFD7.8080001@ro-che.info> References: <55C4DFD7.8080001@ro-che.info> Message-ID: 2015-08-07 18:41 GMT+02:00 Roman Cheplyaka : > As a guess, configuration may have happened in a different dist > directory (like, if you were using sandboxes). > Hmmm, both "cabal install" and "cabal sdist" happened in the same directory without any sandboxes, see the logs in the OP and the config at https://github.com/haskell-opengl/OpenGL/blob/master/.travis.yml. If the sdist really magically happens elsewhere, I consider this a bug in cabal. In general, cabal's behavior is a bit opaque IMHO... -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Fri Aug 7 17:55:29 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Fri, 7 Aug 2015 19:55:29 +0200 Subject: [Haskell-cafe] Serialize to Haskell Message-ID: Hello! I'm wondering if it's possible to serialize some data to a format that is valid Haskell. In practice I would read a file like this: module Foo where myData :: MyData myData = MyData {name = "foo", descr = "test" ... } Reading this into a program is easily feasible with Hint, for example. Then the program would modify some data and serialize it back to: module Foo where myData :: MyData myData = MyData {name = "bar", descr = "test2" ... } In practice I think that the format should be a subset of Haskell that is not Turing-complete. A bit like JSON, which is a subset of Javascript but not Turing complete. Is it possible? Thanks, Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Fri Aug 7 18:55:47 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sat, 8 Aug 2015 01:55:47 +0700 Subject: [Haskell-cafe] Fwd: Haskell Weekly News In-Reply-To: References: Message-ID: *Editorial:*Over a month has elapsed since the last issue. Is the Weekly News turning into the Monthly News? No. I've been working on getting full-length articles into the News. Imagine articles that investigate, analyze, and give the low-down on hoary issues like cabal hell that cannot be telegrammed in a two-sentence paragraph. But my time isn't quantum mechanical. When I do A, I can't at the same time do B. I know that there are fine haskellers who'd gladly write for pay. However, HWN has never had a foundation in place for paid articles. Building that foundation takes time. Now that much of it is in place, let me duly announce that HWN hereby solicits reviews, reports, criticism pieces, and personal essays. - Flexible word count: anywhere between 250 and 750 is fine. - Send me an outline first. - Published articles pay at 68 bitcents, under 200 euros / dollars right now. - You can count on extensive editing for the requisite polish and also to conform to 'house' style. Interested? Email me with a subject line that starts with "[HWN pitch]" followed by the title of your piece. In the body, outline the main points you'll hit and explain how they engage the HWN readership. So on with the News : *Top picks:* - Galois organizes this year's ICFP contest. The 72-hour countdown has just started! After tantalizing us with whisperings of more computational archaelogy (see 2006 ICFP contest ) centering on honey bees, national food security, and the Hebrew alphabet; Portland, Oregon reveals a classic offline AI game programming challenge . According to redditor skatenerd , "it's a lot like Tetris, except you know what pieces are coming." - Rick Dzekman offers constructive criticism based on his "poor UX (User Experience) of a great language (Haskell)". Among the low-lying fruit he identifies: a web search doesn't always link to the latest version on the Hackage website, something easily fixed. Not so low-lying are Cabal, a modern IDE, and Haskell wiki documentation. In sympathy with the sentiments are HN readers and /r/haskell . - Christoffer Stjernl?f brings attention to how only in imperative land does one encounter the awfulness of the same boolean expression getting tested twice in a nested if-inside-if. He uses it to make "the case for controlled side effects", the title of his blog post. Discussions on /r/haskell and Hacker News . - Alexey Shmalko introduces Haskell IO as "the command pattern" to object-oriented programmers. His article resists mentioning monads or do-notation. Appreciated on /r/haskell . - The latest issue of the Functional Works monthly newsletter reminds us about Chakravarty and Keller's "An Introduction to Computing (with Haskell)", a textbook written from multiple years teaching first-year CS. At 150 pages, the book dodges monads -- nary a single mention -- and zooms into I/O actions. It's out-of-print but readily downloadable . - The program for this year's Haskell Symposium is out. PC chaired by Ben Lippmeier, it's truly a smorgasbord. If you can't find a preprint, indefatigable redditors might just have got you covered. - Zhenjiang Hu, John Hughes, and Meng Wang publish "How Functional Programming Mattered" , a survey of FP's impact outside its academic domain in recent years. It is written in the mold of and complements A History of Haskell: Being Lazy with Class (2007) . Comprising 17.5 pages of 2-column ACM-proceedings-style 9-point text, it houses the bibliographical treasure of 122 references, itself a contribution to any debate over priority. /r/haskell - Victor Maia writes a lambda calculus evaluator in javascript that computes 200^200 mod 31 without breaking a sweat. No mean feat, since all numbers are church numerals. How did he pull it off? His javascript implements a fragment of Lamping's optimal algorithm, which is based on interaction nets. (Optimality here is in the sense of Levy-optimality: keeping the number of beta reductions down to an absolute minimum. By itself, this count is generally an inaccurate measure of efficiency.) He wonders on stackoverflow why optimal evaluation has such magical superpowers. The convo at /r/haskell has yet to crack the mystery. - Philippe Desjardins Proulx codes and compares a basic arithmetic expression evaluator in all 5 languages of F#, Scala, Haskell, C++, and Julia. The evaluator acts on a given tree: Philippe doesn't touch parsing. Go, Erlang, and Elixir versions are in HN comments . - Redditor gilmi starts a discussion on /r/haskell about the various FRP systems out there and whether they're ready for real-world use. Ollie Charles glosses classic vs arrowized systems, Doug Beardsley at Soostone testifies that "reflex is the first thing I've used that makes building web UIs enjoyable for me, which is very exciting", and Joseph Abrahamson channels Conal Elliott in staking out the acronym to mean exclusively those systems that admit continuous time. *Quotes of the Week:* - Andrew Cowie : The highlight of my day is "cd ~/src/haskell/stack ; git pull ; stack install". What goodies have they landed this time? - Cale Gibbard : I basically never turn on IncoherentInstances because it basically means "I don't want anything to work, and I'd like to be confused about why." - Redditor fegu : Haskell is like a mental drug, after a few initial hits you absolutely crave it. You will forego lucrative .Net career moves just to keep it, hence your long-term career will take a hit. But the days will be brighter, more enjoyable and there is just that glimmer of hope that in the end you will be able to practice Haskell full time in a well-paid position. I wish I was joking. - On ageism in the software industry : Maybe I've been lucky, but this doesn't mesh with my experience at all. The oldest guys at my company are the ones teaching the classes about Haskell or Scalaz. They're the ones trying out Elixir. They're the ones building frameworks for everyone else to build on top of. The youngest people are banging out feature #4,501 for the website. *Real World Haskell of the Week:* - Fed up with the laggy Netflix UI? Check out the snappy Haskell-powered instantwatcher.com. H/T erichmond on HN . -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Fri Aug 7 23:04:12 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Sat, 8 Aug 2015 01:04:12 +0200 Subject: [Haskell-cafe] Serialize to Haskell In-Reply-To: References: Message-ID: Hi Matthew, yes that's exactly that. I want to do exactly what you would do with a JSON file (read, write), but with a data format that would be valid Haskell (instead of valid javascript). On Fri, Aug 7, 2015 at 8:06 PM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > Hi Corentin, > > I don't quite understand your question please can you explain a bit > more. Do you want to read a valid haskell source file, perform some > changes to the file and then print out a valid source file? > > I am a bit confused about the bit about turing-completeness. > > Matt > > On Fri, Aug 7, 2015 at 7:55 PM, Corentin Dupont > wrote: > > Hello! > > I'm wondering if it's possible to serialize some data to a format that is > > valid Haskell. > > In practice I would read a file like this: > > > > module Foo where > > > > myData :: MyData > > myData = MyData {name = "foo", > > descr = "test" > > ... > > } > > > > Reading this into a program is easily feasible with Hint, for example. > Then > > the program would modify some data and serialize it back to: > > > > module Foo where > > > > myData :: MyData > > myData = MyData {name = "bar", > > descr = "test2" > > ... > > } > > > > In practice I think that the format should be a subset of Haskell that is > > not Turing-complete. > > A bit like JSON, which is a subset of Javascript but not Turing complete. > > Is it possible? > > > > Thanks, > > Corentin > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blaze at ruddy.ru Fri Aug 7 23:12:24 2015 From: blaze at ruddy.ru (Andrey Sverdlichenko) Date: Fri, 7 Aug 2015 16:12:24 -0700 Subject: [Haskell-cafe] ANN: happstack-server-tls-cryptonite Message-ID: Hi, I'd like to announce happstack-server-tls-cryptonite, package adding native TLS support to happstack, utilizing hs-tls and cryptonite packages by Vincent Hanquez. You can now run secure web server without using OpenSSL or other foreign libraries. This package is almost drop-in replacement for happstack-server-tls, just change Happstack.Server.SimpleHTTPS to Happstack.Server.SimpleTLS in imports. Regards, Andrey From donn at avvanta.com Fri Aug 7 23:15:17 2015 From: donn at avvanta.com (Donn Cave) Date: Fri, 7 Aug 2015 16:15:17 -0700 (PDT) Subject: [Haskell-cafe] Serialize to Haskell In-Reply-To: References: Message-ID: <20150807231517.AEAFD93C49@mail.avvanta.com> quoth Corentin Dupont > I want to do exactly what you would do with a JSON file (read, write), but > with a data format that would be valid Haskell (instead of valid > javascript). OK, but I think this doesn't do much to clear up the mystery. Why valid Haskell? That will shed a lot of light on what you really want. You know you can write and read any value that supports Read and Show classes, but there's more valid Haskell that isn't values at all, like the type declarations in your example. And the module declaration, not sure whether that's in any sense a value but I don't think it's going to support Read or Show. The applications I can think of don't need type declarations, and the module would complicate things at best. Donn PS - if you're happy to simply read and write values, next I think it would probably be prudent to verify that this scales to whatever you have in mind, I mean very large values might be more efficiently processed in some other way. From matthewtpickering at gmail.com Fri Aug 7 23:24:36 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 8 Aug 2015 01:24:36 +0200 Subject: [Haskell-cafe] Serialize to Haskell In-Reply-To: References: Message-ID: Alan Zimmerman and myself have written a library which aims to make these sorts of transformations easy. We are still in the early stages but depending on what exactly you want to do then it might be suitable for your purposes. Looking now on hackage the documentation isn't very good so it might not be obvious how you're meant to use it. https://hackage.haskell.org/package/ghc-exactprint The basic idea is, use one of the parsers from the Parsers module, do a (generic) transformation on the resulting ast, then call `exactPrintWithAnns` on the AST and the resulting annotations. For simple transformations (moving, deletion, renaming) it is sufficient to not modify the annotations. When doing insertions/replacements, you will probably have to modify the annotations in some way to get a sensible output. https://hackage.haskell.org/package/ghc-exactprint-0.3.1/docs/Language-Haskell-GHC-ExactPrint-Parsers.html I don't think I'm quite sure what exactly you want, if you can give a specific use case then it will help me give a better answer. We also hang around in #haskell-refactorer if it is transforming source files that you are interested in. Here is an example of how to use the library to insert a type signature for example. https://github.com/alanz/ghc-exactprint/blob/master/examples/InsertSignature.hs Happy to answer any more questions.. Matt On Sat, Aug 8, 2015 at 1:04 AM, Corentin Dupont wrote: > Hi Matthew, > yes that's exactly that. > I want to do exactly what you would do with a JSON file (read, write), but > with a data format that would be valid Haskell (instead of valid > javascript). > > > On Fri, Aug 7, 2015 at 8:06 PM, Matthew Pickering > wrote: >> >> Hi Corentin, >> >> I don't quite understand your question please can you explain a bit >> more. Do you want to read a valid haskell source file, perform some >> changes to the file and then print out a valid source file? >> >> I am a bit confused about the bit about turing-completeness. >> >> Matt >> >> On Fri, Aug 7, 2015 at 7:55 PM, Corentin Dupont >> wrote: >> > Hello! >> > I'm wondering if it's possible to serialize some data to a format that >> > is >> > valid Haskell. >> > In practice I would read a file like this: >> > >> > module Foo where >> > >> > myData :: MyData >> > myData = MyData {name = "foo", >> > descr = "test" >> > ... >> > } >> > >> > Reading this into a program is easily feasible with Hint, for example. >> > Then >> > the program would modify some data and serialize it back to: >> > >> > module Foo where >> > >> > myData :: MyData >> > myData = MyData {name = "bar", >> > descr = "test2" >> > ... >> > } >> > >> > In practice I think that the format should be a subset of Haskell that >> > is >> > not Turing-complete. >> > A bit like JSON, which is a subset of Javascript but not Turing >> > complete. >> > Is it possible? >> > >> > Thanks, >> > Corentin >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > From snailandmail at gmail.com Fri Aug 7 23:28:57 2015 From: snailandmail at gmail.com (Nikita Kartashov) Date: Sat, 8 Aug 2015 02:28:57 +0300 Subject: [Haskell-cafe] More concise code using phantom types Message-ID: Hello! Consider the following code: module Units where data Units a = U Double deriving Eq units :: Double -> a -> Units a units value _ = U value data Meters data Yards meters = undefined :: Meters yards = undefined :: Yards instance Show Meters where show _ = "meters" instance Show Yards where show _ = "yards" extractA :: Units a -> a extractA = undefined instance Show a => Show (Units a) where show u@(U value) = show value ++ " " ++ show $ extractA u main = (print $ units 5 yards) >> (print $ units 5 meters) Is it possible to use something instead extractA function here? For example, substitute "extractA u? with ?undefined :: a?? GHC disallows it, so is there a way to explain that I only need a token with type a? Also, with highlighting on lpaste: http://lpaste.net/138219. With regards, Nikita Kartashov -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From corentin.dupont at gmail.com Fri Aug 7 23:41:05 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Sat, 8 Aug 2015 01:41:05 +0200 Subject: [Haskell-cafe] Serialize to Haskell In-Reply-To: <20150807231517.AEAFD93C49@mail.avvanta.com> References: <20150807231517.AEAFD93C49@mail.avvanta.com> Message-ID: Hi, it's for the Nomyx game (www.nomyx.net). In this game the players submit pieces of code ("rules") that are written in Haskell. I would like to serialize the rules submitted to a Haskell format, to give the possibility to the players to work on their rules offline, to check them with a compiler and store them on Github. I would look like: module MyRules where myRule1 :: Rule myRule1 = Rule {name = "my rule 1", descr = "this is my rule" code = [c|putStrLn "test"|] } Currently the player is able to submit this module file to Nomyx. Nomyx loads the file through a Haskell interpreter. Once it's done, the player is able to propose "myRule1" in the game. But what if the player wants to modify the rule in Nomyx? Then I would like to modify the original file to reflect the changes. In the example, the field "code" contains the actual code of the rule in Haskell. I use a quasi-quotation because I parse it with an interpreter to validate it. But otherwise it is is considered as a simple string. This is why a format in Haskell would suit me (instead of XML or JSON): some of the data I need to serialize is indeed Haskell code. Hope I was not too obscure :) Best, C On Sat, Aug 8, 2015 at 1:15 AM, Donn Cave wrote: > quoth Corentin Dupont > > > I want to do exactly what you would do with a JSON file (read, write), > but > > with a data format that would be valid Haskell (instead of valid > > javascript). > > OK, but I think this doesn't do much to clear up the mystery. > > Why valid Haskell? > > That will shed a lot of light on what you really want. You know > you can write and read any value that supports Read and Show classes, > but there's more valid Haskell that isn't values at all, like the > type declarations in your example. And the module declaration, > not sure whether that's in any sense a value but I don't think > it's going to support Read or Show. > > The applications I can think of don't need type declarations, and > the module would complicate things at best. > > Donn > > PS - if you're happy to simply read and write values, next I think > it would probably be prudent to verify that this scales to whatever > you have in mind, I mean very large values might be more efficiently > processed in some other way. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Fri Aug 7 23:52:19 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Sat, 8 Aug 2015 01:52:19 +0200 Subject: [Haskell-cafe] Serialize to Haskell In-Reply-To: References: Message-ID: The Read and Show instances are exactly for that purpose..... 2015-08-08 1:04 GMT+02:00 Corentin Dupont : > Hi Matthew, > yes that's exactly that. > I want to do exactly what you would do with a JSON file (read, write), but > with a data format that would be valid Haskell (instead of valid > javascript). > > > On Fri, Aug 7, 2015 at 8:06 PM, Matthew Pickering < > matthewtpickering at gmail.com> wrote: > >> Hi Corentin, >> >> I don't quite understand your question please can you explain a bit >> more. Do you want to read a valid haskell source file, perform some >> changes to the file and then print out a valid source file? >> >> I am a bit confused about the bit about turing-completeness. >> >> Matt >> >> >> On Fri, Aug 7, 2015 at 7:55 PM, Corentin Dupont >> wrote: >> > Hello! >> > I'm wondering if it's possible to serialize some data to a format that >> is >> > valid Haskell. >> > In practice I would read a file like this: >> > >> > module Foo where >> > >> > myData :: MyData >> > myData = MyData {name = "foo", >> > descr = "test" >> > ... >> > } >> > >> > Reading this into a program is easily feasible with Hint, for example. >> Then >> > the program would modify some data and serialize it back to: >> > >> > module Foo where >> > >> > myData :: MyData >> > myData = MyData {name = "bar", >> > descr = "test2" >> > ... >> > } >> > >> > In practice I think that the format should be a subset of Haskell that >> is >> > not Turing-complete. >> > A bit like JSON, which is a subset of Javascript but not Turing >> complete. >> > Is it possible? >> > >> > Thanks, >> > Corentin >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilyaraz at gmail.com Sat Aug 8 01:11:06 2015 From: ilyaraz at gmail.com (Ilya Razenshteyn) Date: Fri, 7 Aug 2015 18:11:06 -0700 Subject: [Haskell-cafe] monads, memoization etc Message-ID: Hi everyone, I'm new to Haskell and decided to learn a bit about monads and their utility. Actually, what worked nicely for me was: to read first several pages from "Computational lambda-calculus and monads", then do exercises from https://tonymorris.github.io/blog/posts/20-intermediate-haskell-exercises/, and then map these exercises to actual functions in the standard library. Then, I decided to implement memoization to practice a bit with ST, HashTable's and such. Here is what I managed to get: http://pastebin.com/79pwjLPL . This code computes Fibonacci numbers while caching the intermediate values in a hash table. I tried to make the code as fast as possible (it runs in under 15 seconds, when computing 1M'th Fibonacci number modulo 999983). It uses the package hashtables. I have several question about all this. First, is there a cheap way to speed this code up? Note that I'm interested in a universal memoization strategy, that is I don't want to use arrays instead of hash tables etc. Second, is this code the right way of doing what it does (assuming that I really care about the performance)? Third question. Currently, the code passes "cache" everywhere. It would be natural to combine ST with something like ReaderT to store it there. What is a way to do it? I tried something like "ReaderT (HashTable s) (ST s) Int", but I have not managed to get it work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilyaraz at gmail.com Sat Aug 8 01:17:04 2015 From: ilyaraz at gmail.com (Ilya Razenshteyn) Date: Fri, 7 Aug 2015 18:17:04 -0700 Subject: [Haskell-cafe] monads, memoization etc In-Reply-To: References: Message-ID: quickfix: 10M'th, not 1M'th of course. Cheers, Ilya On Fri, Aug 7, 2015 at 6:11 PM, Ilya Razenshteyn wrote: > Hi everyone, > > I'm new to Haskell and decided to learn a bit about monads and their > utility. Actually, what worked nicely for me was: to read first several > pages from "Computational lambda-calculus and monads", then do exercises > from > https://tonymorris.github.io/blog/posts/20-intermediate-haskell-exercises/, > and then map these exercises to actual functions in the standard library. > > Then, I decided to implement memoization to practice a bit with ST, > HashTable's and such. Here is what I managed to get: > http://pastebin.com/79pwjLPL . This code computes Fibonacci numbers while > caching the intermediate values in a hash table. I tried to make the code > as fast as possible (it runs in under 15 seconds, when computing 1M'th > Fibonacci number modulo 999983). It uses the package hashtables. > > I have several question about all this. > > First, is there a cheap way to speed this code up? Note that I'm > interested in a universal memoization strategy, that is I don't want to use > arrays instead of hash tables etc. > > Second, is this code the right way of doing what it does (assuming that I > really care about the performance)? > > Third question. Currently, the code passes "cache" everywhere. It would be > natural to combine ST with something like ReaderT to store it there. What > is a way to do it? I tried something like "ReaderT (HashTable s) (ST s) > Int", but I have not managed to get it work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Sat Aug 8 01:29:42 2015 From: will.yager at gmail.com (Will Yager) Date: Fri, 7 Aug 2015 18:29:42 -0700 Subject: [Haskell-cafe] monads, memoization etc In-Reply-To: References: Message-ID: <9A6EB2CB-86AE-4454-94EA-7E208587A485@gmail.com> You could use a StateT (Map k v) or something and avoid using ST. No idea what the performance would be like. You could probably get a performance boost using a memo data structure optimized for numeric keys, like IntMap. --Will > On Aug 7, 2015, at 18:11, Ilya Razenshteyn wrote: > > Hi everyone, > > I'm new to Haskell and decided to learn a bit about monads and their utility. Actually, what worked nicely for me was: to read first several pages from "Computational lambda-calculus and monads", then do exercises from https://tonymorris.github.io/blog/posts/20-intermediate-haskell-exercises/, and then map these exercises to actual functions in the standard library. > > Then, I decided to implement memoization to practice a bit with ST, HashTable's and such. Here is what I managed to get: http://pastebin.com/79pwjLPL . This code computes Fibonacci numbers while caching the intermediate values in a hash table. I tried to make the code as fast as possible (it runs in under 15 seconds, when computing 1M'th Fibonacci number modulo 999983). It uses the package hashtables. > > I have several question about all this. > > First, is there a cheap way to speed this code up? Note that I'm interested in a universal memoization strategy, that is I don't want to use arrays instead of hash tables etc. > > Second, is this code the right way of doing what it does (assuming that I really care about the performance)? > > Third question. Currently, the code passes "cache" everywhere. It would be natural to combine ST with something like ReaderT to store it there. What is a way to do it? I tried something like "ReaderT (HashTable s) (ST s) Int", but I have not managed to get it work. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Aug 8 03:02:59 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 7 Aug 2015 23:02:59 -0400 Subject: [Haskell-cafe] More concise code using phantom types In-Reply-To: References: Message-ID: On Fri, Aug 7, 2015 at 7:28 PM, Nikita Kartashov wrote: > Is it possible to use something instead extractA function here? For > example, substitute "extractA u? with ?undefined :: a?? > GHC disallows it, so is there a way to explain that I only need a token > with type a? > It needs a function type there. That said, `const undefined' might work, or even just `undefined', if it can infer the type correctly. I don't *think* you can use 'a' as a type there meaningfully; IIRC it doesn't scope over the method definition, so `a' would be referring to a new type, not the one in the instance header. The ScopedTypeVariables extension would help, along with InstanceSigs so you can specify a signature for `show` with a `forall' in it to activate the scope. See the example at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type-class-extensions.html#instance-sigs for how to do it. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilyaraz at gmail.com Sat Aug 8 10:30:47 2015 From: ilyaraz at gmail.com (Ilya Razenshteyn) Date: Sat, 8 Aug 2015 03:30:47 -0700 Subject: [Haskell-cafe] monads, memoization etc In-Reply-To: References: Message-ID: The third problem (not passing the state everywhere) got solved by using lift. Thanks to the people from #haskell channel. Interestingly, the code became almost twice as slow as a result.. The new code can be found here: http://pastebin.com/hkeJECem On Fri, Aug 7, 2015 at 6:17 PM, Ilya Razenshteyn wrote: > quickfix: 10M'th, not 1M'th of course. > > > Cheers, > Ilya > > On Fri, Aug 7, 2015 at 6:11 PM, Ilya Razenshteyn > wrote: > >> Hi everyone, >> >> I'm new to Haskell and decided to learn a bit about monads and their >> utility. Actually, what worked nicely for me was: to read first several >> pages from "Computational lambda-calculus and monads", then do exercises >> from >> https://tonymorris.github.io/blog/posts/20-intermediate-haskell-exercises/, >> and then map these exercises to actual functions in the standard library. >> >> Then, I decided to implement memoization to practice a bit with ST, >> HashTable's and such. Here is what I managed to get: >> http://pastebin.com/79pwjLPL . This code computes Fibonacci numbers >> while caching the intermediate values in a hash table. I tried to make the >> code as fast as possible (it runs in under 15 seconds, when computing 1M'th >> Fibonacci number modulo 999983). It uses the package hashtables. >> >> I have several question about all this. >> >> First, is there a cheap way to speed this code up? Note that I'm >> interested in a universal memoization strategy, that is I don't want to use >> arrays instead of hash tables etc. >> >> Second, is this code the right way of doing what it does (assuming that I >> really care about the performance)? >> >> Third question. Currently, the code passes "cache" everywhere. It would >> be natural to combine ST with something like ReaderT to store it there. >> What is a way to do it? I tried something like "ReaderT (HashTable s) (ST >> s) Int", but I have not managed to get it work. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Sat Aug 8 11:09:06 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Sat, 8 Aug 2015 14:09:06 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` Message-ID: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Hello, i would like to suggest an idea for modifying the basic data/newtype syntax in Haskell: replace the equality sign `=` with `::=`. When i started learning Haskell, the most confusing part of the syntax for me was the equality sign in `data` definition. I could not even guess what the `data` definition meant without reading a chapter or two about types in Haskell, and i think it was partially due to the equality sign. I still find this notation inconsistent with other uses of the equality sign in Haskell and in general. For example, in type Name = String data Date = Date Int Int Int data Anniversary = Birthday Name Date | Wedding Name Name Date the second line is particularly disorienting IMO because on two sides of the equality, `Date` denotes different things. As far as i understand, in all contexts except those of `data` and `newtype` definitions, the equality sign in Haskell denotes the actual equality for all purposes: if a line foo x y = bar y x is present in a program, `foo a b` and `bar b a` can be used more or less interchangeably elsewhere in the program. Similarly, if the line type Name = String is present, `Name` can be used as `String`. Clearly, the equality in data Date = Date Int Int Int does not have such property. I think that if `::=` was used instead of `=` in `data` and `newtype` definitions, this would suggest to a newcomer that the syntax of the two sides might be different, and would helpfully remind of the Backus?Naur Form for syntax rules. I think that a newcomer to Haskell, like myself, would have had a better chance of guessing the meaning of type Name = String data Date ::= Date Int Int Int data Anniversary ::= Birthday Name Date | Wedding Name Name Date IMO this would make the program easier to read in general and the difference between `type` and `newtype` more clear. Maybe the can even make the use of keywords redundant, by allowing to write simply Name = String Date ::= Date Int Int Int Anniversary ::= Birthday Name Date | Wedding Name Name Date What do you think? Alexey. From ollie at ocharles.org.uk Sat Aug 8 11:40:40 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Sat, 08 Aug 2015 11:40:40 +0000 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: There is reasonable reasoning here, but what you suggest breaks almost all Haskell code that has ever been written. Sounds like an idea better suited to the design of a new language :) Also, i think you need the newtype/data distinction as I believe they are operationally different wrt laziness. ocharles On Sat, 8 Aug 2015 12:09 pm Alexey Muranov wrote: > Hello, > > i would like to suggest an idea for modifying the basic data/newtype > syntax in Haskell: replace the equality sign `=` with `::=`. > > When i started learning Haskell, the most confusing part of the syntax for > me was the equality sign in `data` definition. I could not even guess what > the `data` definition meant without reading a chapter or two about types in > Haskell, and i think it was partially due to the equality sign. I still > find this notation inconsistent with other uses of the equality sign in > Haskell and in general. > > For example, in > > type Name = String > data Date = Date Int Int Int > data Anniversary = Birthday Name Date | Wedding Name Name Date > > the second line is particularly disorienting IMO because on two sides of > the equality, `Date` denotes different things. > > As far as i understand, in all contexts except those of `data` and > `newtype` definitions, the equality sign in Haskell denotes the actual > equality for all purposes: if a line > > foo x y = bar y x > > is present in a program, `foo a b` and `bar b a` can be used more or less > interchangeably elsewhere in the program. Similarly, if the line > > type Name = String > > is present, `Name` can be used as `String`. Clearly, the equality in > > data Date = Date Int Int Int > > does not have such property. > > I think that if `::=` was used instead of `=` in `data` and `newtype` > definitions, this would suggest to a newcomer that the syntax of the two > sides might be different, and would helpfully remind of the Backus?Naur > Form for syntax rules. I think that a newcomer to Haskell, like myself, > would have had a better chance of guessing the meaning of > > type Name = String > data Date ::= Date Int Int Int > data Anniversary ::= Birthday Name Date | Wedding Name Name Date > > IMO this would make the program easier to read in general and the > difference between `type` and `newtype` more clear. Maybe the can even > make the use of keywords redundant, by allowing to write simply > > Name = String > Date ::= Date Int Int Int > Anniversary ::= Birthday Name Date | Wedding Name Name Date > > What do you think? > > Alexey. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Sat Aug 8 12:54:22 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Sat, 8 Aug 2015 15:54:22 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: <6EA9075F-A891-4559-84EE-F8E6057C3FAF@gmail.com> On 8 ao?t 2015, at 14:40, Oliver Charles wrote: > There is reasonable reasoning here, but what you suggest breaks almost all Haskell code that has ever been written. Sounds like an idea better suited to the design of a new language :) > Maybe adding a language pragma or having both would avoid break any code? > Also, i think you need the newtype/data distinction as I believe they are operationally different wrt laziness. > Maybe keeping the `newtype` keyword would suffice? Alexey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Sat Aug 8 14:23:15 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Sat, 8 Aug 2015 16:23:15 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: Hi Alexey, this is indeed a confusion point for many newcomers, including me. In Haskell we are being told that the equality sign really means equality as in "interchangeable", as opposed to "assignment of value" in many other languages. So what about the equal sign in data definition? Plus types and type constructors often have the same name without being the same thing, this adds to the confusion. So I really like your suggestion. However as said Oliver this breaks all existing Haskell code. One thing I quite don't understand is: do we really need to make the newtype/data distinction explicit? If we used only one keyword, it should be quite easy for the compiler to detect the distinction statically. On Sat, Aug 8, 2015 at 1:09 PM, Alexey Muranov wrote: > Hello, > > i would like to suggest an idea for modifying the basic data/newtype > syntax in Haskell: replace the equality sign `=` with `::=`. > > When i started learning Haskell, the most confusing part of the syntax for > me was the equality sign in `data` definition. I could not even guess what > the `data` definition meant without reading a chapter or two about types in > Haskell, and i think it was partially due to the equality sign. I still > find this notation inconsistent with other uses of the equality sign in > Haskell and in general. > > For example, in > > type Name = String > data Date = Date Int Int Int > data Anniversary = Birthday Name Date | Wedding Name Name Date > > the second line is particularly disorienting IMO because on two sides of > the equality, `Date` denotes different things. > > As far as i understand, in all contexts except those of `data` and > `newtype` definitions, the equality sign in Haskell denotes the actual > equality for all purposes: if a line > > foo x y = bar y x > > is present in a program, `foo a b` and `bar b a` can be used more or less > interchangeably elsewhere in the program. Similarly, if the line > > type Name = String > > is present, `Name` can be used as `String`. Clearly, the equality in > > data Date = Date Int Int Int > > does not have such property. > > I think that if `::=` was used instead of `=` in `data` and `newtype` > definitions, this would suggest to a newcomer that the syntax of the two > sides might be different, and would helpfully remind of the Backus?Naur > Form for syntax rules. I think that a newcomer to Haskell, like myself, > would have had a better chance of guessing the meaning of > > type Name = String > data Date ::= Date Int Int Int > data Anniversary ::= Birthday Name Date | Wedding Name Name Date > > IMO this would make the program easier to read in general and the > difference between `type` and `newtype` more clear. Maybe the can even > make the use of keywords redundant, by allowing to write simply > > Name = String > Date ::= Date Int Int Int > Anniversary ::= Birthday Name Date | Wedding Name Name Date > > What do you think? > > Alexey. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at hupel.info Sat Aug 8 14:29:22 2015 From: lars at hupel.info (Lars Hupel) Date: Sat, 8 Aug 2015 16:29:22 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: <55C61242.9010708@hupel.info> Hi Alexey, > I think that if `::=` was used instead of `=` in `data` and `newtype` definitions, this would suggest to a newcomer that the syntax of the two sides might be different, and would helpfully remind of the Backus?Naur Form for syntax rules. I think that a newcomer to Haskell, like myself, would have had a better chance of guessing the meaning of > > type Name = String > data Date ::= Date Int Int Int > data Anniversary ::= Birthday Name Date | Wedding Name Name Date there is already an alternative syntax for declaring datatypes: data Date where Date :: Int -> Int -> Int -> Date data Anniversary where Birthday :: Name -> Date -> Anniversary Wedding :: Name -> Name -> Date -> Anniversary This is called "GADT syntax" and can be enabled with -XGADTSyntax in GHC.* Cheers Lars * The underlying machinery also extends the fragment of admissible datatype declarations beyond what is possible with the standard syntax. See: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 8 14:33:35 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 8 Aug 2015 15:33:35 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: <20150808143335.GI12570@weber> On Sat, Aug 08, 2015 at 04:23:15PM +0200, Corentin Dupont wrote: > One thing I quite don't understand is: do we really need to make the > newtype/data distinction explicit? I'm pretty sure we don't. newtype N = N A defines a datatype isomorphic to data D = D !A but you have to use it slightly differently, that's all. I wrote more about this here: http://stackoverflow.com/posts/21331284/revisions Tom From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 8 14:41:28 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 8 Aug 2015 15:41:28 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808143335.GI12570@weber> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808143335.GI12570@weber> Message-ID: <20150808144128.GJ12570@weber> On Sat, Aug 08, 2015 at 03:33:35PM +0100, Tom Ellis wrote: > On Sat, Aug 08, 2015 at 04:23:15PM +0200, Corentin Dupont wrote: > > One thing I quite don't understand is: do we really need to make the > > newtype/data distinction explicit? > > I'm pretty sure we don't. > > newtype N = N A > > defines a datatype isomorphic to > > data D = D !A > > but you have to use it slightly differently, that's all. I wrote more about > this here: Correction: http://stackoverflow.com/questions/21327740/strict-single-constructor-single-field-data-declaration-vs-newtype/21331284#21331284 (My previous post linked to the previous revisions of the answer!) From silvio.frischi at gmail.com Sat Aug 8 14:48:44 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sat, 08 Aug 2015 16:48:44 +0200 Subject: [Haskell-cafe] Waiting for async exception (and nothing else) In-Reply-To: References: Message-ID: <55C616CC.3050907@gmail.com> > but this seems like a bit of a hack. Waiting on an otherwise-unused MVar > or doing 'atomically retry' don't work because GHC kills them off > straight away. Not that this will help you any but this might actually be a bug. From: https://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Concurrent.html Holding a normal ThreadId reference will prevent the delivery of BlockedIndefinitely exceptions because the reference could be used as the target of throwTo at any time, which would unblock the thread. So this will in fact run forever because threadId is still in scope. main = do threadId <-forkIO $ do var <- newEmptyMVar takeMVar var forever $ threadDelay maxBound so wouldn't it make sense to keep this alive main = do var <- newEmptyMVar takeMVar var because a user interrupt may ocure. Silvio From daniel.trstenjak at gmail.com Sat Aug 8 15:03:06 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Sat, 8 Aug 2015 17:03:06 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: <20150808150306.GA27353@brick> Hi Alexey, > type Name = String > data Date = Date Int Int Int if we're at it ;), then please change it to: alias Name = String type Date = Date Int Int Int Greetings, Daniel From silvio.frischi at gmail.com Sat Aug 8 15:11:40 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sat, 08 Aug 2015 17:11:40 +0200 Subject: [Haskell-cafe] Waiting for async exception (and nothing else) In-Reply-To: <55C616CC.3050907@gmail.com> References: <55C616CC.3050907@gmail.com> Message-ID: <55C61C2C.9000607@gmail.com> Let's see what the ghc people think about it. https://ghc.haskell.org/trac/ghc/ticket/10759 From corentin.dupont at gmail.com Sat Aug 8 15:33:35 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Sat, 8 Aug 2015 17:33:35 +0200 Subject: [Haskell-cafe] Serialize to Haskell In-Reply-To: References: Message-ID: This seems to be what I need! I'll give a look. On Sat, Aug 8, 2015 at 1:24 AM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > Alan Zimmerman and myself have written a library which aims to make > these sorts of transformations easy. We are still in the early stages > but depending on what exactly you want to do then it might be suitable > for your purposes. Looking now on hackage the documentation isn't very > good so it might not be obvious how you're meant to use it. > > https://hackage.haskell.org/package/ghc-exactprint > > The basic idea is, use one of the parsers from the Parsers module, do > a (generic) transformation on the resulting ast, then call > `exactPrintWithAnns` on the AST and the resulting annotations. For > simple transformations (moving, deletion, renaming) it is sufficient > to not modify the annotations. When doing insertions/replacements, you > will probably have to modify the annotations in some way to get a > sensible output. > > > https://hackage.haskell.org/package/ghc-exactprint-0.3.1/docs/Language-Haskell-GHC-ExactPrint-Parsers.html > > I don't think I'm quite sure what exactly you want, if you can give a > specific use case then it will help me give a better answer. We also > hang around in #haskell-refactorer if it is transforming source files > that you are interested in. > > Here is an example of how to use the library to insert a type > signature for example. > > > https://github.com/alanz/ghc-exactprint/blob/master/examples/InsertSignature.hs > > Happy to answer any more questions.. > > Matt > > On Sat, Aug 8, 2015 at 1:04 AM, Corentin Dupont > wrote: > > Hi Matthew, > > yes that's exactly that. > > I want to do exactly what you would do with a JSON file (read, write), > but > > with a data format that would be valid Haskell (instead of valid > > javascript). > > > > > > On Fri, Aug 7, 2015 at 8:06 PM, Matthew Pickering > > wrote: > >> > >> Hi Corentin, > >> > >> I don't quite understand your question please can you explain a bit > >> more. Do you want to read a valid haskell source file, perform some > >> changes to the file and then print out a valid source file? > >> > >> I am a bit confused about the bit about turing-completeness. > >> > >> Matt > >> > >> On Fri, Aug 7, 2015 at 7:55 PM, Corentin Dupont > >> wrote: > >> > Hello! > >> > I'm wondering if it's possible to serialize some data to a format that > >> > is > >> > valid Haskell. > >> > In practice I would read a file like this: > >> > > >> > module Foo where > >> > > >> > myData :: MyData > >> > myData = MyData {name = "foo", > >> > descr = "test" > >> > ... > >> > } > >> > > >> > Reading this into a program is easily feasible with Hint, for example. > >> > Then > >> > the program would modify some data and serialize it back to: > >> > > >> > module Foo where > >> > > >> > myData :: MyData > >> > myData = MyData {name = "bar", > >> > descr = "test2" > >> > ... > >> > } > >> > > >> > In practice I think that the format should be a subset of Haskell that > >> > is > >> > not Turing-complete. > >> > A bit like JSON, which is a subset of Javascript but not Turing > >> > complete. > >> > Is it possible? > >> > > >> > Thanks, > >> > Corentin > >> > > >> > _______________________________________________ > >> > Haskell-Cafe mailing list > >> > Haskell-Cafe at haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlatko.basic at gmail.com Sat Aug 8 15:59:29 2015 From: vlatko.basic at gmail.com (Vlatko Basic) Date: Sat, 8 Aug 2015 17:59:29 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808150306.GA27353@brick> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: <55C62761.7020006@gmail.com> +1 -------- Original Message -------- Subject: Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` From: Daniel Trstenjak To: haskell-cafe at haskell.org Date: 08/08/15 17:03 > > Hi Alexey, > >> type Name = String >> data Date = Date Int Int Int > > if we're at it ;), then please change it to: > > alias Name = String > type Date = Date Int Int Int > > > Greetings, > Daniel > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From miguelimo38 at yandex.ru Sat Aug 8 16:17:50 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 18:17:50 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <55C62761.7020006@gmail.com> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <55C62761.7020006@gmail.com> Message-ID: That's ridiculous. The code would only be intuitive enough if it's written like this: t?pus N?v = Sor adat Id?pont = Id?pont Eg?sz Eg?sz Eg?sz > On 08 Aug 2015, at 17:59, Vlatko Basic wrote: > > +1 > > > -------- Original Message -------- > Subject: Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` > From: Daniel Trstenjak > To: haskell-cafe at haskell.org > Date: 08/08/15 17:03 > >> >> Hi Alexey, >> >>> type Name = String >>> data Date = Date Int Int Int >> >> if we're at it ;), then please change it to: >> >> alias Name = String >> type Date = Date Int Int Int >> >> >> Greetings, >> Daniel >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From strake888 at gmail.com Sat Aug 8 16:55:16 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sat, 8 Aug 2015 08:55:16 -0800 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <55C62761.7020006@gmail.com> Message-ID: On 08/08/2015, MigMit wrote: > That's ridiculous. The code would only be intuitive enough if it's written > like this: > > t?pus N?v = Sor > adat Id?pont = Id?pont Eg?sz Eg?sz Eg?sz +1 behozni Adat.Functor behozni Ir?ny?t?s.Monad behozni Rendszer.BK -- bemenet-kimenet f? :: BK () f? = tenniSort "Hell?, vil?g!" From strake888 at gmail.com Sat Aug 8 16:56:36 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sat, 8 Aug 2015 08:56:36 -0800 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <55C62761.7020006@gmail.com> Message-ID: On 08/08/2015, MigMit wrote: > That's ridiculous. The code would only be intuitive enough if it's written > like this: > > t?pus N?v = Sor > adat Id?pont = Id?pont Eg?sz Eg?sz Eg?sz Actually I think you missed the point here: adat Id?pont ahol Id?pont :: Eg?sz -> Eg?sz -> Eg?sz -> Id?pont Much better ? From miguelimo38 at yandex.ru Sat Aug 8 17:14:57 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 19:14:57 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <55C62761.7020006@gmail.com> Message-ID: <69F78501-B0E2-4C85-AC05-1B64A5F13A6B@yandex.ru> Oh, you're right. We need to use Hungarian notation properly. ?????????? ? iPad > 8 ???. 2015 ?., ? 18:56, M Farkas-Dyck ???????(?): > >> On 08/08/2015, MigMit wrote: >> That's ridiculous. The code would only be intuitive enough if it's written >> like this: >> >> t?pus N?v = Sor >> adat Id?pont = Id?pont Eg?sz Eg?sz Eg?sz > > Actually I think you missed the point here: > > adat Id?pont ahol > Id?pont :: Eg?sz -> Eg?sz -> Eg?sz -> Id?pont > > Much better ? From hilco.wijbenga at gmail.com Sat Aug 8 17:28:21 2015 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Sat, 8 Aug 2015 10:28:21 -0700 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808150306.GA27353@brick> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: On 8 August 2015 at 08:03, Daniel Trstenjak wrote: >> type Name = String >> data Date = Date Int Int Int > > if we're at it ;), then please change it to: > > alias Name = String > type Date = Date Int Int Int I wholeheartedly agree with replacing the current "type" with "alias", the current "type" is just flat out wrong: it does *not* create a type. This should be very simple to do too: introduce "alias" as a new keyword and deprecate "type". No existing code would be affected. I'm on the fence about "type" instead of "data", though. "data" clearly conveys the meaning that we are talking about data only, not functions on that data (as in OOP). (Well, data constructors are functions too.) Then again, as soon as you add "deriving", you *are* defining functions on that data. From will.yager at gmail.com Sat Aug 8 17:45:25 2015 From: will.yager at gmail.com (Will Yager) Date: Sat, 8 Aug 2015 10:45:25 -0700 Subject: [Haskell-cafe] monads, memoization etc In-Reply-To: References: Message-ID: <5770492E-7195-465D-9DBE-0AFAE962902C@gmail.com> > On Aug 8, 2015, at 03:30, Ilya Razenshteyn wrote: > > Interestingly, the code became almost twice as slow as a result.. If I had to guess, I would say that GHC transformed your original function (which took a reference to an ST hashtable) into a faster worker function that passed the hashtable's constituent data around unboxed, among other things. But I don't think GHC will perform similar optimizations now that the hashtable is passed around via ReaderT. --Will From heraldhoi at gmail.com Sat Aug 8 18:29:01 2015 From: heraldhoi at gmail.com (Geraldus) Date: Sat, 08 Aug 2015 18:29:01 +0000 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: type -> alias data -> data newtype -> newalias or newdata? `type` keyword was really confusing for me at the beginning, also this confusion brought another one about `newtype` keyword. ??, 8 ???. 2015 ?. ? 22:28, Hilco Wijbenga : > On 8 August 2015 at 08:03, Daniel Trstenjak > wrote: > >> type Name = String > >> data Date = Date Int Int Int > > > > if we're at it ;), then please change it to: > > > > alias Name = String > > type Date = Date Int Int Int > > I wholeheartedly agree with replacing the current "type" with "alias", > the current "type" is just flat out wrong: it does *not* create a > type. This should be very simple to do too: introduce "alias" as a new > keyword and deprecate "type". No existing code would be affected. > > I'm on the fence about "type" instead of "data", though. "data" > clearly conveys the meaning that we are talking about data only, not > functions on that data (as in OOP). (Well, data constructors are > functions too.) Then again, as soon as you add "deriving", you *are* > defining functions on that data. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Sat Aug 8 19:14:58 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Sat, 08 Aug 2015 19:14:58 +0000 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: I hate to come across as a party-pooper, but do we really think it's realistic that any of these changes will be made? I understand that there may be benefits, but they don't outweigh the cost of breaking almost all existing code. The idea of opting in to this with pragmas just doesn't seem worth it, and further fragments the language, ultimately reducing readability when I pick up another author's code. *ocharles* On Sat, Aug 8, 2015 at 7:29 PM Geraldus wrote: > type -> alias > data -> data > newtype -> newalias or newdata? > > `type` keyword was really confusing for me at the beginning, also this > confusion brought another one about `newtype` keyword. > > ??, 8 ???. 2015 ?. ? 22:28, Hilco Wijbenga : > >> On 8 August 2015 at 08:03, Daniel Trstenjak >> wrote: >> >> type Name = String >> >> data Date = Date Int Int Int >> > >> > if we're at it ;), then please change it to: >> > >> > alias Name = String >> > type Date = Date Int Int Int >> >> I wholeheartedly agree with replacing the current "type" with "alias", >> the current "type" is just flat out wrong: it does *not* create a >> type. This should be very simple to do too: introduce "alias" as a new >> keyword and deprecate "type". No existing code would be affected. >> >> I'm on the fence about "type" instead of "data", though. "data" >> clearly conveys the meaning that we are talking about data only, not >> functions on that data (as in OOP). (Well, data constructors are >> functions too.) Then again, as soon as you add "deriving", you *are* >> defining functions on that data. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sat Aug 8 20:18:43 2015 From: svenpanne at gmail.com (Sven Panne) Date: Sat, 8 Aug 2015 22:18:43 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: 2015-08-08 21:14 GMT+02:00 Oliver Charles : > I hate to come across as a party-pooper, but do we really think it's > realistic that any of these changes will be made? I understand that there > may be benefits, but they don't outweigh the cost of breaking almost all > existing code. The idea of opting in to this with pragmas just doesn't seem > worth it, and further fragments the language, ultimately reducing > readability when I pick up another author's code. > +1 to this. As has already been noted in a different thread, the "let's introduce a pragma, nobody is forced to use it" argument is bogus. It fragments the language for no good reason and one *is* forced to handle it (when reading other people's code etc.). Furthermore, the current example at hand is roughly at position 2 of Wadler's Law of Language Design ( https://wiki.haskell.org/Wadler's_Law), a.k.a. bikeshedding at the lexical level. ;-) Don't get me wrong: If Haskell was still at its infancy, renaming things would probably be beneficial, as "type" is somehow really a misnomer. One could discuss if "newtype" is really needed when we have "data" plus strictness annotations (personally I'm a bit unsure what the common use case for "case" is where they differ and what one might consider more natural). Given the case that people seem to move towards GADTs anyway, the discussion seems a bit moot. Just my 2c. P.S.: If you think this part of Haskell is a bit hard to read and confusing, I seriously propose a week or two in C++'s wonderful meta-programming world with templates... ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Sat Aug 8 20:22:12 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Sat, 8 Aug 2015 23:22:12 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <55C61242.9010708@hupel.info> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <55C61242.9010708@hupel.info> Message-ID: <942B9CEF-C902-421E-A28C-795D5F9E1C36@gmail.com> Hi, Lars, On 8 ao?t 2015, at 17:29, Lars Hupel wrote: > there is already an alternative syntax for declaring datatypes: > > data Date where > Date :: Int -> Int -> Int -> Date > > data Anniversary where > Birthday :: Name -> Date -> Anniversary > Wedding :: Name -> Name -> Date -> Anniversary > > This is called "GADT syntax" and can be enabled with -XGADTSyntax in GHC.* Thank you for suggesting GADT, but i already knew about it. IMO this does not make the syntax with the equality sign (the one to which newcomers are introduced first) less weird :). Alexey. From alexey.muranov at gmail.com Sat Aug 8 20:24:20 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Sat, 8 Aug 2015 23:24:20 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: <704AAF8E-C84A-4D60-B1F4-F72959987D33@gmail.com> Hi Corentin, On 8 ao?t 2015, at 17:23, Corentin Dupont wrote: > One thing I quite don't understand is: do we really need to make the newtype/data distinction explicit? > If we used only one keyword, it should be quite easy for the compiler to detect the distinction statically. I think someone more knowledgable in Haskell than me should answer this. Alexey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hilco.wijbenga at gmail.com Sat Aug 8 20:26:35 2015 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Sat, 8 Aug 2015 13:26:35 -0700 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: On 8 August 2015 at 12:14, Oliver Charles wrote: > I hate to come across as a party-pooper, but do we really think it's > realistic that any of these changes will be made? I understand that there > may be benefits, but they don't outweigh the cost of breaking almost all > existing code. The idea of opting in to this with pragmas just doesn't seem > worth it, and further fragments the language, ultimately reducing > readability when I pick up another author's code. I have no doubt that you are right: nothing will change. However... I don't agree that "it breaks existing code" is a valid argument (in and of itself). You can stick with whatever version of the compiler you are currently using. Nobody is forcing you to change *immediately*. Holding a programming language hostage because of the existing code base is irresponsible. Having said that, changing the language "often" is also irresponsible. So it should only happen, say, every 5 years. More importantly, it should be done by means of a tool (a la gofix, see [1]). Especially with a language like Haskell, it should be relatively simple to create a haskell-fix tool that replaces deprecated structure/syntax with its new-and-improved alternative. Make haskell-fix a standard part of the toolchain and most (all?) problems related to language changes disappear. (I would be very interested to know whether the availability of such a haskell-fix tool would change people's opinion about making language changes.) [1] http://blog.golang.org/introducing-gofix From miguelimo38 at yandex.ru Sat Aug 8 20:43:39 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 22:43:39 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: > One could discuss if "newtype" is really needed when we have "data" plus strictness annotations (personally I'm a bit unsure what the common use case for "case" is where they differ and what one might consider more natural). Prelude> newtype A = A Int deriving Show Prelude> data B = B !Int deriving Show Prelude> let x = case x of A n -> A 1 in x A 1 Prelude> let y = case y of B n -> B 1 in y *** Exception: <> > P.S.: If you think this part of Haskell is a bit hard to read and confusing, I seriously propose a week or two in C++'s wonderful meta-programming world with templates... ;-) Can't agree more From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 8 20:49:46 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 8 Aug 2015 21:49:46 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: <20150808204946.GB15646@weber> On Sat, Aug 08, 2015 at 10:43:39PM +0200, MigMit wrote: > Prelude> newtype A = A Int deriving Show > Prelude> data B = B !Int deriving Show > Prelude> let x = case x of A n -> A 1 in x > A 1 > Prelude> let y = case y of B n -> B 1 in y > *** Exception: <> Sure, they're not exactly the same thing but if you get the translations right you can use them for the same purposes: Prelude> let y = case y of b -> B 1 in y B 1 I list the translations here http://stackoverflow.com/questions/21327740/strict-single-constructor-single-field-data-declaration-vs-newtype/21331284#21331284 Tom From _deepfire at feelingofgreen.ru Sat Aug 8 20:50:49 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Sat, 08 Aug 2015 23:50:49 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: (sfid-20150809_003822_688132_7651B26A) (Sven Panne's message of "Sat, 8 Aug 2015 22:18:43 +0200") References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: <87614p7bdi.fsf@andromedae.feelingofgreen.ru> First of all, I have no opinion of my own -- I merely share the memories of also being confused by "type" not introducing a true type, but a type macro. However there's something in the argument that I don't think is right.. Sven Panne writes: > +1 to this. As has already been noted in a different thread, the "let's introduce > a pragma, nobody is forced to use it" argument is bogus. It fragments the language > for no good reason One moment, please, the good reason has been provided -- newbie confusion. > and one *is* forced to handle it (when reading other people's > code etc.). Furthermore, the current example at hand is roughly at position 2 of > Wadler's Law of Language Design (https://wiki.haskell.org/Wadler's_Law), a.k.a. > bikeshedding at the lexical level. ;-) I don't think that the concept of "bikeshedding", on its own, should be used as a tool to prevent constructive discussion of material shortcomings. > Don't get me wrong: If Haskell was still at its infancy, renaming things would > probably be beneficial, as "type" is somehow really a misnomer. One could discuss > if "newtype" is really needed when we have "data" plus strictness annotations > (personally I'm a bit unsure what the common use case for "case" is where they > differ and what one might consider more natural). Given the case that people seem > to move towards GADTs anyway, the discussion seems a bit moot. The context here is newbies -- so existence of GADTs (which are an advanced concept, let's not forget that!) is off-topic to the proposal. > Just my 2c. > > P.S.: If you think this part of Haskell is a bit hard to read and confusing, I > seriously propose a week or two in C++'s wonderful meta-programming world with > templates... ;-) Hey, we're talking about language adoption here.. I presume.. ..and if we do, any undeserved complication does hurt. So, in the end, the idea will probably be shot down -- but please, let's shoot it down for a good reason, with a clear, irrefutable understanding of why. -- respectfully, ??????? ?????? -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? ? Friedrich Wilhelm Nietzsche From miguelimo38 at yandex.ru Sat Aug 8 20:59:55 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 22:59:55 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <87614p7bdi.fsf@andromedae.feelingofgreen.ru> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: > One moment, please, the good reason has been provided -- newbie confusion. I'm really happy that we are at the stage when this is considered an important source of newbie confusion in Haskell. > So, in the end, the idea will probably be shot down -- but please, let's shoot > it down for a good reason, with a clear, irrefutable understanding of why. The reason is very simple, and it was stated several times already: it will break everything that was written so far, and there is not enough evidence that things would be even a little better. In fact, moving to dynamic typing would a) break less existing code (could be none, if done carefully), and b) remove A LOT of newbie confusion, but for some reason I don't think it's a good idea either. From miguelimo38 at yandex.ru Sat Aug 8 21:02:27 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 23:02:27 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808204946.GB15646@weber> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <20150808204946.GB15646@weber> Message-ID: <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> What you say is "if we don't use some perfectly legitimate language constructs and never use third-party code, than 'data' and 'newtype' are the same". That's certainly true, but that "if" is a very big one. > On 08 Aug 2015, at 22:49, Tom Ellis wrote: > > On Sat, Aug 08, 2015 at 10:43:39PM +0200, MigMit wrote: >> Prelude> newtype A = A Int deriving Show >> Prelude> data B = B !Int deriving Show >> Prelude> let x = case x of A n -> A 1 in x >> A 1 >> Prelude> let y = case y of B n -> B 1 in y >> *** Exception: <> > > Sure, they're not exactly the same thing but if you get the translations > right you can use them for the same purposes: > > Prelude> let y = case y of b -> B 1 in y > B 1 > > I list the translations here > > http://stackoverflow.com/questions/21327740/strict-single-constructor-single-field-data-declaration-vs-newtype/21331284#21331284 > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From allbery.b at gmail.com Sat Aug 8 21:03:01 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 8 Aug 2015 17:03:01 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: On Sat, Aug 8, 2015 at 4:59 PM, MigMit wrote: > > So, in the end, the idea will probably be shot down -- but please, let's > shoot > > it down for a good reason, with a clear, irrefutable understanding of > why. > > The reason is very simple, and it was stated several times already: it > will break everything that was written so far, and there is not enough > evidence that things would be even a little better. This is quite important, folks. Don't tell us how tools will mitigate this. Go look at Python 3's adoption rate --- and it does have the tools --- and tell me again how well that path works for an established language. (Hint: every Python package I use has no intention of moving to Python 3.) Haskell may be new to you personally. That does not mean that it's okay to break what, more than 15 years worth of code? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 8 21:11:18 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 8 Aug 2015 22:11:18 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> Message-ID: <20150808211118.GC15646@weber> On Sat, Aug 08, 2015 at 11:02:27PM +0200, MigMit wrote: > What you say is "if we don't use some perfectly legitimate language > constructs and never use third-party code, than 'data' and 'newtype' are > the same". No, not at all. I'm making a much stronger claim than that. I'm claiming the functionality provided by newtype is completely subsumed by that provided by data. > > On Sat, Aug 08, 2015 at 10:43:39PM +0200, MigMit wrote: > >> Prelude> newtype A = A Int deriving Show > >> Prelude> data B = B !Int deriving Show > >> Prelude> let x = case x of A n -> A 1 in x > >> A 1 > >> Prelude> let y = case y of B n -> B 1 in y > >> *** Exception: <> > > > > Sure, they're not exactly the same thing but if you get the translations > > right you can use them for the same purposes: > > > > Prelude> let y = case y of b -> B 1 in y > > B 1 > > > > I list the translations here > > > > http://stackoverflow.com/questions/21327740/strict-single-constructor-single-field-data-declaration-vs-newtype/21331284#21331284 From allbery.b at gmail.com Sat Aug 8 21:13:30 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 8 Aug 2015 17:13:30 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808211118.GC15646@weber> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> Message-ID: On Sat, Aug 8, 2015 at 5:11 PM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > No, not at all. I'm making a much stronger claim than that. I'm claiming > the functionality provided by newtype is completely subsumed by that > provided by data. > When did `data` start guaranteeing that the representation of a single constructor, strict `data' wrapper around another type is exactly the same as the wrapped type? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Sat Aug 8 21:14:40 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 23:14:40 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808211118.GC15646@weber> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> Message-ID: > On 08 Aug 2015, at 23:11, Tom Ellis wrote: > > On Sat, Aug 08, 2015 at 11:02:27PM +0200, MigMit wrote: >> What you say is "if we don't use some perfectly legitimate language >> constructs and never use third-party code, than 'data' and 'newtype' are >> the same". > > No, not at all. I'm making a much stronger claim than that. I'm claiming > the functionality provided by newtype is completely subsumed by that > provided by data. Well, it's certainly unsupported by evidence. Because third-party code CAN distinguish between those. >>> On Sat, Aug 08, 2015 at 10:43:39PM +0200, MigMit wrote: >>>> Prelude> newtype A = A Int deriving Show >>>> Prelude> data B = B !Int deriving Show >>>> Prelude> let x = case x of A n -> A 1 in x >>>> A 1 >>>> Prelude> let y = case y of B n -> B 1 in y >>>> *** Exception: <> >>> >>> Sure, they're not exactly the same thing but if you get the translations >>> right you can use them for the same purposes: >>> >>> Prelude> let y = case y of b -> B 1 in y >>> B 1 >>> >>> I list the translations here >>> >>> http://stackoverflow.com/questions/21327740/strict-single-constructor-single-field-data-declaration-vs-newtype/21331284#21331284 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 8 21:16:25 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 8 Aug 2015 22:16:25 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <20150808150306.GA27353@brick> <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> Message-ID: <20150808211625.GD15646@weber> On Sat, Aug 08, 2015 at 05:13:30PM -0400, Brandon Allbery wrote: > On Sat, Aug 8, 2015 at 5:11 PM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > > > No, not at all. I'm making a much stronger claim than that. I'm claiming > > the functionality provided by newtype is completely subsumed by that > > provided by data. > > When did `data` start guaranteeing that the representation of a single > constructor, strict `data' wrapper around another type is exactly the same > as the wrapped type? I make no claims about the operational semantics of existing compilers, but can you point out a reason why data of a single strict field *shuoldn't* be compiled in the same way as a newtype? From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 8 21:16:53 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 8 Aug 2015 22:16:53 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <20150808150306.GA27353@brick> <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> Message-ID: <20150808211653.GE15646@weber> On Sat, Aug 08, 2015 at 11:14:40PM +0200, MigMit wrote: > > On 08 Aug 2015, at 23:11, Tom Ellis wrote: > > > > On Sat, Aug 08, 2015 at 11:02:27PM +0200, MigMit wrote: > >> What you say is "if we don't use some perfectly legitimate language > >> constructs and never use third-party code, than 'data' and 'newtype' are > >> the same". > > > > No, not at all. I'm making a much stronger claim than that. I'm claiming > > the functionality provided by newtype is completely subsumed by that > > provided by data. > > Well, it's certainly unsupported by evidence. Because third-party code CAN > distinguish between those. OK, show me the code! From miguelimo38 at yandex.ru Sat Aug 8 21:17:15 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 23:17:15 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> Message-ID: <6BD8E41A-C59C-43FE-9EF3-653575653B42@yandex.ru> I won't say that's a legitimate concern. Representation doesn't matter here; if those two were indistinguishable (by Haskell code, without "hacks"), then the fact that they are represented differently would be irrelevant. But they ARE distinguishable, by a perfectly normal Haskell code. > On 08 Aug 2015, at 23:13, Brandon Allbery wrote: > > On Sat, Aug 8, 2015 at 5:11 PM, Tom Ellis wrote: > No, not at all. I'm making a much stronger claim than that. I'm claiming > the functionality provided by newtype is completely subsumed by that > provided by data. > > When did `data` start guaranteeing that the representation of a single constructor, strict `data' wrapper around another type is exactly the same as the wrapped type? > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From miguelimo38 at yandex.ru Sat Aug 8 21:18:18 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 23:18:18 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808211653.GE15646@weber> References: <20150808150306.GA27353@brick> <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> <20150808211653.GE15646@weber> Message-ID: > On 08 Aug 2015, at 23:16, Tom Ellis wrote: > > On Sat, Aug 08, 2015 at 11:14:40PM +0200, MigMit wrote: >>> On 08 Aug 2015, at 23:11, Tom Ellis wrote: >>> >>> On Sat, Aug 08, 2015 at 11:02:27PM +0200, MigMit wrote: >>>> What you say is "if we don't use some perfectly legitimate language >>>> constructs and never use third-party code, than 'data' and 'newtype' are >>>> the same". >>> >>> No, not at all. I'm making a much stronger claim than that. I'm claiming >>> the functionality provided by newtype is completely subsumed by that >>> provided by data. >> >> Well, it's certainly unsupported by evidence. Because third-party code CAN >> distinguish between those. > > OK, show me the code! I did. You removed it when quoting. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 8 21:19:51 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 8 Aug 2015 22:19:51 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> <20150808211653.GE15646@weber> Message-ID: <20150808211951.GF15646@weber> On Sat, Aug 08, 2015 at 11:18:18PM +0200, MigMit wrote: > > > On 08 Aug 2015, at 23:16, Tom Ellis wrote: > > > > On Sat, Aug 08, 2015 at 11:14:40PM +0200, MigMit wrote: > >>> On 08 Aug 2015, at 23:11, Tom Ellis wrote: > >>> > >>> On Sat, Aug 08, 2015 at 11:02:27PM +0200, MigMit wrote: > >>>> What you say is "if we don't use some perfectly legitimate language > >>>> constructs and never use third-party code, than 'data' and 'newtype' are > >>>> the same". > >>> > >>> No, not at all. I'm making a much stronger claim than that. I'm claiming > >>> the functionality provided by newtype is completely subsumed by that > >>> provided by data. > >> > >> Well, it's certainly unsupported by evidence. Because third-party code CAN > >> distinguish between those. > > > > OK, show me the code! > > I did. You removed it when quoting. Reinstating: >> Prelude> newtype A = A Int deriving Show >> Prelude> data B = B !Int deriving Show >> Prelude> let x = case x of A n -> A 1 in x >> A 1 >> Prelude> let y = case y of B n -> B 1 in y >> *** Exception: <> This isn't third party code. It knows about the constructors of A and B. From allbery.b at gmail.com Sat Aug 8 21:20:00 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 8 Aug 2015 17:20:00 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808211625.GD15646@weber> References: <20150808150306.GA27353@brick> <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> <20150808211625.GD15646@weber> Message-ID: On Sat, Aug 8, 2015 at 5:16 PM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Sat, Aug 08, 2015 at 05:13:30PM -0400, Brandon Allbery wrote: > > On Sat, Aug 8, 2015 at 5:11 PM, Tom Ellis < > > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > > > > > No, not at all. I'm making a much stronger claim than that. I'm > claiming > > > the functionality provided by newtype is completely subsumed by that > > > provided by data. > > > > When did `data` start guaranteeing that the representation of a single > > constructor, strict `data' wrapper around another type is exactly the > same > > as the wrapped type? > > I make no claims about the operational semantics of existing compilers, but > can you point out a reason why data of a single strict field *shuoldn't* be > compiled in the same way as a newtype? Because it's a bizarre special case compared to the way `data` works for everything else? Also, the behavior I described is not something that can just be ignored as an optimization in a particular compiler. It is part of the language specification. In fact, it is the *primary reason* for the existence of `newtype`. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From _deepfire at feelingofgreen.ru Sat Aug 8 21:21:24 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Sun, 09 Aug 2015 00:21:24 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: (sfid-20150809_012224_832145_A5D75F1F) (Brandon Allbery's message of "Sat, 8 Aug 2015 17:03:01 -0400") References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: <871tfd79yj.fsf@andromedae.feelingofgreen.ru> Brandon Allbery writes: > Haskell may be new to you personally. That does not mean that it's okay to break > what, more than 15 years worth of code? I don't mean to come across argumentative -- rather I merely want to point out, that the way of accomplishing it in a non-breaking way was proposed in this thread: an extra keyword + a pragma to guard against name clashes. Whether it's worth the trouble or not -- again, I have no opinion of my own. Please, let's discuss the idea on its merit, and not criticize some flawed version of it. -- respectfully, ??????? ?????? -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? ? Friedrich Wilhelm Nietzsche From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 8 21:23:06 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 8 Aug 2015 22:23:06 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> <20150808211625.GD15646@weber> Message-ID: <20150808212306.GG15646@weber> On Sat, Aug 08, 2015 at 05:20:00PM -0400, Brandon Allbery wrote: > On Sat, Aug 8, 2015 at 5:16 PM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > > On Sat, Aug 08, 2015 at 05:13:30PM -0400, Brandon Allbery wrote: > > > On Sat, Aug 8, 2015 at 5:11 PM, Tom Ellis < > > > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > > > > > > > No, not at all. I'm making a much stronger claim than that. I'm > > claiming > > > > the functionality provided by newtype is completely subsumed by that > > > > provided by data. > > > > > > When did `data` start guaranteeing that the representation of a single > > > constructor, strict `data' wrapper around another type is exactly the > > same > > > as the wrapped type? > > > > I make no claims about the operational semantics of existing compilers, but > > can you point out a reason why data of a single strict field *shuoldn't* be > > compiled in the same way as a newtype? > > Because it's a bizarre special case compared to the way `data` works for > everything else? > > Also, the behavior I described is not something that can just be ignored as > an optimization in a particular compiler. It is part of the language > specification. In fact, it is the *primary reason* for the existence of > `newtype`. I'm not really sure what we're debating here. I merely pointed out that a language with strict data fields has no less functionality than one that adds newtype. I'm not making any proposal, I'm just making an observation that some may find interesting. Tom From allbery.b at gmail.com Sat Aug 8 21:23:53 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 8 Aug 2015 17:23:53 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <871tfd79yj.fsf@andromedae.feelingofgreen.ru> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> <871tfd79yj.fsf@andromedae.feelingofgreen.ru> Message-ID: On Sat, Aug 8, 2015 at 5:21 PM, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote: > I don't mean to come across argumentative -- rather I merely want to point > out, > that the way of accomplishing it in a non-breaking way was proposed in > this thread: > an extra keyword + a pragma to guard against name clashes. > Not worth the fact that I now have to look for two effectively incompatible languages both calling themselves Haskell. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hilco.wijbenga at gmail.com Sat Aug 8 21:27:19 2015 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Sat, 8 Aug 2015 14:27:19 -0700 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: On 8 August 2015 at 14:03, Brandon Allbery wrote: > This is quite important, folks. Don't tell us how tools will mitigate this. > Go look at Python 3's adoption rate --- and it does have the tools --- and > tell me again how well that path works for an established language. (Hint: > every Python package I use has no intention of moving to Python 3.) That seems like a red herring to me. Python does not have a type system to speak of so even simple refactoring is painful. Let alone making changes to the language itself... > Haskell may be new to you personally. That does not mean that it's okay to > break what, more than 15 years worth of code? So when is it okay? :-) Still, if proper tooling automates it, why not? (I'm not advocating making language changes willy-nilly but the argument "it breaks existing code" [in and of itself] implies we are stuck with all mistakes made in the past. Language designers are human too. We need a way forward.) From miguelimo38 at yandex.ru Sat Aug 8 21:32:59 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 23:32:59 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808211951.GF15646@weber> References: <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> <20150808211653.GE15646@weber> <20150808211951.GF15646@weber> Message-ID: <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> >>>> >>>> Well, it's certainly unsupported by evidence. Because third-party code CAN >>>> distinguish between those. >>> >>> OK, show me the code! >> >> I did. You removed it when quoting. > > Reinstating: > >>> Prelude> newtype A = A Int deriving Show >>> Prelude> data B = B !Int deriving Show >>> Prelude> let x = case x of A n -> A 1 in x >>> A 1 >>> Prelude> let y = case y of B n -> B 1 in y >>> *** Exception: <> > > This isn't third party code. It knows about the constructors of A and B. 1) This might be the code written by someone using your library/framework. In which case it would know about A and B. 2) It might be generated by the Template Haskell ? which is free to use whatever constructor is fed into it. From _deepfire at feelingofgreen.ru Sat Aug 8 21:33:41 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Sun, 09 Aug 2015 00:33:41 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: (sfid-20150809_014316_267038_4667F9FD) (Brandon Allbery's message of "Sat, 8 Aug 2015 17:23:53 -0400") References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> <871tfd79yj.fsf@andromedae.feelingofgreen.ru> Message-ID: <87wpx55utm.fsf@andromedae.feelingofgreen.ru> Brandon Allbery writes: > On Sat, Aug 8, 2015 at 5:21 PM, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote: > > I don't mean to come across argumentative -- rather I merely want to point > out, > that the way of accomplishing it in a non-breaking way was proposed in this > thread: > an extra keyword + a pragma to guard against name clashes. > > Not worth the fact that I now have to look for two effectively incompatible > languages both calling themselves Haskell. Do you mean that adding a new keyword to the language, guarded by a language extension, really deserves this strong wording -- "effectively incompatible"? What about the precedents? - TransformListComp: group, by, using - RecursiveDo: mdo, rec Then, I guess there was a number of keywords introduced by Haskell 2010. -- respectfully, ??????? ?????? -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? ? Friedrich Wilhelm Nietzsche From miguelimo38 at yandex.ru Sat Aug 8 21:37:19 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sat, 8 Aug 2015 23:37:19 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: It's generally considered OK to break small parts of code. For example, the infamous n+k patterns ? if I remember correctly, they are still here, but you have to enable them explicitly. It breaks SOME code, but not a lot of it. We might even break a lot of code, but we surely need a VERY good reason to do that. > On 08 Aug 2015, at 23:27, Hilco Wijbenga wrote: > > On 8 August 2015 at 14:03, Brandon Allbery wrote: >> This is quite important, folks. Don't tell us how tools will mitigate this. >> Go look at Python 3's adoption rate --- and it does have the tools --- and >> tell me again how well that path works for an established language. (Hint: >> every Python package I use has no intention of moving to Python 3.) > > That seems like a red herring to me. Python does not have a type > system to speak of so even simple refactoring is painful. Let alone > making changes to the language itself... > >> Haskell may be new to you personally. That does not mean that it's okay to >> break what, more than 15 years worth of code? > > So when is it okay? :-) Still, if proper tooling automates it, why not? > > (I'm not advocating making language changes willy-nilly but the > argument "it breaks existing code" [in and of itself] implies we are > stuck with all mistakes made in the past. Language designers are human > too. We need a way forward.) From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 8 21:38:26 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 8 Aug 2015 22:38:26 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> References: <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> <20150808211653.GE15646@weber> <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> Message-ID: <20150808213826.GA16943@weber> On Sat, Aug 08, 2015 at 11:32:59PM +0200, MigMit wrote: > >>>> Well, it's certainly unsupported by evidence. Because third-party code CAN > >>>> distinguish between those. > >>> > >>> OK, show me the code! > >> > >> I did. You removed it when quoting. > > > > Reinstating: > > > >>> Prelude> newtype A = A Int deriving Show > >>> Prelude> data B = B !Int deriving Show > >>> Prelude> let x = case x of A n -> A 1 in x > >>> A 1 > >>> Prelude> let y = case y of B n -> B 1 in y > >>> *** Exception: <> > > > > This isn't third party code. It knows about the constructors of A and B. > > 1) This might be the code written by someone using your library/framework. > In which case it would know about A and B. Then it's up to me to define and document whatever strictness properties I want for my constructors. To reiterate: I'm *not* suggesting replacing newtype A = A a with data A = A! in existing code. Of course that won't work. But for *new* datatypes choosing one rather than the other gives no difference in terms of denotational semantics. > 2) It might be generated by the Template Haskell ? which is free to use > whatever constructor is fed into it. OK, so show me what goes wrong! From allbery.b at gmail.com Sat Aug 8 21:46:51 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 8 Aug 2015 17:46:51 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: On Sat, Aug 8, 2015 at 5:27 PM, Hilco Wijbenga wrote: > So when is it okay? :-) Still, if proper tooling automates it, why not? Because your tooling does not rewire people's brains and does not automatically run itself on other people's programs when you *look* at them. Because not everyone builds houses of cards and leaves them to collapse on their successor while they go chase the next cool thing, like certain modern "web programmers" who seems to have confused "agile" with "fragile" and therefore think Go rewriting its syntax every week is somehow sensible. And not everyone *can* do things the zero-memory-change-it-all-who-cares-it'll-all-be-different-next-week way; that does not fly on the business end, for example. (I've had people claim to me that they do that with accounting packages. I bet they've never faced an audit and will be learning the hard way why business does not work that way when the auditors *do* show up.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Aug 8 21:49:05 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 8 Aug 2015 17:49:05 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <87wpx55utm.fsf@andromedae.feelingofgreen.ru> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> <871tfd79yj.fsf@andromedae.feelingofgreen.ru> <87wpx55utm.fsf@andromedae.feelingofgreen.ru> Message-ID: On Sat, Aug 8, 2015 at 5:33 PM, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote: > Do you mean that adding a new keyword to the language, guarded by a > language extension, really deserves this strong wording -- "effectively > incompatible"? > Do you mean that I am required to look for this in every program so I know what *actual* language this program is written in? Do you mean that people who have years oof experience with a lnaguage should fully expect to have to look for new magic that means this program is not actually written in the language they know? Do you mean that stability is completely meaningless when you can pretend that adding a pragma justifies changing anything you feel like? Or do you mean that stability simply is not a thing at all? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Aug 8 21:55:14 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 8 Aug 2015 17:55:14 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <87wpx55utm.fsf@andromedae.feelingofgreen.ru> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> <871tfd79yj.fsf@andromedae.feelingofgreen.ru> <87wpx55utm.fsf@andromedae.feelingofgreen.ru> Message-ID: On Sat, Aug 8, 2015 at 5:33 PM, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote: > > What about the precedents? > > - TransformListComp: group, by, using > - RecursiveDo: mdo, rec > If I see those then I know that something is going on. If I don't see `data` and do see some new keyword in its place then I am not reading Haskell code; I know this because I have Haskell code and it uses `data`. If I see `data` and it means something different than what Haskell means by `data`? Oh right, you have decided your incompatible language is still "Haskell", I just have to deal with the fact that it means something completely different now. Have you ever come back to a project 6 months after you last worked on it, or a year after, and had to figure it out again? Consider how well that works when you've decided to mutate the language in the meantime, and your mission critical code was not permitted to be rewritten in the new language because it is mission critical and "oh just run this automated script to fix it" is not a plan that passes business review processes. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Sat Aug 8 22:16:27 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sun, 9 Aug 2015 00:16:27 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150808213826.GA16943@weber> References: <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> <20150808211653.GE15646@weber> <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> <20150808213826.GA16943@weber> Message-ID: >> 1) This might be the code written by someone using your library/framework. >> In which case it would know about A and B. > > Then it's up to me to define and document whatever strictness properties I > want for my constructors. Of course. But it's NOT up to you to restrict the user from using whatever techniques xe wants > in existing code. Of course that won't work. But for *new* datatypes > choosing one rather than the other gives no difference in terms of > denotational semantics. If it makes the difference for the old code, then it would make the difference for the new code as well. > >> 2) It might be generated by the Template Haskell ? which is free to use >> whatever constructor is fed into it. > > OK, so show me what goes wrong! I hate it. OK, here we go: {-# LANGUAGE TemplateHaskell #-} module TH where import Language.Haskell.TH check :: Name -> ExpQ check c = [|let x = case x of $(conP c [[p|_|]]) -> $(conE c) 1 in x|] {-# LANGUAGE TemplateHaskell #-} module Use where import TH newtype A = A Int deriving Show data B = B !Int deriving Show a = $(check 'A) b = $(check 'B) Prelude> :load "Use.hs" [1 of 2] Compiling TH ( TH.hs, interpreted ) [2 of 2] Compiling Use ( Use.hs, interpreted ) Use.hs:6:1: Warning: Top-level binding with no type signature: a :: A Use.hs:7:1: Warning: Top-level binding with no type signature: b :: B Ok, modules loaded: TH, Use. *Use> a A 1 *Use> b C-c C-cInterrupted. From spam at scientician.net Sat Aug 8 22:59:06 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sun, 9 Aug 2015 00:59:06 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <55C62761.7020006@gmail.com> Message-ID: On 08/08/2015 06:17 PM, MigMit wrote: > That's ridiculous. The code would only be intuitive enough if it's written like this: > > t?pus N?v = Sor > adat Id?pont = Id?pont Eg?sz Eg?sz Eg?sz > This. The GHC compiler should only accept syntax in this language. Incedenatlly... which language *is* this? ;) I can also summon strange symbols and weird pronunciations at will, but I'm actually really curious about this... My guess is... Hungarian? (If I'm slow on the uptake, I apologize. I have a rather bad cold at the moment.) Regards, From hilco.wijbenga at gmail.com Sat Aug 8 23:01:35 2015 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Sat, 8 Aug 2015 16:01:35 -0700 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: On 8 August 2015 at 14:46, Brandon Allbery wrote: > On Sat, Aug 8, 2015 at 5:27 PM, Hilco Wijbenga > wrote: >> So when is it okay? :-) Still, if proper tooling automates it, why not? > > Because your tooling does not rewire people's brains and does not > automatically run itself on other people's programs when you *look* at them. I don't think we need to "rewire" our brains to accommodate a few language tweaks. The haskell-fix tool I had in mind would change the source code so you would look at the fixed code. But, yes, there would be a transition time. In my experience that is true for any change to your code base. > Because not everyone builds houses of cards and leaves them to collapse on > their successor while they go chase the next cool thing, like certain modern > "web programmers" who seems to have confused "agile" with "fragile" and > therefore think Go rewriting its syntax every week is somehow sensible. And > not everyone *can* do things the > zero-memory-change-it-all-who-cares-it'll-all-be-different-next-week way; > that does not fly on the business end, for example. (I've had people claim > to me that they do that with accounting packages. I bet they've never faced > an audit and will be learning the hard way why business does not work that > way when the auditors *do* show up.) You seem to be creating a whole mountain range out of a mole hill. :-) I have to maintain a very low quality, legacy code base. So I totally sympathize with the "house of cards" and "fragile" part of your paragraph. But after that I have a hard time making sense of it. Nobody is advocating changing Haskell to look like a completely different language. Or that we start making language changes every week. I really do not understand where you got that impression. Everybody is talking about tiny language tweaks that (hopefully) make the language better. If the agreement is that, yes, it does make the language better than the blanket counter argument "it breaks existing code" should not stop progress. If you don't make improvements now because of existing code then tomorrow there will be more existing code and thus even more inertia. From amindfv at gmail.com Sat Aug 8 23:21:43 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 8 Aug 2015 19:21:43 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: El Aug 8, 2015, a las 19:01, Hilco Wijbenga escribi?: > On 8 August 2015 at 14:46, Brandon Allbery wrote: >> On Sat, Aug 8, 2015 at 5:27 PM, Hilco Wijbenga >> wrote: >>> So when is it okay? :-) Still, if proper tooling automates it, why not? >> >> Because your tooling does not rewire people's brains and does not >> automatically run itself on other people's programs when you *look* at them. > > I don't think we need to "rewire" our brains to accommodate a few > language tweaks. The haskell-fix tool I had in mind would change the > source code so you would look at the fixed code. But, yes, there would > be a transition time. In my experience that is true for any change to > your code base. > An analogy: Haskell's use of "::" and ":" are backwards. Most ML-style languages use ":" for types but iiuc it was assumed using cons would be so common that it should be the quicker one to type. Obviously that estimation was wrong -- we write a lot more types than conses. Annoying? Yes. Way too late and fundamental to change? Also yes. I also disagree with the better-ness (even for beginners) of the proposed changes, but point 1 supersedes that. tom >> Because not everyone builds houses of cards and leaves them to collapse on >> their successor while they go chase the next cool thing, like certain modern >> "web programmers" who seems to have confused "agile" with "fragile" and >> therefore think Go rewriting its syntax every week is somehow sensible. And >> not everyone *can* do things the >> zero-memory-change-it-all-who-cares-it'll-all-be-different-next-week way; >> that does not fly on the business end, for example. (I've had people claim >> to me that they do that with accounting packages. I bet they've never faced >> an audit and will be learning the hard way why business does not work that >> way when the auditors *do* show up.) > > You seem to be creating a whole mountain range out of a mole hill. :-) > > I have to maintain a very low quality, legacy code base. So I totally > sympathize with the "house of cards" and "fragile" part of your > paragraph. But after that I have a hard time making sense of it. > > Nobody is advocating changing Haskell to look like a completely > different language. Or that we start making language changes every > week. I really do not understand where you got that impression. > Everybody is talking about tiny language tweaks that (hopefully) make > the language better. If the agreement is that, yes, it does make the > language better than the blanket counter argument "it breaks existing > code" should not stop progress. If you don't make improvements now > because of existing code then tomorrow there will be more existing > code and thus even more inertia. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From svenpanne at gmail.com Sat Aug 8 23:25:59 2015 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 9 Aug 2015 01:25:59 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: 2015-08-09 1:01 GMT+02:00 Hilco Wijbenga : > On 8 August 2015 at 14:46, Brandon Allbery wrote: > [...] Everybody is talking about tiny language tweaks that (hopefully) make > the language better. If the agreement is that, yes, it does make the > language better than the blanket counter argument "it breaks existing > code" should not stop progress. If you don't make improvements now > because of existing code then tomorrow there will be more existing > code and thus even more inertia. This is flawed reasoning, ignoring basically all reality in business, larger projects, legacy projects etc.: Of course languages should evolve, but there is always a cost associated with it, and this should outweigh the disadvantages. And I can't see this happening here at all: We are talking about perhaps 5min of confusion (if at all) when starting Haskell compared to millions (billions?) of existing LOC perhaps needing a change (or not, who knows?), books (which can't be updated by something like 'gofix'), brains of people using Haskell for over a decade etc. Programming languages are just like natural languages: Even if they are often irregular, they form a common ground for communication and understanding each other. Do we need irregular verbs? No. But try to take them away from native speakers... :-) Are irregular verbs really a problem? No. When you are fluent in a language you don't even think about them anymore. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Sat Aug 8 23:30:50 2015 From: will.yager at gmail.com (Will Yager) Date: Sat, 8 Aug 2015 16:30:50 -0700 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: Obviously a change like this would be horribly destructive to existing code, and for relatively little benefit. There are much larger barriers to understanding Haskell than syntactic trivia like the one mentioned here. That said, it seems reasonable to claim that the existing type declaration keywords (type, data, newtype) can be confusing to newbies and somewhat non-intuitive. If we could go back in time and change these small details without breaking swathes of existing code, perhaps we would. I'm sure most of us who use Haskell on a regular basis have a number of small gripes about the language that aren't important enough to break things over, but would still be convenient or aesthetically pleasing to change if we're going to break backwards compatibility anyway. It is worth asking, then, if we should record these small aesthetic suggestions somewhere for consideration while designing the next major compatibility-breaking release of the Haskell specification (Haskell 2020 or what have you). -Will From _deepfire at feelingofgreen.ru Sat Aug 8 23:50:03 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Sun, 09 Aug 2015 02:50:03 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: (sfid-20150809_035027_929904_1F18D3D9) (Will Yager's message of "Sat, 8 Aug 2015 16:30:50 -0700") References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: <87pp2x5oic.fsf@andromedae.feelingofgreen.ru> Will Yager writes: > Obviously a change like this would be horribly destructive to existing code, and > for relatively little benefit. Hidden behind a pragma -- is it really that horribly destructive? > There are much larger barriers to understanding Haskell than syntactic > trivia like the one mentioned here. Barriers exist at every level of mastery -- the ones that matter are those present at the exact point of one's progression. It is, of course, true that at some point the little awkwardness exits the picture completely -- but for any point of time, there always will be a nontrivial set of people thinking to themselves -- "what the heck?!". > It is worth asking, then, if we should record these small aesthetic suggestions > somewhere for consideration while designing the next major compatibility-breaking > release of the Haskell specification (Haskell 2020 or what have you). Now this is exactly the kind of assessment that I have been hoping to hear! And the idea is that, before the next release of the language specification, it is possible to experiment with the keyword hidden behind the pragma -- and should the result prove satisfactory, all that remains to do is to lift the pragma requirement. Maybe a unified playground for such tweaks -- XNewSyntax, for example. Or do people suggest, that it should somehow suddenly materialise in the next release of the specification, without touching any staging ground? -- respectfully, ??????? ?????? -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? ? Friedrich Wilhelm Nietzsche From mwm at mired.org Sat Aug 8 23:55:34 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 08 Aug 2015 23:55:34 +0000 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: On Sat, Aug 8, 2015 at 6:30 PM Will Yager wrote: > It is worth asking, then, if we should record these small aesthetic > suggestions somewhere for consideration while designing the next major > compatibility-breaking release of the Haskell specification (Haskell 2020 > or what have you). > No, let's not be so optimistic (or pessimistic, depending on how you feel) and call it Haskell 3000 . -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Sun Aug 9 01:54:53 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sat, 8 Aug 2015 21:54:53 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: GHC ships with a solution to the original problem about a very confusing `=`: GADT syntax. I *don't* mean GADTs, in all their glory. It has been correctly observed that GADTs are not for the beginner. But there's nothing wrong at all with GADT syntax: > data Maybe a where > Just :: a -> Maybe a > Nothing :: Maybe a This syntax seems to fix the original poster's problem, and more besides. I've had several beginners complain about things like `data Foo = MkFoo Int`, in that we see the phrase `MkFoo Int`, but these two things -- a data constructor and a type -- belong to two very different parts of the syntax. GADT syntax gets rid of these problems. Perhaps tutorials/teachers should just introduce GADT syntax and mention traditional syntax as a historical note. GHC even has the -XGADTSyntax extension to allow the syntax without full-blown GADTs. To respond to two other strands of this thread: - Beyond the difference already observed between `data` and `newtype`, using `newtype` also works with GHC's Coercible mechanism. This is, of course, GHC-specific and not part of standard Haskell, but I thought it worth mentioning. See https://wiki.haskell.org/GHC/Coercible - Haskellers are, of course, welcome to change keywords in their files via CPP. This works, for example: > #define datatype data > #define alias type > > datatype Boolean = F | T > alias IsGood = Boolean > > invert :: IsGood -> IsGood > invert T = F > invert F = T You can even specify such things via the command line via the -D option, so you could create a wrapper around GHC that added the necessary -D options and then you'd have your new language, with nothing extra in your source files. Good luck sharing your code though! Note that this solution is functionally equivalent to hiding the change behind a pragma. Richard From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Aug 9 08:39:21 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 9 Aug 2015 09:39:21 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> <20150808211653.GE15646@weber> <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> <20150808213826.GA16943@weber> Message-ID: <20150809083921.GB16943@weber> On Sun, Aug 09, 2015 at 12:16:27AM +0200, MigMit wrote: > >> 1) This might be the code written by someone using your library/framework. > >> In which case it would know about A and B. > > > > Then it's up to me to define and document whatever strictness properties I > > want for my constructors. > > Of course. But it's NOT up to you to restrict the user from using whatever > techniques xe wants Can you explain how any of this "restricts the user from using whatever techniques he wants"? > > in existing code. Of course that won't work. But for *new* datatypes > > choosing one rather than the other gives no difference in terms of > > denotational semantics. > > If it makes the difference for the old code, then it would make the > difference for the new code as well. I fail to see how. Breaking an API makes a difference for old code, but new code is written to the new API. > >> 2) It might be generated by the Template Haskell ? which is free to use > >> whatever constructor is fed into it. > > > > OK, so show me what goes wrong! > > {-# LANGUAGE TemplateHaskell #-} > module TH where > import Language.Haskell.TH > check :: Name -> ExpQ > check c = [|let x = case x of $(conP c [[p|_|]]) -> $(conE c) 1 in x|] Right, you can distinguish data declarations from newtype declarations this way, but by using Template Haskell you can also distinguish * data A = A Int * data A = A { a :: Int } * data A = A' Int * data A = A Int !(), and * newtype B = B A (where A has one of the above definitions) from each other. My claim is that * data B = B !A is as indistinguishable from the above four as they are from each other. Tom From vlatko.basic at gmail.com Sun Aug 9 08:44:56 2015 From: vlatko.basic at gmail.com (Vlatko Basic) Date: Sun, 9 Aug 2015 10:44:56 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: <55C71308.20101@gmail.com> I saw this as an entertaining "If I could wish..." survey, and don't think anybody is thinking seriously to implement it. If you asked me a few years ago, I'd say yes, go ahead. The benefit/cost rate is far too small, if any. As for the 'beginner-friendly' reason for change, while learning Haskell, it took me half an hour of confusion, and another half an hour of anger of how 'stupid' Haskell is. :-) But it is interesting to see how many people responded to this. Obviously a touchy thing. > -------- Original Message -------- > Subject: Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use > `::=` instead of `=` > From: Oliver Charles > To: Geraldus , Hilco Wijbenga , > Haskell Cafe > Date: 08/08/15 21:14 > > > I hate to come across as a party-pooper, but do we really think it's realistic > that any of these changes will be made? I understand that there may be > benefits, but they don't outweigh the cost of breaking almost all existing > code. The idea of opting in to this with pragmas just doesn't seem worth it, > and further fragments the language, ultimately reducing readability when I > pick up another author's code. > > /ocharles/ > > On Sat, Aug 8, 2015 at 7:29 PM Geraldus > wrote: > > type -> alias > data -> data > newtype -> newalias or newdata? > > `type` keyword was really confusing for me at the beginning, also this > confusion brought another one about `newtype` keyword. > > ??, 8 ???. 2015 ?. ? 22:28, Hilco Wijbenga >: > > On 8 August 2015 at 08:03, Daniel Trstenjak > > wrote: > >> type Name = String > >> data Date = Date Int Int Int > > > > if we're at it ;), then please change it to: > > > > alias Name = String > > type Date = Date Int Int Int > > I wholeheartedly agree with replacing the current "type" with "alias", > the current "type" is just flat out wrong: it does *not* create a > type. This should be very simple to do too: introduce "alias" as a new > keyword and deprecate "type". No existing code would be affected. > > I'm on the fence about "type" instead of "data", though. "data" > clearly conveys the meaning that we are talking about data only, not > functions on that data (as in OOP). (Well, data constructors are > functions too.) Then again, as soon as you add "deriving", you *are* > defining functions on that data. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Sun Aug 9 10:15:47 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sun, 9 Aug 2015 12:15:47 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150809083921.GB16943@weber> References: <20150808204946.GB15646@weber> <1B61A96B-9596-4976-9C56-B3E971413F2E@yandex.ru> <20150808211118.GC15646@weber> <20150808211653.GE15646@weber> <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> Message-ID: <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> > On 09 Aug 2015, at 10:39, Tom Ellis wrote: > > On Sun, Aug 09, 2015 at 12:16:27AM +0200, MigMit wrote: >>>> 1) This might be the code written by someone using your library/framework. >>>> In which case it would know about A and B. >>> >>> Then it's up to me to define and document whatever strictness properties I >>> want for my constructors. >> >> Of course. But it's NOT up to you to restrict the user from using whatever >> techniques xe wants > > Can you explain how any of this "restricts the user from using whatever > techniques he wants"? User can write the code that distinguishes between these two options. You can't force xer not to. You can't even claim that it's a "hack" and shouldn't be allowed. >>> in existing code. Of course that won't work. But for *new* datatypes >>> choosing one rather than the other gives no difference in terms of >>> denotational semantics. >> >> If it makes the difference for the old code, then it would make the >> difference for the new code as well. > > I fail to see how. Breaking an API makes a difference for old code, but new > code is written to the new API. Code is working or not working regardless of when it was written. > >>>> 2) It might be generated by the Template Haskell ? which is free to use >>>> whatever constructor is fed into it. >>> >>> OK, so show me what goes wrong! >> >> {-# LANGUAGE TemplateHaskell #-} >> module TH where >> import Language.Haskell.TH >> check :: Name -> ExpQ >> check c = [|let x = case x of $(conP c [[p|_|]]) -> $(conE c) 1 in x|] > > Right, you can distinguish data declarations from newtype declarations this > way, but by using Template Haskell you can also distinguish > > * data A = A Int > * data A = A { a :: Int } > * data A = A' Int > * data A = A Int !(), and > * newtype B = B A (where A has one of the above definitions) Sure, because they are different. > from each other. My claim is that > > * data B = B !A > > is as indistinguishable from the above four as they are from each other. Can you please NOT say that some thing can be distinguished AND that they are indistinguishable in the same post? From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Aug 9 10:37:29 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 9 Aug 2015 11:37:29 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> References: <20150808211118.GC15646@weber> <20150808211653.GE15646@weber> <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> Message-ID: <20150809103729.GC16943@weber> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: > > Right, you can distinguish data declarations from newtype declarations this > > way, but by using Template Haskell you can also distinguish > > > > * data A = A Int > > * data A = A { a :: Int } > > * data A = A' Int > > * data A = A Int !(), and > > * newtype B = B A (where A has one of the above definitions) > > Sure, because they are different. > > > from each other. My claim is that > > > > * data B = B !A > > > > is as indistinguishable from the above four as they are from each other. > > Can you please NOT say that some thing can be distinguished AND that they > are indistinguishable in the same post? I think we are perhaps talking at cross purposes. To clarify, here is an explicit statement (somewhat weaker than the full generality of my claim): `data D = D !T` and `newtype N = N T` are isomorphic in the sense that there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and `g . f = id`. Do you agree or disagree with this statement? Then we may proceed. Tom From miguelimo38 at yandex.ru Sun Aug 9 11:09:21 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sun, 9 Aug 2015 13:09:21 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150809103729.GC16943@weber> References: <20150808211118.GC15646@weber> <20150808211653.GE15646@weber> <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> Message-ID: <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> I disagree. ?????????? ? iPad > 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): > > On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: >>> Right, you can distinguish data declarations from newtype declarations this >>> way, but by using Template Haskell you can also distinguish >>> >>> * data A = A Int >>> * data A = A { a :: Int } >>> * data A = A' Int >>> * data A = A Int !(), and >>> * newtype B = B A (where A has one of the above definitions) >> >> Sure, because they are different. >> >>> from each other. My claim is that >>> >>> * data B = B !A >>> >>> is as indistinguishable from the above four as they are from each other. >> >> Can you please NOT say that some thing can be distinguished AND that they >> are indistinguishable in the same post? > > I think we are perhaps talking at cross purposes. > > To clarify, here is an explicit statement (somewhat weaker than the full > generality of my claim): > > `data D = D !T` and `newtype N = N T` are isomorphic in the sense that > there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and > `g . f = id`. > > Do you agree or disagree with this statement? Then we may proceed. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Aug 9 11:17:03 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 9 Aug 2015 12:17:03 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> References: <20150808211653.GE15646@weber> <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> Message-ID: <20150809111703.GD16943@weber> On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: > I disagree. Ah, good. A concrete point of disagreement. What, then, is wrong with the solution f :: D -> N f (D t) = N t g :: N -> D g (N t) = D t If you disagree that `f . g = id` and `g . f = id` then you must be able to find * a type `T` and either * `n :: N` such that `f (g n)` does not denote the same thing as `n` or * `d :: D` such that `g (f d)` does not denote the same thing as `d` Can you? Tom > > 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): > > On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: > >>> Right, you can distinguish data declarations from newtype declarations this > >>> way, but by using Template Haskell you can also distinguish > >>> > >>> * data A = A Int > >>> * data A = A { a :: Int } > >>> * data A = A' Int > >>> * data A = A Int !(), and > >>> * newtype B = B A (where A has one of the above definitions) > >> > >> Sure, because they are different. > >> > >>> from each other. My claim is that > >>> > >>> * data B = B !A > >>> > >>> is as indistinguishable from the above four as they are from each other. > >> > >> Can you please NOT say that some thing can be distinguished AND that they > >> are indistinguishable in the same post? > > > > I think we are perhaps talking at cross purposes. > > > > To clarify, here is an explicit statement (somewhat weaker than the full > > generality of my claim): > > > > `data D = D !T` and `newtype N = N T` are isomorphic in the sense that > > there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and > > `g . f = id`. > > > > Do you agree or disagree with this statement? Then we may proceed. From miguelimo38 at yandex.ru Sun Aug 9 11:30:01 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sun, 9 Aug 2015 13:30:01 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150809111703.GD16943@weber> References: <20150808211653.GE15646@weber> <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> <20150809111703.GD16943@weber> Message-ID: First, the half that I agree with: f . g = id. No doubt. But g . f > id. And the value "d" that you want is "undefined". g (f undefined) = D undefined, which is not the same as (undefined :: D). ?????????? ? iPad > 9 ???. 2015 ?., ? 13:17, Tom Ellis ???????(?): > >> On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: >> I disagree. > > Ah, good. A concrete point of disagreement. What, then, is wrong with the > solution > > f :: D -> N > f (D t) = N t > > g :: N -> D > g (N t) = D t > > If you disagree that `f . g = id` and `g . f = id` then you must be able to > find > > * a type `T` > > and either > > * `n :: N` such that `f (g n)` does not denote the same thing as `n` > > or > > * `d :: D` such that `g (f d)` does not denote the same thing as `d` > > Can you? > > Tom > > >>> 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): >>> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: >>>>> Right, you can distinguish data declarations from newtype declarations this >>>>> way, but by using Template Haskell you can also distinguish >>>>> >>>>> * data A = A Int >>>>> * data A = A { a :: Int } >>>>> * data A = A' Int >>>>> * data A = A Int !(), and >>>>> * newtype B = B A (where A has one of the above definitions) >>>> >>>> Sure, because they are different. >>>> >>>>> from each other. My claim is that >>>>> >>>>> * data B = B !A >>>>> >>>>> is as indistinguishable from the above four as they are from each other. >>>> >>>> Can you please NOT say that some thing can be distinguished AND that they >>>> are indistinguishable in the same post? >>> >>> I think we are perhaps talking at cross purposes. >>> >>> To clarify, here is an explicit statement (somewhat weaker than the full >>> generality of my claim): >>> >>> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that >>> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and >>> `g . f = id`. >>> >>> Do you agree or disagree with this statement? Then we may proceed. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Aug 9 11:35:55 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 9 Aug 2015 12:35:55 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> <20150809111703.GD16943@weber> Message-ID: <20150809113555.GF16943@weber> On the contrary, it *is* the same thing Prelude> data D = D !Int deriving Show Prelude> D undefined *** Exception: Prelude.undefined Prelude> undefined :: D *** Exception: Prelude.undefined On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: > First, the half that I agree with: f . g = id. No doubt. > > But g . f > id. And the value "d" that you want is "undefined". g (f > undefined) = D undefined, which is not the same as (undefined :: D). > > ?????????? ? iPad > > > 9 ???. 2015 ?., ? 13:17, Tom Ellis ???????(?): > > > >> On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: > >> I disagree. > > > > Ah, good. A concrete point of disagreement. What, then, is wrong with the > > solution > > > > f :: D -> N > > f (D t) = N t > > > > g :: N -> D > > g (N t) = D t > > > > If you disagree that `f . g = id` and `g . f = id` then you must be able to > > find > > > > * a type `T` > > > > and either > > > > * `n :: N` such that `f (g n)` does not denote the same thing as `n` > > > > or > > > > * `d :: D` such that `g (f d)` does not denote the same thing as `d` > > > > Can you? > > > > Tom > > > > > >>> 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): > >>> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: > >>>>> Right, you can distinguish data declarations from newtype declarations this > >>>>> way, but by using Template Haskell you can also distinguish > >>>>> > >>>>> * data A = A Int > >>>>> * data A = A { a :: Int } > >>>>> * data A = A' Int > >>>>> * data A = A Int !(), and > >>>>> * newtype B = B A (where A has one of the above definitions) > >>>> > >>>> Sure, because they are different. > >>>> > >>>>> from each other. My claim is that > >>>>> > >>>>> * data B = B !A > >>>>> > >>>>> is as indistinguishable from the above four as they are from each other. > >>>> > >>>> Can you please NOT say that some thing can be distinguished AND that they > >>>> are indistinguishable in the same post? > >>> > >>> I think we are perhaps talking at cross purposes. > >>> > >>> To clarify, here is an explicit statement (somewhat weaker than the full > >>> generality of my claim): > >>> > >>> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that > >>> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and > >>> `g . f = id`. > >>> > >>> Do you agree or disagree with this statement? Then we may proceed. From PascalWittmann at gmx.net Sun Aug 9 13:58:00 2015 From: PascalWittmann at gmx.net (Pascal Wittmann) Date: Sun, 9 Aug 2015 15:58:00 +0200 Subject: [Haskell-cafe] HAL-10 Message-ID: <55C75C68.1070906@gmx.net> Hi there, I just wanted to ask whether I just missed this years HAL (Haskell in Halle/Leipzig) or if it was canceled this year. Cheers Pascal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From miguelimo38 at yandex.ru Sun Aug 9 17:49:10 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sun, 9 Aug 2015 19:49:10 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150809113555.GF16943@weber> References: <20150808211951.GF15646@weber> <107F4F28-8056-4D8C-8621-A341CF25595A@yandex.ru> <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> <20150809111703.GD16943@weber> <20150809113555.GF16943@weber> Message-ID: <905613E9-284A-494B-946E-DDA14FC1BF6C@yandex.ru> You know, you've kinda conviced me. The difference between strict and non-strict parameters is in how constructors work. "data D = D Int" is still the same as "data D = D !Int", but it's constructor ? as a function ? is more restricted. It's somewhat like defining "d n = D $! n", and then not exporting D, but only d. That said, it might be true that semantics differ depending on what is exported. So, it might be true that your D has the same semantics as N. We still can distinguish between those using various unsafe* hacks ? but those are what they are: hacks. ?????????? ? iPad > 9 ???. 2015 ?., ? 13:35, Tom Ellis ???????(?): > > On the contrary, it *is* the same thing > > Prelude> data D = D !Int deriving Show > Prelude> D undefined > *** Exception: Prelude.undefined > Prelude> undefined :: D > *** Exception: Prelude.undefined > > >> On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: >> First, the half that I agree with: f . g = id. No doubt. >> >> But g . f > id. And the value "d" that you want is "undefined". g (f >> undefined) = D undefined, which is not the same as (undefined :: D). >> >> ?????????? ? iPad >> >>>> 9 ???. 2015 ?., ? 13:17, Tom Ellis ???????(?): >>>> >>>> On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: >>>> I disagree. >>> >>> Ah, good. A concrete point of disagreement. What, then, is wrong with the >>> solution >>> >>> f :: D -> N >>> f (D t) = N t >>> >>> g :: N -> D >>> g (N t) = D t >>> >>> If you disagree that `f . g = id` and `g . f = id` then you must be able to >>> find >>> >>> * a type `T` >>> >>> and either >>> >>> * `n :: N` such that `f (g n)` does not denote the same thing as `n` >>> >>> or >>> >>> * `d :: D` such that `g (f d)` does not denote the same thing as `d` >>> >>> Can you? >>> >>> Tom >>> >>> >>>>> 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): >>>>> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: >>>>>>> Right, you can distinguish data declarations from newtype declarations this >>>>>>> way, but by using Template Haskell you can also distinguish >>>>>>> >>>>>>> * data A = A Int >>>>>>> * data A = A { a :: Int } >>>>>>> * data A = A' Int >>>>>>> * data A = A Int !(), and >>>>>>> * newtype B = B A (where A has one of the above definitions) >>>>>> >>>>>> Sure, because they are different. >>>>>> >>>>>>> from each other. My claim is that >>>>>>> >>>>>>> * data B = B !A >>>>>>> >>>>>>> is as indistinguishable from the above four as they are from each other. >>>>>> >>>>>> Can you please NOT say that some thing can be distinguished AND that they >>>>>> are indistinguishable in the same post? >>>>> >>>>> I think we are perhaps talking at cross purposes. >>>>> >>>>> To clarify, here is an explicit statement (somewhat weaker than the full >>>>> generality of my claim): >>>>> >>>>> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that >>>>> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and >>>>> `g . f = id`. >>>>> >>>>> Do you agree or disagree with this statement? Then we may proceed. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From alexey.muranov at gmail.com Sun Aug 9 18:12:31 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Sun, 9 Aug 2015 21:12:31 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: Message-ID: On 9 ao?t 2015, at 15:00, haskell-cafe-request at haskell.org wrote: > From: Will Yager > Subject: Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` > Date: 9 ao?t 2015 02:30:50 UTC+3 > To: Hilco Wijbenga > Cc: Haskell Cafe , MigMit > It is worth asking, then, if we should record these small aesthetic suggestions somewhere for consideration while designing the next major compatibility-breaking release of the Haskell specification (Haskell 2020 or what have you). +1 Alexey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Aug 9 20:04:37 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 9 Aug 2015 21:04:37 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: Message-ID: <20150809200437.GC20036@weber> On Sun, Aug 09, 2015 at 09:12:31PM +0300, Alexey Muranov wrote: > On 9 ao?t 2015, at 15:00, haskell-cafe-request at haskell.org wrote: > > From: Will Yager > > Subject: Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` > > Date: 9 ao?t 2015 02:30:50 UTC+3 > > To: Hilco Wijbenga > > Cc: Haskell Cafe , MigMit > > > It is worth asking, then, if we should record these small aesthetic suggestions somewhere for consideration while designing the next major compatibility-breaking release of the Haskell specification (Haskell 2020 or what have you). > > +1 Very much +1 From amindfv at gmail.com Sun Aug 9 20:48:25 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sun, 9 Aug 2015 16:48:25 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150809200437.GC20036@weber> References: <20150809200437.GC20036@weber> Message-ID: <84816381-C348-4E13-A997-695C40560186@gmail.com> El Aug 9, 2015, a las 16:04, Tom Ellis escribi?: > On Sun, Aug 09, 2015 at 09:12:31PM +0300, Alexey Muranov wrote: >> On 9 ao?t 2015, at 15:00, haskell-cafe-request at haskell.org wrote: >>> From: Will Yager >>> Subject: Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` >>> Date: 9 ao?t 2015 02:30:50 UTC+3 >>> To: Hilco Wijbenga >>> Cc: Haskell Cafe , MigMit >> >>> It is worth asking, then, if we should record these small aesthetic suggestions somewhere for consideration while designing the next major compatibility-breaking release of the Haskell specification (Haskell 2020 or what have you). >> >> +1 > > Very much +1 I have to say, I'm very -1 on what sounds like a Perl 6 or Python 3 endeavor. Small and incremental seems to demonstrably be the way to make breaking changes. tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Aug 9 20:53:26 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 9 Aug 2015 21:53:26 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <84816381-C348-4E13-A997-695C40560186@gmail.com> References: <20150809200437.GC20036@weber> <84816381-C348-4E13-A997-695C40560186@gmail.com> Message-ID: <20150809205326.GF20036@weber> On Sun, Aug 09, 2015 at 04:48:25PM -0400, amindfv at gmail.com wrote: > El Aug 9, 2015, a las 16:04, Tom Ellis escribi?: > > On Sun, Aug 09, 2015 at 09:12:31PM +0300, Alexey Muranov wrote: > >> On 9 ao?t 2015, at 15:00, haskell-cafe-request at haskell.org wrote: > >>> From: Will Yager > >>> Subject: Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` > >>> Date: 9 ao?t 2015 02:30:50 UTC+3 > >>> To: Hilco Wijbenga > >>> Cc: Haskell Cafe , MigMit > >> > >>> It is worth asking, then, if we should record these small aesthetic suggestions somewhere for consideration while designing the next major compatibility-breaking release of the Haskell specification (Haskell 2020 or what have you). > >> > >> +1 > > > > Very much +1 > > I have to say, I'm very -1 on what sounds like a Perl 6 or Python 3 > endeavor. Small and incremental seems to demonstrably be the way to make > breaking changes. My +1 was to keeping a record of small but breaking changes that, if made at inception, would have benefitted what Haskell is now. What anyone else wants to *do* with such a record is up to them. Tom From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Aug 9 21:10:04 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 9 Aug 2015 22:10:04 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <905613E9-284A-494B-946E-DDA14FC1BF6C@yandex.ru> References: <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> <20150809111703.GD16943@weber> <20150809113555.GF16943@weber> <905613E9-284A-494B-946E-DDA14FC1BF6C@yandex.ru> Message-ID: <20150809211004.GG20036@weber> On Sun, Aug 09, 2015 at 07:49:10PM +0200, MigMit wrote: > You know, you've kinda conviced me. I hope I'm correct then! > The difference between strict and non-strict parameters is in how > constructors work. "data D = D Int" is still the same as "data D = D > !Int", but it's constructor ? as a function ? is more restricted. It's > somewhat like defining "d n = D $! n", and then not exporting D, but only > d. Right. > That said, it might be true that semantics differ depending on what is > exported. So, it might be true that your D has the same semantics as N. > We still can distinguish between those using various unsafe* hacks ? but > those are what they are: hacks. > > ?????????? ? iPad > > > 9 ???. 2015 ?., ? 13:35, Tom Ellis ???????(?): > > > > On the contrary, it *is* the same thing > > > > Prelude> data D = D !Int deriving Show > > Prelude> D undefined > > *** Exception: Prelude.undefined > > Prelude> undefined :: D > > *** Exception: Prelude.undefined > > > > > >> On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: > >> First, the half that I agree with: f . g = id. No doubt. > >> > >> But g . f > id. And the value "d" that you want is "undefined". g (f > >> undefined) = D undefined, which is not the same as (undefined :: D). > >> > >> ?????????? ? iPad > >> > >>>> 9 ???. 2015 ?., ? 13:17, Tom Ellis ???????(?): > >>>> > >>>> On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: > >>>> I disagree. > >>> > >>> Ah, good. A concrete point of disagreement. What, then, is wrong with the > >>> solution > >>> > >>> f :: D -> N > >>> f (D t) = N t > >>> > >>> g :: N -> D > >>> g (N t) = D t > >>> > >>> If you disagree that `f . g = id` and `g . f = id` then you must be able to > >>> find > >>> > >>> * a type `T` > >>> > >>> and either > >>> > >>> * `n :: N` such that `f (g n)` does not denote the same thing as `n` > >>> > >>> or > >>> > >>> * `d :: D` such that `g (f d)` does not denote the same thing as `d` > >>> > >>> Can you? > >>> > >>> Tom > >>> > >>> > >>>>> 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): > >>>>> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: > >>>>>>> Right, you can distinguish data declarations from newtype declarations this > >>>>>>> way, but by using Template Haskell you can also distinguish > >>>>>>> > >>>>>>> * data A = A Int > >>>>>>> * data A = A { a :: Int } > >>>>>>> * data A = A' Int > >>>>>>> * data A = A Int !(), and > >>>>>>> * newtype B = B A (where A has one of the above definitions) > >>>>>> > >>>>>> Sure, because they are different. > >>>>>> > >>>>>>> from each other. My claim is that > >>>>>>> > >>>>>>> * data B = B !A > >>>>>>> > >>>>>>> is as indistinguishable from the above four as they are from each other. > >>>>>> > >>>>>> Can you please NOT say that some thing can be distinguished AND that they > >>>>>> are indistinguishable in the same post? > >>>>> > >>>>> I think we are perhaps talking at cross purposes. > >>>>> > >>>>> To clarify, here is an explicit statement (somewhat weaker than the full > >>>>> generality of my claim): > >>>>> > >>>>> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that > >>>>> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and > >>>>> `g . f = id`. > >>>>> > >>>>> Do you agree or disagree with this statement? Then we may proceed. > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From will.yager at gmail.com Sun Aug 9 23:49:18 2015 From: will.yager at gmail.com (Will Yager) Date: Sun, 9 Aug 2015 16:49:18 -0700 Subject: [Haskell-cafe] Appropriate location for list of language suggestions Message-ID: <8A1488AE-8663-4326-AC1E-ECD9E82C0506@gmail.com> This email is in response to the (ongoing) Haskell-cafe discussion about type declaration syntax. There are a number of hypothetical changes to Haskell that could be aesthetically pleasing or convenient if implemented, but not to such a degree that the added convenience outweighs the added complexity of a pragma-gated feature or the cost of breaking existing code. (Case in point: renaming type/newtype/data to be less confusing to first-time users) However, there may be better opportunities to implement such changes in the future, and it would be a shame if every good (but perhaps somewhat trivial) idea was lost to the annals of the mailing list. Therefore, I proposed that we might maintain a list of nitpicks, which could be used to inform future decisions about breaking changes to the Haskell specification. I'm not sure what the most appropriate forum is for such a list. The mailing list is sub-optimal, because we might end up with a huge email chain littered with bikeshedding reply-alls. I would be willing to host and maintain such a list on Github, but that seems somewhat antithetical to the Haskell community's generally more distributed style of discussion. The wiki might be appropriate, but I don't know if it's conducive to proper moderation; we may have to filter out suggestions like "add for loops". --Will From strake888 at gmail.com Mon Aug 10 00:48:33 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sun, 9 Aug 2015 16:48:33 -0800 Subject: [Haskell-cafe] Pattern guards in comprehensions Message-ID: <55c7f16a.e407460a.c9fee.ffff831a@mx.google.com> I propose we add pattern guards in comprehensions, but I'm not sure what syntax would work. Consider this function: allMinus :: [Natural] -> [Natural] allMinus m = mapMaybe (-? m) where n -? m | m > n = Nothing | True = Just (n-m) One may wish to write such as a list comprehension, but it is cumbersome: allMinus m ns = [n' | n@((-? m) -> Just n') <- ns] This would be clearer with pattern guards, fictitious syntax here: allMinus m ns = [n' | n <- ns, Just n' <- n -? m] Alas, this conflicts with the other part of list comprehension syntax. Try we this, actual syntax now: allMinus m ns = [n' | n <- ns, let Just n' = n -? m] Nope, that's an error if (any (< m) ns). I recognize in this case the one in terms of mapMaybe is quite clear, but in the case of some other code I'm writing it's much more complicated. Ideas: 1. Modify semantics of let in comprehension to skip that element on pattern mismatch 2. Use another keyword, e.g. [n' | n <- ns where Just n' <- n -? m] Thoughts? From eir at cis.upenn.edu Mon Aug 10 02:49:02 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 9 Aug 2015 22:49:02 -0400 Subject: [Haskell-cafe] Appropriate location for list of language suggestions In-Reply-To: <8A1488AE-8663-4326-AC1E-ECD9E82C0506@gmail.com> References: <8A1488AE-8663-4326-AC1E-ECD9E82C0506@gmail.com> Message-ID: I think that a wiki (either the one at wiki.haskell.org or the one at https://ghc.haskell.org/trac/ghc/, but probably the first is more general) is a great place for such a list. Any such list will be treated critically by any consumers (that is, future implementors/language designers), so I'm not worried about silly suggestions like for loops. Additionally, if it's started with suggestions containing links to mailing-list discussions advocating for a design, then a consumer can see which suggestions have (at least some) buy-in from the community. Richard On Aug 9, 2015, at 7:49 PM, Will Yager wrote: > This email is in response to the (ongoing) Haskell-cafe discussion about type declaration syntax. > > There are a number of hypothetical changes to Haskell that could be aesthetically pleasing or convenient if implemented, but not to such a degree that the added convenience outweighs the added complexity of a pragma-gated feature or the cost of breaking existing code. > > (Case in point: renaming type/newtype/data to be less confusing to first-time users) > > However, there may be better opportunities to implement such changes in the future, and it would be a shame if every good (but perhaps somewhat trivial) idea was lost to the annals of the mailing list. > > Therefore, I proposed that we might maintain a list of nitpicks, which could be used to inform future decisions about breaking changes to the Haskell specification. > > I'm not sure what the most appropriate forum is for such a list. The mailing list is sub-optimal, because we might end up with a huge email chain littered with bikeshedding reply-alls. I would be willing to host and maintain such a list on Github, but that seems somewhat antithetical to the Haskell community's generally more distributed style of discussion. > > The wiki might be appropriate, but I don't know if it's conducive to proper moderation; we may have to filter out suggestions like "add for loops". > > --Will > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From eir at cis.upenn.edu Mon Aug 10 02:53:01 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 9 Aug 2015 22:53:01 -0400 Subject: [Haskell-cafe] Pattern guards in comprehensions In-Reply-To: <55c7f16a.e407460a.c9fee.ffff831a@mx.google.com> References: <55c7f16a.e407460a.c9fee.ffff831a@mx.google.com> Message-ID: <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> This can be done today: > allMinus m ns = [ n' | n <- ns, Just n' <- [n -? m] ] The syntax is a bit regrettable, but it works quite well. You could use `Just n' <- return (n -? m)` if you wanted, or be even more pedantic and make a synonym `patternMatch :: a -> [a]; patternMatch = return` and say `Just n' <- patternMatch (n -? m)`. Richard On Aug 9, 2015, at 8:48 PM, M Farkas-Dyck wrote: > I propose we add pattern guards in comprehensions, but I'm not sure what syntax would work. Consider this function: > > allMinus :: [Natural] -> [Natural] > allMinus m = mapMaybe (-? m) > where n -? m | m > n = Nothing > | True = Just (n-m) > > One may wish to write such as a list comprehension, but it is cumbersome: > > allMinus m ns = [n' | n@((-? m) -> Just n') <- ns] > > This would be clearer with pattern guards, fictitious syntax here: > > allMinus m ns = [n' | n <- ns, Just n' <- n -? m] > > Alas, this conflicts with the other part of list comprehension syntax. Try we this, actual syntax now: > > allMinus m ns = [n' | n <- ns, let Just n' = n -? m] > > Nope, that's an error if (any (< m) ns). > > I recognize in this case the one in terms of mapMaybe is quite clear, but in the case of some other code I'm writing it's much more complicated. > > Ideas: > 1. Modify semantics of let in comprehension to skip that element on pattern mismatch > 2. Use another keyword, e.g. [n' | n <- ns where Just n' <- n -? m] > > Thoughts? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From strake888 at gmail.com Mon Aug 10 03:55:46 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sun, 9 Aug 2015 19:55:46 -0800 Subject: [Haskell-cafe] Pattern guards in comprehensions In-Reply-To: <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> References: <55c7f16a.e407460a.c9fee.ffff831a@mx.google.com> <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> Message-ID: <55c81d4a.c59f420a.37d1.ffffe278@mx.google.com> On 09/08/2015 at 22:53:01 -0400, Richard Eisenberg wrote: > This can be done today: > > > allMinus m ns = [ n' | n <- ns, Just n' <- [n -? m] ] Ah, obviously. Please excuse my earlier stupidity. From eir at cis.upenn.edu Mon Aug 10 03:57:34 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 9 Aug 2015 23:57:34 -0400 Subject: [Haskell-cafe] Pattern guards in comprehensions In-Reply-To: <55c81d4a.c59f420a.37d1.ffffe278@mx.google.com> References: <55c7f16a.e407460a.c9fee.ffff831a@mx.google.com> <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> <55c81d4a.c59f420a.37d1.ffffe278@mx.google.com> Message-ID: Apologies if my earlier message came across as a bit brutal. When I first saw this pattern a little while ago, I was surprised by it too! Cheers, Richard On Aug 9, 2015, at 11:55 PM, M Farkas-Dyck wrote: > On 09/08/2015 at 22:53:01 -0400, Richard Eisenberg wrote: >> This can be done today: >> >>> allMinus m ns = [ n' | n <- ns, Just n' <- [n -? m] ] > > Ah, obviously. Please excuse my earlier stupidity. From strake888 at gmail.com Mon Aug 10 05:07:27 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sun, 9 Aug 2015 21:07:27 -0800 Subject: [Haskell-cafe] Pattern guards in comprehensions In-Reply-To: References: <55c7f16a.e407460a.c9fee.ffff831a@mx.google.com> <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> <55c81d4a.c59f420a.37d1.ffffe278@mx.google.com> Message-ID: <55c82e18.882e460a.4f50.fffffed1@mx.google.com> On 09/08/2015 at 23:57:34 -0400, Richard Eisenberg wrote: > Apologies if my earlier message came across as a bit brutal. Not at all; thanks for the help ? From lee.duhem at gmail.com Mon Aug 10 05:48:06 2015 From: lee.duhem at gmail.com (Lee Duhem) Date: Mon, 10 Aug 2015 13:48:06 +0800 Subject: [Haskell-cafe] monads, memoization etc In-Reply-To: References: Message-ID: On Sat, Aug 8, 2015 at 9:11 AM, Ilya Razenshteyn wrote: > Note that I'm interested in a universal memoization strategy, Have you read https://wiki.haskell.org/Memoization ? lee From alexey.muranov at gmail.com Mon Aug 10 09:22:04 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Mon, 10 Aug 2015 02:22:04 -0700 (PDT) Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150809205326.GF20036@weber> References: <20150809200437.GC20036@weber> <84816381-C348-4E13-A997-695C40560186@gmail.com> <20150809205326.GF20036@weber> Message-ID: On Sunday, August 9, 2015 at 11:53:35 PM UTC+3, Tom Ellis wrote: > > > My +1 was to keeping a record of small but breaking changes that, if made > at > inception, would have benefitted what Haskell is now. What anyone else > wants to *do* with such a record is up to them. > A separate +1 to this emphasis on keeping track of possible or desired (even if unfeasible) improvements. Here is my another argument for this: academic papers about Haskell or functional programming do not have to keep to the actual Haskell syntax. IMO, they could benefit in clarity by switching to some pseudo-Haskell with `:` instead of `::` for typing, `::=` instead of `=` in `data` definition, etc: the description language of the underlying abstraction should be independent from the current implementation syntax. Alexey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Mon Aug 10 09:28:54 2015 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Mon, 10 Aug 2015 12:28:54 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <20150809200437.GC20036@weber> <84816381-C348-4E13-A997-695C40560186@gmail.com> <20150809205326.GF20036@weber> Message-ID: <3133161439198934@web7g.yandex.ru> So that copy-pasting from the paper to the interpreter would result in compilation failures. Bravo. 10.08.2015, 12:22, "Alexey Muranov" : > On Sunday, August 9, 2015 at 11:53:35 PM UTC+3, Tom Ellis wrote: >> My +1 was to keeping a record of small but breaking changes that, if made at >> inception, would have benefitted what Haskell is now. ?What anyone else >> wants to *do* with such a record is up to them. > > A separate +1 to this emphasis on keeping track of possible or desired (even if unfeasible) improvements. > > Here is my another argument for this: academic papers about Haskell or functional programming do not have to keep to the actual Haskell syntax. ?IMO, they could benefit in clarity by switching to some pseudo-Haskell with `:` instead of `::` for typing, `::=` instead of `=` in `data` definition, etc: ?the description language of the underlying abstraction should be independent from the current implementation syntax. > > Alexey. > , > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From alexey.muranov at gmail.com Mon Aug 10 09:30:44 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Mon, 10 Aug 2015 12:30:44 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <3133161439198934@web7g.yandex.ru> References: <20150809200437.GC20036@weber> <84816381-C348-4E13-A997-695C40560186@gmail.com> <20150809205326.GF20036@weber> <3133161439198934@web7g.yandex.ru> Message-ID: <7A6E035D-8F18-47FE-BF9C-5F7DD17715C8@gmail.com> On 10 ao?t 2015, at 12:28, Miguel Mitrofanov wrote: > So that copy-pasting from the paper to the interpreter would result in compilation failures. Bravo. I was talking about academic papers,, not about programmers' blog posts. Alexey. From miguelimo38 at yandex.ru Mon Aug 10 09:35:11 2015 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Mon, 10 Aug 2015 12:35:11 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <7A6E035D-8F18-47FE-BF9C-5F7DD17715C8@gmail.com> References: <20150809200437.GC20036@weber> <84816381-C348-4E13-A997-695C40560186@gmail.com> <20150809205326.GF20036@weber> <3133161439198934@web7g.yandex.ru> <7A6E035D-8F18-47FE-BF9C-5F7DD17715C8@gmail.com> Message-ID: <1201131439199311@web13o.yandex.ru> Me too. They usually contain quite a lot of usable, or, at least, runnable code. 10.08.2015, 12:30, "Alexey Muranov" : > On 10 ao?t 2015, at 12:28, Miguel Mitrofanov wrote: > >> ?So that copy-pasting from the paper to the interpreter would result in compilation failures. Bravo. > > I was talking about academic papers,, not about programmers' blog posts. > > Alexey. From anselm.scholl at tu-harburg.de Mon Aug 10 11:38:23 2015 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Mon, 10 Aug 2015 13:38:23 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150809211004.GG20036@weber> References: <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> <20150809111703.GD16943@weber> <20150809113555.GF16943@weber> <905613E9-284A-494B-946E-DDA14FC1BF6C@yandex.ru> <20150809211004.GG20036@weber> Message-ID: <55C88D2F.1050102@tu-harburg.de> There is still a difference between a data type with one strict field and a newtype: You can strip the constructor of a newtype without evaluating anything. Suppose we have data D = D !D data N = N N d :: D d = D d n :: N n = N n d and n both evaluate to bottom, but it is possible to pattern match on (N t) and succeed, while matching on (D t) does not. Example: mkDs :: Int -> D -> String mkDs i (D t) | i <= 0 = [] | otherwise = 'd' : mkDs (i - 1) t mkNs :: Int -> N -> String mkNs i (N t) | i <= 0 = [] | otherwise = 'n' : mkNs (i - 1) t Evaluating mkNs 5 n returns "nnnnn", while evaluating mkDs 5 d loops forever. Now we can define: f :: D -> N f (D t) = N (f t) g :: N -> D g (N t) = D (g t) id1 :: D -> D id1 = g . f id2 :: N -> N id2 = f . g If both representations should be equal, we should get that mkNs 5 n == mkNs 5 (id2 n). But id2 converts everything to the D type first, which is only inhabited by _|_, and then pattern matches on it. So we get "nnnnn" == _|_, which is obviously false. If we change f to use a lazy pattern match, the equality holds again. So D and N are maybe equivalent if we allow only lazy pattern matches on D. As this is not the case, the two are clearly not equivalent. On 08/09/2015 11:10 PM, Tom Ellis wrote: > On Sun, Aug 09, 2015 at 07:49:10PM +0200, MigMit wrote: >> You know, you've kinda conviced me. > > I hope I'm correct then! > >> The difference between strict and non-strict parameters is in how >> constructors work. "data D = D Int" is still the same as "data D = D >> !Int", but it's constructor ? as a function ? is more restricted. It's >> somewhat like defining "d n = D $! n", and then not exporting D, but only >> d. > > Right. > >> That said, it might be true that semantics differ depending on what is >> exported. So, it might be true that your D has the same semantics as N. >> We still can distinguish between those using various unsafe* hacks ? but >> those are what they are: hacks. >> >> ?????????? ? iPad >> >>> 9 ???. 2015 ?., ? 13:35, Tom Ellis ???????(?): >>> >>> On the contrary, it *is* the same thing >>> >>> Prelude> data D = D !Int deriving Show >>> Prelude> D undefined >>> *** Exception: Prelude.undefined >>> Prelude> undefined :: D >>> *** Exception: Prelude.undefined >>> >>> >>>> On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: >>>> First, the half that I agree with: f . g = id. No doubt. >>>> >>>> But g . f > id. And the value "d" that you want is "undefined". g (f >>>> undefined) = D undefined, which is not the same as (undefined :: D). >>>> >>>> ?????????? ? iPad >>>> >>>>>> 9 ???. 2015 ?., ? 13:17, Tom Ellis ???????(?): >>>>>> >>>>>> On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: >>>>>> I disagree. >>>>> >>>>> Ah, good. A concrete point of disagreement. What, then, is wrong with the >>>>> solution >>>>> >>>>> f :: D -> N >>>>> f (D t) = N t >>>>> >>>>> g :: N -> D >>>>> g (N t) = D t >>>>> >>>>> If you disagree that `f . g = id` and `g . f = id` then you must be able to >>>>> find >>>>> >>>>> * a type `T` >>>>> >>>>> and either >>>>> >>>>> * `n :: N` such that `f (g n)` does not denote the same thing as `n` >>>>> >>>>> or >>>>> >>>>> * `d :: D` such that `g (f d)` does not denote the same thing as `d` >>>>> >>>>> Can you? >>>>> >>>>> Tom >>>>> >>>>> >>>>>>> 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): >>>>>>> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: >>>>>>>>> Right, you can distinguish data declarations from newtype declarations this >>>>>>>>> way, but by using Template Haskell you can also distinguish >>>>>>>>> >>>>>>>>> * data A = A Int >>>>>>>>> * data A = A { a :: Int } >>>>>>>>> * data A = A' Int >>>>>>>>> * data A = A Int !(), and >>>>>>>>> * newtype B = B A (where A has one of the above definitions) >>>>>>>> >>>>>>>> Sure, because they are different. >>>>>>>> >>>>>>>>> from each other. My claim is that >>>>>>>>> >>>>>>>>> * data B = B !A >>>>>>>>> >>>>>>>>> is as indistinguishable from the above four as they are from each other. >>>>>>>> >>>>>>>> Can you please NOT say that some thing can be distinguished AND that they >>>>>>>> are indistinguishable in the same post? >>>>>>> >>>>>>> I think we are perhaps talking at cross purposes. >>>>>>> >>>>>>> To clarify, here is an explicit statement (somewhat weaker than the full >>>>>>> generality of my claim): >>>>>>> >>>>>>> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that >>>>>>> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and >>>>>>> `g . f = id`. >>>>>>> >>>>>>> Do you agree or disagree with this statement? Then we may proceed. >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From amindfv at gmail.com Mon Aug 10 12:40:43 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 10 Aug 2015 08:40:43 -0400 Subject: [Haskell-cafe] Pattern guards in comprehensions In-Reply-To: <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> References: <55c7f16a.e407460a.c9fee.ffff831a@mx.google.com> <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> Message-ID: There's an even nicer way! Use view patterns: allMinus m ns = [ n' | ((?- m) -> Just n') <- ns ] I wrote a blog post about this when i discovered it but my blog's not up at the moment... Tom El Aug 9, 2015, a las 22:53, Richard Eisenberg escribi?: > This can be done today: > >> allMinus m ns = [ n' | n <- ns, Just n' <- [n -? m] ] > > The syntax is a bit regrettable, but it works quite well. You could use `Just n' <- return (n -? m)` if you wanted, or be even more pedantic and make a synonym `patternMatch :: a -> [a]; patternMatch = return` and say `Just n' <- patternMatch (n -? m)`. > > Richard > > On Aug 9, 2015, at 8:48 PM, M Farkas-Dyck wrote: > >> I propose we add pattern guards in comprehensions, but I'm not sure what syntax would work. Consider this function: >> >> allMinus :: [Natural] -> [Natural] >> allMinus m = mapMaybe (-? m) >> where n -? m | m > n = Nothing >> | True = Just (n-m) >> >> One may wish to write such as a list comprehension, but it is cumbersome: >> >> allMinus m ns = [n' | n@((-? m) -> Just n') <- ns] >> >> This would be clearer with pattern guards, fictitious syntax here: >> >> allMinus m ns = [n' | n <- ns, Just n' <- n -? m] >> >> Alas, this conflicts with the other part of list comprehension syntax. Try we this, actual syntax now: >> >> allMinus m ns = [n' | n <- ns, let Just n' = n -? m] >> >> Nope, that's an error if (any (< m) ns). >> >> I recognize in this case the one in terms of mapMaybe is quite clear, but in the case of some other code I'm writing it's much more complicated. >> >> Ideas: >> 1. Modify semantics of let in comprehension to skip that element on pattern mismatch >> 2. Use another keyword, e.g. [n' | n <- ns where Just n' <- n -? m] >> >> Thoughts? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From haskell at jschneider.net Mon Aug 10 13:06:50 2015 From: haskell at jschneider.net (Jon Schneider) Date: Mon, 10 Aug 2015 14:06:50 +0100 Subject: [Haskell-cafe] Unregisterised builds Message-ID: Good day all, I am still having issues with (the output from) the cross compiler I have built for PowerPC (e500 family). It seems the runtime is vaguely sane in that it's purposefully whirring round schedule() but for some reason for a "Hello World" allocates stack then heap (after ^C) then runs out then locks up but does not exit. I don't (yet) understand the runtime enough to find the boundary between behaving and not. /tmp # ./helloworld +RTS -Ds created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: allocating new stack chunk of size 32768 bytes cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: allocating new stack chunk of size 32768 bytes ... I have gone through the various +RTS flags but feel I'm going to have to use gdb some more. When using unregisterised to what extent does the compiler need to know about the target platform ? If I said ./configure --target none-of-your-business --with-gcc=my-whizzy-gcc --with-other-tools=... --enable-unregisterised would I be right in saying it this could not be done because it still needs to know things like the word size, endianness and so on or couldn't it get this information just from header files ? What I'm trying to get at is if I did not think there was anything wrong with my cross-gcc, partially because I have experimented with different versions and platforms, what other PowerPC-sepcific knowledge is employed by the unregisterised ghc ? Jon From alexey.muranov at gmail.com Mon Aug 10 13:18:11 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Mon, 10 Aug 2015 06:18:11 -0700 (PDT) Subject: [Haskell-cafe] Appropriate location for list of language suggestions In-Reply-To: <8A1488AE-8663-4326-AC1E-ECD9E82C0506@gmail.com> References: <8A1488AE-8663-4326-AC1E-ECD9E82C0506@gmail.com> Message-ID: As i have said in the other thread, i like the idea of keeping a list of hypothetical improvements to Haskell syntax for whatever purpose it can serve. I want just to add that IMO dissatisfaction with a programming language's syntax is not a negligible motivation in creating new languages: see [CoffeeScript](http://coffeescript.org) and [MoonScript](http://moonscript.org) for example. Alexey. On Monday, August 10, 2015 at 2:49:28 AM UTC+3, Will Yager wrote: > > This email is in response to the (ongoing) Haskell-cafe discussion about > type declaration syntax. > > There are a number of hypothetical changes to Haskell that could be > aesthetically pleasing or convenient if implemented, but not to such a > degree that the added convenience outweighs the added complexity of a > pragma-gated feature or the cost of breaking existing code. > > (Case in point: renaming type/newtype/data to be less confusing to > first-time users) > > However, there may be better opportunities to implement such changes in > the future, and it would be a shame if every good (but perhaps somewhat > trivial) idea was lost to the annals of the mailing list. > > Therefore, I proposed that we might maintain a list of nitpicks, which > could be used to inform future decisions about breaking changes to the > Haskell specification. > > I'm not sure what the most appropriate forum is for such a list. The > mailing list is sub-optimal, because we might end up with a huge email > chain littered with bikeshedding reply-alls. I would be willing to host and > maintain such a list on Github, but that seems somewhat antithetical to the > Haskell community's generally more distributed style of discussion. > > The wiki might be appropriate, but I don't know if it's conducive to > proper moderation; we may have to filter out suggestions like "add for > loops". > > --Will > > > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Mon Aug 10 13:56:53 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 10 Aug 2015 09:56:53 -0400 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <55C88D2F.1050102@tu-harburg.de> References: <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> <20150809111703.GD16943@weber> <20150809113555.GF16943@weber> <905613E9-284A-494B-946E-DDA14FC1BF6C@yandex.ru> <20150809211004.GG20036@weber> <55C88D2F.1050102@tu-harburg.de> Message-ID: <6154F4D1-D851-423E-AA31-F764B4FBDC74@gmail.com> El Aug 10, 2015, a las 7:38, Jonas Scholl escribi?: > There is still a difference between a data type with one strict field > and a newtype: You can strip the constructor of a newtype without > evaluating anything. > > Suppose we have > > data D = D !D > > data N = N N > This should be "newtype N = N N", no? Tom > d :: D > d = D d > > n :: N > n = N n > > d and n both evaluate to bottom, but it is possible to pattern match on > (N t) and succeed, while matching on (D t) does not. Example: > > mkDs :: Int -> D -> String > mkDs i (D t) | i <= 0 = [] > | otherwise = 'd' : mkDs (i - 1) t > > mkNs :: Int -> N -> String > mkNs i (N t) | i <= 0 = [] > | otherwise = 'n' : mkNs (i - 1) t > > Evaluating mkNs 5 n returns "nnnnn", while evaluating mkDs 5 d loops > forever. Now we can define: > > f :: D -> N > f (D t) = N (f t) > > g :: N -> D > g (N t) = D (g t) > > id1 :: D -> D > id1 = g . f > > id2 :: N -> N > id2 = f . g > > If both representations should be equal, we should get that mkNs 5 n == > mkNs 5 (id2 n). But id2 converts everything to the D type first, which > is only inhabited by _|_, and then pattern matches on it. So we get > "nnnnn" == _|_, which is obviously false. If we change f to use a lazy > pattern match, the equality holds again. So D and N are maybe equivalent > if we allow only lazy pattern matches on D. As this is not the case, the > two are clearly not equivalent. > > On 08/09/2015 11:10 PM, Tom Ellis wrote: >> On Sun, Aug 09, 2015 at 07:49:10PM +0200, MigMit wrote: >>> You know, you've kinda conviced me. >> >> I hope I'm correct then! >> >>> The difference between strict and non-strict parameters is in how >>> constructors work. "data D = D Int" is still the same as "data D = D >>> !Int", but it's constructor ? as a function ? is more restricted. It's >>> somewhat like defining "d n = D $! n", and then not exporting D, but only >>> d. >> >> Right. >> >>> That said, it might be true that semantics differ depending on what is >>> exported. So, it might be true that your D has the same semantics as N. >>> We still can distinguish between those using various unsafe* hacks ? but >>> those are what they are: hacks. >>> >>> ?????????? ? iPad >>> >>>> 9 ???. 2015 ?., ? 13:35, Tom Ellis ???????(?): >>>> >>>> On the contrary, it *is* the same thing >>>> >>>> Prelude> data D = D !Int deriving Show >>>> Prelude> D undefined >>>> *** Exception: Prelude.undefined >>>> Prelude> undefined :: D >>>> *** Exception: Prelude.undefined >>>> >>>> >>>>> On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: >>>>> First, the half that I agree with: f . g = id. No doubt. >>>>> >>>>> But g . f > id. And the value "d" that you want is "undefined". g (f >>>>> undefined) = D undefined, which is not the same as (undefined :: D). >>>>> >>>>> ?????????? ? iPad >>>>> >>>>>>> 9 ???. 2015 ?., ? 13:17, Tom Ellis ???????(?): >>>>>>> >>>>>>> On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: >>>>>>> I disagree. >>>>>> >>>>>> Ah, good. A concrete point of disagreement. What, then, is wrong with the >>>>>> solution >>>>>> >>>>>> f :: D -> N >>>>>> f (D t) = N t >>>>>> >>>>>> g :: N -> D >>>>>> g (N t) = D t >>>>>> >>>>>> If you disagree that `f . g = id` and `g . f = id` then you must be able to >>>>>> find >>>>>> >>>>>> * a type `T` >>>>>> >>>>>> and either >>>>>> >>>>>> * `n :: N` such that `f (g n)` does not denote the same thing as `n` >>>>>> >>>>>> or >>>>>> >>>>>> * `d :: D` such that `g (f d)` does not denote the same thing as `d` >>>>>> >>>>>> Can you? >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>>>> 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): >>>>>>>> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: >>>>>>>>>> Right, you can distinguish data declarations from newtype declarations this >>>>>>>>>> way, but by using Template Haskell you can also distinguish >>>>>>>>>> >>>>>>>>>> * data A = A Int >>>>>>>>>> * data A = A { a :: Int } >>>>>>>>>> * data A = A' Int >>>>>>>>>> * data A = A Int !(), and >>>>>>>>>> * newtype B = B A (where A has one of the above definitions) >>>>>>>>> >>>>>>>>> Sure, because they are different. >>>>>>>>> >>>>>>>>>> from each other. My claim is that >>>>>>>>>> >>>>>>>>>> * data B = B !A >>>>>>>>>> >>>>>>>>>> is as indistinguishable from the above four as they are from each other. >>>>>>>>> >>>>>>>>> Can you please NOT say that some thing can be distinguished AND that they >>>>>>>>> are indistinguishable in the same post? >>>>>>>> >>>>>>>> I think we are perhaps talking at cross purposes. >>>>>>>> >>>>>>>> To clarify, here is an explicit statement (somewhat weaker than the full >>>>>>>> generality of my claim): >>>>>>>> >>>>>>>> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that >>>>>>>> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and >>>>>>>> `g . f = id`. >>>>>>>> >>>>>>>> Do you agree or disagree with this statement? Then we may proceed. >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From strake888 at gmail.com Mon Aug 10 15:14:58 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Mon, 10 Aug 2015 07:14:58 -0800 Subject: [Haskell-cafe] Pattern guards in comprehensions In-Reply-To: References: <55c7f16a.e407460a.c9fee.ffff831a@mx.google.com> <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> Message-ID: <55c8bc7a.a75a460a.7a531.43a4@mx.google.com> On 10/08/2015 at 08:40:43 -0400, amindfv at gmail.com wrote: > There's an even nicer way! Use view patterns: > > allMinus m ns = [ n' | ((?- m) -> Just n') <- ns ] In this case it's not bad, but in some cases the guarded form is clearer, e.g. f z ys = [g x y | y@(flip h z -> Just x) <- ys] vs. f z ys = [g x y | y <- ys, Just x <- [h y z]] tho this is personal preference. From sean at functionaljobs.com Mon Aug 10 16:00:01 2015 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 10 Aug 2015 12:00:01 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <55c8ca842a7b8@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Software Engineer / Researcher at Galois Inc. http://functionaljobs.com/jobs/8856-software-engineer-researcher-at-galois-inc Cheers, Sean Murphy FunctionalJobs.com From anselm.scholl at tu-harburg.de Mon Aug 10 17:54:00 2015 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Mon, 10 Aug 2015 19:54:00 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <6154F4D1-D851-423E-AA31-F764B4FBDC74@gmail.com> References: <20150808213826.GA16943@weber> <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> <20150809111703.GD16943@weber> <20150809113555.GF16943@weber> <905613E9-284A-494B-946E-DDA14FC1BF6C@yandex.ru> <20150809211004.GG20036@weber> <55C88D2F.1050102@tu-harburg.de> <6154F4D1-D851-423E-AA31-F764B4FBDC74@gmail.com> Message-ID: <55C8E538.5040009@tu-harburg.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Of course... my mistake. And now we also have mkNs 5 n == mkNs 5 (id2 n), without any lazy pattern matching. But we still have mkDs 5 d == _|_, so N and D still have different semantics. On 08/10/2015 03:56 PM, amindfv at gmail.com wrote: > El Aug 10, 2015, a las 7:38, Jonas Scholl escribi?: > >> There is still a difference between a data type with one strict field >> and a newtype: You can strip the constructor of a newtype without >> evaluating anything. >> >> Suppose we have >> >> data D = D !D >> >> data N = N N >> > > This should be "newtype N = N N", no? > > Tom > >> d :: D >> d = D d >> >> n :: N >> n = N n >> >> d and n both evaluate to bottom, but it is possible to pattern match on >> (N t) and succeed, while matching on (D t) does not. Example: >> >> mkDs :: Int -> D -> String >> mkDs i (D t) | i <= 0 = [] >> | otherwise = 'd' : mkDs (i - 1) t >> >> mkNs :: Int -> N -> String >> mkNs i (N t) | i <= 0 = [] >> | otherwise = 'n' : mkNs (i - 1) t >> >> Evaluating mkNs 5 n returns "nnnnn", while evaluating mkDs 5 d loops >> forever. Now we can define: >> >> f :: D -> N >> f (D t) = N (f t) >> >> g :: N -> D >> g (N t) = D (g t) >> >> id1 :: D -> D >> id1 = g . f >> >> id2 :: N -> N >> id2 = f . g >> >> If both representations should be equal, we should get that mkNs 5 n == >> mkNs 5 (id2 n). But id2 converts everything to the D type first, which >> is only inhabited by _|_, and then pattern matches on it. So we get >> "nnnnn" == _|_, which is obviously false. If we change f to use a lazy >> pattern match, the equality holds again. So D and N are maybe equivalent >> if we allow only lazy pattern matches on D. As this is not the case, the >> two are clearly not equivalent. >> >> On 08/09/2015 11:10 PM, Tom Ellis wrote: >>> On Sun, Aug 09, 2015 at 07:49:10PM +0200, MigMit wrote: >>>> You know, you've kinda conviced me. >>> >>> I hope I'm correct then! >>> >>>> The difference between strict and non-strict parameters is in how >>>> constructors work. "data D = D Int" is still the same as "data D = D >>>> !Int", but it's constructor ? as a function ? is more restricted. It's >>>> somewhat like defining "d n = D $! n", and then not exporting D, but only >>>> d. >>> >>> Right. >>> >>>> That said, it might be true that semantics differ depending on what is >>>> exported. So, it might be true that your D has the same semantics as N. >>>> We still can distinguish between those using various unsafe* hacks ? but >>>> those are what they are: hacks. >>>> >>>> ?????????? ? iPad >>>> >>>>> 9 ???. 2015 ?., ? 13:35, Tom Ellis ???????(?): >>>>> >>>>> On the contrary, it *is* the same thing >>>>> >>>>> Prelude> data D = D !Int deriving Show >>>>> Prelude> D undefined >>>>> *** Exception: Prelude.undefined >>>>> Prelude> undefined :: D >>>>> *** Exception: Prelude.undefined >>>>> >>>>> >>>>>> On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: >>>>>> First, the half that I agree with: f . g = id. No doubt. >>>>>> >>>>>> But g . f > id. And the value "d" that you want is "undefined". g (f >>>>>> undefined) = D undefined, which is not the same as (undefined :: D). >>>>>> >>>>>> ?????????? ? iPad >>>>>> >>>>>>>> 9 ???. 2015 ?., ? 13:17, Tom Ellis ???????(?): >>>>>>>> >>>>>>>> On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: >>>>>>>> I disagree. >>>>>>> >>>>>>> Ah, good. A concrete point of disagreement. What, then, is wrong with the >>>>>>> solution >>>>>>> >>>>>>> f :: D -> N >>>>>>> f (D t) = N t >>>>>>> >>>>>>> g :: N -> D >>>>>>> g (N t) = D t >>>>>>> >>>>>>> If you disagree that `f . g = id` and `g . f = id` then you must be able to >>>>>>> find >>>>>>> >>>>>>> * a type `T` >>>>>>> >>>>>>> and either >>>>>>> >>>>>>> * `n :: N` such that `f (g n)` does not denote the same thing as `n` >>>>>>> >>>>>>> or >>>>>>> >>>>>>> * `d :: D` such that `g (f d)` does not denote the same thing as `d` >>>>>>> >>>>>>> Can you? >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>>>> 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): >>>>>>>>> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: >>>>>>>>>>> Right, you can distinguish data declarations from newtype declarations this >>>>>>>>>>> way, but by using Template Haskell you can also distinguish >>>>>>>>>>> >>>>>>>>>>> * data A = A Int >>>>>>>>>>> * data A = A { a :: Int } >>>>>>>>>>> * data A = A' Int >>>>>>>>>>> * data A = A Int !(), and >>>>>>>>>>> * newtype B = B A (where A has one of the above definitions) >>>>>>>>>> >>>>>>>>>> Sure, because they are different. >>>>>>>>>> >>>>>>>>>>> from each other. My claim is that >>>>>>>>>>> >>>>>>>>>>> * data B = B !A >>>>>>>>>>> >>>>>>>>>>> is as indistinguishable from the above four as they are from each other. >>>>>>>>>> >>>>>>>>>> Can you please NOT say that some thing can be distinguished AND that they >>>>>>>>>> are indistinguishable in the same post? >>>>>>>>> >>>>>>>>> I think we are perhaps talking at cross purposes. >>>>>>>>> >>>>>>>>> To clarify, here is an explicit statement (somewhat weaker than the full >>>>>>>>> generality of my claim): >>>>>>>>> >>>>>>>>> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that >>>>>>>>> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and >>>>>>>>> `g . f = id`. >>>>>>>>> >>>>>>>>> Do you agree or disagree with this statement? Then we may proceed. >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVyOUvAAoJEM0PYZBmfhoBXnIIALpMHC8BHMN5EgKREFQfsX6k dhyhOxaxDxHM7gYcgxKo5il2rtDJT5sNjuzeyBfBpxKqmjg1YSLEsB3E2fGC8JZV LOBCROAqbcmAXRPNAKdbMaT8XYaLrMqFkqWpcNjxe752RAbqgbb9II1O7GLKYSDZ Q3cEIvBRBHcfeQKQRHnbunXdrdojRZf9LdSbm/HkzatPdToAMUsTdhNAPRhnxM5R EHP2uhmtwRzEcCZ+/tzeJ/OYltqZ9hJ419CwwJs8z9hJUprLpdK4HS76IvDde3kq wFUWqzpESAgOxrtp6lTwLFSsOsXyg3PM4x0+F27sA/z+ls6GrvYM+VcXa4XMBlU= =jkjF -----END PGP SIGNATURE----- From electreg at list.ru Mon Aug 10 21:17:23 2015 From: electreg at list.ru (=?UTF-8?B?QWxleGV5IEVnb3Jvdg==?=) Date: Tue, 11 Aug 2015 00:17:23 +0300 Subject: [Haskell-cafe] =?utf-8?b?Q29uc3RyYWludHMgb24gPCQ+IHZzIDwkIT4=?= Message-ID: <1439241443.499457350@f293.i.mail.ru> Hello haskellers, I wonder why <$> and <$!> have different typeclass constraints? (<$>) :: Functor f => (a -> b) -> f a -> f b (<$!>) :: Monad m => (a -> b) -> m a -> m b From cma at bitemyapp.com Mon Aug 10 21:20:16 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 10 Aug 2015 16:20:16 -0500 Subject: [Haskell-cafe] Constraints on <$> vs <$!> In-Reply-To: <1439241443.499457350@f293.i.mail.ru> References: <1439241443.499457350@f293.i.mail.ru> Message-ID: http://stackoverflow.com/questions/9423622/strict-fmap-using-only-functor-not-monad seems to cover it. On Mon, Aug 10, 2015 at 4:17 PM, Alexey Egorov wrote: > Hello haskellers, > > I wonder why <$> and <$!> have different typeclass constraints? > > (<$>) :: Functor f => (a -> b) -> f a -> f b > (<$!>) :: Monad m => (a -> b) -> m a -> m b > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Mon Aug 10 21:30:49 2015 From: will.yager at gmail.com (Will Yager) Date: Mon, 10 Aug 2015 14:30:49 -0700 Subject: [Haskell-cafe] Constraints on <$> vs <$!> In-Reply-To: References: <1439241443.499457350@f293.i.mail.ru> Message-ID: <14FBA039-6D07-4188-B669-9A907B348ADF@gmail.com> What about f <$!> x = (f $!) <$> x ? --Will > On Aug 10, 2015, at 14:20, Christopher Allen wrote: > > http://stackoverflow.com/questions/9423622/strict-fmap-using-only-functor-not-monad seems to cover it. > >> On Mon, Aug 10, 2015 at 4:17 PM, Alexey Egorov wrote: >> Hello haskellers, >> >> I wonder why <$> and <$!> have different typeclass constraints? >> >> (<$>) :: Functor f => (a -> b) -> f a -> f b >> (<$!>) :: Monad m => (a -> b) -> m a -> m b >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Mon Aug 10 21:38:03 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Mon, 10 Aug 2015 23:38:03 +0200 Subject: [Haskell-cafe] Constraints on <$> vs <$!> In-Reply-To: <14FBA039-6D07-4188-B669-9A907B348ADF@gmail.com> References: <1439241443.499457350@f293.i.mail.ru> <14FBA039-6D07-4188-B669-9A907B348ADF@gmail.com> Message-ID: <63FC9B27-5FE7-434D-9FD4-42B4A1658984@yandex.ru> Prelude Control.Applicative> let f <$!> x = (f $!) <$> x Prelude Control.Applicative> :t (<$!>) (<$!>) :: Functor f => (a -> b) -> f a -> f b > On 10 Aug 2015, at 23:30, Will Yager wrote: > > What about > > f <$!> x = (f $!) <$> x > > ? > > --Will > > > > On Aug 10, 2015, at 14:20, Christopher Allen wrote: > >> http://stackoverflow.com/questions/9423622/strict-fmap-using-only-functor-not-monad seems to cover it. >> >> On Mon, Aug 10, 2015 at 4:17 PM, Alexey Egorov wrote: >> Hello haskellers, >> >> I wonder why <$> and <$!> have different typeclass constraints? >> >> (<$>) :: Functor f => (a -> b) -> f a -> f b >> (<$!>) :: Monad m => (a -> b) -> m a -> m b >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From hyarion at iinet.net.au Mon Aug 10 22:32:57 2015 From: hyarion at iinet.net.au (Ben) Date: Tue, 11 Aug 2015 08:32:57 +1000 Subject: [Haskell-cafe] Constraints on <$> vs <$!> In-Reply-To: <14FBA039-6D07-4188-B669-9A907B348ADF@gmail.com> Message-ID: <553a628b7a5291d7c27c380eaf316bac8cf19ebe@webmail.iinet.net.au> This doesn't buy you very much, unfortunately. (f $!) only forces its argument if the result is ever forced. So if the implementation of fmap doesn't force the function calls (and normally it won't, with no possible way to use the result for anything) then f x doesn't either; the arguments to those calls are not forced, and so the contents of the original structure remain unforced. For example: Prelude> let f x = (f $!) x() :: Functor f => (a -> b) -> f a -> f b Prelude> let z = const True [undefined]z :: [Bool] Prelude> case z of (_:_) -> "matched""matched"it :: String Prelude> z[*** Exception: Prelude.undefined The undefined bomb only goes off when I start to force the elements of z; prior to that no strictness has been gained, and the list contains a thunk as normal. In particular, this version of wouldn't help with the lazy IO problem described in that stackoverflow question Christopher linked earlier. -- Ben ----- Original Message ----- From: "Will Yager" To:"Christopher Allen" Cc:"haskell-cafe" Sent:Mon, 10 Aug 2015 14:30:49 -0700 Subject:Re: [Haskell-cafe] Constraints on vs What about f x = (f $!) x? ? --Will On Aug 10, 2015, at 14:20, Christopher Allen wrote: http://stackoverflow.com/questions/9423622/strict-fmap-using-only-functor-not-monad [2] seems to cover it. On Mon, Aug 10, 2015 at 4:17 PM, Alexey Egorov wrote: Hello haskell ers, I wonder why and have different typeclass constraints? () :: Functor f => (a -> b) -> f a -> f b () :: Monad m => (a -> b) -> m a -> m b _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org [4] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe [5] -- Chris Allen Currently working on?http://haskellbook.com [6] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org [7] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe [8] Links: ------ [1] mailto:cma at bitemyapp.com [2] http://stackoverflow.com/questions/9423622/strict-fmap-using-only-functor-not-monad [3] mailto:electreg at list.ru [4] mailto:Haskell-Cafe at haskell.org [5] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe [6] http://haskellbook.com [7] mailto:Haskell-Cafe at haskell.org [8] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Aug 10 22:47:00 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 10 Aug 2015 23:47:00 +0100 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <55C88D2F.1050102@tu-harburg.de> References: <20150809083921.GB16943@weber> <617E6E7B-4FEF-4DD3-A8B3-D154708A13DE@yandex.ru> <20150809103729.GC16943@weber> <50109D6C-01F7-4755-9784-FE619409B479@yandex.ru> <20150809111703.GD16943@weber> <20150809113555.GF16943@weber> <905613E9-284A-494B-946E-DDA14FC1BF6C@yandex.ru> <20150809211004.GG20036@weber> <55C88D2F.1050102@tu-harburg.de> Message-ID: <20150810224700.GH20036@weber> I'm not claiming that they should behave the same with regard to the *syntax* of case analysis (NB case analysis of newtypes is already treated specially since the constructor doesn't actually exist). Again I refer interested parties to my proposed translation between the two methods of defining types: http://stackoverflow.com/posts/21331284/revisions Does this answer your objection? Tom On Mon, Aug 10, 2015 at 01:38:23PM +0200, Jonas Scholl wrote: > There is still a difference between a data type with one strict field > and a newtype: You can strip the constructor of a newtype without > evaluating anything. > > Suppose we have > > data D = D !D > > data N = N N > > d :: D > d = D d > > n :: N > n = N n > > d and n both evaluate to bottom, but it is possible to pattern match on > (N t) and succeed, while matching on (D t) does not. Example: > > mkDs :: Int -> D -> String > mkDs i (D t) | i <= 0 = [] > | otherwise = 'd' : mkDs (i - 1) t > > mkNs :: Int -> N -> String > mkNs i (N t) | i <= 0 = [] > | otherwise = 'n' : mkNs (i - 1) t > > Evaluating mkNs 5 n returns "nnnnn", while evaluating mkDs 5 d loops > forever. Now we can define: > > f :: D -> N > f (D t) = N (f t) > > g :: N -> D > g (N t) = D (g t) > > id1 :: D -> D > id1 = g . f > > id2 :: N -> N > id2 = f . g > > If both representations should be equal, we should get that mkNs 5 n == > mkNs 5 (id2 n). But id2 converts everything to the D type first, which > is only inhabited by _|_, and then pattern matches on it. So we get > "nnnnn" == _|_, which is obviously false. If we change f to use a lazy > pattern match, the equality holds again. So D and N are maybe equivalent > if we allow only lazy pattern matches on D. As this is not the case, the > two are clearly not equivalent. > > On 08/09/2015 11:10 PM, Tom Ellis wrote: > > On Sun, Aug 09, 2015 at 07:49:10PM +0200, MigMit wrote: > >> You know, you've kinda conviced me. > > > > I hope I'm correct then! > > > >> The difference between strict and non-strict parameters is in how > >> constructors work. "data D = D Int" is still the same as "data D = D > >> !Int", but it's constructor ? as a function ? is more restricted. It's > >> somewhat like defining "d n = D $! n", and then not exporting D, but only > >> d. > > > > Right. > > > >> That said, it might be true that semantics differ depending on what is > >> exported. So, it might be true that your D has the same semantics as N. > >> We still can distinguish between those using various unsafe* hacks ? but > >> those are what they are: hacks. > >> > >> ?????????? ? iPad > >> > >>> 9 ???. 2015 ?., ? 13:35, Tom Ellis ???????(?): > >>> > >>> On the contrary, it *is* the same thing > >>> > >>> Prelude> data D = D !Int deriving Show > >>> Prelude> D undefined > >>> *** Exception: Prelude.undefined > >>> Prelude> undefined :: D > >>> *** Exception: Prelude.undefined > >>> > >>> > >>>> On Sun, Aug 09, 2015 at 01:30:01PM +0200, MigMit wrote: > >>>> First, the half that I agree with: f . g = id. No doubt. > >>>> > >>>> But g . f > id. And the value "d" that you want is "undefined". g (f > >>>> undefined) = D undefined, which is not the same as (undefined :: D). > >>>> > >>>> ?????????? ? iPad > >>>> > >>>>>> 9 ???. 2015 ?., ? 13:17, Tom Ellis ???????(?): > >>>>>> > >>>>>> On Sun, Aug 09, 2015 at 01:09:21PM +0200, MigMit wrote: > >>>>>> I disagree. > >>>>> > >>>>> Ah, good. A concrete point of disagreement. What, then, is wrong with the > >>>>> solution > >>>>> > >>>>> f :: D -> N > >>>>> f (D t) = N t > >>>>> > >>>>> g :: N -> D > >>>>> g (N t) = D t > >>>>> > >>>>> If you disagree that `f . g = id` and `g . f = id` then you must be able to > >>>>> find > >>>>> > >>>>> * a type `T` > >>>>> > >>>>> and either > >>>>> > >>>>> * `n :: N` such that `f (g n)` does not denote the same thing as `n` > >>>>> > >>>>> or > >>>>> > >>>>> * `d :: D` such that `g (f d)` does not denote the same thing as `d` > >>>>> > >>>>> Can you? > >>>>> > >>>>> Tom > >>>>> > >>>>> > >>>>>>> 9 ???. 2015 ?., ? 12:37, Tom Ellis ???????(?): > >>>>>>> On Sun, Aug 09, 2015 at 12:15:47PM +0200, MigMit wrote: > >>>>>>>>> Right, you can distinguish data declarations from newtype declarations this > >>>>>>>>> way, but by using Template Haskell you can also distinguish > >>>>>>>>> > >>>>>>>>> * data A = A Int > >>>>>>>>> * data A = A { a :: Int } > >>>>>>>>> * data A = A' Int > >>>>>>>>> * data A = A Int !(), and > >>>>>>>>> * newtype B = B A (where A has one of the above definitions) > >>>>>>>> > >>>>>>>> Sure, because they are different. > >>>>>>>> > >>>>>>>>> from each other. My claim is that > >>>>>>>>> > >>>>>>>>> * data B = B !A > >>>>>>>>> > >>>>>>>>> is as indistinguishable from the above four as they are from each other. > >>>>>>>> > >>>>>>>> Can you please NOT say that some thing can be distinguished AND that they > >>>>>>>> are indistinguishable in the same post? > >>>>>>> > >>>>>>> I think we are perhaps talking at cross purposes. > >>>>>>> > >>>>>>> To clarify, here is an explicit statement (somewhat weaker than the full > >>>>>>> generality of my claim): > >>>>>>> > >>>>>>> `data D = D !T` and `newtype N = N T` are isomorphic in the sense that > >>>>>>> there exist `f :: D -> N` and `g :: N -> D` such that `f . g = id` and > >>>>>>> `g . f = id`. > >>>>>>> > >>>>>>> Do you agree or disagree with this statement? Then we may proceed. > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From targen at gmail.com Tue Aug 11 00:54:40 2015 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Mon, 10 Aug 2015 20:24:40 -0430 Subject: [Haskell-cafe] Pattern guards in comprehensions In-Reply-To: <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> References: <55c7f16a.e407460a.c9fee.ffff831a@mx.google.com> <6F462ED8-8E7E-4758-A509-3F2B65928942@cis.upenn.edu> Message-ID: On Sun, Aug 9, 2015 at 10:23 PM, Richard Eisenberg wrote: > This can be done today: > >> allMinus m ns = [ n' | n <- ns, Just n' <- [n -? m] ] > > The syntax is a bit regrettable, but it works quite well. On a somewhat related note, this trick is a nice way to introduce let-like bindings in languages like Python that have comprehension syntax and no explicit support for pure intermediate bindings: [ str(x) + ' is ' + str(i) + ' dozens' for i in range(1, 9) for x in [12*i] ] It?s also useful when you want to simulate monadic-ish things sometimes: x = {'a': { 'b': 'c', 'd': 'e'}, 'f': 'g'} [ z for y in [x.get('a')] if y for z in [y.get('b')] if z ] # => ['c'] [ z for y in [x.get('q')] if y for z in [y.get('b')] if z ] # => [] Almost feels like having some simple monads! From ok at cs.otago.ac.nz Tue Aug 11 01:03:38 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 11 Aug 2015 13:03:38 +1200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <20150809200437.GC20036@weber> <84816381-C348-4E13-A997-695C40560186@gmail.com> <20150809205326.GF20036@weber> Message-ID: <5861A325-1A0E-425A-A9FC-760AA21FD877@cs.otago.ac.nz> On 10/08/2015, at 9:22 pm, Alexey Muranov wrote: > > Here is my another argument for this: academic papers about Haskell or functional programming do not have to keep to the actual Haskell syntax. Very often they do not. From ky3 at atamo.com Tue Aug 11 07:05:39 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 11 Aug 2015 14:05:39 +0700 Subject: [Haskell-cafe] Constraints on <$> vs <$!> In-Reply-To: <553a628b7a5291d7c27c380eaf316bac8cf19ebe@webmail.iinet.net.au> References: <14FBA039-6D07-4188-B669-9A907B348ADF@gmail.com> <553a628b7a5291d7c27c380eaf316bac8cf19ebe@webmail.iinet.net.au> Message-ID: On Tue, Aug 11, 2015 at 5:32 AM, Ben wrote: > In particular, this version of <$!> wouldn't help with the lazy IO problem > described in that stackoverflow question Christopher linked earlier. We can say more. The version of <$!> that the SO question author himself gives as a solution to the lazy IO problem doesn't really work. I'm referring to: forceM :: Monad m => m a -> m a forceM m = do v <- m; return $! v (<$!>) :: Monad m => (a -> b) -> m a -> m b f <$!> m = liftM f (forceM m) and changing out <$> for <$!> in getLines h = lines <$> hGetContents h With the change, all of short files get read, thanks to file buffering. Like the first 4K or so. Bad surprise when you try it with longer files. There's a right path through lazy I/O and a wrong one. Rather than take the wrong one, better the following instead: main = mapM_ putStrLn =<< lines <$> readFile "test.txt" But if withFile is absolutely needed (experts only): main = withFile "test.txt" ReadMode getAndPutLines where getAndPutLines :: Handle -> IO () getAndPutLines h = mapM_ putStrLn =<< lines <$> hGetContents h -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.Hage at uu.nl Tue Aug 11 20:47:20 2015 From: J.Hage at uu.nl (Jurriaan Hage) Date: Tue, 11 Aug 2015 22:47:20 +0200 Subject: [Haskell-cafe] Final call for papers for IFL 2015 Message-ID: Hello, Please, find below the final call for papers for IFL 2015. Note that the draft submission date has been extended until August 15. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ?? IFL 2015 - Call for papers 27th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2015 University of Koblenz-Landau, Koblenz, Germany In cooperation with ACM SIGPLAN September 14-16, 2015 http://ifl2015.wikidot.com/ Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2015 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Peer-review Following the IFL tradition, IFL 2015 will use a post-symposium review process to produce the formal proceedings. All participants of IFL2015 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Important dates August 15: Submission deadline draft papers August 17: Notification of acceptance for presentation August 19: Early registration deadline August 26: Late registration deadline September 7: Submission deadline for pre-symposium proceedings September 14-16: IFL Symposium December 1: Submission deadline for post-symposium proceedings January 15, 2016: Notification of acceptance for post-symposium proceedings March 1, 2016: Camera-ready version for post-symposium proceedings Submission details Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2015 Topics IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2015, please contact the PC chair at rlaemmel at acm.org. Topics of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee Chair: Ralf L?mmel, University of Koblenz-Landau, Germany - Malgorzata Biernacka, University of Wroclaw, Poland - Laura M. Castro, University of A Coru?a, Spain - Martin Erwig, Oregon State University, USA - Dan Ghica, University of Birmingham, UK - Andrew Gill, University of Kansas, USA - Stephan Herhut, Google, USA - Zhenjiang Hu, National Institute of Informatics (NII), Japan - Mauro Jaskelioff, CIFASIS/Universidad Nacional de Rosario, Argentina - Fr?d?ric Jouault, ESEO, France - Oleg Kiselyov, Tohoku University, Japan - Lindsey Kuper, Indiana University, USA - Rita Loogen, Philipps-Universit?t Marburg, Germany - Akimasa Morihata, University of Tokyo, Japan - Atsushi Ohori, Tohoku University, Japan - Bruno C. D. S. Oliveira, The University of Hong Kong, Hong Kong - Frank Piessens, Katholieke Universiteit Leuven, Belgium - Norman Ramsey, Tufts University, USA - Matthew Roberts, Macquarie University, Australia - Manfred Schmidt-Schauss, Goethe-University Frankfurt, Germany - Simon Thompson, University of Kent, UK - Stephanie Weirich, University of Pennsylvania, USA - Steve Zdancewic, University of Pennsylvania , USA Venue The 27th IFL will be held in association with the Faculty of Computer Science, University of Koblenz-Landau, Campus Koblenz. Koblenz is well connected by train to several international airports. For instance, Koblenz can be reached from Frankfurt by high-speed train ICE within an hour. The modern Koblenz campus is close to the city center and can be reached by foot, bus, or cab. See the website for more information on the venue. Social events The conference attendees are welcome at ?Kaffeewirtschaft? in the historical center of Koblenz on the evening of arrival (Sunday, 13 September). A special reception takes places on Monday in the form of a wine tasting and guided tour at ?Weingut Lunnebach?. The conference banquet on Tuesday is held at the historical site ?Festung Ehrenbreitstein? at Restaurant Casino with a wonderful view over the city and the two rivers Rhine and Moselle. - http://www.kaffeewirtschaft.de/ - http://www.weingut-lunnebach.de/ - https://www.cafehahn.de/impressionen_189.html From manny at fpcomplete.com Wed Aug 12 00:50:57 2015 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Tue, 11 Aug 2015 17:50:57 -0700 Subject: [Haskell-cafe] ANN: stack-0.1.3.0 Message-ID: New release of stack, a build tool. See README for installation and upgrade instructions. Note: on Windows, this version does some trickery with code pages to work around issues with GHC?s output. If you run into any trouble, please report it (see issue #757 ). Major changes: - Overhauled target parsing, added --test and --bench options #651 - For details, see Build commands Wiki page - Detect when a module is compiled but not listed in the cabal file (#32 ) - A warning is displayed for any modules that should be added to other-modules in the .cabal file - These modules are taken into account when determining whether a package needs to be built - Respect TemplateHaskell addDependentFile dependency changes (#105 ) - TH dependent files are taken into account when determining whether a package needs to be built. Other enhancements: - Set the HASKELL_DIST_DIR environment variable #524 - Track build status of tests and benchmarks #525 - --no-run-tests #517 - Targets outside of root dir don?t build #366 - Upper limit on number of flag combinations to test #543 - Fuzzy matching support to give better error messages for close version numbers #504 - --local-bin-path global option. Use to change where binaries get placed on a --copy-bins #342 - Custom snapshots #111 - ?force-dirty flag: Force treating all local packages as having dirty files (useful for cases where stack can?t detect a file change) - GHC error messages: display file paths as absolute instead of relative for better editor integration - Add the --copy-bins option #569 - Give warnings on unexpected config keys #48 - Remove Docker pass-host option - Don?t require cabal-install to upload #313 - Generate indexes for all deps and all installed snapshot packages #143 - Provide --resolver global option #645 - Also supports --resolver nightly, --resolver lts, and --resolver lts-X - Make stack build --flag error when flag or package is unknown #617 - Preserve file permissions when unpacking sources #666 - stack build etc work outside of a project - list-dependencies command #638 - --upgrade-cabal option to stack setup #174 - --exec option #651 - --only-dependencies implemented correctly #387 Bug fixes: - Extensions from the other-extensions field no longer enabled by default #449 - Fix: haddock forces rebuild of empty packages #452 - Don?t copy over executables excluded by component selection #605 - Fix: stack fails on Windows with git package in stack.yaml and no git binary on path #712 - Fixed GHCi issue: Specifying explicit package versions (#678) - Fixed GHCi issue: Specifying -odir and -hidir as .stack-work/odir (#529) - Fixed GHCi issue: Specifying A instead of A.ext for modules (#498) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at stefan-klinger.de Wed Aug 12 14:26:59 2015 From: haskell at stefan-klinger.de (haskell at stefan-klinger.de) Date: Wed, 12 Aug 2015 16:26:59 +0200 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt Message-ID: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> Hi, I'm stuck with maintaining a State in a Haskeline program that would survive an interrupt with Ctrl-C. The following is a MWE I have distilled out of a bigger project. It revolves around a simple (I guess) read-eval-print loop using Haskeline, and a stacked StateT to maintain a state. This MWE reads a line from the user, calculates its `length`, and adds the length to an Int forming the state. If the user types the special input "sleep" the program sleeps for 5 seconds, simulating a longer computation. Every time the user presses Ctrl-C * a running computation should be interrupted, or * when at the prompt, the current input should be cleared. * In any case, the state must be maintained! Unfortunately, Ctrl-C also clears the state. At first I thought I had stacked the `StateT` and `InputT` in the wrong order. But changing from `InputT (StateT Int IO) ()` to `StateT Int (InputT IO) ()` seems not to change anything (which really gives me the creeps). This message contains both versions (one commented out), they compile with $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 $ ghc --make -Wall -outputdir tmp -o mwe StateMwe.lhs Example run, comments (`<--...`) added later: $ ./mwe type> arglschluargl Adding length of "arglschluargl" 13 type> lalala Adding length of "lalala" 19 type> <--no input, state unchanged Adding length of "" 19 type> sleep Sleeping 5 seconds... ^C <--Here I have hit C-c type> <--no input, state unchanged Adding length of "" 0 <--WRONG: that should be 19 Here we go: > import Control.Monad.State.Strict > import Control.Concurrent ( threadDelay ) > import System.Console.Haskeline > {- Version one: `StateT` inside `InputT` > main :: IO () > main = evalStateT (runInputT defaultSettings $ noesc repl) 0 This catches an interrupt via Ctrl-C and restarts the passed operation. > noesc :: MonadException m => InputT m a -> InputT m a > noesc w = withInterrupt $ let loop = handle (\Interrupt -> loop) w in loop The read-eval-print loop: EOF terminates, `sleep` delays, and any other input modifies the integer state. > repl :: InputT (StateT Int IO) () > repl = do x <- getInputLine "\ntype> " > case x of > Nothing -> return () > Just "sleep" > -> do outputStrLn "Sleeping 5 seconds..." > lift . lift . threadDelay $ 5 * 10^(6::Int) > outputStrLn "...not interrupted" > repl > Just t > -> do outputStrLn $ "Adding length of " ++ show t > lift $ modify (+ length t) > v <- lift get > outputStrLn $ show v > repl > -} > {- Version two: `InputT` inside `StateT` > main :: IO () > main = runInputT defaultSettings . noesc $ evalStateT repl 0 This catches an interrupt via Ctrl-C and restarts the passed operation. I suspect that I have to rearrange this to accommodate the modified stacking, but I could not come up with anything that compiles... > noesc :: MonadException m => InputT m a -> InputT m a > noesc w = withInterrupt $ let loop = handle (\Interrupt -> loop) w in loop As above, with `lift` in different places. To get a better understanding of what's going on, I do not want to use mtl's lift-to-the-right-monad magic (yet). > repl :: StateT Int (InputT IO) () > repl = do x <- lift $ getInputLine "\ntype> " > case x of > Nothing -> return () > Just "sleep" > -> do lift $ outputStrLn "Sleeping 5 seconds..." > lift . lift . threadDelay $ 5 * 10^(6::Int) > lift $ outputStrLn "...not interrupted" > repl > Just t > -> do lift . outputStrLn $ "Adding length of " ++ show t > modify (+ length t) > v <- get > lift . outputStrLn $ show v > repl > -} Any help would be welcome... Stefan -- http://stefan-klinger.de o/X /\/ \ From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Aug 12 15:09:43 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 12 Aug 2015 16:09:43 +0100 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt In-Reply-To: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> References: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> Message-ID: <20150812150943.GI20036@weber> On Wed, Aug 12, 2015 at 04:26:59PM +0200, haskell at stefan-klinger.de wrote: > At first I thought I had stacked the `StateT` and `InputT` in the > wrong order. But changing from `InputT (StateT Int IO) ()` to `StateT > Int (InputT IO) ()` seems not to change anything (which really gives > me the creeps). InputT is essentially ReaderT http://hackage.haskell.org/package/haskeline-0.7.2.1/docs/src/System-Console-Haskeline-InputT.html#InputT so it's not surprising that the order has no effect. Reader commutes with State. Tom From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Aug 12 15:15:33 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 12 Aug 2015 16:15:33 +0100 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt In-Reply-To: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> References: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> Message-ID: <20150812151532.GJ20036@weber> On Wed, Aug 12, 2015 at 04:26:59PM +0200, haskell at stefan-klinger.de wrote: > Version two: `InputT` inside `StateT` > > > main :: IO () > > main = runInputT defaultSettings . noesc $ evalStateT repl 0 Instead of this, how about `hoist`ing noesc inside the StateT? (I would have tried this myself but it would be too fiddly to reconstitute working code from your email.) Tom From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Aug 12 15:16:43 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 12 Aug 2015 16:16:43 +0100 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt In-Reply-To: <20150812151532.GJ20036@weber> References: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> <20150812151532.GJ20036@weber> Message-ID: <20150812151643.GK20036@weber> On Wed, Aug 12, 2015 at 04:15:33PM +0100, Tom Ellis wrote: > On Wed, Aug 12, 2015 at 04:26:59PM +0200, haskell at stefan-klinger.de wrote: > > Version two: `InputT` inside `StateT` > > > > > main :: IO () > > > main = runInputT defaultSettings . noesc $ evalStateT repl 0 > > Instead of this, how about `hoist`ing noesc inside the StateT? hoist is here: http://haddock.stackage.org/lts-2.22/mmorph-1.0.4/Control-Monad-Morph.html#v:hoist From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Aug 12 15:49:12 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 12 Aug 2015 16:49:12 +0100 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt In-Reply-To: <20150812151532.GJ20036@weber> References: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> <20150812151532.GJ20036@weber> Message-ID: <20150812154912.GL20036@weber> On Wed, Aug 12, 2015 at 04:15:33PM +0100, Tom Ellis wrote: > On Wed, Aug 12, 2015 at 04:26:59PM +0200, haskell at stefan-klinger.de wrote: > > Version two: `InputT` inside `StateT` > > > > > main :: IO () > > > main = runInputT defaultSettings . noesc $ evalStateT repl 0 > > Instead of this, how about `hoist`ing noesc inside the StateT? Actually, thinking about it some more I think this is a more fiddly problem that the like of http://hackage.haskell.org/package/MonadCatchIO-transformers-0.3.0.0/docs/Control-Monad-CatchIO.html exist to solve, but I'm not so familiar with that kind of thing myself. Tom From haskell at stefan-klinger.de Wed Aug 12 15:49:10 2015 From: haskell at stefan-klinger.de (haskell at stefan-klinger.de) Date: Wed, 12 Aug 2015 17:49:10 +0200 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt In-Reply-To: <20150812151532.GJ20036@weber> References: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> <20150812151532.GJ20036@weber> Message-ID: <20150812154910.GA571@tauhou.fritz.box> On 2015-Aug-12, Tom Ellis wrote with possible deletions: > On Wed, Aug 12, 2015 at 04:26:59PM +0200, haskell at stefan-klinger.de wrote: > > Version two: `InputT` inside `StateT` > > > > > main :: IO () > > > main = runInputT defaultSettings . noesc $ evalStateT repl 0 > > Instead of this, how about `hoist`ing noesc inside the StateT? Hmmmm... like so? > main = runInputT defaultSettings $ evalStateT (hoist noesc repl) 0 that behaves just the same way. I need to do some reading before I understand what that actually does... > (I would have tried this myself but it would be too fiddly to reconstitute > working code from your email.) Sorry, I have taken extra care that my original posting actually compiles. I just save the message as `StateMwe.lhs` and compile... But thanks for the suggestion! Stefan -- http://stefan-klinger.de o/X /\/ \ From mikael.brockman at gmail.com Wed Aug 12 15:55:29 2015 From: mikael.brockman at gmail.com (mikael.brockman at gmail.com) Date: Wed, 12 Aug 2015 17:55:29 +0200 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt References: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> <20150812150943.GI20036@weber> Message-ID: <87r3n8y00e.fsf@gmail.com> Tom Ellis writes: > On Wed, Aug 12, 2015 at 04:26:59PM +0200, haskell at stefan-klinger.de wrote: >> At first I thought I had stacked the `StateT` and `InputT` in the >> wrong order. But changing from `InputT (StateT Int IO) ()` to `StateT >> Int (InputT IO) ()` seems not to change anything (which really gives >> me the creeps). > > InputT is essentially ReaderT > > http://hackage.haskell.org/package/haskeline-0.7.2.1/docs/src/System-Console-Haskeline-InputT.html#InputT > > so it's not surprising that the order has no effect. Reader commutes with > State. Note in the source there that the state of the Haskeline stuff itself uses "ReaderT (IO _) vs StateT so that exceptions (e.g. ctrl-c) don't cause us to lose the existing state." If there was a more elegant solution, Haskeline itself could use it, I guess? So it's probably at least hard to do generally for any exception occurring in the application? But could one get away with using `handle` at the particular sites where one expects to be interrupted, e.g. around the call to `threadDelay`? From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Aug 12 16:02:37 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 12 Aug 2015 17:02:37 +0100 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt In-Reply-To: <20150812154910.GA571@tauhou.fritz.box> References: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> <20150812151532.GJ20036@weber> <20150812154910.GA571@tauhou.fritz.box> Message-ID: <20150812160237.GM20036@weber> On Wed, Aug 12, 2015 at 05:49:10PM +0200, haskell at stefan-klinger.de wrote: > On 2015-Aug-12, Tom Ellis wrote with possible deletions: > > On Wed, Aug 12, 2015 at 04:26:59PM +0200, haskell at stefan-klinger.de wrote: > > > Version two: `InputT` inside `StateT` > > > > > > > main :: IO () > > > > main = runInputT defaultSettings . noesc $ evalStateT repl 0 > > > > Instead of this, how about `hoist`ing noesc inside the StateT? > > Hmmmm... like so? > > > main = runInputT defaultSettings $ evalStateT (hoist noesc repl) 0 That was what I was thinking. > that behaves just the same way. I need to do some reading before I > understand what that actually does... I think it's probably a dead end then. In fact it may well be doing exactly what you were doing before in longhand. > > (I would have tried this myself but it would be too fiddly to reconstitute > > working code from your email.) > > Sorry, I have taken extra care that my original posting actually > compiles. I just save the message as `StateMwe.lhs` and compile... Good idea. I didn't think of lhs. My fault, not yours! Tom From haskell at stefan-klinger.de Wed Aug 12 15:59:03 2015 From: haskell at stefan-klinger.de (haskell at stefan-klinger.de) Date: Wed, 12 Aug 2015 17:59:03 +0200 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt In-Reply-To: <87r3n8y00e.fsf@gmail.com> References: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> <20150812150943.GI20036@weber> <87r3n8y00e.fsf@gmail.com> Message-ID: <20150812155903.GB571@tauhou.fritz.box> On 2015-Aug-12, mikael.brockman at gmail.com wrote with possible deletions: > But could one get away with using `handle` at the particular sites where > one expects to be interrupted, e.g. around the call to `threadDelay`? Yeah, I've had that, but I don't like it: When the user's wetware decides that somethig takes longer than expected, it decides to press Ctrl-C. Now the calculation might just terminate an instant before the keypress, yielding a race condition between whether the interrupt is caught, or not (or by which exception handler). Also, pressing C-c (un)intentionally at the prompt would either terminate the program, or reset all settings made in the interactive session, thats way more than I'd like to happen. But thanks for the idea... Stefan -- http://stefan-klinger.de o/X /\/ \ From mikael.brockman at gmail.com Wed Aug 12 16:11:41 2015 From: mikael.brockman at gmail.com (mikael.brockman at gmail.com) Date: Wed, 12 Aug 2015 18:11:41 +0200 Subject: [Haskell-cafe] Combine `StateT` and `InputT` to maintain state on Ctrl-C interrupt References: <20150812142658.GA20171@phobos90.inf.uni-konstanz.de> <20150812150943.GI20036@weber> <87r3n8y00e.fsf@gmail.com> <20150812155903.GB571@tauhou.fritz.box> Message-ID: <87mvxwxz9e.fsf@gmail.com> haskell at stefan-klinger.de writes: > On 2015-Aug-12, mikael.brockman at gmail.com wrote with possible deletions: >> But could one get away with using `handle` at the particular sites where >> one expects to be interrupted, e.g. around the call to `threadDelay`? > > Yeah, I've had that, but I don't like it: When the user's wetware > decides that somethig takes longer than expected, it decides to press > Ctrl-C. Now the calculation might just terminate an instant before > the keypress, yielding a race condition between whether the interrupt > is caught, or not (or by which exception handler). Also, pressing C-c > (un)intentionally at the prompt would either terminate the program, or > reset all settings made in the interactive session, thats way more > than I'd like to happen. > > But thanks for the idea... > Stefan Maybe keeping the state in an I/O variable is the most viable way. I can't explain clearly why that would be the case, but it seems tricky to work "externally" with the state carried by StateT, since it only exists in the transient form of a value threaded through lambdas... From manny at fpcomplete.com Wed Aug 12 16:12:16 2015 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Wed, 12 Aug 2015 09:12:16 -0700 Subject: [Haskell-cafe] ANN: stack-0.1.3.1 Message-ID: New release of stack, a build tool. This is a patch release to fix a bug in v0.1.3.0 . See README for installation and upgrade instructions. Note: on Windows, this version does some trickery with code pages to work around issues with GHC?s output. If you run into any trouble, please report it (see issue #757 ). Bug fixes: - Ignore disabled executables #763 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From debdutk at gnulinuxed.tk Wed Aug 12 16:54:42 2015 From: debdutk at gnulinuxed.tk (debdutk at gnulinuxed.tk) Date: Wed, 12 Aug 2015 12:54:42 -0400 Subject: [Haskell-cafe] Location Of Prelude.hs Message-ID: Hi, I was reading the book "The Haskell Road to Logic, Math and Programming" and it refers to /usr/lib/hugs/libraries/Hugs/ as the probable location for Prelude.hs. I am currently using Elementary OS Luna (based of Ubuntu 12.04) and could not file the file at the specified location. Can anyone please tell me where to find it? _____________________ Yours Truly, Debdut Karmakar -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Aug 12 17:03:33 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 12 Aug 2015 13:03:33 -0400 Subject: [Haskell-cafe] Location Of Prelude.hs In-Reply-To: References: Message-ID: On Wed, Aug 12, 2015 at 12:54 PM, wrote: > I was reading the book "The Haskell Road to Logic, Math and Programming" > and it refers to /usr/lib/hugs/libraries/Hugs/ as the probable location for > Prelude.hs. I am currently using Elementary OS Luna (based of Ubuntu 12.04) > and could not file the file at the specified location. Can anyone please > tell me where to find it? > Hugs is obsolete and unmaintained, so you are unlikely to find that anywhere. ghc compiles, where Hugs is an interpreter, so it does not come with Prelude source. The API documentation gives me a link to http://lambda.haskell.org/platform/doc/current/ghc-doc/libraries/haskell2010-1.1.1.0/src/Prelude.html (syntax-highlighted source). Beyond that you'd need to get the source to ghc; note that there will be three different Prelude sources (haskell98 standard, haskell2010 standard, and ghc's default behavior) and that all three are largely built from parts imported from elsewhere. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From debdutk at gnulinuxed.tk Wed Aug 12 17:13:59 2015 From: debdutk at gnulinuxed.tk (debdutk at gnulinuxed.tk) Date: Wed, 12 Aug 2015 13:13:59 -0400 Subject: [Haskell-cafe] Location Of Prelude.hs In-Reply-To: References: Message-ID: On 2015-08-12 13:03, Brandon Allbery wrote: > On Wed, Aug 12, 2015 at 12:54 PM, wrote: > >> I was reading the book "The Haskell Road to Logic, Math and Programming" and it refers to /usr/lib/hugs/libraries/Hugs/ as the probable location for Prelude.hs. I am currently using Elementary OS Luna (based of Ubuntu 12.04) and could not file the file at the specified location. Can anyone please tell me where to find it? > > Hugs is obsolete and unmaintained, so you are unlikely to find that anywhere. > > ghc compiles, where Hugs is an interpreter, so it does not come with Prelude source. > > The API documentation gives me a link to http://lambda.haskell.org/platform/doc/current/ghc-doc/libraries/haskell2010-1.1.1.0/src/Prelude.html [1] (syntax-highlighted source). Beyond that you'd need to get the source to ghc; note that there will be three different Prelude sources (haskell98 standard, haskell2010 standard, and ghc's default behavior) and that all three are largely built from parts imported from elsewhere. > -- > > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net [2] Thanks for that. But I think that HUGS also has a Prelude.hs . After doing a bit of searching, I found it and posting it for reference : Prelude.hs is found in /USR/LIB/HUGS/PACKAGES/BASE/PRELUDE.HS for ubuntu and debian based distros. _____________________ Yours Truly, Debdut Karmakar Links: ------ [1] http://lambda.haskell.org/platform/doc/current/ghc-doc/libraries/haskell2010-1.1.1.0/src/Prelude.html [2] http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Wed Aug 12 17:15:56 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Wed, 12 Aug 2015 10:15:56 -0700 Subject: [Haskell-cafe] Location Of Prelude.hs In-Reply-To: References: Message-ID: A useful trick is that you can access the source of a function or type directly by clicking the 'source' link to the right of the name in the documentation[1]. This will take you to the module where the identifier was defined rather than where it was imported from. (For example, Maybe is defined in Data.Maybe[2].) [1]: https://hackage.haskell.org/package/base-4.5.0.0/docs/Prelude.html [2]: https://hackage.haskell.org/package/base-4.5.0.0/docs/src/Data-Maybe.html#Maybe On Wed, Aug 12, 2015 at 10:03 AM, Brandon Allbery wrote: > On Wed, Aug 12, 2015 at 12:54 PM, wrote: > >> I was reading the book "The Haskell Road to Logic, Math and Programming" >> and it refers to /usr/lib/hugs/libraries/Hugs/ as the probable location for >> Prelude.hs. I am currently using Elementary OS Luna (based of Ubuntu 12.04) >> and could not file the file at the specified location. Can anyone please >> tell me where to find it? >> > Hugs is obsolete and unmaintained, so you are unlikely to find that > anywhere. > > ghc compiles, where Hugs is an interpreter, so it does not come with > Prelude source. > > The API documentation gives me a link to > http://lambda.haskell.org/platform/doc/current/ghc-doc/libraries/haskell2010-1.1.1.0/src/Prelude.html > (syntax-highlighted source). Beyond that you'd need to get the source to > ghc; note that there will be three different Prelude sources (haskell98 > standard, haskell2010 standard, and ghc's default behavior) and that all > three are largely built from parts imported from elsewhere. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.Burton at brighton.ac.uk Wed Aug 12 17:19:05 2015 From: J.Burton at brighton.ac.uk (James Burton) Date: Wed, 12 Aug 2015 18:19:05 +0100 Subject: [Haskell-cafe] Location Of Prelude.hs In-Reply-To: References: Message-ID: <55CB8009.40802@brighton.ac.uk> On 12/08/15 18:03, Brandon Allbery wrote: > On Wed, Aug 12, 2015 at 12:54 PM, > wrote: > > __ > > I was reading the book "The Haskell Road to Logic, Math and > Programming" and it refers to /usr/lib/hugs/libraries/Hugs/ as the > probable location for Prelude.hs. I am currently using Elementary OS > Luna (based of Ubuntu 12.04) and could not file the file at the > specified location. Can anyone please tell me where to find it? > > Hugs is obsolete and unmaintained, so you are unlikely to find that > anywhere. > The Hugs Prelude is/was nice and simple -- self-contained, no compiler pragmas -- which is why you're encouraged to read it in the Haskell Road book...I think the idea is to convey that the student could have written it themselves, including things that are primitive in other languages, with no magic required. http://ogi.altocumulus.org/~hallgren/Programatica/tools/hi/libs/HugsLibraries/Hugs/Prelude.hs?plain > ghc compiles, where Hugs is an interpreter, so it does not come with > Prelude source. > > The API documentation gives me a link to > http://lambda.haskell.org/platform/doc/current/ghc-doc/libraries/haskell2010-1.1.1.0/src/Prelude.html > (syntax-highlighted source). Beyond that you'd need to get the source to > ghc; note that there will be three different Prelude sources (haskell98 > standard, haskell2010 standard, and ghc's default behavior) and that all > three are largely built from parts imported from elsewhere. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > > ___________________________________________________________ > This email has been scanned by MessageLabs' Email Security > System on behalf of the University of Brighton. > For more information see http://www.brighton.ac.uk/is/spam/ > ___________________________________________________________ > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > ___________________________________________________________ This email has been scanned by MessageLabs' Email Security System on behalf of the University of Brighton. For more information see http://www.brighton.ac.uk/is/spam/ ___________________________________________________________ From allbery.b at gmail.com Wed Aug 12 17:24:38 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 12 Aug 2015 13:24:38 -0400 Subject: [Haskell-cafe] Location Of Prelude.hs In-Reply-To: <55CB8009.40802@brighton.ac.uk> References: <55CB8009.40802@brighton.ac.uk> Message-ID: On Wed, Aug 12, 2015 at 1:19 PM, James Burton wrote: > The Hugs Prelude is/was nice and simple -- self-contained, no compiler > pragmas -- which is why you're encouraged to read it in the Haskell Road > book...I think the idea is to convey that the student could have written > it themselves, including things that are primitive in other languages, > with no magic required. > I wonder if https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009 would be a reasonable alternative given the unmaintained-ness of Hugs? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvio.frischi at gmail.com Wed Aug 12 21:20:31 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Wed, 12 Aug 2015 23:20:31 +0200 Subject: [Haskell-cafe] Unique Ordered Types Message-ID: <55CBB89F.8020001@gmail.com> Hi I'm experimenting with a unit system in haskell where users can add "base units". I want to reduce units after multiplication and bring it into a canonical form. The problem is what kind of types can the units have. 1) data UnitA data UnitB Problem: They can't be ordered so UnitA * UnitB can be compared to UnitB * UnitA, but I can't make a canonical form, which would make type inference a lot better. 2) type UnitA = Zero type UnitB = Suc Zero Problem: Now they can be ordered. But users can create conflicting "basic units" Silvio From cma at bitemyapp.com Wed Aug 12 21:24:51 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 12 Aug 2015 16:24:51 -0500 Subject: [Haskell-cafe] Unique Ordered Types In-Reply-To: <55CBB89F.8020001@gmail.com> References: <55CBB89F.8020001@gmail.com> Message-ID: http://hackage.haskell.org/package/units is a pretty deep example of how to have type-safe units. On Wed, Aug 12, 2015 at 4:20 PM, Silvio Frischknecht < silvio.frischi at gmail.com> wrote: > Hi I'm experimenting with a unit system in haskell where users can add > "base units". I want to reduce units after multiplication and bring it > into a canonical form. The problem is what kind of types can the units > have. > > 1) > > data UnitA > data UnitB > > Problem: They can't be ordered so UnitA * UnitB can be compared to UnitB > * UnitA, but I can't make a canonical form, which would make type > inference a lot better. > > 2) > > type UnitA = Zero > type UnitB = Suc Zero > > Problem: Now they can be ordered. But users can create conflicting > "basic units" > > > > Silvio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvio.frischi at gmail.com Wed Aug 12 23:24:54 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Thu, 13 Aug 2015 01:24:54 +0200 Subject: [Haskell-cafe] Unique Ordered Types In-Reply-To: References: <55CBB89F.8020001@gmail.com> Message-ID: <55CBD5C6.9060408@gmail.com> Looks very nice. A bit large for my taste though. Anyway, it seems they can't order their units either. That's why (|+|) :: (d1 @~ d2, Num n) => Qu d1 l n -> Qu d2 l n -> Qu d1 l n and not (|+|) :: (Num n) => Qu d l n -> Qu d l n -> Qu d l n This will always be a bit annoying. You can almost never safely write Qu (Foo :* Bar) l n but will always have to write (d @~ (Foo :* Bar)) => Qu d l n in your types. Silvio From silvio.frischi at gmail.com Wed Aug 12 23:41:12 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Thu, 13 Aug 2015 01:41:12 +0200 Subject: [Haskell-cafe] Unique Ordered Types In-Reply-To: <55CBD5C6.9060408@gmail.com> References: <55CBB89F.8020001@gmail.com> <55CBD5C6.9060408@gmail.com> Message-ID: <55CBD998.9040406@gmail.com> Btw I think I found a solution in https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-TypeLits.html there is a type level sort type family CmpSymbol m n :: Ordering This might work. Silvio From will.yager at gmail.com Thu Aug 13 00:58:31 2015 From: will.yager at gmail.com (Will Yager) Date: Wed, 12 Aug 2015 17:58:31 -0700 Subject: [Haskell-cafe] Unique Ordered Types In-Reply-To: <55CBB89F.8020001@gmail.com> References: <55CBB89F.8020001@gmail.com> Message-ID: <107E5B70-9538-4DB3-B999-1EBD55E4B5E5@gmail.com> What kind of units are these? dimensional normalizes units by representing them like Foo Int Int Int. (Those are type-level "ints".) So if length is Foo 1 0 0 and time is Foo 0 1 0, then length* time = Foo 1 1 0 = time* length. Does this work for your application? --Will > On Aug 12, 2015, at 14:20, Silvio Frischknecht wrote: > > Hi I'm experimenting with a unit system in haskell where users can add > "base units". I want to reduce units after multiplication and bring it > into a canonical form. The problem is what kind of types can the units have. > > 1) > > data UnitA > data UnitB > > Problem: They can't be ordered so UnitA * UnitB can be compared to UnitB > * UnitA, but I can't make a canonical form, which would make type > inference a lot better. > > 2) > > type UnitA = Zero > type UnitB = Suc Zero > > Problem: Now they can be ordered. But users can create conflicting > "basic units" > > > > Silvio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From eir at cis.upenn.edu Thu Aug 13 02:21:30 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 12 Aug 2015 22:21:30 -0400 Subject: [Haskell-cafe] Unique Ordered Types In-Reply-To: <55CBD998.9040406@gmail.com> References: <55CBB89F.8020001@gmail.com> <55CBD5C6.9060408@gmail.com> <55CBD998.9040406@gmail.com> Message-ID: Hi Silvio, I'm the author of the units package. Yes, the types are annoying and painfully indirect, exactly because of the problem you identify. CmpSymbol might work for you. Note that it works only on Symbols (type-level strings) and not arbitrary types. I didn't like it because I wanted it to be possible to leverage Haskell's module system to allow distinct units but with the same name, declared in different modules. (For example, "pound" can refer to a plethora of different units.) This requirement may have been a step too far, and I'd be curious to see how much the system could be simplified without it. Good luck! Richard On Aug 12, 2015, at 7:41 PM, Silvio Frischknecht wrote: > Btw I think I found a solution in > > https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-TypeLits.html > > there is a type level sort > > type family CmpSymbol m n :: Ordering > > This might work. > > Silvio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From silvio.frischi at gmail.com Thu Aug 13 02:29:32 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Thu, 13 Aug 2015 04:29:32 +0200 Subject: [Haskell-cafe] Unique Ordered Types In-Reply-To: References: <55CBB89F.8020001@gmail.com> <55CBD5C6.9060408@gmail.com> <55CBD998.9040406@gmail.com> Message-ID: <55CC010C.7020303@gmail.com> > CmpSymbol might work for you. Note that it works only on Symbols > (type-level strings) and not arbitrary types. I didn't like it > because I wanted it to be possible to leverage Haskell's module > system to allow distinct units but with the same name, declared in > different modules. (For example, "pound" can refer to a plethora of > different units.) This requirement may have been a step too far, and > I'd be curious to see how much the system could be simplified without > it. I'm currently trying to achieve this by combining Symbols with Typeable and TemplateHaskell. Should be possible. Silvio From will.yager at gmail.com Thu Aug 13 05:18:09 2015 From: will.yager at gmail.com (William Yager) Date: Wed, 12 Aug 2015 22:18:09 -0700 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) Message-ID: Hello all, I put together a small library for the purpose of creating overloaded indexing operators. The library is available at https://hackage.haskell.org/package/keyed . I would like to solicit some advice on the design of this library. Q1: The library uses TypeFamilies to determine which types to use for the index type (which is used to look up a value) and the value type (which is returned from a lookup). I originally did this using MultiParamTypeClasses and FunctionalDependencies, but thought this was cleaner; are there any good reasons to go back to using FunDeps? Q2: Data.Keyed provides pure indexing, while Data.MKeyed provides monadic indexing (e.g. for mutable vectors or concurrent STM-based maps). I'm having some trouble with the fact that mutable vectors are keyed on the PrimState of their corresponding PrimMonad. Right now, there is a type in the MKeyed class definition called MContainer. This is the type of the Monad that the lookup operation returns. I.e. (!) :: MKeyed d => d -> MKey d -> MContainer d (MValue d) ~ (!) :: IOVector a -> Int -> IO a or (!) :: STVector s a -> Int -> ST s a Unfortunately, this causes an overlap (because both IOVector and STVector are aliased to MVector). I tried making an instance for MVector, but the problem is that it's difficult to actually go from `IOVector a = MVector RealWorld a` to `IO` or `STVector s a = MVector s a` to `ST`, because neither `IO` nor `ST` appears in the type of the vector. I can't do instance (PrimMonad m, s ~ PrimState m) => MKeyed (MVector s a) where ... type MContainer (MVector (PrimState m) a) = m because you can't have type synonyms on the LHS of the type. I tried bringing `m` into scope using RankNTypes, but that didn't work. Is there some syntax I can use to bring `m` into scope here? Or should I be doing this part entirely differently? Q3: Is there any way to automatically derive all instances of Keyed for all types of Data.Vector (using Data.Vector.Generic)? Using `instance Vector v a => Keyed (v a) where ...` doesn't work, as it overlaps with everything of the form `(d :: * -> *) (a :: *) :: *`, like `[a]`. Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From apfelmus at quantentunnel.de Thu Aug 13 08:32:44 2015 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu, 13 Aug 2015 10:32:44 +0200 Subject: [Haskell-cafe] HAL-10 In-Reply-To: <55C75C68.1070906@gmx.net> References: <55C75C68.1070906@gmx.net> Message-ID: Pascal Wittmann wrote: > Hi there, > > I just wanted to ask whether I just missed this years HAL (Haskell in > Halle/Leipzig) or if it was canceled this year. Neither, I believe. As far as I know, the organizers have neither announced nor canceled it. I dimly remember that somewhere around September could be a likely date, but please don't quote me on that. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From chpatrick at gmail.com Thu Aug 13 10:04:29 2015 From: chpatrick at gmail.com (Patrick Chilton) Date: Thu, 13 Aug 2015 12:04:29 +0200 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) In-Reply-To: References: Message-ID: FWIW lens has a bit more powerful implementation of Data.Keyed: https://hackage.haskell.org/package/lens-4.12.3/docs/Control-Lens-At.html#t:Ixed On Thu, Aug 13, 2015 at 7:18 AM, William Yager wrote: > Hello all, > > I put together a small library for the purpose of creating overloaded > indexing operators. The library is available at > https://hackage.haskell.org/package/keyed . > > I would like to solicit some advice on the design of this library. > > Q1: > The library uses TypeFamilies to determine which types to use for the > index type (which is used to look up a value) and the value type (which is > returned from a lookup). > > I originally did this using MultiParamTypeClasses and > FunctionalDependencies, but thought this was cleaner; are there any good > reasons to go back to using FunDeps? > > Q2: > Data.Keyed provides pure indexing, while Data.MKeyed provides monadic > indexing (e.g. for mutable vectors or concurrent STM-based maps). > > I'm having some trouble with the fact that mutable vectors are keyed on > the PrimState of their corresponding PrimMonad. > > Right now, there is a type in the MKeyed class definition called > MContainer. This is the type of the Monad that the lookup operation > returns. I.e. > > (!) :: MKeyed d => d -> MKey d -> MContainer d (MValue d) > ~ > (!) :: IOVector a -> Int -> IO a > or > (!) :: STVector s a -> Int -> ST s a > > Unfortunately, this causes an overlap (because both IOVector and STVector > are aliased to MVector). > > I tried making an instance for MVector, but the problem is that it's > difficult to actually go from `IOVector a = MVector RealWorld a` to `IO` or > `STVector s a = MVector s a` to `ST`, because neither `IO` nor `ST` appears > in the type of the vector. I can't do > > instance (PrimMonad m, s ~ PrimState m) => MKeyed (MVector s a) where ... > type MContainer (MVector (PrimState m) a) = m > > because you can't have type synonyms on the LHS of the type. > > I tried bringing `m` into scope using RankNTypes, but that didn't work. > > Is there some syntax I can use to bring `m` into scope here? > > Or should I be doing this part entirely differently? > > Q3: > Is there any way to automatically derive all instances of Keyed for all > types of Data.Vector (using Data.Vector.Generic)? Using `instance Vector v > a => Keyed (v a) where ...` doesn't work, as it overlaps with everything of > the form `(d :: * -> *) (a :: *) :: *`, like `[a]`. > > Thanks, > Will > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Thu Aug 13 10:32:30 2015 From: lambda.fairy at gmail.com (Chris Wong) Date: Thu, 13 Aug 2015 22:32:30 +1200 Subject: [Haskell-cafe] [ANN] base91 In-Reply-To: References: Message-ID: Hi Alvaro, Sorry about the late response, but is this overloading truly necessary? `Text.unpack` isn't that much to type, and I'm not sure if the benefits of overloading outweigh the cognitive load. `String` and `[Word8]` are rare in production code, and not everyone uses (or is aware of) mono-traversable. As a data point, the base16-bytestring and base64-bytestring packages only expose functions of type `ByteString -> ByteString`. On Sat, Jul 11, 2015 at 7:11 AM, Alvaro J. Genial wrote: > > On Fri, Jul 10, 2015 at 9:46 AM, Patrick Chilton > wrote: >> >> Take a look at mono-traversable. pure' is singleton and Foldable' is >> MonoFoldable. > > > > On Fri, Jul 10, 2015 at 9:47 AM, Patrick Chilton > wrote: >> >> Actually Applicative' is MonoPointed. > > > Thank you! Indeed, I was able to re-implement the library deferring to > MonoFoldable and MonoPointed and then collapse the whole thing to a single > module with two functions that automatically work with all suitable input > and output types. > > In terms of the package (and since I'll be bumping the major version) I > don't think the specialized modules are needed any more, since they're just > a small subset of the combinatorial input/output space. Or is there a > tangible benefit to users in providing more concretely typed versions for > those (unusual?) cases where the return type is ambiguous? So, given: > > type Input i e = (MonoFoldable i, Element i ~ e) > type Output o e = (MonoPointed o, Element o ~ e, Monoid o) > > encode :: forall i o. (Input i Word8, Output o Char) => i -> o > decode :: forall i o. (Input i Char, Output o Word8) => i -> o > > Does including and exposing the following... > > encodeToString :: Input i Word8 => i -> [Char] > decodeToBytes :: Input i Char => i -> [Word8] > encodeBytes :: Output o Char => [Word8] -> o > decodeString :: Output o Word8 => [Char] -> o > encodeBytesToString :: [Word8] -> [Char] > decodeStringToBytes :: [Char] -> [Word8] > > ...add any value, being trivially defined as equal to the generic version? > (Plus, the explosion doubles with another dimension like lazy vs. strict.) I > don't see much advantage over e.g. (encode ws :: String) for the first case. > > Thanks again, > > Alvaro > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Wong (https://lambda.xyz) "Humans find such fascinating ways to waste their time." -- Steven Universe From tomas.carnecky at gmail.com Thu Aug 13 19:21:17 2015 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Thu, 13 Aug 2015 19:21:17 +0000 Subject: [Haskell-cafe] Standards-conform CSS tokenizer Message-ID: Recently I wrote a CSS tokenizer based on the css-syntax spec (the same standard that Blink now uses to parse CSS). The detailed description of my motivation is in the readme, but if I had to describe it in a sentence: The existing Haskell parsers were too high-level for me needs, they provided too much abstraction. The package does not implement the full parser, at least one token type is not implemented. But it should be able to tokenize most CSS files. I copied the tests from the Blink source. All but one pass (and of course the tests for the token types that are not implemented) While the spec describes the algorithm in a way that pretty much prescribes the implementation, I chose to use attoparsec instead. Not sure about the speed implications, but speed is not that important for me. The spec module also describes a parser. I did not have time to implement it, and am currently not planning to. But it would be nice if that was part of the package as well. I had hoped to be able to write a minimizer as well, but I'm not sure if it's possible to write a minimizer just on the token stream, maybe the full parser is needed for that. However, consecutive whitespace is collapsed so tokenizing and then serializing the file will in most cases lead to a smaller file. Hackage: http://hackage.haskell.org/package/css-syntax GitHub repo: https://github.com/wereHamster/haskell-css-syntax Spec: https://drafts.csswg.org/css-syntax -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at galois.com Thu Aug 13 19:37:41 2015 From: ryan at galois.com (Ryan Wright) Date: Thu, 13 Aug 2015 12:37:41 -0700 Subject: [Haskell-cafe] Internship Opportunity at Galois: Winter/Spring 2016 Message-ID: Galois has some exciting opportunities for interns in software research and engineering for the Winter/Spring of 2016. Most of our projects use Haskell to some extent, so this is a great chance to get experience applying functional programming to important real-world problems. Please pass along this posting to anyone you think might be interested--even if they don't yet know Haskell! Thank you, Ryan Wright # Galois Software Engineering/Research Intern # Galois is currently seeking software engineering and research interns for Winter/Spring 2016 at all educational levels. We are committed to matching interns with exciting and engaging engineering work that fits their particular interests, creating lasting value for interns, Galois, and our community. A Galois internship is a chance to tackle cutting-edge, meaningful problems in a uniquely collaborative environment with world-leading researchers. Roles may include technology research and development, requirements gathering, implementation, testing, formal verification, and infrastructure development. Past interns have integrated formal methods tools into larger projects, built comprehensive validation suites, synthesized high-performance cryptographic algorithms, written autopilots for quad-copters, designed the syntax and semantics of scripting languages, and researched type system extensions for academic publication. We deeply believe in providing comprehensive support and mentorship to all of our employees, particularly interns. We provide our employees with a steward who regularly checks in to ensure that they feel welcome and safe in the Galois community while gaining real value from their experiences. ## Important Dates ## Applications due: October 1st, 2015 Internship period (flexible): January through April, 2016 ## About Galois ## Our mission is to create trustworthiness in critical systems. We?re in the business of taking blue-sky ideas and turning them into real-world technology solutions. We?ve been developing real-world systems for over ten years using functional programming, language design, and formal methods. Galois values diversity. We believe that differing viewpoints and experiences are essential to the process of innovation. We look broadly, including outside of established communities, to deliver innovation. ## How to Prepare ## An internship is an opportunity for learning and growth as an engineer. To make the most of the opportunity, we ask that candidates have experience reading, writing, and maintaining code in a realistic project. Many university courses involve multi-week collaborative projects that provide this type of experience. Most of our projects use the Haskell programming language and the git version control system. These tools aren?t often taught in computer science classes, but there are many free resources available that we recommend for learning: - [Learn You a Haskell] for Great Good! [1] by Miran Lipova?a - [Real World Haskell] [2] by Bryan O?Sullivan, Don Stewart, and John Goerzen - [tryGit] [3] by Code School - [Pro Git] [4] by Scott Chacon [1]: http://learnyouahaskell.com/ [2]: http://book.realworldhaskell.org/ [3]: http://try.github.io [4]: http://git-scm.com/book ## Qualifications ## The ability to be geographically located in Portland during the internship Experience reading, writing, and maintaining code in a project as described above Proficiency in software development practices such as design, documentation, testing, and the use of version control Well-developed verbal and written communication skills; comfort in a collaborative team environment The following skills are not required, but may be relevant to a particular project. - Proficiency in Haskell or other programming languages with rich type systems (eg., OCaml, Standard ML, Scala) - Experience using C and assembly languages for low-level systems programming - Development experience in high assurance systems or security software - Specific experience in an area of Galois? expertise, such as: - Assured information sharing - Software modeling and formal verification - Cyber-physical systems and control systems - Operating systems, virtualization and secure platforms - Networking and mobile technology - Cyber defense systems - Scientific computing - Program analysis and software evaluation - Web security ## Logistics ## The length and start date of the internship are negotiable: starting any time from the new year through next spring is acceptable, but an intern must be at Galois for at least three continuous months. The internship is paid competitively, and interns are responsible for living arrangements (although we can certainly help you find arrangements). Galois is located in the heart of downtown Portland with multiple public transportation options available and world-class bicycle infrastructure. ## Application Details ## We?re looking for people who can invent, learn, think, and inspire. We reward creativity and thrive on collaboration. If you are interested, please send your cover letter and resume to us via http://galois-inc.hiringthing.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Thu Aug 13 20:14:47 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 13 Aug 2015 13:14:47 -0700 Subject: [Haskell-cafe] FGL: The cost and propoer way of changing the label at a node. In-Reply-To: References: Message-ID: What about changing an edge's label? Again all I can think of is to replace the edge with a new one, but that seems likely inefficient, particularly if I wanted to handle a lot of edges as a batch. On Thu, Aug 6, 2015 at 3:41 PM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > The easiest way of changing the label of one node is to obtain its > Context using `match`, and update the label in the Context and then > put it back in the graph with (&). > > Ignoring log factors (which are from the graph implementations, not > the FGL model) this ends up being O(|degree of node|). > > On 7 August 2015 at 08:29, Jeffrey Brown wrote: > > Is changing the label at a node O(N)? > > > > The only way I can think of to do it is with a map, like the following -- > > which works, but seems like its speed must be linear in the number of > nodes > > of the graph: > > > >> :m Data.Graph.Inductive.Example Data.Graph.Inductive.Graph > >> let f c@(adjIn, node, lab, adjOut) = case node of {1 -> (adjIn, node, > 'b', > >> adjOut); _ -> c} > >> loop > > mkGraph [(1,'a')] [(1,1,())] > >> gmap f loop > > mkGraph [(1,'b')] [(1,1,())] > >> > > > > Is that in fact the right way? Am I somehow missing the point of FGL if I > > have to do a lot of that? > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Thu Aug 13 20:43:41 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 13 Aug 2015 13:43:41 -0700 Subject: [Haskell-cafe] Folding part of a graph, and FGL's gfold function. Message-ID: Given a node N and an edge label L, I want to do things like "find N, and all of N's L-children, and all of their L-children ... and add up their values". Ideally the fold would not traverse the whole graph. (Note that in general, the subgraph induced by N and L-succession is not a tree.) Writing the fold myself, I can only imagine a very inefficient solution -- I would find each of N's L-children first, collect them, then find each of theirs, etc. In Data.Graph.Inductive.Basic, FGL provides a function called "gfold". This is its type signature: -- | Directed graph fold. gfold :: (Graph gr) => (Context a b -> [Node]) -- ^ direction of fold -> (Context a b -> c -> d) -- ^ depth aggregation -> (Maybe d -> c -> c, c) -- ^ breadth\/level aggregation -> [Node] -> gr a b -> c Is it what I'm looking for? If so, how does it work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Thu Aug 13 21:58:31 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 14 Aug 2015 07:58:31 +1000 Subject: [Haskell-cafe] FGL: The cost and propoer way of changing the label at a node. In-Reply-To: References: Message-ID: On 14 August 2015 at 06:14, Jeffrey Brown wrote: > What about changing an edge's label? Again all I can think of is to replace > the edge with a new one, but that seems likely inefficient, particularly if > I wanted to handle a lot of edges as a batch. If you're doing it as a batch, then it might be worth using emap; otherwise, for a single edge do the same procedure: for an edge (u,v,l), match on `u`, adjust the `(l,v)` in the fourth field of the Context and put it back with &. > > On Thu, Aug 6, 2015 at 3:41 PM, Ivan Lazar Miljenovic > wrote: >> >> The easiest way of changing the label of one node is to obtain its >> Context using `match`, and update the label in the Context and then >> put it back in the graph with (&). >> >> Ignoring log factors (which are from the graph implementations, not >> the FGL model) this ends up being O(|degree of node|). >> >> On 7 August 2015 at 08:29, Jeffrey Brown wrote: >> > Is changing the label at a node O(N)? >> > >> > The only way I can think of to do it is with a map, like the following >> > -- >> > which works, but seems like its speed must be linear in the number of >> > nodes >> > of the graph: >> > >> >> :m Data.Graph.Inductive.Example Data.Graph.Inductive.Graph >> >> let f c@(adjIn, node, lab, adjOut) = case node of {1 -> (adjIn, node, >> >> 'b', >> >> adjOut); _ -> c} >> >> loop >> > mkGraph [(1,'a')] [(1,1,())] >> >> gmap f loop >> > mkGraph [(1,'b')] [(1,1,())] >> >> >> > >> > Is that in fact the right way? Am I somehow missing the point of FGL if >> > I >> > have to do a lot of that? >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com > > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From jeffbrown.the at gmail.com Thu Aug 13 22:03:39 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 13 Aug 2015 15:03:39 -0700 Subject: [Haskell-cafe] FGL: The cost and propoer way of changing the label at a node. In-Reply-To: References: Message-ID: Right, of course! Thanks again, Ivan! On Thu, Aug 13, 2015 at 2:58 PM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On 14 August 2015 at 06:14, Jeffrey Brown wrote: > > What about changing an edge's label? Again all I can think of is to > replace > > the edge with a new one, but that seems likely inefficient, particularly > if > > I wanted to handle a lot of edges as a batch. > > If you're doing it as a batch, then it might be worth using emap; > otherwise, for a single edge do the same procedure: for an edge > (u,v,l), match on `u`, adjust the `(l,v)` in the fourth field of the > Context and put it back with &. > > > > > On Thu, Aug 6, 2015 at 3:41 PM, Ivan Lazar Miljenovic > > wrote: > >> > >> The easiest way of changing the label of one node is to obtain its > >> Context using `match`, and update the label in the Context and then > >> put it back in the graph with (&). > >> > >> Ignoring log factors (which are from the graph implementations, not > >> the FGL model) this ends up being O(|degree of node|). > >> > >> On 7 August 2015 at 08:29, Jeffrey Brown > wrote: > >> > Is changing the label at a node O(N)? > >> > > >> > The only way I can think of to do it is with a map, like the following > >> > -- > >> > which works, but seems like its speed must be linear in the number of > >> > nodes > >> > of the graph: > >> > > >> >> :m Data.Graph.Inductive.Example Data.Graph.Inductive.Graph > >> >> let f c@(adjIn, node, lab, adjOut) = case node of {1 -> (adjIn, > node, > >> >> 'b', > >> >> adjOut); _ -> c} > >> >> loop > >> > mkGraph [(1,'a')] [(1,1,())] > >> >> gmap f loop > >> > mkGraph [(1,'b')] [(1,1,())] > >> >> > >> > > >> > Is that in fact the right way? Am I somehow missing the point of FGL > if > >> > I > >> > have to do a lot of that? > >> > > >> > _______________________________________________ > >> > Haskell-Cafe mailing list > >> > Haskell-Cafe at haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > > >> > >> > >> > >> -- > >> Ivan Lazar Miljenovic > >> Ivan.Miljenovic at gmail.com > >> http://IvanMiljenovic.wordpress.com > > > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Fri Aug 14 02:10:04 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 14 Aug 2015 12:10:04 +1000 Subject: [Haskell-cafe] Folding part of a graph, and FGL's gfold function. In-Reply-To: References: Message-ID: On 14 August 2015 at 06:43, Jeffrey Brown wrote: > Given a node N and an edge label L, I want to do things like "find N, and > all of N's L-children, and all of their L-children ... and add up their > values". Ideally the fold would not traverse the whole graph. (Note that in > general, the subgraph induced by N and L-succession is not a tree.) > > Writing the fold myself, I can only imagine a very inefficient solution -- I > would find each of N's L-children first, collect them, then find each of > theirs, etc. > > In Data.Graph.Inductive.Basic, FGL provides a function called "gfold". This > is its type signature: > > -- | Directed graph fold. > gfold :: (Graph gr) => (Context a b -> [Node]) -- ^ direction of fold > -> (Context a b -> c -> d) -- ^ depth aggregation > -> (Maybe d -> c -> c, c) -- ^ breadth\/level aggregation > -> [Node] > -> gr a b > -> c > > Is it what I'm looking for? If so, how does it work? I suspect it _isn't_ what you're looking for, as you don't want to traverse the entire graph. For an example of what you could do, have a look here: https://github.com/haskell/fgl/blob/master/fgl-arbitrary/test/TestSuite.hs#L50 (where `vis` is a Set is used to keep track of already visited nodes to avoid getting into endless loops, and `cnd` is a set of candidates for recursion). > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From will.yager at gmail.com Fri Aug 14 05:31:53 2015 From: will.yager at gmail.com (William Yager) Date: Thu, 13 Aug 2015 22:31:53 -0700 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) In-Reply-To: References: Message-ID: Thanks! Looks like they're doing it much the same way. However, the purpose of this was for syntactic simplicity, which I think it's hard to argue Lens provides in this case. "^? ix" isn't exactly user-friendly, and it only provides a substitute for "!?", not "!". (Or at least, I couldn't figure out how to get "!" behavior cleanly.) The idea here is that you might want some sort of universal, simple indexing syntax like brackets in other languages, particularly if you have lots of different indexed structures in your module. It can be annoying to have to index Seq, Map, etc. in the same scope. --Will On Thu, Aug 13, 2015 at 3:04 AM, Patrick Chilton wrote: > FWIW lens has a bit more powerful implementation of Data.Keyed: > https://hackage.haskell.org/package/lens-4.12.3/docs/Control-Lens-At.html#t:Ixed > > On Thu, Aug 13, 2015 at 7:18 AM, William Yager > wrote: > >> Hello all, >> >> I put together a small library for the purpose of creating overloaded >> indexing operators. The library is available at >> https://hackage.haskell.org/package/keyed . >> >> I would like to solicit some advice on the design of this library. >> >> Q1: >> The library uses TypeFamilies to determine which types to use for the >> index type (which is used to look up a value) and the value type (which is >> returned from a lookup). >> >> I originally did this using MultiParamTypeClasses and >> FunctionalDependencies, but thought this was cleaner; are there any good >> reasons to go back to using FunDeps? >> >> Q2: >> Data.Keyed provides pure indexing, while Data.MKeyed provides monadic >> indexing (e.g. for mutable vectors or concurrent STM-based maps). >> >> I'm having some trouble with the fact that mutable vectors are keyed on >> the PrimState of their corresponding PrimMonad. >> >> Right now, there is a type in the MKeyed class definition called >> MContainer. This is the type of the Monad that the lookup operation >> returns. I.e. >> >> (!) :: MKeyed d => d -> MKey d -> MContainer d (MValue d) >> ~ >> (!) :: IOVector a -> Int -> IO a >> or >> (!) :: STVector s a -> Int -> ST s a >> >> Unfortunately, this causes an overlap (because both IOVector and STVector >> are aliased to MVector). >> >> I tried making an instance for MVector, but the problem is that it's >> difficult to actually go from `IOVector a = MVector RealWorld a` to `IO` or >> `STVector s a = MVector s a` to `ST`, because neither `IO` nor `ST` appears >> in the type of the vector. I can't do >> >> instance (PrimMonad m, s ~ PrimState m) => MKeyed (MVector s a) where ... >> type MContainer (MVector (PrimState m) a) = m >> >> because you can't have type synonyms on the LHS of the type. >> >> I tried bringing `m` into scope using RankNTypes, but that didn't work. >> >> Is there some syntax I can use to bring `m` into scope here? >> >> Or should I be doing this part entirely differently? >> >> Q3: >> Is there any way to automatically derive all instances of Keyed for all >> types of Data.Vector (using Data.Vector.Generic)? Using `instance Vector v >> a => Keyed (v a) where ...` doesn't work, as it overlaps with everything of >> the form `(d :: * -> *) (a :: *) :: *`, like `[a]`. >> >> Thanks, >> Will >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita at karetnikov.org Fri Aug 14 06:08:38 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Fri, 14 Aug 2015 09:08:38 +0300 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) In-Reply-To: (William Yager's message of "Thu, 13 Aug 2015 22:31:53 -0700") References: Message-ID: <878u9e8krd.fsf@karetnikov.org> > However, the purpose of this was for syntactic simplicity, which I think > it's hard to argue Lens provides in this case. "^? ix" isn't exactly > user-friendly, and it only provides a substitute for "!?", not "!". (Or at > least, I couldn't figure out how to get "!" behavior cleanly.) Look at the type: [1,2,3,4] ^. ix 2 :: (Num a, Monoid a) => a It typechecks, but the result must be a Monoid that has a Num instance. There are Product and Sum wrappers for Num (because the identity element can be either 0 or 1, depending on mappend, which can be + or *). So, this works fine: getSum $ [1,2,3,4] ^. ix 2 => 3 getSum $ [1,2,3,4] ^. ix 42 => 0 From nikita at karetnikov.org Fri Aug 14 06:13:31 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Fri, 14 Aug 2015 09:13:31 +0300 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) In-Reply-To: <878u9e8krd.fsf@karetnikov.org> (Nikita Karetnikov's message of "Fri, 14 Aug 2015 09:08:38 +0300") References: <878u9e8krd.fsf@karetnikov.org> Message-ID: <874mk28kj8.fsf@karetnikov.org> > getSum $ [1,2,3,4] ^. ix 42 > => 0 Oh, one more thing: this is a bit different from ! or !! (in a good way) because it doesn't raise an exception. From will.yager at gmail.com Fri Aug 14 06:21:39 2015 From: will.yager at gmail.com (William Yager) Date: Thu, 13 Aug 2015 23:21:39 -0700 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) In-Reply-To: <874mk28kj8.fsf@karetnikov.org> References: <878u9e8krd.fsf@karetnikov.org> <874mk28kj8.fsf@karetnikov.org> Message-ID: That's completely different behavior than indexing, and introduces even more syntactic noise if you just want to index. If I mis-index a vector, I don't want it to fail silently with mempty; I want it to fail loudly. What you've described (default value on out-of-bounds access) is not correct for most use cases. Sometimes exceptions are the right behavior. --Will On Thu, Aug 13, 2015 at 11:13 PM, Nikita Karetnikov wrote: > > getSum $ [1,2,3,4] ^. ix 42 > > => 0 > > Oh, one more thing: this is a bit different from ! or !! (in a good way) > because it doesn't raise an exception. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Aug 14 06:29:05 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 14 Aug 2015 07:29:05 +0100 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) In-Reply-To: References: <878u9e8krd.fsf@karetnikov.org> <874mk28kj8.fsf@karetnikov.org> Message-ID: <20150814062905.GY20036@weber> On Thu, Aug 13, 2015 at 10:31:53PM -0700, William Yager wrote: > it only provides a substitute for "!?", not "!". (Or at least, I couldn't > figure out how to get "!" behavior cleanly.) (Don't you want ^?!)? http://haddock.stackage.org/lts-3.0/microlens-0.2.0.0/Lens-Micro.html#v:-94--63 and also available in Control.Lens. Tom From will.yager at gmail.com Fri Aug 14 06:36:01 2015 From: will.yager at gmail.com (William Yager) Date: Thu, 13 Aug 2015 23:36:01 -0700 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) In-Reply-To: <20150814062905.GY20036@weber> References: <878u9e8krd.fsf@karetnikov.org> <874mk28kj8.fsf@karetnikov.org> <20150814062905.GY20036@weber> Message-ID: Yep, that'll do it! Alright, so we've established how to replicate (!) and (!?) using lens; what about (!!) and (!!?)? Those were the ones that gave me typing trouble. Also, I'm still interested in auto-deriviation of Ixed/Keyed instances for all Vector types through Vector.Generic. Thanks, Will On Thu, Aug 13, 2015 at 11:29 PM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Thu, Aug 13, 2015 at 10:31:53PM -0700, William Yager wrote: > > it only provides a substitute for "!?", not "!". (Or at least, I couldn't > > figure out how to get "!" behavior cleanly.) > > (Don't you want ^?!)? > > > > http://haddock.stackage.org/lts-3.0/microlens-0.2.0.0/Lens-Micro.html#v:-94--63 > > and also available in Control.Lens. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Aug 14 06:41:30 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 14 Aug 2015 07:41:30 +0100 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) In-Reply-To: References: <878u9e8krd.fsf@karetnikov.org> <874mk28kj8.fsf@karetnikov.org> <20150814062905.GY20036@weber> Message-ID: <20150814064130.GZ20036@weber> On Thu, Aug 13, 2015 at 11:36:01PM -0700, William Yager wrote: > Alright, so we've established how to replicate (!) and (!?) using lens; > what about (!!) and (!!?)? Those were the ones that gave me typing trouble. Can't you just define an indexed getter for the particular case you care about? From roma at ro-che.info Fri Aug 14 06:44:56 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 14 Aug 2015 09:44:56 +0300 Subject: [Haskell-cafe] Library for overloaded indexing (a la (!)) In-Reply-To: References: <878u9e8krd.fsf@karetnikov.org> <874mk28kj8.fsf@karetnikov.org> Message-ID: <55CD8E68.4000703@ro-che.info> On 14/08/15 09:21, William Yager wrote: > If I mis-index a vector, I don't want it to fail silently with mempty; I > want it to fail loudly. What you've described (default value on > out-of-bounds access) is not correct for most use cases. Sometimes > exceptions are the right behavior. Precisely. ?An element is not found, so I'll just return 0[*] or "".? Even JavaScript knows better than that. Granted, there *is* a way to use this API properly (using Maybe-like monoids). But it's also easy to make the wrong code type-check without realizing it. [*] that's essentially what Nikita proposed earlier in the thread -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jens.blanck at gmail.com Fri Aug 14 09:30:37 2015 From: jens.blanck at gmail.com (Jens Blanck) Date: Fri, 14 Aug 2015 09:30:37 +0000 Subject: [Haskell-cafe] Problem parallelising simple algorithm Message-ID: The following code simply computes the Euler constant by binary splitting. I'm struggling to get any speed-up on multi-core. Why do I get a fair number of fizzled? Why don't I get any real speed-up even if it claims to run tasks in parallel? Could I have exhausted the integer arithmetic unit(s) on my chip (i7-4790)? How would I verify that? The following is the code and typical runs on 1 and 4 cores respectively. --------- import Control.Parallel.Strategies import Control.DeepSeq import Data.Ratio divConq :: (NFData b) => (a -> b) -> a -> (a -> Bool) -> (b -> b -> b) -> (a -> Maybe (a,a)) -> b divConq f arg threshold conquer divide = go arg where go arg = case divide arg of Nothing -> f arg Just (l0,r0) -> conquer l1 r1 `using` strat where l1 = go l0 r1 = go r0 strat x = do r l1; r r1; return x where r | threshold arg = rdeepseq | otherwise = rpar pqCombine :: (Integer, Integer) -> (Integer, Integer) -> (Integer, Integer) pqCombine (pl, ql) (pr, qr) = (pl*qr+pr, ql*qr) pq :: (Integer, Integer) -> (Integer, Integer) pq (a, b) = (\t -> (sum t, last t)) $ scanl1 (*) [b,b-1..a+1] euler :: Integer -> Rational euler n = let (p,q) = divConq pq (0,n) (\(a,b) -> b-a < 10000) pqCombine (\(a,b) -> if b-a > 5 then let m = (a+b+1) `div` 2 in Just ((a,m), (m, b)) else Nothing) in p%q main = print $ euler 320000 `seq` () ---------- > ./BinSplit +RTS -s -N1 () 178,375,880 bytes allocated in the heap 2,452,040 bytes copied during GC 3,222,696 bytes maximum residency (7 sample(s)) 883,040 bytes maximum slop 11 MB total memory in use (2 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 333 colls, 0 par 0.004s 0.002s 0.0000s 0.0000s Gen 1 7 colls, 0 par 0.001s 0.001s 0.0001s 0.0003s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 126 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 126 fizzled) INIT time 0.001s ( 0.000s elapsed) MUT time 0.928s ( 0.936s elapsed) GC time 0.005s ( 0.003s elapsed) EXIT time 0.001s ( 0.000s elapsed) Total time 0.935s ( 0.939s elapsed) Alloc rate 192,215,387 bytes per MUT second Productivity 99.4% of total user, 98.9% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 > ./BinSplit +RTS -s -N4 () 178,727,480 bytes allocated in the heap 3,506,488 bytes copied during GC 3,650,032 bytes maximum residency (7 sample(s)) 934,976 bytes maximum slop 12 MB total memory in use (1 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 141 colls, 141 par 0.009s 0.002s 0.0000s 0.0001s Gen 1 7 colls, 6 par 0.003s 0.001s 0.0001s 0.0001s Parallel GC work balance: 38.80% (serial 0%, perfect 100%) TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4) SPARKS: 126 (12 converted, 0 overflowed, 0 dud, 0 GC'd, 114 fizzled) INIT time 0.002s ( 0.002s elapsed) MUT time 2.104s ( 0.946s elapsed) GC time 0.012s ( 0.003s elapsed) EXIT time 0.001s ( 0.000s elapsed) Total time 2.119s ( 0.951s elapsed) Alloc rate 84,946,520 bytes per MUT second Productivity 99.3% of total user, 221.3% of total elapsed gc_alloc_block_sync: 600 whitehole_spin: 0 gen[0].sync: 9 gen[1].sync: 1073 -------------- next part -------------- An HTML attachment was scrubbed... URL: From devnull1999 at yahoo.com Fri Aug 14 19:00:33 2015 From: devnull1999 at yahoo.com (Eric) Date: Fri, 14 Aug 2015 19:00:33 +0000 (UTC) Subject: [Haskell-cafe] "Could not list sources" warning in sandboxed project with add-source deps Message-ID: <2056653448.4793642.1439578833840.JavaMail.yahoo@mail.yahoo.com> I'm getting a warning > Warning: Could not list sources of the add-source dependency 'xyz'.> Skipping the timestamp check. when building a sandboxed project with add-source dependencies. ?I tried increasing the verbosity of cabal, but it still won't tell me what's going wrong so I can fix it. Any suggestions on how to debug or fix this? thanks,--Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at schmong.org Fri Aug 14 20:34:32 2015 From: michael at schmong.org (Michael Litchard) Date: Fri, 14 Aug 2015 13:34:32 -0700 Subject: [Haskell-cafe] How to model outer space for a MUD Message-ID: Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some planet. I'm curious as to how one might model this system that could simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. None of these? Ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From toad3k at gmail.com Fri Aug 14 20:44:33 2015 From: toad3k at gmail.com (David McBride) Date: Fri, 14 Aug 2015 16:44:33 -0400 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: If you are thinking of it as a 3d grid, you might just have a (Map (Integer, Integer, Integer) Contents, where every room in this 3d grid that has something in it is in the map and every room that is empty space has no corresponding entry in the map. Then when you enter a room you can quickly look up what is in that room, then reasonably quickly check the neighbors in every direction to see what the ship might be able to sense were it to travel in that direction. In this case, space is infinite, but the datastructure is only as big as the amount of content you have. On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard wrote: > Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some > planet. I'm curious as to how one might model this system that could > simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. > None of these? Ideas? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Fri Aug 14 20:50:07 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Fri, 14 Aug 2015 13:50:07 -0700 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: It depends on exactly what you want to represent and how you want to do it. The first thing that comes to mind for me would be using an octtree[1], which is the three-dimensional analog of a quadtree[2]. Conal Elliott has an interesting point about using quadtrees to represent images in Haskell[3], and you should be able to adapt the idea to indexing into a three dimensional world with an octtree. [1]: https://en.wikipedia.org/wiki/Octree [2]: https://en.wikipedia.org/wiki/Quadtree [3]: http://conal.net/blog/posts/topless-data On Fri, Aug 14, 2015 at 1:44 PM, David McBride wrote: > If you are thinking of it as a 3d grid, you might just have a (Map > (Integer, Integer, Integer) Contents, where every room in this 3d grid that > has something in it is in the map and every room that is empty space has no > corresponding entry in the map. > > Then when you enter a room you can quickly look up what is in that room, > then reasonably quickly check the neighbors in every direction to see what > the ship might be able to sense were it to travel in that direction. > > In this case, space is infinite, but the datastructure is only as big as > the amount of content you have. > > On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard > wrote: > >> Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some >> planet. I'm curious as to how one might model this system that could >> simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. >> None of these? Ideas? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kc1956 at gmail.com Fri Aug 14 21:00:30 2015 From: kc1956 at gmail.com (KC) Date: Fri, 14 Aug 2015 14:00:30 -0700 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: I agree with Tikhon But a sparse matrix might be conceptually simpler to start with But are sparse matrices easy to implement in Haskell and then is it easy to change the data structure layer on? -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey On Aug 14, 2015 1:50 PM, "Tikhon Jelvis" wrote: > It depends on exactly what you want to represent and how you want to do it. > > The first thing that comes to mind for me would be using an octtree[1], > which is the three-dimensional analog of a quadtree[2]. Conal Elliott has > an interesting point about using quadtrees to represent images in > Haskell[3], and you should be able to adapt the idea to indexing into a > three dimensional world with an octtree. > > [1]: https://en.wikipedia.org/wiki/Octree > > [2]: https://en.wikipedia.org/wiki/Quadtree > > [3]: http://conal.net/blog/posts/topless-data > > On Fri, Aug 14, 2015 at 1:44 PM, David McBride wrote: > >> If you are thinking of it as a 3d grid, you might just have a (Map >> (Integer, Integer, Integer) Contents, where every room in this 3d grid that >> has something in it is in the map and every room that is empty space has no >> corresponding entry in the map. >> >> Then when you enter a room you can quickly look up what is in that room, >> then reasonably quickly check the neighbors in every direction to see what >> the ship might be able to sense were it to travel in that direction. >> >> In this case, space is infinite, but the datastructure is only as big as >> the amount of content you have. >> >> On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard >> wrote: >> >>> Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some >>> planet. I'm curious as to how one might model this system that could >>> simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. >>> None of these? Ideas? >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Fri Aug 14 21:41:39 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Fri, 14 Aug 2015 23:41:39 +0200 Subject: [Haskell-cafe] "Could not list sources" warning in sandboxed project with add-source deps In-Reply-To: <2056653448.4793642.1439578833840.JavaMail.yahoo@mail.yahoo.com> References: <2056653448.4793642.1439578833840.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi, On 14 August 2015 at 21:00, Eric wrote: > I'm getting a warning > >> Warning: Could not list sources of the add-source dependency 'xyz'. >> Skipping the timestamp check. > > when building a sandboxed project with add-source dependencies. I tried > increasing the verbosity of cabal, but it still won't tell me what's going > wrong so I can fix it. > > Any suggestions on how to debug or fix this? Check the output of `cabal sandbox list-sources`. A likely cause is that one of add-source dependencies refers to a non-existent directory. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Aug 14 21:46:35 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 14 Aug 2015 22:46:35 +0100 Subject: [Haskell-cafe] A type level puzzle Message-ID: <20150814214635.GE20036@weber> For the type level gurus: I would like to define types Sum :: [Field] -> * (:::) :: String -> * -> Field used like this Sum '[ "foo" ::: a, "bar" ::: b, "baz" ::: c ] (I hope this makes sense. I'm not quite familiar with the syntax.) such that Sum '[ s1 ::: a1, ... ] unifies with Sum '[ s1 ::: b1, ... ] to give Sum '[ s1 ::: c1, ... ] where c1 is the unification of a1 and b1. If sn is absent from exactly one of the unificands then its type is copied over unchanged. If sn is absent from both then it is absent from the unification. The types should also be invariant under permutation of the list. This is perhaps a bit obscure so I'll explain the application. This is intended for the sumtype equivalent of a record type, so if we have Sum '[ "foo" ::: a, "bar" ::: b ] and Sum '[ "foo" ::: a, "baz" ::: c ] then I take take the sum of these sums and get something of type Sum '[ "foo" ::: a, "bar" ::: b, "baz" ::: c ] If it makes it easier than I am happy for Sum '[ s1 ::: a1, ... ] to unify with forall ak. Sum '[ s1 ::: a1, ..., sk ::: ak ] This is justified by forall b. Either a b being isomorphic to a. Is such a type possible? If so my next question will be about how to type deconstructors of such things, but let's start with a small first step! Thanks, Tom From michael at schmong.org Fri Aug 14 22:23:52 2015 From: michael at schmong.org (Michael Litchard) Date: Fri, 14 Aug 2015 15:23:52 -0700 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: Well, thinking more about it, I think I want an 8-regular complete graph. I've been doodling and came to the conclusion pretty quickly that thinking of this space in terms of a grid wasn't quite right. I *would* like to only hold data of populated nodes if possible, to model an infinite space as David mentioned. I've been looking at fgl to help me think about this problem in terms of a graph. I'll think and tinker over the weekend and see if I can come up with something more articulate. Not committed to a graph, but I want a discrete structure and this looks like it fits the bill at the moment. On Fri, Aug 14, 2015 at 2:00 PM, KC wrote: > I agree with Tikhon > > But a sparse matrix might be conceptually simpler to start with > But are sparse matrices easy to implement in Haskell and then is it easy > to change the data structure layer on? > > -- > -- > > Sent from an expensive device which will be obsolete in a few months! :D > > Casey > > On Aug 14, 2015 1:50 PM, "Tikhon Jelvis" wrote: > >> It depends on exactly what you want to represent and how you want to do >> it. >> >> The first thing that comes to mind for me would be using an octtree[1], >> which is the three-dimensional analog of a quadtree[2]. Conal Elliott has >> an interesting point about using quadtrees to represent images in >> Haskell[3], and you should be able to adapt the idea to indexing into a >> three dimensional world with an octtree. >> >> [1]: https://en.wikipedia.org/wiki/Octree >> >> [2]: https://en.wikipedia.org/wiki/Quadtree >> >> [3]: http://conal.net/blog/posts/topless-data >> >> On Fri, Aug 14, 2015 at 1:44 PM, David McBride wrote: >> >>> If you are thinking of it as a 3d grid, you might just have a (Map >>> (Integer, Integer, Integer) Contents, where every room in this 3d grid that >>> has something in it is in the map and every room that is empty space has no >>> corresponding entry in the map. >>> >>> Then when you enter a room you can quickly look up what is in that room, >>> then reasonably quickly check the neighbors in every direction to see what >>> the ship might be able to sense were it to travel in that direction. >>> >>> In this case, space is infinite, but the datastructure is only as big as >>> the amount of content you have. >>> >>> On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard >>> wrote: >>> >>>> Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some >>>> planet. I'm curious as to how one might model this system that could >>>> simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. >>>> None of these? Ideas? >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Fri Aug 14 22:31:23 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Fri, 14 Aug 2015 15:31:23 -0700 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: I would not model space -- there's too much of it -- rather Things in space. Each Thing has a 3d coordinate (plus more geometric information, plus more information). Things can be rooms, and things can have position defined in terms of other things. On Fri, Aug 14, 2015 at 3:23 PM, Michael Litchard wrote: > Well, thinking more about it, I think I want an 8-regular complete graph. > I've been doodling and came to the conclusion pretty quickly that thinking > of this space in terms of a grid wasn't quite right. I *would* like to only > hold data of populated nodes if possible, to model an infinite space as > David mentioned. I've been looking at fgl to help me think about this > problem in terms of a graph. I'll think and tinker over the weekend and see > if I can come up with something more articulate. Not committed to a graph, > but I want a discrete structure and this looks like it fits the bill at the > moment. > > On Fri, Aug 14, 2015 at 2:00 PM, KC wrote: > >> I agree with Tikhon >> >> But a sparse matrix might be conceptually simpler to start with >> But are sparse matrices easy to implement in Haskell and then is it easy >> to change the data structure layer on? >> >> -- >> -- >> >> Sent from an expensive device which will be obsolete in a few months! :D >> >> Casey >> >> On Aug 14, 2015 1:50 PM, "Tikhon Jelvis" wrote: >> >>> It depends on exactly what you want to represent and how you want to do >>> it. >>> >>> The first thing that comes to mind for me would be using an octtree[1], >>> which is the three-dimensional analog of a quadtree[2]. Conal Elliott has >>> an interesting point about using quadtrees to represent images in >>> Haskell[3], and you should be able to adapt the idea to indexing into a >>> three dimensional world with an octtree. >>> >>> [1]: https://en.wikipedia.org/wiki/Octree >>> >>> [2]: https://en.wikipedia.org/wiki/Quadtree >>> >>> [3]: http://conal.net/blog/posts/topless-data >>> >>> On Fri, Aug 14, 2015 at 1:44 PM, David McBride wrote: >>> >>>> If you are thinking of it as a 3d grid, you might just have a (Map >>>> (Integer, Integer, Integer) Contents, where every room in this 3d grid that >>>> has something in it is in the map and every room that is empty space has no >>>> corresponding entry in the map. >>>> >>>> Then when you enter a room you can quickly look up what is in that >>>> room, then reasonably quickly check the neighbors in every direction to see >>>> what the ship might be able to sense were it to travel in that direction. >>>> >>>> In this case, space is infinite, but the datastructure is only as big >>>> as the amount of content you have. >>>> >>>> On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard >>>> wrote: >>>> >>>>> Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some >>>>> planet. I'm curious as to how one might model this system that could >>>>> simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. >>>>> None of these? Ideas? >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Fri Aug 14 22:36:17 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Fri, 14 Aug 2015 15:36:17 -0700 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: The problem with just modeling things is that certain questions become difficult. For example, it's often useful to know what thing is closest to some given thing, or what a thing's closest neighbor is. Moreover, while there is certainly a lot of space out there, this is Haskell so we can model all of it lazily. That's what Conal's blog post is about: a practical way to lazily model images with no bounds and no resolution limit. On Aug 14, 2015 3:31 PM, "Jeffrey Brown" wrote: > I would not model space -- there's too much of it -- rather Things in > space. Each Thing has a 3d coordinate (plus more geometric information, > plus more information). Things can be rooms, and things can have position > defined in terms of other things. > > On Fri, Aug 14, 2015 at 3:23 PM, Michael Litchard > wrote: > >> Well, thinking more about it, I think I want an 8-regular complete graph. >> I've been doodling and came to the conclusion pretty quickly that thinking >> of this space in terms of a grid wasn't quite right. I *would* like to only >> hold data of populated nodes if possible, to model an infinite space as >> David mentioned. I've been looking at fgl to help me think about this >> problem in terms of a graph. I'll think and tinker over the weekend and see >> if I can come up with something more articulate. Not committed to a graph, >> but I want a discrete structure and this looks like it fits the bill at the >> moment. >> >> On Fri, Aug 14, 2015 at 2:00 PM, KC wrote: >> >>> I agree with Tikhon >>> >>> But a sparse matrix might be conceptually simpler to start with >>> But are sparse matrices easy to implement in Haskell and then is it easy >>> to change the data structure layer on? >>> >>> -- >>> -- >>> >>> Sent from an expensive device which will be obsolete in a few months! :D >>> >>> Casey >>> >>> On Aug 14, 2015 1:50 PM, "Tikhon Jelvis" wrote: >>> >>>> It depends on exactly what you want to represent and how you want to do >>>> it. >>>> >>>> The first thing that comes to mind for me would be using an octtree[1], >>>> which is the three-dimensional analog of a quadtree[2]. Conal Elliott has >>>> an interesting point about using quadtrees to represent images in >>>> Haskell[3], and you should be able to adapt the idea to indexing into a >>>> three dimensional world with an octtree. >>>> >>>> [1]: https://en.wikipedia.org/wiki/Octree >>>> >>>> [2]: https://en.wikipedia.org/wiki/Quadtree >>>> >>>> [3]: http://conal.net/blog/posts/topless-data >>>> >>>> On Fri, Aug 14, 2015 at 1:44 PM, David McBride >>>> wrote: >>>> >>>>> If you are thinking of it as a 3d grid, you might just have a (Map >>>>> (Integer, Integer, Integer) Contents, where every room in this 3d grid that >>>>> has something in it is in the map and every room that is empty space has no >>>>> corresponding entry in the map. >>>>> >>>>> Then when you enter a room you can quickly look up what is in that >>>>> room, then reasonably quickly check the neighbors in every direction to see >>>>> what the ship might be able to sense were it to travel in that direction. >>>>> >>>>> In this case, space is infinite, but the datastructure is only as big >>>>> as the amount of content you have. >>>>> >>>>> On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard >>>> > wrote: >>>>> >>>>>> Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some >>>>>> planet. I'm curious as to how one might model this system that could >>>>>> simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. >>>>>> None of these? Ideas? >>>>>> >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at schmong.org Fri Aug 14 22:41:51 2015 From: michael at schmong.org (Michael Litchard) Date: Fri, 14 Aug 2015 15:41:51 -0700 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: I'm looking for unbounded but discrete, but I think conal's blog post can help me work this out. On Fri, Aug 14, 2015 at 3:36 PM, Tikhon Jelvis wrote: > The problem with just modeling things is that certain questions become > difficult. For example, it's often useful to know what thing is closest to > some given thing, or what a thing's closest neighbor is. > > Moreover, while there is certainly a lot of space out there, this is > Haskell so we can model all of it lazily. That's what Conal's blog post is > about: a practical way to lazily model images with no bounds and no > resolution limit. > On Aug 14, 2015 3:31 PM, "Jeffrey Brown" wrote: > >> I would not model space -- there's too much of it -- rather Things in >> space. Each Thing has a 3d coordinate (plus more geometric information, >> plus more information). Things can be rooms, and things can have position >> defined in terms of other things. >> >> On Fri, Aug 14, 2015 at 3:23 PM, Michael Litchard >> wrote: >> >>> Well, thinking more about it, I think I want an 8-regular complete >>> graph. I've been doodling and came to the conclusion pretty quickly that >>> thinking of this space in terms of a grid wasn't quite right. I *would* >>> like to only hold data of populated nodes if possible, to model an infinite >>> space as David mentioned. I've been looking at fgl to help me think about >>> this problem in terms of a graph. I'll think and tinker over the weekend >>> and see if I can come up with something more articulate. Not committed to a >>> graph, but I want a discrete structure and this looks like it fits the bill >>> at the moment. >>> >>> On Fri, Aug 14, 2015 at 2:00 PM, KC wrote: >>> >>>> I agree with Tikhon >>>> >>>> But a sparse matrix might be conceptually simpler to start with >>>> But are sparse matrices easy to implement in Haskell and then is it >>>> easy to change the data structure layer on? >>>> >>>> -- >>>> -- >>>> >>>> Sent from an expensive device which will be obsolete in a few months! :D >>>> >>>> Casey >>>> >>>> On Aug 14, 2015 1:50 PM, "Tikhon Jelvis" wrote: >>>> >>>>> It depends on exactly what you want to represent and how you want to >>>>> do it. >>>>> >>>>> The first thing that comes to mind for me would be using an >>>>> octtree[1], which is the three-dimensional analog of a quadtree[2]. Conal >>>>> Elliott has an interesting point about using quadtrees to represent images >>>>> in Haskell[3], and you should be able to adapt the idea to indexing into a >>>>> three dimensional world with an octtree. >>>>> >>>>> [1]: https://en.wikipedia.org/wiki/Octree >>>>> >>>>> [2]: https://en.wikipedia.org/wiki/Quadtree >>>>> >>>>> [3]: http://conal.net/blog/posts/topless-data >>>>> >>>>> On Fri, Aug 14, 2015 at 1:44 PM, David McBride >>>>> wrote: >>>>> >>>>>> If you are thinking of it as a 3d grid, you might just have a (Map >>>>>> (Integer, Integer, Integer) Contents, where every room in this 3d grid that >>>>>> has something in it is in the map and every room that is empty space has no >>>>>> corresponding entry in the map. >>>>>> >>>>>> Then when you enter a room you can quickly look up what is in that >>>>>> room, then reasonably quickly check the neighbors in every direction to see >>>>>> what the ship might be able to sense were it to travel in that direction. >>>>>> >>>>>> In this case, space is infinite, but the datastructure is only as big >>>>>> as the amount of content you have. >>>>>> >>>>>> On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard < >>>>>> michael at schmong.org> wrote: >>>>>> >>>>>>> Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some >>>>>>> planet. I'm curious as to how one might model this system that could >>>>>>> simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. >>>>>>> None of these? Ideas? >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Haskell-Cafe mailing list >>>>>>> Haskell-Cafe at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at schmong.org Fri Aug 14 22:44:47 2015 From: michael at schmong.org (Michael Litchard) Date: Fri, 14 Aug 2015 15:44:47 -0700 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: The octree looks promising. On Fri, Aug 14, 2015 at 3:41 PM, Michael Litchard wrote: > I'm looking for unbounded but discrete, but I think conal's blog post can > help me work this out. > > On Fri, Aug 14, 2015 at 3:36 PM, Tikhon Jelvis wrote: > >> The problem with just modeling things is that certain questions become >> difficult. For example, it's often useful to know what thing is closest to >> some given thing, or what a thing's closest neighbor is. >> >> Moreover, while there is certainly a lot of space out there, this is >> Haskell so we can model all of it lazily. That's what Conal's blog post is >> about: a practical way to lazily model images with no bounds and no >> resolution limit. >> On Aug 14, 2015 3:31 PM, "Jeffrey Brown" wrote: >> >>> I would not model space -- there's too much of it -- rather Things in >>> space. Each Thing has a 3d coordinate (plus more geometric information, >>> plus more information). Things can be rooms, and things can have position >>> defined in terms of other things. >>> >>> On Fri, Aug 14, 2015 at 3:23 PM, Michael Litchard >>> wrote: >>> >>>> Well, thinking more about it, I think I want an 8-regular complete >>>> graph. I've been doodling and came to the conclusion pretty quickly that >>>> thinking of this space in terms of a grid wasn't quite right. I *would* >>>> like to only hold data of populated nodes if possible, to model an infinite >>>> space as David mentioned. I've been looking at fgl to help me think about >>>> this problem in terms of a graph. I'll think and tinker over the weekend >>>> and see if I can come up with something more articulate. Not committed to a >>>> graph, but I want a discrete structure and this looks like it fits the bill >>>> at the moment. >>>> >>>> On Fri, Aug 14, 2015 at 2:00 PM, KC wrote: >>>> >>>>> I agree with Tikhon >>>>> >>>>> But a sparse matrix might be conceptually simpler to start with >>>>> But are sparse matrices easy to implement in Haskell and then is it >>>>> easy to change the data structure layer on? >>>>> >>>>> -- >>>>> -- >>>>> >>>>> Sent from an expensive device which will be obsolete in a few months! >>>>> :D >>>>> >>>>> Casey >>>>> >>>>> On Aug 14, 2015 1:50 PM, "Tikhon Jelvis" wrote: >>>>> >>>>>> It depends on exactly what you want to represent and how you want to >>>>>> do it. >>>>>> >>>>>> The first thing that comes to mind for me would be using an >>>>>> octtree[1], which is the three-dimensional analog of a quadtree[2]. Conal >>>>>> Elliott has an interesting point about using quadtrees to represent images >>>>>> in Haskell[3], and you should be able to adapt the idea to indexing into a >>>>>> three dimensional world with an octtree. >>>>>> >>>>>> [1]: https://en.wikipedia.org/wiki/Octree >>>>>> >>>>>> [2]: https://en.wikipedia.org/wiki/Quadtree >>>>>> >>>>>> [3]: http://conal.net/blog/posts/topless-data >>>>>> >>>>>> On Fri, Aug 14, 2015 at 1:44 PM, David McBride >>>>>> wrote: >>>>>> >>>>>>> If you are thinking of it as a 3d grid, you might just have a (Map >>>>>>> (Integer, Integer, Integer) Contents, where every room in this 3d grid that >>>>>>> has something in it is in the map and every room that is empty space has no >>>>>>> corresponding entry in the map. >>>>>>> >>>>>>> Then when you enter a room you can quickly look up what is in that >>>>>>> room, then reasonably quickly check the neighbors in every direction to see >>>>>>> what the ship might be able to sense were it to travel in that direction. >>>>>>> >>>>>>> In this case, space is infinite, but the datastructure is only as >>>>>>> big as the amount of content you have. >>>>>>> >>>>>>> On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard < >>>>>>> michael at schmong.org> wrote: >>>>>>> >>>>>>>> Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some >>>>>>>> planet. I'm curious as to how one might model this system that could >>>>>>>> simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. >>>>>>>> None of these? Ideas? >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Haskell-Cafe mailing list >>>>>>>> Haskell-Cafe at haskell.org >>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Haskell-Cafe mailing list >>>>>>> Haskell-Cafe at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From devnull1999 at yahoo.com Sat Aug 15 00:36:58 2015 From: devnull1999 at yahoo.com (Eric) Date: Sat, 15 Aug 2015 00:36:58 +0000 (UTC) Subject: [Haskell-cafe] "Could not list sources" warning in sandboxed project with add-source deps In-Reply-To: References: Message-ID: <167712915.4956723.1439599018568.JavaMail.yahoo@mail.yahoo.com> Thanks for the quick reply, Mikhail, but no: the output of "cabal sandbox list-sources" looks fine. Any other ideas, anyone? --Eric On Friday, August 14, 2015 2:41 PM, Mikhail Glushenkov wrote: Hi, On 14 August 2015 at 21:00, Eric wrote: > I'm getting a warning > >> Warning: Could not list sources of the add-source dependency 'xyz'. >> Skipping the timestamp check. > > when building a sandboxed project with add-source dependencies.? I tried > increasing the verbosity of cabal, but it still won't tell me what's going > wrong so I can fix it. > > Any suggestions on how to debug or fix this? Check the output of `cabal sandbox list-sources`. A likely cause is that one of add-source dependencies refers to a non-existent directory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Sat Aug 15 00:48:27 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Sat, 15 Aug 2015 02:48:27 +0200 Subject: [Haskell-cafe] "Could not list sources" warning in sandboxed project with add-source deps In-Reply-To: <167712915.4956723.1439599018568.JavaMail.yahoo@mail.yahoo.com> References: <167712915.4956723.1439599018568.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi, On 15 August 2015 at 02:36, Eric wrote: > Thanks for the quick reply, Mikhail, but no: the output of "cabal sandbox > list-sources" looks fine. One other possibility is that one of the dependencies lists a non-existing file in its .cabal file, e.g. as part of extra-source-files. From devnull1999 at yahoo.com Sat Aug 15 01:07:35 2015 From: devnull1999 at yahoo.com (Eric) Date: Sat, 15 Aug 2015 01:07:35 +0000 (UTC) Subject: [Haskell-cafe] "Could not list sources" warning in sandboxed project with add-source deps In-Reply-To: References: Message-ID: <659211382.466361.1439600855184.JavaMail.yahoo@mail.yahoo.com> That was it! ?Thanks, Mikhail. ?You've saved me a lot of recompiling. --Eri On Friday, August 14, 2015 5:48 PM, Mikhail Glushenkov wrote: One other possibility is that one of the dependencies lists a non-existing file in its .cabal file, e.g. as part of extra-source-files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Sat Aug 15 07:46:42 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Sat, 15 Aug 2015 08:46:42 +0100 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: There are two other tree-like structures that may contain interesting ideas for you: https://en.wikipedia.org/wiki/K-d_tree https://en.wikipedia.org/wiki/R-tree A straight octree has a couple of issues: it can become badly unbalanced, and if your objects have spatial extent then some of them will intersect more than one child region. The K-d tree fixes the balance problem, and the R-tree fixes both. The difficulty with the R-tree is that there are lots of different ways you might divide your things into regions, each with different balance properties. Furthermore if things are moving around then you will have to worry about rebalancing or else all your leaf regions will end up covering all of space! HTH, David On 14 August 2015 at 23:44, Michael Litchard wrote: > The octree looks promising. > > On Fri, Aug 14, 2015 at 3:41 PM, Michael Litchard > wrote: > >> I'm looking for unbounded but discrete, but I think conal's blog post can >> help me work this out. >> >> On Fri, Aug 14, 2015 at 3:36 PM, Tikhon Jelvis wrote: >> >>> The problem with just modeling things is that certain questions become >>> difficult. For example, it's often useful to know what thing is closest to >>> some given thing, or what a thing's closest neighbor is. >>> >>> Moreover, while there is certainly a lot of space out there, this is >>> Haskell so we can model all of it lazily. That's what Conal's blog post is >>> about: a practical way to lazily model images with no bounds and no >>> resolution limit. >>> On Aug 14, 2015 3:31 PM, "Jeffrey Brown" >>> wrote: >>> >>>> I would not model space -- there's too much of it -- rather Things in >>>> space. Each Thing has a 3d coordinate (plus more geometric information, >>>> plus more information). Things can be rooms, and things can have position >>>> defined in terms of other things. >>>> >>>> On Fri, Aug 14, 2015 at 3:23 PM, Michael Litchard >>>> wrote: >>>> >>>>> Well, thinking more about it, I think I want an 8-regular complete >>>>> graph. I've been doodling and came to the conclusion pretty quickly that >>>>> thinking of this space in terms of a grid wasn't quite right. I *would* >>>>> like to only hold data of populated nodes if possible, to model an infinite >>>>> space as David mentioned. I've been looking at fgl to help me think about >>>>> this problem in terms of a graph. I'll think and tinker over the weekend >>>>> and see if I can come up with something more articulate. Not committed to a >>>>> graph, but I want a discrete structure and this looks like it fits the bill >>>>> at the moment. >>>>> >>>>> On Fri, Aug 14, 2015 at 2:00 PM, KC wrote: >>>>> >>>>>> I agree with Tikhon >>>>>> >>>>>> But a sparse matrix might be conceptually simpler to start with >>>>>> But are sparse matrices easy to implement in Haskell and then is it >>>>>> easy to change the data structure layer on? >>>>>> >>>>>> -- >>>>>> -- >>>>>> >>>>>> Sent from an expensive device which will be obsolete in a few months! >>>>>> :D >>>>>> >>>>>> Casey >>>>>> >>>>>> On Aug 14, 2015 1:50 PM, "Tikhon Jelvis" wrote: >>>>>> >>>>>>> It depends on exactly what you want to represent and how you want to >>>>>>> do it. >>>>>>> >>>>>>> The first thing that comes to mind for me would be using an >>>>>>> octtree[1], which is the three-dimensional analog of a quadtree[2]. Conal >>>>>>> Elliott has an interesting point about using quadtrees to represent images >>>>>>> in Haskell[3], and you should be able to adapt the idea to indexing into a >>>>>>> three dimensional world with an octtree. >>>>>>> >>>>>>> [1]: https://en.wikipedia.org/wiki/Octree >>>>>>> >>>>>>> [2]: https://en.wikipedia.org/wiki/Quadtree >>>>>>> >>>>>>> [3]: http://conal.net/blog/posts/topless-data >>>>>>> >>>>>>> On Fri, Aug 14, 2015 at 1:44 PM, David McBride >>>>>>> wrote: >>>>>>> >>>>>>>> If you are thinking of it as a 3d grid, you might just have a (Map >>>>>>>> (Integer, Integer, Integer) Contents, where every room in this 3d grid that >>>>>>>> has something in it is in the map and every room that is empty space has no >>>>>>>> corresponding entry in the map. >>>>>>>> >>>>>>>> Then when you enter a room you can quickly look up what is in that >>>>>>>> room, then reasonably quickly check the neighbors in every direction to see >>>>>>>> what the ship might be able to sense were it to travel in that direction. >>>>>>>> >>>>>>>> In this case, space is infinite, but the datastructure is only as >>>>>>>> big as the amount of content you have. >>>>>>>> >>>>>>>> On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard < >>>>>>>> michael at schmong.org> wrote: >>>>>>>> >>>>>>>>> Star Wars MUD has a 3-D coordinate system such that (0,0,0) is >>>>>>>>> some planet. I'm curious as to how one might model this system that could >>>>>>>>> simulate a ship's movement through a 3-D grid. Matrix, 3-D array, graph. >>>>>>>>> None of these? Ideas? >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Haskell-Cafe mailing list >>>>>>>>> Haskell-Cafe at haskell.org >>>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Haskell-Cafe mailing list >>>>>>>> Haskell-Cafe at haskell.org >>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Haskell-Cafe mailing list >>>>>>> Haskell-Cafe at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Sat Aug 15 09:48:10 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Sat, 15 Aug 2015 10:48:10 +0100 Subject: [Haskell-cafe] Reactive config file generation Message-ID: Hi all, I am using Apache Zookeeper as a service directory: I have a bunch of services which announce their presence by making nodes in Zookeeper, so that dependent services can update their configuration to make use of the available services, and stop trying to use services that have died. Zookeeper is a pretty nice fit for this because it supports watching a node for changes, so in theory there is no need to poll Zookeeper periodically. The services that I control work with this just fine, but there are some (e.g. an Nginx reverse-proxy) that are reconfigured using the rather more common approach of updating a file (or files) and then sending the process a signal. I am currently pondering how to make this work without polling, or manually triggering a refresh script, which is how it is currently done. I've never used FRP, but am at least vaguely aware of it and from my high-level understanding it seems like this could be a very good fit. The Zookeeper state is a time-varying value which I want to convert into a time-varying set of files, ideally as declaratively as possible. So, two questions to the FRP congnoscenti out there. Firstly, is it worthwhile to attempt this using FRP at all? I'm sure I could do it by hand too. Secondly, which of the many FRP libraries would you recommend for it? There are loads on the Wiki, seemingly in various states of repair and documentation. Any pointers on how to choose one that's featureful enough, performant enough, and being actively maintained? Thanks in advance, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sat Aug 15 11:53:39 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 15 Aug 2015 07:53:39 -0400 Subject: [Haskell-cafe] How to model outer space for a MUD Message-ID: <201508151153.t7FBrdca018612@tahoe.cs.Dartmouth.EDU> > I would not model space -- there's too much of it This lesson has hit home over and over again when people come to the realization that the "inner loop" of their program is unrelated to what the program is nominally doing, Most of the running time is initialization! doug From silvio.frischi at gmail.com Sat Aug 15 12:35:53 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sat, 15 Aug 2015 14:35:53 +0200 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: <20150814214635.GE20036@weber> References: <20150814214635.GE20036@weber> Message-ID: <55CF3229.60402@gmail.com> I'm not going to do the whole thing for you but I can help start you off. The type level string you think of is called Symbol. Symbol is a kind on it's own and not (*) it has a type for every string. You can use the functions in the following link to work with them. https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-TypeLits.html so you might have newtype (symbol :: Symbol) ::: value = Field value you can basically use any typelevel combinator you want for Sum e.g. ("foo" ::: Int) `(,)` ("bar" ::: Char) `(,)` ... or make your own You will have to use type families which are basically type level functions to merge two sums. If you run into trouble you can have a look at the following link which does some similar things. https://hackage.haskell.org/package/type-level-sets-0.5/docs/Data-Type-Set.html P.S. Prepare for a headache Cheers Silvio From ariep at xs4all.nl Sat Aug 15 12:46:30 2015 From: ariep at xs4all.nl (Arie Peterson) Date: Sat, 15 Aug 2015 14:46:30 +0200 Subject: [Haskell-cafe] Cross-compiling fails for package 'directory' Message-ID: <2422933.78PkZY3ekX@pook> Following , I have built a cross-compiling ghc for creating programs that run on the raspberry pi. This ghc has built a "hello world" program that runs on the rpi: OK so far. Unfortunately, building the package 'directory-1.2.3.0' with this cross- compiler fails with the following error message: "System/Directory/Internal.hsc:31 directive const_str cannot be handled in cross-compilation mode" The offending function from System.Directory is this one: > -- | Filename extension for executable files (including the dot if any) > -- (usually @\"\"@ on POSIX systems and @\".exe\"@ on Windows or OS\/2). > exeExtension :: String > exeExtension = (#const_str EXE_EXTENSION) Although one can imagine that the meaning of this function is tricky when cross-compiling, I don't think that has actually anything to do with the error. The problem is that hsc2hs cannot handle this 'const_str' directive; see . Now my question: how can this be fixed? Is the failure of hsc2hs to support this directive just a matter of "not implemented right now", maybe by lack of importance? Or is there a fundamental problem? If fixing hsc2hs is hard, could the 'directory' package perhaps choose another way to implement this function? From mle+hs at mega-nerd.com Sat Aug 15 12:47:28 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 15 Aug 2015 22:47:28 +1000 Subject: [Haskell-cafe] Unregisterised builds In-Reply-To: References: Message-ID: <20150815224728.fe6f49080aa5d009162ec065@mega-nerd.com> Jon Schneider wrote: > I am still having issues with (the output from) the cross compiler I have > built for PowerPC (e500 family). That's just 32 bit PowerPC isn't it? > what other PowerPC-sepcific knowledge is employed by the unregisterised > ghc ? Why unregistered? I have a 32 bit PowerPC machine running Linux and GHC work fine with the registered native code gen back end although I haven't tried cross compiling to PowerPC. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Aug 15 13:12:57 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 15 Aug 2015 14:12:57 +0100 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: <55CF3229.60402@gmail.com> References: <20150814214635.GE20036@weber> <55CF3229.60402@gmail.com> Message-ID: <20150815131257.GF20036@weber> On Sat, Aug 15, 2015 at 02:35:53PM +0200, Silvio Frischknecht wrote: > I'm not going to do the whole thing for you but I can help start you off. > > The type level string you think of is called Symbol. Symbol is a kind on > it's own and not (*) it has a type for every string. You can use the > functions in the following link to work with them. > > https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-TypeLits.html > > so you might have > > newtype (symbol :: Symbol) ::: value = Field value > > you can basically use any typelevel combinator you want for Sum e.g. > > ("foo" ::: Int) `(,)` ("bar" ::: Char) `(,)` ... > > or make your own > > You will have to use type families which are basically type level > functions to merge two sums. > > If you run into trouble you can have a look at the following link which > does some similar things. > > https://hackage.haskell.org/package/type-level-sets-0.5/docs/Data-Type-Set.html > > > P.S. Prepare for a headache A good headache or a bad headache? If it's hard to learn but ultimately satisfying and useful then I'm all up for it. If it's hard to learn because Haskell doesn't really support it naturally then I'll probably avoid it. Tom From exio4.com at gmail.com Sat Aug 15 13:26:32 2015 From: exio4.com at gmail.com (Esteban I. RM.) Date: Sat, 15 Aug 2015 10:26:32 -0300 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: <20150815131257.GF20036@weber> References: <20150814214635.GE20036@weber> <55CF3229.60402@gmail.com> <20150815131257.GF20036@weber> Message-ID: it is not a nice headache; doing quasi dependent types ends with lots of redundancy like implementing functions both at the type level and the value level, duplicating data types definitions (even though singletons helps there) If you want to learn more about dependent types, looking at Idris or Agda is what you actually want. I would avoid it, Haskell's type system is not a nice programming language to work with On Aug 15, 2015 10:13 AM, "Tom Ellis" < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Sat, Aug 15, 2015 at 02:35:53PM +0200, Silvio Frischknecht wrote: > > I'm not going to do the whole thing for you but I can help start you off. > > > > The type level string you think of is called Symbol. Symbol is a kind on > > it's own and not (*) it has a type for every string. You can use the > > functions in the following link to work with them. > > > > https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-TypeLits.html > > > > so you might have > > > > newtype (symbol :: Symbol) ::: value = Field value > > > > you can basically use any typelevel combinator you want for Sum e.g. > > > > ("foo" ::: Int) `(,)` ("bar" ::: Char) `(,)` ... > > > > or make your own > > > > You will have to use type families which are basically type level > > functions to merge two sums. > > > > If you run into trouble you can have a look at the following link which > > does some similar things. > > > > > https://hackage.haskell.org/package/type-level-sets-0.5/docs/Data-Type-Set.html > > > > > > P.S. Prepare for a headache > > A good headache or a bad headache? If it's hard to learn but ultimately > satisfying and useful then I'm all up for it. If it's hard to learn > because > Haskell doesn't really support it naturally then I'll probably avoid it. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvio.frischi at gmail.com Sat Aug 15 13:35:29 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sat, 15 Aug 2015 15:35:29 +0200 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: <20150815131257.GF20036@weber> References: <20150814214635.GE20036@weber> <55CF3229.60402@gmail.com> <20150815131257.GF20036@weber> Message-ID: <55CF4021.3000509@gmail.com> > A good headache or a bad headache? If it's hard to learn but ultimately > satisfying and useful then I'm all up for it. If it's hard to learn because > Haskell doesn't really support it naturally then I'll probably avoid it. Well that depends on how you look at it. GHC has a fair number of extensions for dealing with type level programming. And there surely is a reason for all of them. And you can get some elegant type level programming. But it's hard to get right. It's is especially hard if you want Haskell to infer your types. It can definitely be worth it. I coded a unit system the day before yesterday. I'm using it in my project now and that was definitely worth it. But I've done stuff like this before and it usually takes a few days for me to wrap my head around things. Btw. I'm just an enthusiast. I don't do this professionally. I can tell you the extensions you will probably need and that you should have a look at. TypeFamilies - often useful (closed type families for defaults) KindSignatures - for working with different kinds such as Symbol TypeOperators - for making typelevel operators DataKinds - If you want to make your own kinds (probably not needed) Silvio From capn.freako at gmail.com Sat Aug 15 14:00:41 2015 From: capn.freako at gmail.com (David Banas) Date: Sat, 15 Aug 2015 07:00:41 -0700 Subject: [Haskell-cafe] Redundant entries in .cabal file? Message-ID: <92BBFB27-8443-42AC-9CB1-6E92B037E5B8@gmail.com> Hi all, Does anyone know why I?m getting redundant entries in my ?cabal init? generated .cabal file: library exposed-modules: Language.Broker, Language.Broker ? Is it because I?m using a *.hsc file, as my source, and cabal is finding both files: Broker.hsc, and Broker.hs in the Language directory? Thanks, -db -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sat Aug 15 14:50:13 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 15 Aug 2015 10:50:13 -0400 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: <55CF4021.3000509@gmail.com> References: <20150814214635.GE20036@weber> <55CF3229.60402@gmail.com> <20150815131257.GF20036@weber> <55CF4021.3000509@gmail.com> Message-ID: <39501AA9-FC7D-4AB6-9D85-F24B6A673ABC@gmail.com> In Vivid 0.2 (out any day now!) I use type strings pretty pervasively. I'd say that for my needs they were really useful, but the design phase was long (and kinda painful). I can imagine many cases where they're too painful and/or not powerful enough but I'm very happy with what I ended up with. A-, would type string again. tom El Aug 15, 2015, a las 9:35, Silvio Frischknecht escribi?: >> A good headache or a bad headache? If it's hard to learn but ultimately >> satisfying and useful then I'm all up for it. If it's hard to learn because >> Haskell doesn't really support it naturally then I'll probably avoid it. > > Well that depends on how you look at it. GHC has a fair number of > extensions for dealing with type level programming. And there surely is > a reason for all of them. And you can get some elegant type level > programming. But it's hard to get right. It's is especially hard if you > want Haskell to infer your types. It can definitely be worth it. I coded > a unit system the day before yesterday. I'm using it in my project now > and that was definitely worth it. But I've done stuff like this before > and it usually takes a few days for me to wrap my head around things. > > Btw. I'm just an enthusiast. I don't do this professionally. > > I can tell you the extensions you will probably need and that you should > have a look at. > > TypeFamilies - often useful (closed type families for defaults) > KindSignatures - for working with different kinds such as Symbol > TypeOperators - for making typelevel operators > > DataKinds - If you want to make your own kinds (probably not needed) > > > Silvio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From acowley at seas.upenn.edu Sat Aug 15 14:56:55 2015 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Sat, 15 Aug 2015 10:56:55 -0400 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: <20150814214635.GE20036@weber> References: <20150814214635.GE20036@weber> Message-ID: On Friday, August 14, 2015, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > For the type level gurus: > > I would like to define types > > Sum :: [Field] -> * > > (:::) :: String -> * -> Field > > used like this > > Sum '[ "foo" ::: a, "bar" ::: b, "baz" ::: c ] > > (I hope this makes sense. I'm not quite familiar with the syntax.) > > such that > > Sum '[ s1 ::: a1, ... ] > > unifies with > > Sum '[ s1 ::: b1, ... ] > > to give > > Sum '[ s1 ::: c1, ... ] > > where c1 is the unification of a1 and b1. If sn is absent from exactly one > of the unificands then its type is copied over unchanged. If sn is absent > from both then it is absent from the unification. The types should also be > invariant under permutation of the list. > > This is perhaps a bit obscure so I'll explain the application. This is > intended for the sumtype equivalent of a record type, so if we have > > Sum '[ "foo" ::: a, "bar" ::: b ] > > and > > Sum '[ "foo" ::: a, "baz" ::: c ] > > then I take take the sum of these sums and get something of type > > Sum '[ "foo" ::: a, "bar" ::: b, "baz" ::: c ] > > If it makes it easier than I am happy for > > Sum '[ s1 ::: a1, ... ] > > to unify with > > forall ak. Sum '[ s1 ::: a1, ..., sk ::: ak ] > > This is justified by > > forall b. Either a b > > being isomorphic to a. > > Is such a type possible? If so my next question will be about how to type > deconstructors of such things, but let's start with a small first step! > > Thanks, > > Tom This won't get you everything you mention out of the box, but I expect you can piece together the last bits of what you want with the exception that type inference will be limited. Here are basic open sums, conversions between sums and products, and matching against sums: I make rather heavy use of this kind of programming, and have thus far found it to scale up quite well. Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasen.dubi at gmail.com Sat Aug 15 18:07:14 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Sat, 15 Aug 2015 21:07:14 +0300 Subject: [Haskell-cafe] Redundant entries in .cabal file? In-Reply-To: <92BBFB27-8443-42AC-9CB1-6E92B037E5B8@gmail.com> References: <92BBFB27-8443-42AC-9CB1-6E92B037E5B8@gmail.com> Message-ID: You can just rename one of them for a second and run `cabal init` again. Cheers On Sat, Aug 15, 2015 at 5:00 PM, David Banas wrote: > Hi all, > > Does anyone know why I?m getting redundant entries in my ?cabal init? > generated .cabal file: > > library > exposed-modules: Language.Broker, Language.Broker > > > ? > > Is it because I?m using a *.hsc file, as my source, and cabal is finding > both files: > > Broker.hsc, and > Broker.hs > > in the Language directory? > > Thanks, > -db > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From rf at rufflewind.com Sat Aug 15 21:58:11 2015 From: rf at rufflewind.com (Phil Ruffwind) Date: Sat, 15 Aug 2015 17:58:11 -0400 Subject: [Haskell-cafe] Cross-compiling fails for package 'directory' In-Reply-To: <2422933.78PkZY3ekX@pook> References: <2422933.78PkZY3ekX@pook> Message-ID: > Is the failure of hsc2hs to support this directive just a matter of "not > implemented right now", maybe by lack of importance? Or is there a fundamental > problem? See also: https://ghc.haskell.org/trac/ghc/ticket/9689 One would probably have to implement a C string literal parser to do this properly. > If fixing hsc2hs is hard, could the 'directory' package perhaps choose another > way to implement this function? Can you try this workaround? diff --git a/System/Directory/Internal.hsc b/System/Directory/Internal.hsc index a0a71db..0f9b71f 100644 --- a/System/Directory/Internal.hsc +++ b/System/Directory/Internal.hsc @@ -1,3 +1,5 @@ +{-# LANGUAGE CPP #-} +##include #include module System.Directory.Internal @@ -28,4 +30,4 @@ import System.Directory.Internal.Posix -- | Filename extension for executable files (including the dot if any) -- (usually @\"\"@ on POSIX systems and @\".exe\"@ on Windows or OS\/2). exeExtension :: String -exeExtension = (#const_str EXE_EXTENSION) +exeExtension = EXE_EXTENSION From ariep at xs4all.nl Sun Aug 16 11:51:29 2015 From: ariep at xs4all.nl (Arie Peterson) Date: Sun, 16 Aug 2015 13:51:29 +0200 Subject: [Haskell-cafe] Cross-compiling fails for package 'directory' In-Reply-To: References: <2422933.78PkZY3ekX@pook> Message-ID: <2592933.Da6Q8FIPT4@pook> On Saturday 15 August 2015 17:58:11 Phil Ruffwind wrote: > [...] > Can you try this workaround? > [...] This works: 'directory' now succesfully compiles. Many thanks! From aeroboy94 at gmail.com Sun Aug 16 12:09:28 2015 From: aeroboy94 at gmail.com (Arian van Putten) Date: Sun, 16 Aug 2015 14:09:28 +0200 Subject: [Haskell-cafe] Packages in haskell and licensing Message-ID: Hey there, Is there currently any way to look up what licenses all your packages that you pull in have? For example, if I have a GPLv3 package, I want to make sure to not pull in any MIT dependencies. Is something like that currently possible or on the roadmap? -- Groetjes, Arian -------------- next part -------------- An HTML attachment was scrubbed... URL: From targen at gmail.com Sun Aug 16 12:45:48 2015 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Sun, 16 Aug 2015 08:15:48 -0430 Subject: [Haskell-cafe] Packages in haskell and licensing In-Reply-To: References: Message-ID: On Sun, Aug 16, 2015 at 7:39 AM, Arian van Putten wrote: > Is there currently any way to look up what licenses all your packages that > you pull in have? Yep: https://hackage.haskell.org/package/cabal-dependency-licenses From adam at bergmark.nl Sun Aug 16 20:50:44 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Sun, 16 Aug 2015 22:50:44 +0200 Subject: [Haskell-cafe] Packages in haskell and licensing In-Reply-To: References: Message-ID: Slightly off-topic but my impression was that MIT was compatible with GPLv3, is that not the case? - Adam On Sun, Aug 16, 2015 at 2:45 PM, Manuel G?mez wrote: > On Sun, Aug 16, 2015 at 7:39 AM, Arian van Putten > wrote: > > Is there currently any way to look up what licenses all your packages > that > > you pull in have? > > Yep: https://hackage.haskell.org/package/cabal-dependency-licenses > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j at functorgroup.com Sun Aug 16 23:22:24 2015 From: j at functorgroup.com (Johan Glimming) Date: Mon, 17 Aug 2015 01:22:24 +0200 Subject: [Haskell-cafe] =?utf-8?q?Swedish_spin-off_has_openings_for_advanc?= =?utf-8?q?ed_functional_programmers_-_Haskell=2C_OCaml=2C_Scala=2C_and_mo?= =?utf-8?q?re=2C_Functor=2C_the_Swedish_Martin-L=C3=B6f_type_theory_spinof?= =?utf-8?q?f=2C_is_in_the_midst_of_recruiting_right_now=2C_interviewing_be?= =?utf-8?q?ginning_already_=E2=80=94_Is_it_for_you=3F?= Message-ID: Hi, Do you want to be part of the journey as the Functor startup research spin-off innovates the future of software engineering? Do you want to make a difference? Do you want to devote your talents where it can have incredible impact on the entire software industry? Functor, Sweden, is again looking for brilliant minds, essentially co-founders as a generous equity program will after a certain threshold time make sure developers, building the company indeed, also own what they are building. Now, for what follows, hold on to your seats a bit, and remember we are a spinoff startup still, and have no marketing department though we do have expertise in human resources, the most important resource for any company at any given time, to nourish and breed a culture of excellence at any given time at Functor. Remote work initially is not a problem before we move those we can, though probably not all developers will be able to move, to great office space in Sweden. We have to recruit internationally for obvious reasons (read about our technology below). There are openings at Functor Group AB, and Functor AB, Functor Consulting AB, Sweden, including also remote work, except for Scala consultants who must immediately relocate. Feel free to forward this further, and jobs at functor.se can also be used according to the final paragraph in this posting, while we favour the LinkedIn job advertisement with as many of the appendices we hope for as possible (see https://goo.gl/4agSy6 ). We are in the midst of recruitment, and those who already applied please stay tuned, for others, check the following and the links further below. Note that we use both Haskell and OCaml in our development. Functor Scalor? heavily uses Haskell in its top layers but the Martin-L?f type theory virtual machine is written in OCaml so we need you to master functional programming at large, since OCaml is at the moment faster and has for our purposes the right libraries for LLVM bindings etcetera. We do static analysis for embedded software with our product Functor Prevent?, and 95% of that software is written in C, just like Erlang/OTP, MySQL, IoT OSes and the Linux kernel, and numerous trending projects at GitHub, and OpenSSL where we have shown we would have prevented the Heartbleed bug and security vulnerability the worst bug in human history in the sense of numerous metrics, whilst damages are impossible to know (you did change all your passwords, we hope), and other bugs such as the sendmail bug whereby virtually all UNIX and Linux servers where open to attack some years ago and hopefully for the most part patched today ? Apply to work at Functor as LinkedIn job applications are still accepted now but closing soon and interviews has begun. We might need you at Functor for our success and further growth: ? Apply from LinkedIn , see instructions below, https://goo.gl/ZkdMQY ? For instructions read the last paragraph of the earlier LinkedIn posting: https://goo.gl/4agSy6 We use Haskell, OCaml, LLVM and our tools are closely tied to the C programming language and indeed to functional programming. Embedded software market is one target market, and skills in compiler design, type systems and operational semantics is key to our teams though we look for optimised teams as a whole, and your particular skill set may or may not include a PhD, but surely industrial experience. We have openings for Research Engineers and have some renown Research Engineers already. Research collaboration is key to our success and projects planned including a large EU project CONSTRUCTOR next year. We have strong industrial partners and some very high-profile customers internationally. The customer-driven journey is still at an early stage, while founded in 2011, and your contributions would be key to our success. Since last year, we use OCaml for key components in both Functor Prevent? and Functor Scalor? lower layers, including due to LLVM bindings and for performance (both tools are exceptionally efficient. The Functor Scalor? with the new Score? low-level type theory machine uses OCaml. Hence, the lowest lavel is indeed pure Martin-L?f type theory. Functor Scalor? is amazingly ultimately solid Scandinavian operational semantics adapted for a meta programming language specifically. With this core developed and then in every detail overseen by Per Martin-L?f himself, we have a reliable and state-of-the-art virtual machine. Our research adds to this a defined W-type monad creating a category with the desirable properties. Hence, on top of the solid logic core, Scalor? has facilities to perform as fast as C in critical components. The benchmarks speak for themselves, and yet Scalor? is a new kind of meta programming platform, aligned with the domain-driven design movement, though we have aligned it with advances in software engineering, known as domain engineering, which is an emerging new methodology giving DDD a solid foundation, but at the same time not compromising in any way, in any product, the simplicity and elegance. Programmers are not mathematicians, but inside our products you will find some seriously exciting technology to make it all possible. See www.language-driven.org and www.domain-specific.org. For this reason, we need additional brilliant OCaml developers to strengthen our teams, both for Functor Prevent? and its program analysis with dependent types also based on solid operational semantics, and Functor Scalor? with full-blown type theory, named the new constructive programming paradigm already back in 2012, unwittingly perhaps a name coined by Per Martin-L?f himself. Recent progress has made all this possible, and industrial productification has made it all usable in real-world applications, despite the advanced technology inside, which can be trusted, implies elegance, coherence, simplicity, and with close to zero-learning curve for Prevent? and a lean one for Functor Scalor?. Scala consultants will be sent straight from the top down into projects at Ericsson for very challenging work. For these three consultants we require an exceptionally strong background with Scala projects as we team up with Typesafe and secure projects that can only be matched by exceptional Scala developers. Our Functor Scalor? is oriented somewhat differently than Scala, see www.domainspecific.org for some initial information on that products that appeals to very large companies at this stage, while Functor Prevent? is suitable for just about any software development projects, currently doing static analysis with dependent types and automatic testing for C code, such as the Erlang code base, Twitter?s MySQL branch or embedded software at large, see www.functorprevent.com or www.static-analysis.org , and also the standalone tool www.functor.se/prevent which secures systems including a project at a customer with a range of 100 MEUR/each equipment investments, all relying on the VxWorks C code where our Functor Prevent? delivers its value to prevent up to 50% of the bugs in certain projects, already with its current R1 feature set! For instructions on how to best apply, what we recommend, read our pre-compaign LinkedIn posting: ? Openings for functional programmers at Swedish startup , https://goo.gl/4agSy6 - see instructions on last paragraph! Read up with links above to our webpages (last link), and postings on LinkedIn and Facebook: ? The Future of Software Engineering , https://goo.gl/mbd76F ? Functor looks to strengthen leadership , https://goo.gl/rVtMLx See also recent news media coverage of Functor, and other LinkedIn postings: ? Embedded Conference Scandinavia , https://goo.gl/1vN2Ij ? Information for STHML TECH FEST , https://goo.gl/kANCT5 ? STHML TECH FEST invitation , https://goo.gl/RzEI9H Older job campaign provides some useful further information ? beware that it is not the current one: ? Openings globally for Scala & Haskell developers, https://goo.gl/6is0xU , now out-dated but can be good reading just the same for candidates! Some of our Facebook pages, like them and see occasional posts in your own news feed as a result: ? Functor AB , www.facebook.com/functor ? Functor Group AB , www.facebook.com/functorgroup Join some interesting groups on Facebook and contribute: ? Software Bugs , https://www.facebook.com/groups/softwarebugs ? High-Tech Startups in Sweden igh-Tech Startups in Sweden , with the allegedly richest woman in Sweden, the acting Wallenberg family are all men, serial entrepreneur in IT already a member in this new group that we manage, https://www.facebook.com/groups/hightechsweden/ ? High-Tech Startup Jobs in Sweden , https://www.facebook.com/groups/swedentech We host a newly announced event sporting leaders of the largest entrepreneur networks in Sweden although just announced, welcome to join us at Hotellet in Stockholm, which is an amazing place for the kick-off. Special invites and keynote speaker, plus mingle and drinks of course, all professional in the spirit of the group description for High-Tech Startups in Sweden, which organises the event (viz. Functor AB, Functor Group AB), co-hosts to be announced: ? High-Tech Startup Meetup Launch hosted by Functor Group AB , all welcome within this special interest community, it?s perhaps just an airplane away? APPENDIX FOR SOME TECHNOLOGY INSIGHTS AND OUR VISION FRAMED ACTUALLY BY NO ONE ELSE BUT BJARNE STROUSTRUP IN HIS COMPUTER REVIEW PAPER OF THE YEAR (2012) CONTRIBUTION: Why dependent types then? You probably already understand this, and the reasons are numerous and far from just technical. You have surely read up on many papers such as ?Why depdendent types matter?? and more. You might see why the timing is just right now, but let?s hear out what a very influential programming language contributors has to say about the problems we address and how they should be addressed: Stroustrup didn?t quite imagine going outside C++, at least not in his Computing Reviews "Best of 2012" paper (PDF via link below). His paper on Infrastructure Software (, though, makes the case for dependent type theory and our products very strongly. John Mitchell frames his contributions very well by writing " The main goal of C++ is to provide object-oriented features in a C-based language without compromising the efficiency of C ? data abstraction and object-oriented features ? better static type checking ? efficiency of compiled code ?? (book reference below). Functor Scalor? has an object-based object model derived from the Timber projects (which came out of O?Haskell) and a novel component model on top of that for low-level performance with dependently typed interfaces. Added to the domain-driven design movement and augmenting it, meaning methodological advantages of a meta programming language, Functor Scalor? is a direct solution to the problems pinpointed by Stroustrup in IEEE Computer, January, 2012: ? Stroustrup?s ?Software Development for Infrastructure? paper selected by CR Best of 2012 : Standard C++ , we advise strongly to skip those pages towards the end involving C++, for obvious reasons when the Constructive Programming Paradigm was coined to be the next programming paradigm in STEW 2012 co-autthored by Thorsten Altenkirch and Patrik Jansson (?What is the next programming paradigm??, STEW 2012). Let?s also cite L?h, McBride and Swierstra in a paper that is probably familiar to all of you: "Most functional programmers are hesitant to program with dependent types. It is said that type checking becomes undecidable; the type checker will always loop; and that dependent types are just really, really, hard. The same programmers, however, are perfectly happy to program with a ghastly hodgepodge of complex type system extensions. Current Haskell implementations, for instance, support generalized algebraic data types, multi-parameter type classes with functional dependencies, associated types and type families, impredicative higher-ranked types, and there are even more extensions on the way. Programmers seem to be willing to go to great lengths just to avoid dependent types. One of the major barriers preventing the further proliferation of dependent types is a lack of understanding amongst the general functional programming community. While, by now, there are quite a few good experimental tools and programming languages based on dependent types, it is hard to grasp how these tools actually work. A significant part of the literature available on dependent types is written by type theorists for other type theorists to read. As a result, these papers are often not easily accessible to functional programmers.? L?h et al, A tutorial implementation of a dependently typed lambda calculus (? ), Fundamenta Informaticae, no. 2 (vol.102), 2010, pp. 177-207. See also this link if you wish. As we are developers, bringing cutting-edge technology and a mountain of research right into the industry, standing on the shoulders of giants and work done during four decades, you may enjoy also eg this article: ? Sheard et al, Language-based verification will change the world , ACM proceedings of the FSE/SDP, Future of software engineering research, SIGSOFT/FSE'10 18th ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-18), 2010, ACM Press. (PDF ) Not to in any way diminish the contributions of Bjarne Stroustrup we include this image courtesy of Google Books, click to read the book about why C++ is not up to the tasks that Functor Scalor? and Functor Prevent? are. C++ has had great impact on the software community and is still heavily used. That said, John Mitchell lists numerous shortcomings in the book, but we honour Stroustrup in this manner: John Mitchell writes (Concepts of Programming Languages, Cambridge University Press, 2002): "C++ is an object-oriented extension of the C language. It was originally called C with classes , with the name C++ originating around 1984. A Bell Laboratories researcher interested in simulation, Bjarne Stroustrup began the C++ project in the early 1980s. His goal was to add objects and classes to C, using his experience with Simula as the basis for the design. The design and implementation of C++ was originally a one-person effort, with no apparent intent to produce a commercial product. However, as interest in objects and program structure grew over the course of the 1980s, C++ became popular and widely used. In the 1990s, C++ became the most widely used object-oriented language, with good compilers and development environments available for the Macintosh, PC, and Unix-based workstations." We are not using C++ in any of our products, but honour the historical importance of Stroustrup. You?ll find us easily on Twitter, @functors, @functorgroup, @functortech, etc! PS. Servers are again considerably boosted / upgraded this very night (CET), but subscribe to newsletter.functorgroup.com and you?ll receive a message when the server work is completed, and for rare but then important news from us in the future. Our real, non-backup site deserves a careful read through before you apply, we strongly recommend this as you would have to share our vision and believe in it too. Some links in this email may not work until tomorrow as we host everything on our own secure very powerful HP servers, hosting very sensitive customer code from companies you are familiar to should we disclose their name, and therefore have invested in our servers again. Be sure to check back on the links such as domain-specific.org and so on and indeed www.functorgroup.com tomorrow CET when we open the firewall again and liberate our work horses, then even stronger. Compile time with Haskell is not as blazingly fast as running Functor Prevent?, for all the good reasons, and therefore you will benefit from 48 processors and more when working on our servers. Yours Sincerely, Johan Glimming ? Dr Johan Glimming Chief Executive Officer at Functor AB, Chairman at Functor Group AB LinkedIn: se.linkedin.com/in/glimming Functor AB, Box 7070, 164 07 Kista, SWEDEN , tel. +46-8-55005500 Web: www.functorgroup.com Twitter: @functors UK tel: +44-1223-911400 US tel: +1-(415)-513-0090 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AAEAAQAAAAAAAANzAAAAJGYzZjMzYmEzLTg2N2QtNDE2My1iNWQ4LTIyYWFjZTkxYzc5YQ.jpeg Type: image/jpeg Size: 55252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AAEAAQAAAAAAAAJyAAAAJDY0ZmQ2NDc1LTY5ZjAtNDBlNC1hN2JmLTNmYzllZTllMjg5OA.jpeg Type: image/jpeg Size: 46048 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-13.png Type: image/png Size: 29003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-15.png Type: image/png Size: 299312 bytes Desc: not available URL: From winterkoninkje at gmail.com Mon Aug 17 03:04:06 2015 From: winterkoninkje at gmail.com (wren romano) Date: Sun, 16 Aug 2015 23:04:06 -0400 Subject: [Haskell-cafe] How to model outer space for a MUD In-Reply-To: References: Message-ID: On Fri, Aug 14, 2015 at 4:34 PM, Michael Litchard wrote: > Star Wars MUD has a 3-D coordinate system such that (0,0,0) is some planet. > I'm curious as to how one might model this system that could simulate a > ship's movement through a 3-D grid. Matrix, 3-D array, graph. None of these? > Ideas? The octtree suggestions are good for if you need to keep track of nearest-neighbors information. If you're going to be keeping track of orientation as well as position, note that that means you have six dimensions (three for location; and three for orientation). Moreover, for the orientation I'd suggest using quaternions instead of Euler angles (aka: roll, pitch, yaw). Euler angles have a number of problems including non-uniqueness of representation and loosing degrees of freedom due to gimbal lock[1]? whereas quaternions avoid those problems. [1] -- Live well, ~wren From debdutk at gnulinuxed.tk Mon Aug 17 08:44:55 2015 From: debdutk at gnulinuxed.tk (Debdut Karmakar) Date: Mon, 17 Aug 2015 04:44:55 -0400 Subject: [Haskell-cafe] oddsFrom3 function Message-ID: I am a haskell beginner and wondering how the following function works (in procedure) : oddsFrom3 :: [Integer] oddsFrom3 = 3 : map (+2) oddsFrom3 Thanks for your help. -- A GNU [1] LINUX [2] Patron Links: ------ [1] http://gnu.org [2] http://www.linuxfoundation.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Mon Aug 17 08:49:50 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Mon, 17 Aug 2015 10:49:50 +0200 Subject: [Haskell-cafe] oddsFrom3 function In-Reply-To: References: Message-ID: <20150817084950.GA18244@machine> Hi Debdut, On Mon, Aug 17, 2015 at 04:44:55AM -0400, Debdut Karmakar wrote: > I am a haskell beginner and wondering how the following function works (in > procedure) : > > > oddsFrom3 :: [Integer] > oddsFrom3 = 3 : map (+2) oddsFrom3 > > > Thanks for your help. Try to expand a few steps of the recursion by hand e.g.: 3 : (map (+2) (3 : map (+2) (3 : map (+2) ...))) As you can see, the deeper you go more 'map (+2)' are applied to '3'. Greetings, Daniel From dxld at darkboxed.org Mon Aug 17 09:39:39 2015 From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=) Date: Mon, 17 Aug 2015 11:39:39 +0200 Subject: [Haskell-cafe] ANN: ghc-mod-5.3.0.0 Message-ID: <20150817093937.GA24984@grml> I'm pleased to announce the long awaited release of ghc-mod 5.3.0.0! What is ghc-mod? ================ ghc-mod is both a backend program for enhancing editors and other kinds of development environments with support for Haskell and a library for abstracting the black magic incantations required to use the GHC API in various environments, especially Cabal projects. The library is used by ambitious projects like HaRe[1] and mote[2]. After a period of declining activity, development has been picking up pace again since I have taken over as maintainer. Most changes during versions 5.0.0 through 5.2.1.2 consisted only of fixes and internal cleanup work, but this release brings with it vastly improved Cabal support and support for GHC 7.10. ghc-mod now has intimate knowledge of the components in a Cabal project, this allows it to make much more informed decisions about which options to pass to GHC for any given module than previously possible. The largest complication for this work was the fact that ghc-mod must consult Cabal's internal configuration information (the file that `cabal configure` generates) which is bound to one specific version of Cabal (the library) while surviving users upgrading their cabal-install executables, which will link `cabal` (the executable) against a different version of Cabal (the library) thus breaking ghc-mod's ability to read the configuration information. Out of the frustration with this horrible state of affairs cabal-helper was born (https://github.com/DanielG/cabal-helper) which now isolates ghc-mod against any and all Cabal version related problems. Long story short this all is a major step forward in terms of how well ghc-mod's suggestions reflect what `cabal build` would report, and should also allow ghc-mod to work even in more complicated Cabal setups. How to contribute ================= Right now ghc-mod has only one core developer and only a handful of occasional drive-by contributors even though it's a non-insignificant part of the first-time Haskell experience, we regularly receive bug reports and support requests from people only just starting Haskell hacking. Unfortunately in the last 7 months this experience was not a very good one because we are sorely lacking active contributors willing to actually fix bugs. I think this is a very disappointing state of affairs since we're essentially driving people away to other languages for no good reason. The way forward --------------- Right now I'm working full time on ghc-mod as part of a summer internship at IIJ Innovation Institute in Japan and will continue to do so until the end of September. I would like to invite anyone who is interested in improving ghc-mod to come and talk to me in #ghc-mod on Freenode (I'm "dxld" there) or E-Mail me directly. During my internship I will be working on splitting ghc-mod into a frontend and backend package to make integration with external tools like HaRe and mote easier, rewriting the ghc-mod frontend tools to be based on a server-client architecture and if time allows adding proper interactive code execution to ghc-mod so it can be used as a ghci replacement in frontends. In the meantime my supervisor Kazu Yamamoto will also be hacking on ghc-mod, mostly improving the Emacs frontend and possibly merging it into haskell-mode[3]. The ghc-mod code base can be quite a beast for anyone looking at if for the first time, I've been trying to improve the situation since I joined the project but after a while you just loose this new pair of eyes and become blind to all the things that could be improved. While I'm still at IIJ-II I can offer anyone who wants to work on ghc-mod my support in getting started with the codebase. Getting ghc-mod =============== Github: https://github.com/kazu-yamamoto/ghc-mod Hackage: http://hackage.haskell.org/package/ghc-mod Frontends: - Emacs (native): https://github.com/kazu-yamamoto/ghc-mod https://github.com/iquiw/company-ghc - Vim: https://github.com/eagletmt/ghcmod-vim https://github.com/eagletmt/neco-ghc - Atom: https://github.com/atom-haskell/ide-haskell https://github.com/andyfriesen/Helium Known issues ============ The new and improved Cabal support required heavy use of caching and there seem to still be some cases of cache invalidation of the module graph not working properly. For now these can be fixed by deleting dist/setup-config.ghc-mod.* ghc-mod's `case`, `sig` and `refine` commands do not work properly with GHC 7.10 yet: https://github.com/kazu-yamamoto/ghc-mod/issues/438 If you do notice any other problems please report them: https://github.com/kazu-yamamoto/ghc-mod/issues ---- [1]: https://github.com/alanz/HaRe [2]: https://github.com/imeckler/mote [3]: https://github.com/kazu-yamamoto/ghc-mod/issues/454#issuecomment-127603458 https://github.com/kazu-yamamoto/ghc-mod/issues/544 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From silvio.frischi at gmail.com Mon Aug 17 11:35:33 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Mon, 17 Aug 2015 13:35:33 +0200 Subject: [Haskell-cafe] oddsFrom3 function In-Reply-To: References: Message-ID: This is a classical example that combines lazy (actually the real name is non-strict) lists and recursion. You can find an explanation of such a combination here http://stackoverflow.com/questions/6273621/understanding-a-recursively-defined-list-fibs-in-terms-of-zipwith Silvio -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Mon Aug 17 17:14:17 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 17 Aug 2015 13:14:17 -0400 Subject: [Haskell-cafe] Kill forked threads in ghci Message-ID: <60CD3A31-2975-462D-A365-24097B194232@gmail.com> Is there a way in ghci to kill all running background processes without quitting ghci itself? E.g. if I do > forkIO . forever $ print 5 >> threadDelay 1000000 If I don't have the ThreadId, is there any way for me to stop printing "5"s without killing ghci? tom From silvio.frischi at gmail.com Mon Aug 17 17:57:49 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Mon, 17 Aug 2015 19:57:49 +0200 Subject: [Haskell-cafe] Kill forked threads in ghci In-Reply-To: <60CD3A31-2975-462D-A365-24097B194232@gmail.com> References: <60CD3A31-2975-462D-A365-24097B194232@gmail.com> Message-ID: <55D2209D.6060803@gmail.com> I've come across that problem too. I found this on stackoverflow. http://stackoverflow.com/questions/24999636/is-there-a-way-to-kill-all-forked-threads-in-a-ghci-session-without-restarting-i If you're doing the forking, you can simply write a function forkIO that registers threadId's in some global MVar. Otherwise I don't know. Silvio From alexey.muranov at gmail.com Mon Aug 17 21:16:51 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Mon, 17 Aug 2015 14:16:51 -0700 (PDT) Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: Funnily, i've just noticed that this notation with `::=` to define data types is used in [Why Functional Programming Matters by John Hughes](http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html). Just a remark. Alexey. On Saturday, August 8, 2015 at 1:09:24 PM UTC+2, Alexey Muranov wrote: > > Hello, > > i would like to suggest an idea for modifying the basic data/newtype > syntax in Haskell: replace the equality sign `=` with `::=`. > > When i started learning Haskell, the most confusing part of the syntax for > me was the equality sign in `data` definition. I could not even guess what > the `data` definition meant without reading a chapter or two about types in > Haskell, and i think it was partially due to the equality sign. I still > find this notation inconsistent with other uses of the equality sign in > Haskell and in general. > > For example, in > > type Name = String > data Date = Date Int Int Int > data Anniversary = Birthday Name Date | Wedding Name Name Date > > the second line is particularly disorienting IMO because on two sides of > the equality, `Date` denotes different things. > > As far as i understand, in all contexts except those of `data` and > `newtype` definitions, the equality sign in Haskell denotes the actual > equality for all purposes: if a line > > foo x y = bar y x > > is present in a program, `foo a b` and `bar b a` can be used more or less > interchangeably elsewhere in the program. Similarly, if the line > > type Name = String > > is present, `Name` can be used as `String`. Clearly, the equality in > > data Date = Date Int Int Int > > does not have such property. > > I think that if `::=` was used instead of `=` in `data` and `newtype` > definitions, this would suggest to a newcomer that the syntax of the two > sides might be different, and would helpfully remind of the Backus?Naur > Form for syntax rules. I think that a newcomer to Haskell, like myself, > would have had a better chance of guessing the meaning of > > type Name = String > data Date ::= Date Int Int Int > data Anniversary ::= Birthday Name Date | Wedding Name Name Date > > IMO this would make the program easier to read in general and the > difference between `type` and `newtype` more clear. Maybe the can even > make the use of keywords redundant, by allowing to write simply > > Name = String > Date ::= Date Int Int Int > Anniversary ::= Birthday Name Date | Wedding Name Name Date > > What do you think? > > Alexey. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Tue Aug 18 05:52:55 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 18 Aug 2015 17:52:55 +1200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <87614p7bdi.fsf@andromedae.feelingofgreen.ru> Message-ID: On 9/08/2015, at 8:59 am, MigMit wrote: > > The reason is very simple, and it was stated several times already: it will break everything that was written so far, and there is not enough evidence that things would be even a little better. Not just everything written IN Haskell, but everything written ABOUT Haskell as well. Like books, lecture notes, tutorials, ... For what it's worth, -- Ada type I1 is new Integer; -- isomorphic but incompatible subtype I2 is Integer; -- just an alias (* ML *) datatype 'a tsil = LIN | SNOC of 'a tsil * 'a type revints = int stil (* spell the words backwards *) // F# type T = A | B | C;; type R = T;; // How's that for confusing? Defining a new type (T) and an // alias (R) use the *same* keyword and operator! type S = S;; // defines a new type with one constructor, but // type S = T;; // would have defined S as an alias for T. % Mercury :- type strange ---> foo(int) ; bar(string). :- type wierd == strange. % different operator. % Erlang -type tsil(T) :: nil | {snoc,tsil(T),T}. -type revints() :: tsil(integer()). % This looks as bad as F#, but it's either better or worse, % depending on your viewpoint. Erlang types are not % Hindley-Milner types and it does not have ADT (sum-of- % products) declarations. 'snoc' above is just a constant. % BOTH declarations are aliases. // Clean ::Tsil a = Lin | Snoc (Tsil a) a ::RevInts :== Tsil Int //different operator "::" is used to *introduce* a type in Clean, presumably because infix "::" is used to *apply* a type (Empty :: RevInts). Haskell is actually pretty clear. From ok at cs.otago.ac.nz Tue Aug 18 06:16:12 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 18 Aug 2015 18:16:12 +1200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> Message-ID: <0EB2F628-9032-4040-B81B-5EECEB4E9C62@cs.otago.ac.nz> On 9/08/2015, at 5:28 am, Hilco Wijbenga wrote: > I wholeheartedly agree with replacing the current "type" with "alias", That would be to replace a precise time with a vague one. All sorts of things can be aliased. Especially when someone writes code that I would like to use, but writes it with an American accent, I would very much like to be able to do things *like* alias Colour = Color and I would like to do this for types, for modules, for constructors, for plain functions, &c. I am not saying that the same *form* of declaration should be used in each case, but that declarations all using the _word_ 'alias' should be available to make it quite plain to the reader what is going on. In particular, there is currently no way to give an additional name to a constructor that lets you *use* it as a constructor. 'alias' is far too potentially useful a word to squander this way. Consider ML: val thingy = 42 This says that 'thingy' is another name for the val(ue) 42. It's an equality for values. type 'a sequence = 'a list This says that for any type 't, 't sequence is another name for the type 't list. It's an equality for types. Type is the *perfect* word here, in ML. Now Haskell does not the 'val' keyword (nor the 'fun' keyword) and it doesn't need them. But it *does* have two kinds of type declaration, one of which *IS* a type equality type Sequence t = [t] and *looks like it*, and one of which ISN'T a type equality. If you want to argue about the grammar of 'data' declarations, go right ahead. I myself was a little confused by them at the beginning, because the declare a new type and some constructors, but do not declare 'data' in the sense that a DATA statement in BASIC or Fortran or the DATA DIVISION in COBOL does. The word 'data' is so very far from conveying the idea "introduce a new type" that it's not funny. But to be confused by 'type' declarations? That's, well, alien. Especially as in the Haskell teaching material I'm familiar with, people are introduced to 'type' declarations doing the utterly familiar 'introduce a new name for an old type' thing before they're introduced to 'data'. > the current "type" is just flat out wrong: it does *not* create a > type. AND IT DOES NOT *CLAIM* TO CREATE A TYPE. It claims to state a type EQUALITY, and it really does. It's just like if you write answer = 42 This does NOT define a new constant. It gives a new name for an existing value. Next thing someone will say that this ought to be written value_alias answer = 42 or something. From daniel.trstenjak at gmail.com Tue Aug 18 06:49:40 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 18 Aug 2015 08:49:40 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <0EB2F628-9032-4040-B81B-5EECEB4E9C62@cs.otago.ac.nz> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <0EB2F628-9032-4040-B81B-5EECEB4E9C62@cs.otago.ac.nz> Message-ID: <20150818064940.GA2735@machine> Hi Richard, > AND IT DOES NOT *CLAIM* TO CREATE A TYPE. > It claims to state a type EQUALITY, and it really does. I can understand your reasoning and only looking at 'type' it's fine, but you've to look at 'type/newtype/data' at once, and if 'data' is strangely named, what other name would you take for it? > It's just like if you write > > answer = 42 > > This does NOT define a new constant. It gives a new name for > an existing value. Next thing someone will say that this ought > to be written > > value_alias answer = 42 > > or something. But with this point of view 'type Sequence t = [t]' is also somehow bogus and should just be 'Sequence t = [t]'. Greetings, Daniel From ok at cs.otago.ac.nz Tue Aug 18 07:10:24 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 18 Aug 2015 19:10:24 +1200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150818064940.GA2735@machine> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <0EB2F628-9032-4040-B81B-5EECEB4E9C62@cs.otago.ac.nz> <20150818064940.GA2735@machine> Message-ID: <62FC9D99-37DF-465B-9E68-1FF3D6BE57D8@cs.otago.ac.nz> On 18/08/2015, at 6:49 pm, Daniel Trstenjak wrote: > > Hi Richard, > >> AND IT DOES NOT *CLAIM* TO CREATE A TYPE. >> It claims to state a type EQUALITY, and it really does. > > I can understand your reasoning and only looking at 'type' it's fine, but > you've to look at 'type/newtype/data' at once, and if 'data' is > strangely named, what other name would you take for it? Oh, I _have_ looked at them all at once. In fact looking at them all at once was precisely what made it easy to understand them. newtype *says* it introduces a new type, and it *does*. The distinction between type and newtype makes it extremely hard to be confused about 'type', or any rate hard to both be awake and *remain* confused for long. What name would I have used for 'data'? While 'newtype T x = T x' and 'data T x = T !x' _aren't_ exactly the same in Haskell, they _could_ have been, and then 'newtype' would have been the perfect replacement for 'data'. The fact that 'newtype' and 'data' *both* introduce new types is surely the one confusing point here. But again, this makes 'data' the confusing keyword, not 'type' and not 'newtype'. More precisely, we could have had something like newtype T x = ~T !x {- current newtype -} newtype C x = A | B x | C x x { - current data -} or some such distinction. But we have what we have, and it certainly isn't *more* confusing than F# or Clean. If this is the worst problem beginners have, Haskell must be in wonderful shape. > >> It's just like if you write >> >> answer = 42 >> >> This does NOT define a new constant. It gives a new name for >> an existing value. Next thing someone will say that this ought >> to be written >> >> value_alias answer = 42 >> >> or something. > > But with this point of view 'type Sequence t = [t]' is also somehow > bogus and should just be 'Sequence t = [t]'. WRONG. Type names and function names live in different namespaces. 'type' is NECESSARY to specify the namespace that Sequence lives in. From _deepfire at feelingofgreen.ru Tue Aug 18 08:13:59 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Tue, 18 Aug 2015 11:13:59 +0300 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <62FC9D99-37DF-465B-9E68-1FF3D6BE57D8@cs.otago.ac.nz> (sfid-20150818_113043_121406_D3D6A964) (Richard A. O'Keefe's message of "Tue, 18 Aug 2015 19:10:24 +1200") References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <0EB2F628-9032-4040-B81B-5EECEB4E9C62@cs.otago.ac.nz> <20150818064940.GA2735@machine> <62FC9D99-37DF-465B-9E68-1FF3D6BE57D8@cs.otago.ac.nz> Message-ID: <87wpwtypx4.fsf@feelingofgreen.ru> "Richard A. O'Keefe" writes: > But we have what we have, and it certainly isn't *more* > confusing than F# or Clean. If this is the worst problem > beginners have, Haskell must be in wonderful shape. This isn't supposed to be a contest of any sort, in my mind, but rather an attempt to improve things, in absolute terms. The way you dissected the type/newtype/data trinity.. I must say I like it best. The distinction between 'type' and 'newtype' really ought to be underscored, and in this context 'data' is what stands out, indeed. -- ? ???????e? / respectfully, ??????? ?????? -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? ? Friedrich Wilhelm Nietzsche From silvio.frischi at gmail.com Tue Aug 18 16:52:36 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Tue, 18 Aug 2015 18:52:36 +0200 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: References: <20150814214635.GE20036@weber> <55CF3229.60402@gmail.com> <20150815131257.GF20036@weber> Message-ID: <55D362D4.9040300@gmail.com> > I would avoid it, Haskell's type system is not a nice programming > language to work with Do you know why this is so? And why dependent types are such a problem in Haskell? I've been wondering this for a while. Is it a GHC (System FC) problem or generally a Haskell problem? Or is it just that nobody really knows how dependent types are supposed to work anyway, so it's all a bit best effort? Or does it have something to do with inferring types and choosing instances. P.S. I'm more interested in practical problems or examples than a mathematical proof of why one type system is incompatible with another. Silvio From alexey.muranov at gmail.com Wed Aug 19 08:09:29 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Wed, 19 Aug 2015 10:09:29 +0200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <0EB2F628-9032-4040-B81B-5EECEB4E9C62@cs.otago.ac.nz> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <0EB2F628-9032-4040-B81B-5EECEB4E9C62@cs.otago.ac.nz> Message-ID: <419CED05-0567-4363-BC5E-A04863B08E33@gmail.com> On 18 ao?t 2015, at 08:16, Richard A. O'Keefe wrote: > If you want to argue about the grammar of 'data' declarations, > go right ahead. I myself was a little confused by them at > the beginning, because the declare a new type and some > constructors, but do not declare 'data' in the sense that a > DATA statement in BASIC or Fortran or the DATA DIVISION in > COBOL does. The word 'data' is so very far from conveying > the idea "introduce a new type" that it's not funny. Ok, then, just hypothetically (i do not want to argue about actually introducing it), how about type Name = String type Date ::= Date Int Int Int type Anniversary ::= Birthday Name Date | Wedding Name Name Date instead of type Name = String data Date = Date Int Int Int data Anniversary = Birthday Name Date | Wedding Name Name Date ? Alexey. From apfelmus at quantentunnel.de Wed Aug 19 16:12:04 2015 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Wed, 19 Aug 2015 18:12:04 +0200 Subject: [Haskell-cafe] Reactive config file generation In-Reply-To: References: Message-ID: Hello David, author of the FRP library "reactive-banana"[1] here. Well, you can certainly use FRP in this context, but your situation seems so simple that I'm not sure if it's worth it here. The way I see FRP is that it helps you deal with time-varying state in a way that does not lead to spaghetti code. The fundamental insight is a semantic one, but on the practical side, FRP simplifies change propagation and reasoning about the order of changes. Your situation looks like you do not have to keep track of state, i.e. most of your operations seem to be pure or idempotent, so while FRP won't hurt it, it won't make your life significantly easier either. On the question of choosing a library, I would, of course, recommend "reactive-banana", but I may be a little biased there. :) I can also recommend "sodium" [2], which is very similar. There are also two very recent offerings, "reflex" [3] and "frpnow" [4]. I don't know much about the former. The latter has a nice theory background, but seems to be pull-based. Best regards, Heinrich Apfelmus [1]: https://wiki.haskell.org/Reactive-banana [2]: https://hackage.haskell.org/package/sodium [3]: https://hackage.haskell.org/package/reflex [4]: https://hackage.haskell.org/package/frpnow -- http://apfelmus.nfshost.com David Turner wrote: > Hi all, > > I am using Apache Zookeeper as a service directory: I have a bunch of > services which announce their presence by making nodes in Zookeeper, so > that dependent services can update their configuration to make use of the > available services, and stop trying to use services that have died. > > Zookeeper is a pretty nice fit for this because it supports watching a node > for changes, so in theory there is no need to poll Zookeeper periodically. > The services that I control work with this just fine, but there are some > (e.g. an Nginx reverse-proxy) that are reconfigured using the rather more > common approach of updating a file (or files) and then sending the process > a signal. I am currently pondering how to make this work without polling, > or manually triggering a refresh script, which is how it is currently done. > > I've never used FRP, but am at least vaguely aware of it and from my > high-level understanding it seems like this could be a very good fit. The > Zookeeper state is a time-varying value which I want to convert into a > time-varying set of files, ideally as declaratively as possible. > > So, two questions to the FRP congnoscenti out there. Firstly, is it > worthwhile to attempt this using FRP at all? I'm sure I could do it by hand > too. Secondly, which of the many FRP libraries would you recommend for it? > There are loads on the Wiki, seemingly in various states of repair and > documentation. Any pointers on how to choose one that's featureful enough, > performant enough, and being actively maintained? > > Thanks in advance, > > David > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From silvio.frischi at gmail.com Wed Aug 19 17:27:18 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Wed, 19 Aug 2015 19:27:18 +0200 Subject: [Haskell-cafe] Reactive config file generation In-Reply-To: References: Message-ID: <55D4BC76.8010208@gmail.com> frp-zoo is a nice comparison of frp libraries. Where you can easily compare how day deal with three typical problems. https://github.com/gelisam/frp-zoo Silvio From eir at cis.upenn.edu Wed Aug 19 18:04:47 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 19 Aug 2015 14:04:47 -0400 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: <55D362D4.9040300@gmail.com> References: <20150814214635.GE20036@weber> <55CF3229.60402@gmail.com> <20150815131257.GF20036@weber> <55D362D4.9040300@gmail.com> Message-ID: <679A2E52-641F-4D41-A275-E9275FDC5E64@cis.upenn.edu> On Aug 18, 2015, at 12:52 PM, Silvio Frischknecht wrote: >> I would avoid it, Haskell's type system is not a nice programming >> language to work with > > Do you know why this is so? Here's my take: the type-level programming features have been added one-at-a-time, without a coherent attempt to make a "type-level programming language". So it's missing some niceties, like case statements in type family definitions and local definitions. Some of these are easier to add than others. (Actually, the two I've listed here wouldn't be bad. Lambda is another story, though.) > And why dependent types are such a problem > in Haskell? No existing dependently typed language can infer the type of `length` from its body. But a dependently typed Haskell must do so. From a practical standpoint, GHC is just really big. And adding dependent types is a pervasive change that takes a *lot* of time. My dissertation (github.com/goldfirere/thesis) is about adding dependent types to GHC. I believe I've solved the first problem, basically by copying Adam Gundry's approach (http://adam.gundry.co.uk/pub/thesis/). Still working on that practical problem, though. Expect some changes in time for 7.12 though. (See https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 for some discussion here.) The bottom line: there is reason to hope that Haskell will have dependent types within the next two years or so. Richard From silvio.frischi at gmail.com Wed Aug 19 20:54:24 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Wed, 19 Aug 2015 22:54:24 +0200 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: <679A2E52-641F-4D41-A275-E9275FDC5E64@cis.upenn.edu> References: <20150814214635.GE20036@weber> <55CF3229.60402@gmail.com> <20150815131257.GF20036@weber> <55D362D4.9040300@gmail.com> <679A2E52-641F-4D41-A275-E9275FDC5E64@cis.upenn.edu> Message-ID: <55D4ED00.6050208@gmail.com> > My dissertation (github.com/goldfirere/thesis) is about adding > dependent types to GHC. I believe I've solved the first problem, > basically by copying Adam Gundry's approach > (http://adam.gundry.co.uk/pub/thesis/). Still working on that > practical problem, though. Expect some changes in time for 7.12 > though. (See > https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 for > some discussion here.) It's always nice to see things are happening. GHC is awesome. The thing with the star also being a typeoperator is a bit unfortunate. I always thought it a bit inconsistent to use an operator lexem for typekind even though it's not an operator at all. A normal name would have done. > The bottom line: there is reason to hope that Haskell will have > dependent types within the next two years or so. What exactly does that mean? The ability to use normal functions, Ints and Strings at typelevel, instead of type families, Nats and Symbols. or Just have a type-level language that is similar to the commonly used type dependent languages. Silvio From gale at sefer.org Thu Aug 20 00:01:07 2015 From: gale at sefer.org (Yitzchak Gale) Date: Thu, 20 Aug 2015 03:01:07 +0300 Subject: [Haskell-cafe] Haskell developer position in Jerusalem Message-ID: We have a position open for a Haskell developer. This is an on-site position at our development center in Jerusalem. You will be working on our enterprise customer-tailored content delivery products - see the "Products" tab on our home page - which are implemented (mostly) in Haskell. Search for Haskell on our "Careers" page for a fuller description of the position. Submit your CV to [jobs at suite-sol.com](mailto:jobs at suite-sol.com), but also feel free to contact me if you have any questions. Thanks, Yitz From eir at cis.upenn.edu Thu Aug 20 03:30:07 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 19 Aug 2015 23:30:07 -0400 Subject: [Haskell-cafe] A type level puzzle In-Reply-To: <55D4ED00.6050208@gmail.com> References: <20150814214635.GE20036@weber> <55CF3229.60402@gmail.com> <20150815131257.GF20036@weber> <55D362D4.9040300@gmail.com> <679A2E52-641F-4D41-A275-E9275FDC5E64@cis.upenn.edu> <55D4ED00.6050208@gmail.com> Message-ID: <3BC0232B-C531-4E52-BAC9-8C57720B4911@cis.upenn.edu> On Aug 19, 2015, at 4:54 PM, Silvio Frischknecht wrote: >> My dissertation (github.com/goldfirere/thesis) is about adding >> dependent types to GHC. I believe I've solved the first problem, >> basically by copying Adam Gundry's approach >> (http://adam.gundry.co.uk/pub/thesis/). Still working on that >> practical problem, though. Expect some changes in time for 7.12 >> though. (See >> https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1 for >> some discussion here.) > > It's always nice to see things are happening. GHC is awesome. > > The thing with the star also being a typeoperator is a bit unfortunate. > I always thought it a bit inconsistent to use an operator lexem for > typekind even though it's not an operator at all. A normal name would > have done. Agreed completely. But that backward-compatibility nightmare that this change would cause just isn't worth it. > >> The bottom line: there is reason to hope that Haskell will have >> dependent types within the next two years or so. > > What exactly does that mean? > > The ability to use normal functions, Ints and Strings at typelevel, > instead of type families, Nats and Symbols. > > or > > Just have a type-level language that is similar to the commonly used > type dependent languages. While I'm not sure what will happen with Nat/Symbol vs Int/String yet, I am hoping that functions will just be able to be used in types. We'll see how it all works out. But I'm aiming more for the first description than the second. As for timing: finishing an unpolished, not-ready-to-merge but functional implementation is part of my dissertation. I'm very much hoping to graduate by next summer, so there is a big incentive for me to actually get this done! Richard From will.yager at gmail.com Thu Aug 20 05:30:30 2015 From: will.yager at gmail.com (William Yager) Date: Wed, 19 Aug 2015 22:30:30 -0700 Subject: [Haskell-cafe] List of nitpicks Message-ID: Hello all, Inspired by the recent thread re. modifying data/type/newtype syntax, I've made a wiki article dedicated to Haskell-related nitpicks. I've added a few entries; one from the thread I just mentioned, and a classic from way back in the 90s (map vs fmap). https://wiki.haskell.org/Nitpicks Hopefully, this page will help us keep track of what people are annoyed about (especially people who aren't already inured to the quirks of Haskell) as well as give us inspiration for future proposals. Cheers, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Aug 20 05:52:23 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 20 Aug 2015 06:52:23 +0100 Subject: [Haskell-cafe] Haskell developer position in Jerusalem In-Reply-To: References: Message-ID: <20150820055223.GS5871@weber> On Thu, Aug 20, 2015 at 03:01:07AM +0300, Yitzchak Gale wrote: > We have a position open for a Haskell developer. This is an on-site > position at our development center in Jerusalem. You will be working > on our enterprise customer-tailored content delivery products - see > the "Products" tab on our home page - which are implemented (mostly) > in Haskell. This appears to be the Home Page http://www.suite-sol.com/ (I don't believe there was a direct link). Tom From ky3 at atamo.com Thu Aug 20 06:04:22 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Thu, 20 Aug 2015 13:04:22 +0700 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: References: Message-ID: On Thu, Aug 20, 2015 at 12:30 PM, William Yager wrote: a classic from way back in the 90s (map vs fmap) The arguments surrounding FTP are also relevant. See http://neilmitchell.blogspot.com/2014/10/why-traversablefoldable-should-not-be.html There isn't always a "right" answer but a spectrum of trade-offs. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.caught.air at gmail.com Thu Aug 20 06:07:29 2015 From: i.caught.air at gmail.com (Alex Belanger) Date: Thu, 20 Aug 2015 02:07:29 -0400 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: References: Message-ID: I like the idea. Is the source mendatory though? I'm personally annoyed by the (-) usage for negative integer literals and partial functions in Prelude (head, etc). Alex On Aug 20, 2015 1:30 AM, "William Yager" wrote: > Hello all, > > Inspired by the recent thread re. modifying data/type/newtype syntax, I've > made a wiki article dedicated to Haskell-related nitpicks. I've added a few > entries; one from the thread I just mentioned, and a classic from way back > in the 90s (map vs fmap). > > https://wiki.haskell.org/Nitpicks > > Hopefully, this page will help us keep track of what people are annoyed > about (especially people who aren't already inured to the quirks of > Haskell) as well as give us inspiration for future proposals. > > Cheers, > Will > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Thu Aug 20 06:47:30 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Thu, 20 Aug 2015 08:47:30 +0200 Subject: [Haskell-cafe] haddock complains about unknown symbol in .a file Message-ID: <55D57802.6090108@htwk-leipzig.de> Dear all, what is happening here? http://hackage.haskell.org/package/satchmo-2.9.9.1/reports/1/log The library is built, but haddock fails with haddock: /home/builder/hackage-server/build-cache/tmp-install/lib/x86_64-linux-ghc-7.8.3/minisat-0.1.2/libHSminisat-0.1.2.a: unknown symbol `_ZGVZN7Minisat6Option13getOptionListEvE7options' Why is haddock complaining, but ghc is not? Any pointers appreciated (to explain and solve the problem - I think there's a work-around of uploading documentation to hackage but that does not feel right) - J.W. From gale at sefer.org Thu Aug 20 07:44:06 2015 From: gale at sefer.org (Yitzchak Gale) Date: Thu, 20 Aug 2015 10:44:06 +0300 Subject: [Haskell-cafe] Haskell developer position in Jerusalem In-Reply-To: <20150820055223.GS5871@weber> References: <20150820055223.GS5871@weber> Message-ID: Tom Ellis wrote: > This appears to be the Home Page http://www.suite-sol.com/ (I don't believe > there was a direct link). Yes, thanks. Sorry, this was a paste from reddit, and of course the links didn't come through. :) Products page: http://suite-sol.com/products/ Search for "Haskell" on our "Careers" page for a fuller description of the position: http://suite-sol.com/about-us/careers/ Submit your CV to jobs at suite-sol.com, but also feel free to contact me directly if you have any questions. Thanks, Yitz >> We have a position open for a Haskell developer. This is an on-site >> position at our development center in Jerusalem. You will be working >> on our enterprise customer-tailored content delivery products - see >> the "Products" tab on our home page - which are implemented (mostly) >> in Haskell. From fa-ml at ariis.it Thu Aug 20 10:10:53 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 20 Aug 2015 12:10:53 +0200 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: References: Message-ID: <20150820101053.GA1532@casa.casa> On Wed, Aug 19, 2015 at 10:30:30PM -0700, William Yager wrote: > Hello all, > > Inspired by the recent thread re. modifying data/type/newtype syntax, I've > made a wiki article dedicated to Haskell-related nitpicks. Thank you for having set up the page, it's a great for referencing those endless threads. I'll subscribe to the page feed ( https://wiki.haskell.org/index.php?title=Nitpicks&feed=atom&action=history ) to see what are people's pet hates! From alexey.muranov at gmail.com Thu Aug 20 12:42:14 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Thu, 20 Aug 2015 05:42:14 -0700 (PDT) Subject: [Haskell-cafe] List of nitpicks In-Reply-To: References: Message-ID: Dear William, thank you for setting up this wiki page. Here is another benefit of having it: it can be referenced in beginner's introductions to Haskell to help newcomers to distinguish between subtleties and known quirks, to reduce overall confusion. It would have helped me in any case. I would like to add here another nitpick that was mentioned in the aforementioned discussion: `:` and `::` in Haskell are "backwards" :). Alexey. On Thursday, August 20, 2015 at 7:30:37 AM UTC+2, William Yager wrote: > > Hello all, > > Inspired by the recent thread re. modifying data/type/newtype syntax, I've > made a wiki article dedicated to Haskell-related nitpicks. I've added a few > entries; one from the thread I just mentioned, and a classic from way back > in the 90s (map vs fmap). > > https://wiki.haskell.org/Nitpicks > > Hopefully, this page will help us keep track of what people are annoyed > about (especially people who aren't already inured to the quirks of > Haskell) as well as give us inspiration for future proposals. > > Cheers, > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.cameron at covenanteyes.com Thu Aug 20 12:57:44 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Thu, 20 Aug 2015 12:57:44 +0000 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: References: , Message-ID: <1440075469029.85200@covenanteyes.com> ?I wonder if some of these nitpicks could actually be solved by splitting "prelude" out as a separate module. Packages could then begin depending on a certain version [range] of prelude (apart from base/GHC version). That could allow breaking changes to prelude without breaking code (all hail the PVP!). Elliot ________________________________ From: Haskell-Cafe on behalf of Alexey Muranov Sent: Thursday, August 20, 2015 8:42 AM To: Haskell-cafe Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] List of nitpicks Dear William, thank you for setting up this wiki page. Here is another benefit of having it: it can be referenced in beginner's introductions to Haskell to help newcomers to distinguish between subtleties and known quirks, to reduce overall confusion. It would have helped me in any case. I would like to add here another nitpick that was mentioned in the aforementioned discussion: `:` and `::` in Haskell are "backwards" :). Alexey. On Thursday, August 20, 2015 at 7:30:37 AM UTC+2, William Yager wrote: Hello all, Inspired by the recent thread re. modifying data/type/newtype syntax, I've made a wiki article dedicated to Haskell-related nitpicks. I've added a few entries; one from the thread I just mentioned, and a classic from way back in the 90s (map vs fmap). https://wiki.haskell.org/Nitpicks Hopefully, this page will help us keep track of what people are annoyed about (especially people who aren't already inured to the quirks of Haskell) as well as give us inspiration for future proposals. Cheers, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.cameron at covenanteyes.com Thu Aug 20 13:22:01 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Thu, 20 Aug 2015 06:22:01 -0700 (PDT) Subject: [Haskell-cafe] List of nitpicks In-Reply-To: References: Message-ID: ?I wonder if some of these nitpicks could actually be solved by splitting "prelude" out as a separate module. Packages could then begin depending on a certain version [range] of prelude (apart from base/GHC version). That could allow breaking changes to prelude without breaking code (all hail the PVP!). Of course, Prelude would still be imported implicitly by default. Elliot On Thursday, August 20, 2015 at 1:30:37 AM UTC-4, William Yager wrote: > > Hello all, > > Inspired by the recent thread re. modifying data/type/newtype syntax, I've > made a wiki article dedicated to Haskell-related nitpicks. I've added a few > entries; one from the thread I just mentioned, and a classic from way back > in the 90s (map vs fmap). > > https://wiki.haskell.org/Nitpicks > > Hopefully, this page will help us keep track of what people are annoyed > about (especially people who aren't already inured to the quirks of > Haskell) as well as give us inspiration for future proposals. > > Cheers, > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.blanck at gmail.com Thu Aug 20 14:51:16 2015 From: jens.blanck at gmail.com (Jens Blanck) Date: Thu, 20 Aug 2015 14:51:16 +0000 Subject: [Haskell-cafe] Problem parallelising simple algorithm In-Reply-To: References: Message-ID: So, I tried to use the Par monad instead of the Eval monad (only splitting the work into two parts, see below). I now get (with 1 and 4 cores): TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.001s elapsed) MUT time 0.994s ( 0.998s elapsed) GC time 0.048s ( 0.051s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 1.042s ( 1.050s elapsed) ------------ TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.001s elapsed) MUT time 1.083s ( 0.922s elapsed) GC time 0.116s ( 0.038s elapsed) EXIT time 0.001s ( 0.000s elapsed) Total time 1.200s ( 0.961s elapsed) So, some slight gain, but not a lot. Admittedly, the call to fromRational seems to take a good chunk of time. Any comments? Jens --------------- import Control.Monad.Par hiding (parMap) import Data.Ratio pqCombine :: (Integer, Integer) -> (Integer, Integer) -> (Integer, Integer) pqCombine (pl, ql) (pr, qr) = (pl*qr+pr, ql*qr) pq :: (Integer, Integer) -> (Integer, Integer) pq (a, b) | d > 5 = let m = (a+b+1) `div` 2 pql = pq (a, m) pqr = pq (m, b) in pqCombine pql pqr | otherwise = (sum $ scanl1 (*) [b,b-1..a+1], product [a+1..b]) where d = b - a main = print . flip seq () . (\(p,q) -> fromRational (p%q)) . runPar $ do i <- new j <- new fork (put i (pq (0,160000))) fork (put j (pq (160000,320000))) a <- get i b <- get j return (pqCombine a b) On Fri, 14 Aug 2015 at 10:31 Jens Blanck wrote: > The following code simply computes the Euler constant by binary > splitting. I'm struggling to get any speed-up on multi-core. > > Why do I get a fair number of fizzled? > Why don't I get any real speed-up even if it claims to run tasks in > parallel? > > Could I have exhausted the integer arithmetic unit(s) on my chip > (i7-4790)? > How would I verify that? > > The following is the code and typical runs on 1 and 4 cores respectively. > > --------- > > import Control.Parallel.Strategies > import Control.DeepSeq > > import Data.Ratio > > divConq :: (NFData b) => (a -> b) > -> a > -> (a -> Bool) > -> (b -> b -> b) > -> (a -> Maybe (a,a)) > -> b > divConq f arg threshold conquer divide = go arg > where > go arg = > case divide arg of > Nothing -> f arg > Just (l0,r0) -> conquer l1 r1 `using` strat > where > l1 = go l0 > r1 = go r0 > strat x = do r l1; r r1; return x > where r | threshold arg = rdeepseq > | otherwise = rpar > > pqCombine :: (Integer, Integer) -> (Integer, Integer) -> (Integer, Integer) > pqCombine (pl, ql) (pr, qr) = (pl*qr+pr, ql*qr) > > pq :: (Integer, Integer) -> (Integer, Integer) > pq (a, b) = (\t -> (sum t, last t)) $ scanl1 (*) [b,b-1..a+1] > > euler :: Integer -> Rational > euler n = > let (p,q) = divConq pq > (0,n) > (\(a,b) -> b-a < 10000) > pqCombine > (\(a,b) -> if b-a > 5 > then let m = (a+b+1) `div` 2 in Just > ((a,m), (m, b)) > else Nothing) > in p%q > > main = print $ euler 320000 `seq` () > > ---------- > > > ./BinSplit +RTS -s -N1 > () > 178,375,880 bytes allocated in the heap > 2,452,040 bytes copied during GC > 3,222,696 bytes maximum residency (7 sample(s)) > 883,040 bytes maximum slop > 11 MB total memory in use (2 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 333 colls, 0 par 0.004s 0.002s 0.0000s > 0.0000s > Gen 1 7 colls, 0 par 0.001s 0.001s 0.0001s > 0.0003s > > TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) > > SPARKS: 126 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 126 fizzled) > > INIT time 0.001s ( 0.000s elapsed) > MUT time 0.928s ( 0.936s elapsed) > GC time 0.005s ( 0.003s elapsed) > EXIT time 0.001s ( 0.000s elapsed) > Total time 0.935s ( 0.939s elapsed) > > Alloc rate 192,215,387 bytes per MUT second > > Productivity 99.4% of total user, 98.9% of total elapsed > > gc_alloc_block_sync: 0 > whitehole_spin: 0 > gen[0].sync: 0 > gen[1].sync: 0 > > > > > ./BinSplit +RTS -s -N4 > () > 178,727,480 bytes allocated in the heap > 3,506,488 bytes copied during GC > 3,650,032 bytes maximum residency (7 sample(s)) > 934,976 bytes maximum slop > 12 MB total memory in use (1 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 141 colls, 141 par 0.009s 0.002s 0.0000s > 0.0001s > Gen 1 7 colls, 6 par 0.003s 0.001s 0.0001s > 0.0001s > > Parallel GC work balance: 38.80% (serial 0%, perfect 100%) > > TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4) > > SPARKS: 126 (12 converted, 0 overflowed, 0 dud, 0 GC'd, 114 fizzled) > > INIT time 0.002s ( 0.002s elapsed) > MUT time 2.104s ( 0.946s elapsed) > GC time 0.012s ( 0.003s elapsed) > EXIT time 0.001s ( 0.000s elapsed) > Total time 2.119s ( 0.951s elapsed) > > Alloc rate 84,946,520 bytes per MUT second > > Productivity 99.3% of total user, 221.3% of total elapsed > > gc_alloc_block_sync: 600 > whitehole_spin: 0 > gen[0].sync: 9 > gen[1].sync: 1073 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From defigueiredo at ucdavis.edu Thu Aug 20 15:33:16 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Thu, 20 Aug 2015 09:33:16 -0600 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: References: Message-ID: <55D5F33C.8020201@ucdavis.edu> Should there be a similar place for tooling and libraries? Those are not part of the language but can significantly change one's experience while coding in Haskell. One of my nitpicks (or rough edges) is that QuickCheck fails by letting all tests pass when you mistakenly provide polymorphic type signatures. This is definitely not safe default behavior, especially for security testing. Cheers, Dimitri Em 19/08/15 23:30, William Yager escreveu: > Hello all, > > Inspired by the recent thread re. modifying data/type/newtype syntax, > I've made a wiki article dedicated to Haskell-related nitpicks. I've > added a few entries; one from the thread I just mentioned, and a > classic from way back in the 90s (map vs fmap). > > https://wiki.haskell.org/Nitpicks > > Hopefully, this page will help us keep track of what people are > annoyed about (especially people who aren't already inured to the > quirks of Haskell) as well as give us inspiration for future proposals. > > Cheers, > Will > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Thu Aug 20 16:13:21 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Thu, 20 Aug 2015 18:13:21 +0200 Subject: [Haskell-cafe] List of nitpicks Message-ID: <55D5FCA1.6050302@htwk-leipzig.de> > Should there be a similar place for tooling and libraries? a Gargantuan task > QuickCheck fails by letting all tests pass > when you mistakenly provide polymorphic type signatures. No! Prelude Test.QuickCheck> quickCheck $ ( (\ x -> 1 > 9) :: a -> Bool) *** Failed! Falsifiable (after 1 test): () I think you mean "defaults everything to () and thus runs polymorphic tests at unexpected types" Prelude Test.QuickCheck> quickCheck $ ( (\ xs -> xs == reverse xs ) :: Eq a => [a] -> Bool) +++ OK, passed 100 tests. - J.W. From defigueiredo at ucdavis.edu Thu Aug 20 17:07:16 2015 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Thu, 20 Aug 2015 11:07:16 -0600 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: <55D5FCA1.6050302@htwk-leipzig.de> References: <55D5FCA1.6050302@htwk-leipzig.de> Message-ID: <55D60944.9000601@ucdavis.edu> Em 20/08/15 10:13, Johannes Waldmann escreveu: >> Should there be a similar place for tooling and libraries? > a Gargantuan task > > >> QuickCheck fails by letting all tests pass >> when you mistakenly provide polymorphic type signatures. > No! > > > Prelude Test.QuickCheck> quickCheck $ ( (\ x -> 1 > 9) :: a -> Bool) > *** Failed! Falsifiable (after 1 test): > () > > > I think you mean "defaults everything to () > and thus runs polymorphic tests at unexpected types" Exactly, but if you are testing with positive tests (which I find to be the common case and what you want in security testing), that usually means all the tests pass. > Prelude Test.QuickCheck> quickCheck $ ( (\ xs -> xs == reverse xs ) :: > Eq a => [a] -> Bool) > +++ OK, passed 100 tests. > > > - J.W. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From michael at schmong.org Thu Aug 20 20:30:30 2015 From: michael at schmong.org (Michael Litchard) Date: Thu, 20 Aug 2015 13:30:30 -0700 Subject: [Haskell-cafe] octree implementation - followup to "How to model outer space for a MUD" Message-ID: It looks like Octree is what I want if I can solve a particular problem. First let me articulate what I am looking for. (1) Objects in 3-d space with no spatial extent. Collision is determined by two objects occupying the same point.' (2) Efficient insert-delete-update #2 seems to be the problem. I found this library, thankfully. I believe it's exactly what I am looking for, but for quadtrees. https://github.com/AshleyMoni/QuadTree I'm a little overwhelmed as this is a new data structure for me. I believe if I can grok what is going on in this library, I can take these ideas and extend them to the octree. I'm referring specifically to this module https://github.com/AshleyMoni/QuadTree/blob/master/Data/QuadTree/Internal.hs And these functions setLocation :: Eq a => Location -> a -> QuadTree a -> QuadTree a setLocation = set . atLocation atLocation (Having difficulty cutting and pasting this to mail.) I'd like to be able to visualize how the tree is being compressed, it may help to be able to see what happens to the tree when it's not compressed. Does anyone have a pointer or advice in how to break this library down in parts to help me grok, in a way that will help me extend to octree? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Thu Aug 20 20:41:01 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Thu, 20 Aug 2015 13:41:01 -0700 Subject: [Haskell-cafe] octree implementation - followup to "How to model outer space for a MUD" In-Reply-To: References: Message-ID: Are you already familiar with lenses? From a glance at the code you linked, it will be hard to understand what's going on unless you are. Personally, my advice is to implement a simple, limited quadtree yourself. The first part of "Functional Programming with QuadTrees"[1] is basically a tutorial on quadtrees with code in Miranda?eminently readable for Haskellers. That's where I would start: write up the code from their examples in Haskell, play around with it and add an extra function or two to understand what's going on. Once you have an intuition for the underlying ideas, you can expand it to octtrees and more complex operations. [1]: http://conal.net/papers/warren-burton/Functional%20Programming%20and%20Quadtrees.pdf On Thu, Aug 20, 2015 at 1:30 PM, Michael Litchard wrote: > It looks like Octree is what I want if I can solve a particular problem. > First let me articulate what I am looking for. > > (1) Objects in 3-d space with no spatial extent. Collision is determined > by two objects occupying the same point.' > > (2) Efficient insert-delete-update > > #2 seems to be the problem. I found this library, thankfully. I believe > it's exactly what I am looking for, but for quadtrees. > > https://github.com/AshleyMoni/QuadTree > > I'm a little overwhelmed as this is a new data structure for me. I believe > if I can grok what is going on in this library, I can take these ideas and > extend them to the octree. I'm referring specifically to this module > > > https://github.com/AshleyMoni/QuadTree/blob/master/Data/QuadTree/Internal.hs > > And these functions > > setLocation :: Eq a => Location -> a -> QuadTree a -> QuadTree a > setLocation = set . atLocation > > atLocation (Having difficulty cutting and pasting this to mail.) > > I'd like to be able to visualize how the tree is being compressed, it may > help to be able to see what happens to the tree when it's not compressed. > > Does anyone have a pointer or advice in how to break this library down in > parts to help me grok, in a way that will help me extend to octree? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikesteele81 at gmail.com Thu Aug 20 20:50:19 2015 From: mikesteele81 at gmail.com (Michael Steele) Date: Thu, 20 Aug 2015 13:50:19 -0700 Subject: [Haskell-cafe] octree implementation - followup to "How to model outer space for a MUD" In-Reply-To: References: Message-ID: Michael, In case your interested in another example, there's also a quadtree in the "gloss-algorithms" [1] package. [1]: http://hackage.haskell.org/package/gloss-algorithms On Thu, Aug 20, 2015 at 1:41 PM, Tikhon Jelvis wrote: > Are you already familiar with lenses? From a glance at the code you > linked, it will be hard to understand what's going on unless you are. > > Personally, my advice is to implement a simple, limited quadtree yourself. > The first part of "Functional Programming with QuadTrees"[1] is basically a > tutorial on quadtrees with code in Miranda?eminently readable for > Haskellers. That's where I would start: write up the code from their > examples in Haskell, play around with it and add an extra function or two > to understand what's going on. > > Once you have an intuition for the underlying ideas, you can expand it to > octtrees and more complex operations. > > [1]: > http://conal.net/papers/warren-burton/Functional%20Programming%20and%20Quadtrees.pdf > > On Thu, Aug 20, 2015 at 1:30 PM, Michael Litchard > wrote: > >> It looks like Octree is what I want if I can solve a particular problem. >> First let me articulate what I am looking for. >> >> (1) Objects in 3-d space with no spatial extent. Collision is determined >> by two objects occupying the same point.' >> >> (2) Efficient insert-delete-update >> >> #2 seems to be the problem. I found this library, thankfully. I believe >> it's exactly what I am looking for, but for quadtrees. >> >> https://github.com/AshleyMoni/QuadTree >> >> I'm a little overwhelmed as this is a new data structure for me. I >> believe if I can grok what is going on in this library, I can take these >> ideas and extend them to the octree. I'm referring specifically to this >> module >> >> >> https://github.com/AshleyMoni/QuadTree/blob/master/Data/QuadTree/Internal.hs >> >> And these functions >> >> setLocation :: Eq a => Location -> a -> QuadTree a -> QuadTree a >> setLocation = set . atLocation >> >> atLocation (Having difficulty cutting and pasting this to mail.) >> >> I'd like to be able to visualize how the tree is being compressed, it may >> help to be able to see what happens to the tree when it's not compressed. >> >> Does anyone have a pointer or advice in how to break this library down in >> parts to help me grok, in a way that will help me extend to octree? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- -- Michael Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at schmong.org Thu Aug 20 21:00:31 2015 From: michael at schmong.org (Michael Litchard) Date: Thu, 20 Aug 2015 14:00:31 -0700 Subject: [Haskell-cafe] octree implementation - followup to "How to model outer space for a MUD" In-Reply-To: References: Message-ID: Perfect, thanks to you both. On Thu, Aug 20, 2015 at 1:50 PM, Michael Steele wrote: > Michael, > > In case your interested in another example, there's also a quadtree in the > "gloss-algorithms" [1] package. > > [1]: http://hackage.haskell.org/package/gloss-algorithms > > On Thu, Aug 20, 2015 at 1:41 PM, Tikhon Jelvis wrote: > >> Are you already familiar with lenses? From a glance at the code you >> linked, it will be hard to understand what's going on unless you are. >> >> Personally, my advice is to implement a simple, limited quadtree >> yourself. The first part of "Functional Programming with QuadTrees"[1] is >> basically a tutorial on quadtrees with code in Miranda?eminently readable >> for Haskellers. That's where I would start: write up the code from their >> examples in Haskell, play around with it and add an extra function or two >> to understand what's going on. >> >> Once you have an intuition for the underlying ideas, you can expand it to >> octtrees and more complex operations. >> >> [1]: >> http://conal.net/papers/warren-burton/Functional%20Programming%20and%20Quadtrees.pdf >> >> On Thu, Aug 20, 2015 at 1:30 PM, Michael Litchard >> wrote: >> >>> It looks like Octree is what I want if I can solve a particular problem. >>> First let me articulate what I am looking for. >>> >>> (1) Objects in 3-d space with no spatial extent. Collision is determined >>> by two objects occupying the same point.' >>> >>> (2) Efficient insert-delete-update >>> >>> #2 seems to be the problem. I found this library, thankfully. I believe >>> it's exactly what I am looking for, but for quadtrees. >>> >>> https://github.com/AshleyMoni/QuadTree >>> >>> I'm a little overwhelmed as this is a new data structure for me. I >>> believe if I can grok what is going on in this library, I can take these >>> ideas and extend them to the octree. I'm referring specifically to this >>> module >>> >>> >>> https://github.com/AshleyMoni/QuadTree/blob/master/Data/QuadTree/Internal.hs >>> >>> And these functions >>> >>> setLocation :: Eq a => Location -> a -> QuadTree a -> QuadTree a >>> setLocation = set . atLocation >>> >>> atLocation (Having difficulty cutting and pasting this to mail.) >>> >>> I'd like to be able to visualize how the tree is being compressed, it >>> may help to be able to see what happens to the tree when it's not >>> compressed. >>> >>> Does anyone have a pointer or advice in how to break this library down >>> in parts to help me grok, in a way that will help me extend to octree? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > -- Michael Steele > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Thu Aug 20 21:23:39 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Thu, 20 Aug 2015 23:23:39 +0200 Subject: [Haskell-cafe] ANN: cabal-bounds 1.0.0 Message-ID: <20150820212339.GA28896@machine> cabal-bounds[1] is a command line programm for managing the bounds/versions of the dependencies in a cabal file. Changes for 1.0.0 ================= * automatically find the cabal and setup-config files * ignore the base library by default Perhaps the two most relevant use cases: Initialize Bounds ================= If you have started a new project, created a cabal file, added dependencies to it, build it, and now want to set the lower and upper bounds of the dependencies according to the currently used versions of the build, then you can just call: $> cabal-bounds update This call will update the bounds of the dependencies of the cabal file in the working directory. Raise the Upper Bounds ====================== If you have several cabalized projects, then it can be quite time consuming to keep the bounds of your dependencies up to date. Especially if you're following the [package versioning policy](), then you want to raise your upper bounds from time to time, to allow the building with newer versions of the dependencies. `cabal-bounds` tries to automate this update process to some degree. So a typical update process might look like: # update the version infos of all libraries $> cabal update # drops the upper bound of all dependencies of the cabal file in the working directory $> cabal-bounds drop --upper # create a cabal sandbox for building your project, this ensures that you're really using # the newest available versions of the dependencies, otherwise you would be constraint # to the already installed versions $> cabal sandbox init # build your project $> cabal install # update the upper bound of all dependencies of the cabal file in the working directory $> cabal-bounds update --upper Please consult the README for further informations. [1] https://github.com/dan-t/cabal-bounds From jeffbrown.the at gmail.com Thu Aug 20 23:13:26 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 20 Aug 2015 16:13:26 -0700 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <419CED05-0567-4363-BC5E-A04863B08E33@gmail.com> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <0EB2F628-9032-4040-B81B-5EECEB4E9C62@cs.otago.ac.nz> <419CED05-0567-4363-BC5E-A04863B08E33@gmail.com> Message-ID: Anybody who comes acros "data _ = _" and feels entitled to understand it before looking up the data keyword is being too lazy. On Wed, Aug 19, 2015 at 1:09 AM, Alexey Muranov wrote: > On 18 ao?t 2015, at 08:16, Richard A. O'Keefe wrote: > > > If you want to argue about the grammar of 'data' declarations, > > go right ahead. I myself was a little confused by them at > > the beginning, because the declare a new type and some > > constructors, but do not declare 'data' in the sense that a > > DATA statement in BASIC or Fortran or the DATA DIVISION in > > COBOL does. The word 'data' is so very far from conveying > > the idea "introduce a new type" that it's not funny. > > Ok, then, just hypothetically (i do not want to argue about actually > introducing it), how about > > type Name = String > type Date ::= Date Int Int Int > type Anniversary ::= Birthday Name Date | Wedding Name Name Date > > instead of > > type Name = String > data Date = Date Int Int Int > data Anniversary = Birthday Name Date | Wedding Name Name Date > > ? > > Alexey. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Thu Aug 20 23:47:51 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Fri, 21 Aug 2015 00:47:51 +0100 Subject: [Haskell-cafe] Reactive config file generation In-Reply-To: References: Message-ID: Hi Heinrich (and other helpful souls), Thanks for the replies. I started out this response with an attempt to give more detail in the hope of explaining why I thought this was rather more complicated than it first appears: at least, applying a new config is expensive so idempotence isn't very helpful. However, in the process of writing this I came to the conclusion that there is a rather simple, if slightly inelegant solution. I can write some code which generates the initial config and also logs what nodes in ZK were read or enumerated; by keeping this log I can watch for updates and if anything is updated then I can re-generate the whole config, compare it for equality against the previous config, and apply the new config if needs be. I call this slightly inelegant because I was kind of hoping to be able to re-run just the part of the config-generation function that was downstream of the update that fired. On reflection, this seems unnecessarily frugal - these are not large configs I'm dealing with, so not worth much effort to cut out the extra computation. I suppose this is in some sense a poor-man FRP? But it'll do for me and does seem rather simple. Many thanks, David On 19 August 2015 at 17:12, Heinrich Apfelmus wrote: > Hello David, > > author of the FRP library "reactive-banana"[1] here. > > Well, you can certainly use FRP in this context, but your situation seems > so simple that I'm not sure if it's worth it here. The way I see FRP is > that it helps you deal with time-varying state in a way that does not lead > to spaghetti code. The fundamental insight is a semantic one, but on the > practical side, FRP simplifies change propagation and reasoning about the > order of changes. > > Your situation looks like you do not have to keep track of state, i.e. > most of your operations seem to be pure or idempotent, so while FRP won't > hurt it, it won't make your life significantly easier either. > > > On the question of choosing a library, I would, of course, recommend > "reactive-banana", but I may be a little biased there. :) I can also > recommend "sodium" [2], which is very similar. There are also two very > recent offerings, "reflex" [3] and "frpnow" [4]. I don't know much about > the former. The latter has a nice theory background, but seems to be > pull-based. > > > Best regards, > Heinrich Apfelmus > > [1]: https://wiki.haskell.org/Reactive-banana > [2]: https://hackage.haskell.org/package/sodium > [3]: https://hackage.haskell.org/package/reflex > [4]: https://hackage.haskell.org/package/frpnow > > -- > http://apfelmus.nfshost.com > > > David Turner wrote: > >> Hi all, >> >> I am using Apache Zookeeper as a service directory: I have a bunch of >> services which announce their presence by making nodes in Zookeeper, so >> that dependent services can update their configuration to make use of the >> available services, and stop trying to use services that have died. >> >> Zookeeper is a pretty nice fit for this because it supports watching a >> node >> for changes, so in theory there is no need to poll Zookeeper periodically. >> The services that I control work with this just fine, but there are some >> (e.g. an Nginx reverse-proxy) that are reconfigured using the rather more >> common approach of updating a file (or files) and then sending the process >> a signal. I am currently pondering how to make this work without polling, >> or manually triggering a refresh script, which is how it is currently >> done. >> >> I've never used FRP, but am at least vaguely aware of it and from my >> high-level understanding it seems like this could be a very good fit. The >> Zookeeper state is a time-varying value which I want to convert into a >> time-varying set of files, ideally as declaratively as possible. >> >> So, two questions to the FRP congnoscenti out there. Firstly, is it >> worthwhile to attempt this using FRP at all? I'm sure I could do it by >> hand >> too. Secondly, which of the many FRP libraries would you recommend for it? >> There are loads on the Wiki, seemingly in various states of repair and >> documentation. Any pointers on how to choose one that's featureful enough, >> performant enough, and being actively maintained? >> >> Thanks in advance, >> >> David >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Fri Aug 21 08:26:57 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 21 Aug 2015 11:26:57 +0300 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: <55D60944.9000601@ucdavis.edu> References: <55D5FCA1.6050302@htwk-leipzig.de> <55D60944.9000601@ucdavis.edu> Message-ID: <55D6E0D1.3080407@ro-che.info> On 20/08/15 20:07, Dimitri DeFigueiredo wrote: > Em 20/08/15 10:13, Johannes Waldmann escreveu: >>> Should there be a similar place for tooling and libraries? >> a Gargantuan task >> >> >>> QuickCheck fails by letting all tests pass >>> when you mistakenly provide polymorphic type signatures. >> No! >> >> >> Prelude Test.QuickCheck> quickCheck $ ( (\ x -> 1 > 9) :: a -> Bool) >> *** Failed! Falsifiable (after 1 test): >> () >> >> >> I think you mean "defaults everything to () >> and thus runs polymorphic tests at unexpected types" > Exactly, but if you are testing with positive tests (which I find to be > the common case and what you want in security testing), that usually > means all the tests pass. > >> Prelude Test.QuickCheck> quickCheck $ ( (\ xs -> xs == reverse xs ) :: >> Eq a => [a] -> Bool) >> +++ OK, passed 100 tests. This can be solved, by the way: https://ro-che.info/articles/2013-02-19-smallcheck#required-type-annotations -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rustompmody at gmail.com Fri Aug 21 16:56:47 2015 From: rustompmody at gmail.com (Rustom Mody) Date: Fri, 21 Aug 2015 22:26:47 +0530 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: On Sat, Aug 8, 2015 at 4:39 PM, Alexey Muranov wrote: > Hello, > > i would like to suggest an idea for modifying the basic data/newtype > syntax in Haskell: replace the equality sign `=` with `::=`. > > When i started learning Haskell, the most confusing part of the syntax for > me was the equality sign in `data` definition. I could not even guess what > the `data` definition meant without reading a chapter or two about types in > Haskell, and i think it was partially due to the equality sign. I still > find this notation inconsistent with other uses of the equality sign in > Haskell and in general. > > For example, in > > type Name = String > data Date = Date Int Int Int > data Anniversary = Birthday Name Date | Wedding Name Name Date > > the second line is particularly disorienting IMO because on two sides of > the equality, `Date` denotes different things. > > As far as i understand, in all contexts except those of `data` and > `newtype` definitions, the equality sign in Haskell denotes the actual > equality for all purposes: if a line > > foo x y = bar y x > > is present in a program, `foo a b` and `bar b a` can be used more or less > interchangeably elsewhere in the program. Similarly, if the line > > type Name = String > > is present, `Name` can be used as `String`. Clearly, the equality in > > data Date = Date Int Int Int > > does not have such property. > > I think that if `::=` was used instead of `=` in `data` and `newtype` > definitions, this would suggest to a newcomer that the syntax of the two > sides might be different, and would helpfully remind of the Backus?Naur > Form for syntax rules. I think that a newcomer to Haskell, like myself, > would have had a better chance of guessing the meaning of > > type Name = String > data Date ::= Date Int Int Int > data Anniversary ::= Birthday Name Date | Wedding Name Name Date > > IMO this would make the program easier to read in general and the > difference between `type` and `newtype` more clear. Maybe the can even > make the use of keywords redundant, by allowing to write simply > > Name = String > Date ::= Date Int Int Int > Anniversary ::= Birthday Name Date | Wedding Name Name Date > > What do you think? > I taught functional programming (with gofer) some decades ago. I found some of your points (and some more) slowed down students sufficiently that making small changes in gofer was worth the effort My changes are described here http://www.the-magus.in/Publications/notation.pdf The appendix at end summarises the changes. Note that the ctype keyword (concrete-type) as replacement for 'data' predates GADT by about a decade though I came to it from a pedagogy not a generality angle If someone wants to try it, this modified gofer is at https://github.com/rusimody/gofer Note: I am really not entering the debate that Haskell should be changed Regards Rusi -- http://www.the-magus.in http://blog.languager.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Fri Aug 21 17:40:24 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sat, 22 Aug 2015 00:40:24 +0700 Subject: [Haskell-cafe] Haskell Weekly News Message-ID: *Top picks:* - Gabriel Gonzalez evaluates Haskell in the style of a State-of-the-Union address. He rates Haskell from Immature to Mature to Best-in-class under 28 headings, the first four being *Compilers,* *Server-side web programming,* *Scripting / Command-line applications,* and *Numerical programming.* He also recommends libraries and tutorials under each heading. Reverberations on Hacker News and /r/haskell . - Challenged over claims of FP productivity improvement, Douglas M. Auclair rattles off success stories from his previous work at various subsidiaries of the US Federal Gov fending for the taxpayer to the tune of billions of dollars. Nibbles of interest on Hacker News . - Aaron Wolf goes from zero programming directly to Haskell and writes of his experience. His favorite learning resource is the Haskell Wikibook , which he can improve as he reads. He is co-founder of Snowdrift.coop, a crowdfunding platform for freely-licensed works . The Haskell Reddit finds Aaron's testimony a change from the "Haskell is too hard for me" meme. - The season of introspection continues. On the heels of Hu, Hughes, and Wang on "How Functional Programming Mattered" (see previous HWN ); Michael Green, Kathleen Fisher, and David Walker track the ebb and flow of research topics in the conference proceedings of the Big Four: Principles of PL (POPL), PL Design and Implementation (PLDI), International Conference on FP (ICFP); and OOP, Systems, Languages, Apps (OOPSLA). No mention of Haskell but if you're looking for a brief history of PL research -- the slides are even more succinct -- this is the only data-driven survey you'll find. - Doug Beardsley reminds us that date-based version inference cannot replace the role of explicit version upper bounds. The reason? The package developer might not be using the latest version of its dependencies on the day they publish the work. Also, among the 72 comments of the /r/haskell convo , Doug observes that Stackage over-conservatively locks to a single version, whereas community-wide adherence to the Package Versioning Policy (PVP) of original hackage yields seamless delivery of bugfixes and improvements. - In less than a week, Xmonad will lose its issue tracking system. On Aug 24, Google Code goes read-only . Community heroes Brandon Allbery and Daniel Wagner work at grabbing a backup of the issues. Still no consensus over what and where to migrate to. - Mark Dominus delves into the bits and bytes of the 1999 Cosmic Call attempt by astrophysicists to contact aliens. He shows the visual bitmaps transmitted into space. Brent Yorgey writes to say he enjoys the 23-part series interspersed with little puzzles. *Quotes of the Week:* - Doug McIlroy : Conditional compilation is admitting defeat. - /u/kamatsu : I feel like the reason people find Haskell an eye-opening experience is because their CS education was deficient. - @wfaler : Is there a club to join when you silently sob at having to give your Monad Transformers Monad Transformers? Sounds a lot like #EnterpriseFP -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaumh at gmail.com Fri Aug 21 18:58:23 2015 From: guillaumh at gmail.com (Guillaume Hoffmann) Date: Fri, 21 Aug 2015 15:58:23 -0300 Subject: [Haskell-cafe] Darcs Hacking Sprint #9 (September 18th-20th, Paris) Message-ID: Dear Hackers the next Darcs Sprint that will be in Paris, on September 18-20 at IRILL (near Place d'Italie). Please check out the details at: http://darcs.net/Sprints/2015-09 Here are three things to know 1. Everybody is welcome to join us. We'd love to have you, whatever your Haskell or Darcs hacking experience. Also, if you've got a wacky idea for the future of version control, or a cool use for the Darcs library, you should join us too :-) 2. Please let us know if you're attending. Just add your name to http://wiki.darcs.net/Sprints/2015-09 and you're good to go. You can also send us an email. 3. We can reimburse travel costs (within reason!). Let us know if you'd like a reimbursement, and save your receipts. Many thanks to everybody who participated in our fundraising drives or who gave money on the side. Thanks also to the Software Freedom Conservancy for making fundraising and reimbursements so painless! If you can't join us in person, but you'd like to cheer us on, say hello at http://darcs.net/Donations ! see you in one month! Guillaume From johannes.waldmann at htwk-leipzig.de Sat Aug 22 10:23:51 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Sat, 22 Aug 2015 12:23:51 +0200 Subject: [Haskell-cafe] List of nitpicks Message-ID: <55D84DB7.1070002@htwk-leipzig.de> >> quickCheck $ ( (\ xs -> xs == reverse xs ) :: Eq a => [a] -> Bool) > This can be solved, by the way: > https://ro-che.info/articles/2013-02-19-smallcheck#required-type-annotations Very good indeed. But (and here's another nit to pick - about ghc) - your > smallCheck 5 $ \x y -> x == (y :: Integer) would look much clearer that way: > smallCheck 5 $ \ (x::Integer) (y :: Integer) -> x == y but ghc complains about missing ScopedTypeVariables and that error message is fully incomprehensible (e.g., to beginning students) as there is no type variable anywhere. There was a PatternSignatures option but it seems gone (deprecated). I believe that (PatternSignatures and) ScopedTypeVariables should be on by default. It is currently off only to help those that are too lazy to write "forall t . " in (inner) declarations? Leaving out quantifiers should never be encouraged. And putting type declarations next to the name declaration (that is, on the "x" under the lambda) should be the normal thing to do. Everything else feels like a work-around, and it is a distraction when teaching. Putting language options at the top of the source file, or in .ghci, is also a distraction. - J.W. From johannes.waldmann at htwk-leipzig.de Sat Aug 22 11:12:26 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Sat, 22 Aug 2015 13:12:26 +0200 Subject: [Haskell-cafe] HAL-10 (preliminary announcement) Message-ID: <55D8591A.5000703@htwk-leipzig.de> Dear all, > ... this year's Haskell in Leipzig I have been busy with many other things, so there are no concrete plans right now. But I think we should do it, and I am willing to host it at my institution. So - how about December 4/5 (Friday noon - Saturday noon)? (it is easier to get lecture rooms on the week-end) If you have comments or suggestions for HAL this year, then please email me, or stammtisch at haskell.iba-cg.de , or someone could set up a wiki page somewhere. Let's say we start collecting opinions now, and make a decision and a formal announcement end of September. http://www.imn.htwk-leipzig.de/~waldmann/HAL2015/ - Johannes Waldmann. From allbery.b at gmail.com Sat Aug 22 13:33:06 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 22 Aug 2015 09:33:06 -0400 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: <55D84DB7.1070002@htwk-leipzig.de> References: <55D84DB7.1070002@htwk-leipzig.de> Message-ID: On Sat, Aug 22, 2015 at 6:23 AM, Johannes Waldmann < johannes.waldmann at htwk-leipzig.de> wrote: > I believe that (PatternSignatures and) ScopedTypeVariables > should be on by default. It is currently off only to help those > that are too lazy to write "forall t . " in (inner) declarations? > More because the language committee is ridiculously conservative. I think this is Public Enemy Number One as far as extensions that really ought to be part of the standard by now. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Sat Aug 22 14:31:32 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 22 Aug 2015 16:31:32 +0200 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: References: <55D84DB7.1070002@htwk-leipzig.de> Message-ID: On 08/22/2015 03:33 PM, Brandon Allbery wrote: > On Sat, Aug 22, 2015 at 6:23 AM, Johannes Waldmann < > johannes.waldmann at htwk-leipzig.de> wrote: > >> I believe that (PatternSignatures and) ScopedTypeVariables >> should be on by default. It is currently off only to help those >> that are too lazy to write "forall t . " in (inner) declarations? >> > > More because the language committee is ridiculously conservative. I think > this is Public Enemy Number One as far as extensions that really ought to > be part of the standard by now. > > I can only second that. I seems to me that trying to have the default experience in GHC be some sort of Haskell2010 pseudo-standard is not useful[1]. I happen to believe that standards without more than one serious implementor are a terrible way to move things along. Let's *exploit* the fact that there is only one[2] really viable compiler at this precise moment in time, and move things forward more rapidly! [1] I believe there were some AMP things in base/Prelude which mean that GHC-by-default is not technically Haskell2010. [2] I realize that there's JHC, UHC, etc., but let's face it... unless those compilers implement most of the GHC extensions, then you're not going to get anything substantial (e.g. lens) to compile with those compilers. Regards, From mgajda at mimuw.edu.pl Sun Aug 23 05:09:32 2015 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Sun, 23 Aug 2015 13:09:32 +0800 Subject: [Haskell-cafe] octree implementation - followup to "How to model outer space for a MUD" Message-ID: Hi, And if you search for Octree on Hackage, you would have also found my Octree implementation. It does not do re-balancing, but in this type of application you talk about it may not be needed. http://hackage.haskell.org/package/Octree Funny part, is that implementation may be easier to read than algo description I read first time: http://hackage.haskell.org/package/Octree-0.5.4.2/docs/src/Data-Octree-Internal.html . It worked perfectly for my use cases (checking for collisions of 1000-100000 objects), but (just in case) the initial creation from list structure make the octree balanced. Note that balanced octree is supposed to be much faster than KD-tree, and may be also faster than R-tree in memory, since it is very shallow structure - log_8 between 10k and 1m changes only from below 5 to below 7! I was also very happy with its cache behaviour, although in theory R-tree could be better. I am also extremely interested in making sure that Haskell has a good choice of multidimensional metric data structures, so I am closely following maintenance of kd-tree, Ashley?s, and Gloss? quadtrees. And if you really want to have re-balancing, please contact me on my email. -- Best regards Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From neto at netowork.me Sun Aug 23 20:21:01 2015 From: neto at netowork.me (Ernesto Rodriguez) Date: Sun, 23 Aug 2015 22:21:01 +0200 Subject: [Haskell-cafe] ANN: MicrosoftTranslator-0.1.0.1 Message-ID: Dear Cafe, I needed to translate text in my Haskell code and Microsoft Translator[2] seems to be the easiest and cheapest (free 2M chars/month) way to do it. I wrapped my code in this package[1]. I tried to make it easy to use. If you plan to use Microsoft Translator in Haskell but don't want to use my package, I still recommend you look at my source code since the documentation in Microsoft's page appears to be incorrect (I had to see the source code of the Python package to get it to work). In any case, it is very easy to use: > translate "clientId" "clientSecret" "hello" English German Right "hallo" It is in an early stage and I haven't added most of the languages supported by Microsoft Translator. Pull requests are welcome :) Best Regards, Ernesto Rodriguez [1] http://hackage.haskell.org/package/MicrosoftTranslator-0.1.0.1 [2] https://www.microsoft.com/en-us/translator/default.aspx -- Ernesto Rodriguez Masters Student Computer Science Utrecht University www.netowork.me github.com/netogallo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch.howard at zoho.com Mon Aug 24 05:34:42 2015 From: ch.howard at zoho.com (Christopher Howard) Date: Sun, 23 Aug 2015 21:34:42 -0800 Subject: [Haskell-cafe] Elementary math question: primality test for huge numbers Message-ID: <20150823213442.66323377@nimrodel> Hi. I was working through a math chapter explaining the RSA algorithm, and I was implementing it in Haskell for learning sake. However, the chapter does not explain how you efficiently pick the two prime numbers. I scanned through the WP page on primality tests but it was somewhat overwhelming. What would be the standard primality test for this sort of application, and is it already built in to Base somewhere? -- Biblical creationism: http://tinyurl.com/qfyeg4a Free Bible software: http://xiphos.org Software freedom: http://tinyurl.com/qjnpnsm Free computer operating system: http://tinyurl.com/7wczchu Alternative to MS Office: http://tinyurl.com/aw9p6d4 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From will.yager at gmail.com Mon Aug 24 05:38:57 2015 From: will.yager at gmail.com (William Yager) Date: Mon, 24 Aug 2015 00:38:57 -0500 Subject: [Haskell-cafe] Elementary math question: primality test for huge numbers In-Reply-To: <20150823213442.66323377@nimrodel> References: <20150823213442.66323377@nimrodel> Message-ID: See section 4.4. http://cacr.uwaterloo.ca/hac/about/chap4.pdf --Will Yager On Mon, Aug 24, 2015 at 12:34 AM, Christopher Howard wrote: > Hi. I was working through a math chapter explaining the RSA algorithm, > and I was implementing it in Haskell for learning sake. However, the > chapter does not explain how you efficiently pick the two prime > numbers. I scanned through the WP page on primality tests but it was > somewhat overwhelming. What would be the standard primality test for > this sort of application, and is it already built in to Base somewhere? > > -- > Biblical creationism: http://tinyurl.com/qfyeg4a > Free Bible software: http://xiphos.org > Software freedom: http://tinyurl.com/qjnpnsm > Free computer operating system: http://tinyurl.com/7wczchu > Alternative to MS Office: http://tinyurl.com/aw9p6d4 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Mon Aug 24 07:18:14 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Mon, 24 Aug 2015 17:18:14 +1000 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances Message-ID: Lets say there's a type `T` I've imported from a package I don't control. I can easily write new functions to work on `T`. For example, I could write: f :: T -> T -> T f x y = ... I've extended T's functionality. No need for newtypes. This makes sense. Whilst a newtype in the following case: newtype Time = Time Int because in this case `Time` is conceptually different to `Int`. For example, you shouldn't multiply two `Time`s So in summary, we've just extended T's functionality appropriately, without introducing a newtype. But this could be dangerous. Lets say another module writer writes a similar function "f". Then if someone imports their module and ours, there will be a clash. Fortunately the compiler tells about this when it happens, and we can then use qualified imports to workaround the clash. This I'll get back to later. Now lets say I want to extend T's functionality some more, but this time by making it an instance of class C. Class C already exists in a package I don't control. Now it would be unreasonable for every class writer to write instances for every possible data type that is appropriate for their class. As you can see, it's an O(n^2) problem, so there will undoubtably be situations where one needs to write instances for data types and classes in separate packages. One recommended approach here is to newtype T, like the following: newtype MyT = MyT T however I find this incredibly ugly. Conceptually, there is no "newtype", and now there's different types of Ts bashing around which really are the same thing. Not only that, they're incompatible, for no good reason. Instead of these different Ts being different types because they're conceptually different things that shouldn't be mixed, the type of these objects depends solely on what operations I want to apply to them. Imagine a rule where: f :: T -> T -> T was only legal in the module T was defined. If you wanted to define T anywhere else, you'd have to do: f :: MyT -> MyT -> MyT That's how messy the newtype solution is, it wouldn't be accepted for ordinary functions, and I don't think it's reasonable to apply that messiness to class functions. A second approach is an orphan instance. The recommendation here is to put the orphan instances in their own module, so the user can choose to import them. This may works ok if your user is writing an executable. But what if your user is writing a library themselves. But once, you, or your user, directly uses one of the instances, they need to import it, and they pollute the global instance namespace for anyone that uses their package. This is okay if you're the only person doing it, but I think it's reasonable to say that if your practices would be bad if someone else was doing them also, then they're a bad practice. Indeed, if someone else writes their own instances and they clash with yours, people simply can't use your package and their package in the same program. This is bad. In the simple "function" case. We deal with the clash of two functions named "f" using qualified imports. We can't do that instances, nor can we even hide one of the instances. So to recap here we've tried: (1) Copying the data type. We've decided this has lots of problems. (2) Just making an orphan instance. This has serious problems too. I want to suggest a third option: (3) Copying the class. What would this involve: a) Making a new class (say C1), with the same class methods as the existing one (say C). b) Making an instance of the class like so: instance (C x) => C1 x where f = ModuleC.f ... which forwards all the calls to C. c) Add your new instances to C1 (these will overlap with the above but they will be more specific so with overlapping instances this is allowed). Now if your users want to use your instances, they import C1. They can still use the data type T as usual on the old instances, or on any existing functions defined on T directly. The big question is, what if someone else does this, and creates C2? Then they'll be a clash. But in this case, classes, unlike instances, can be explicitly imported and qualified. Your packages won't be impossible to use together, just the user will have to import one of them qualified. That's acceptable, we understand we have to do this sometimes with clashing function names too. So I guess my questions are: What do you think of my analysis? Are there parts that are incorrect? What do you think of my solution? Is there reasons why it is not as good as the "newtype" or "orphan instances" approach? Is there a way to make my solution easier to implement, i.e. less typing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Mon Aug 24 09:09:44 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 24 Aug 2015 11:09:44 +0200 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: Message-ID: On 24 August 2015 at 09:18, Clinton Mead wrote: > A second approach is an orphan instance. The recommendation here is to put > the orphan instances in their own module, so the user can choose to import > them. > > This may works ok if your user is writing an executable. But what if your > user is writing a library themselves. But once, you, or your user, directly > uses one of the instances, they need to import it, and they pollute the > global instance namespace for anyone that uses their package. For this reason, I think the recommended course of action is to make a canonical place for the instance, so that everyone can use it. For example, if you have a library 'foo' providing T, and a library 'bar' providing C, put the instance in a new package 'foo-bar' (or 'bar-foo'). Then everyone can use that one instance, since Haskell is built on the assumption that every type has one unique instance per class. > I want to suggest a third option: > > (3) Copying the class. This would make a new distinct class, which means you can't call any methods which have the original class as the context (f :: C a => a -> a) since that class won't exist for type T (you are trying to avoid defining that orphan instance). So I don't think this is usable in most cases, unless I'm missing something. Erik From heraldhoi at gmail.com Mon Aug 24 09:32:35 2015 From: heraldhoi at gmail.com (Geraldus) Date: Mon, 24 Aug 2015 09:32:35 +0000 Subject: [Haskell-cafe] getNumCapabilities always returns 1 with GHC 7.10.2 on OS X Message-ID: I have OS X Yosemite 10.10.4. There are two bundles of GHC (from ghcformacosx.github.io): 7.10.1 and 7.10.2. The latter always shows me one core when running `getNumCapabilities` action: *GHC 7.10.2* > stack ghci +RTS -N8 Using resolver: lts-3.0 from global config file: /Users/arthurfayzrakhmanov/.stack/global/stack.yaml Configuring GHCi with the following packages: GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :m +Control.Concurrent Prelude Control.Concurrent> getNumCapabilities 1 *GHC 7.10.1* > /Applications/ghc-7.10.1.app/Contents/bin/ghci +RTS -N8 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :m +Control.Concurrent Prelude Control.Concurrent> getNumCapabilities 8 It looks like a 7.10.2 bug, can some one confirm that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Aug 24 09:36:37 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 24 Aug 2015 12:36:37 +0300 Subject: [Haskell-cafe] getNumCapabilities always returns 1 with GHC 7.10.2 on OS X In-Reply-To: References: Message-ID: It looks like you're sending the RTS options to `stack` in the first one, not to ghci itself. What's the result with `$(stack exec which ghci) +RTS -N8`? On Mon, Aug 24, 2015 at 12:32 PM, Geraldus wrote: > I have OS X Yosemite 10.10.4. There are two bundles of GHC (from > ghcformacosx.github.io): 7.10.1 and 7.10.2. The latter always shows me > one core when running `getNumCapabilities` action: > > *GHC 7.10.2* > > stack ghci +RTS -N8 > Using resolver: lts-3.0 from global config file: > /Users/arthurfayzrakhmanov/.stack/global/stack.yaml > Configuring GHCi with the following packages: > GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help > Prelude> :m +Control.Concurrent > Prelude Control.Concurrent> getNumCapabilities > 1 > > > *GHC 7.10.1* > > /Applications/ghc-7.10.1.app/Contents/bin/ghci +RTS -N8 > GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help > Prelude> :m +Control.Concurrent > Prelude Control.Concurrent> getNumCapabilities > 8 > > It looks like a 7.10.2 bug, can some one confirm that? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Mon Aug 24 09:54:48 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Mon, 24 Aug 2015 19:54:48 +1000 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: Message-ID: The original class still exists, I can't see how making a new class based on the old on affects that. Won't existing functions in modules which import the old class instead of the new class continue to work? On Monday, 24 August 2015, Erik Hesselink wrote: > On 24 August 2015 at 09:18, Clinton Mead > wrote: > > A second approach is an orphan instance. The recommendation here is to > put > > the orphan instances in their own module, so the user can choose to > import > > them. > > > > This may works ok if your user is writing an executable. But what if your > > user is writing a library themselves. But once, you, or your user, > directly > > uses one of the instances, they need to import it, and they pollute the > > global instance namespace for anyone that uses their package. > > For this reason, I think the recommended course of action is to make a > canonical place for the instance, so that everyone can use it. For > example, if you have a library 'foo' providing T, and a library 'bar' > providing C, put the instance in a new package 'foo-bar' (or > 'bar-foo'). Then everyone can use that one instance, since Haskell is > built on the assumption that every type has one unique instance per > class. > > > I want to suggest a third option: > > > > (3) Copying the class. > > This would make a new distinct class, which means you can't call any > methods which have the original class as the context (f :: C a => a -> > a) since that class won't exist for type T (you are trying to avoid > defining that orphan instance). So I don't think this is usable in > most cases, unless I'm missing something. > > Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Mon Aug 24 10:06:52 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 24 Aug 2015 12:06:52 +0200 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: Message-ID: I meant that presumably, there are library functions like 'f :: C a => ...' that you want to use with type T. But copying class C to C2, and only giving an instance C2 T doesn't allow you to do that. Erik On 24 August 2015 at 11:54, Clinton Mead wrote: > The original class still exists, I can't see how making a new class based on > the old on affects that. Won't existing functions in modules which import > the old class instead of the new class continue to work? > > > On Monday, 24 August 2015, Erik Hesselink wrote: >> >> On 24 August 2015 at 09:18, Clinton Mead wrote: >> > A second approach is an orphan instance. The recommendation here is to >> > put >> > the orphan instances in their own module, so the user can choose to >> > import >> > them. >> > >> > This may works ok if your user is writing an executable. But what if >> > your >> > user is writing a library themselves. But once, you, or your user, >> > directly >> > uses one of the instances, they need to import it, and they pollute the >> > global instance namespace for anyone that uses their package. >> >> For this reason, I think the recommended course of action is to make a >> canonical place for the instance, so that everyone can use it. For >> example, if you have a library 'foo' providing T, and a library 'bar' >> providing C, put the instance in a new package 'foo-bar' (or >> 'bar-foo'). Then everyone can use that one instance, since Haskell is >> built on the assumption that every type has one unique instance per >> class. >> >> > I want to suggest a third option: >> > >> > (3) Copying the class. >> >> This would make a new distinct class, which means you can't call any >> methods which have the original class as the context (f :: C a => a -> >> a) since that class won't exist for type T (you are trying to avoid >> defining that orphan instance). So I don't think this is usable in >> most cases, unless I'm missing something. >> >> Erik From miguelimo38 at yandex.ru Mon Aug 24 10:10:37 2015 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Mon, 24 Aug 2015 13:10:37 +0300 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: Message-ID: <828071440411037@web13h.yandex.ru> If, for your data, you create an instance of the new class ? but not the original one, then you can't use all the machinery that expects input being of the old class. Which is the point. 24.08.2015, 12:55, "Clinton Mead" : > The original class still exists, I can't see how making a new class based on the old on affects that. Won't existing functions in modules which import the old class instead of the new class?continue to work? > > On Monday, 24 August 2015, Erik Hesselink wrote: >> On 24 August 2015 at 09:18, Clinton Mead wrote: >>> A second approach is an orphan instance. The recommendation here is to put >>> the orphan instances in their own module, so the user can choose to import >>> them. >>> >>> This may works ok if your user is writing an executable. But what if your >>> user is writing a library themselves. But once, you, or your user, directly >>> uses one of the instances, they need to import it, and they pollute the >>> global instance namespace for anyone that uses their package. >> >> For this reason, I think the recommended course of action is to make a >> canonical place for the instance, so that everyone can use it. For >> example, if you have a library 'foo' providing T, and a library 'bar' >> providing C, put the instance in a new package 'foo-bar' (or >> 'bar-foo'). Then everyone can use that one instance, since Haskell is >> built on the assumption that every type has one unique instance per >> class. >> >>> I want to suggest a third option: >>> >>> (3) Copying the class. >> >> This would make a new distinct class, which means you can't call any >> methods which have the original class as the context (f :: C a => a -> >> a) since that class won't exist for type T (you are trying to avoid >> defining that orphan instance). So I don't think this is usable in >> most cases, unless I'm missing something. >> >> Erik > , > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From heraldhoi at gmail.com Mon Aug 24 10:14:23 2015 From: heraldhoi at gmail.com (Geraldus) Date: Mon, 24 Aug 2015 10:14:23 +0000 Subject: [Haskell-cafe] getNumCapabilities always returns 1 with GHC 7.10.2 on OS X In-Reply-To: References: Message-ID: Ok, now it shows me eight cores. So, I've passed arguments incorrectly, what is the correct way to do this? *(Also, `$(stack exec which ghci) +RTS -N8` does not work with fish shell which I'm using by default, but I tested your suggestion in bash)* ??, 24 ???. 2015 ?. ? 14:37, Michael Snoyman : > It looks like you're sending the RTS options to `stack` in the first one, > not to ghci itself. What's the result with `$(stack exec which ghci) +RTS > -N8`? > > On Mon, Aug 24, 2015 at 12:32 PM, Geraldus wrote: > >> I have OS X Yosemite 10.10.4. There are two bundles of GHC (from >> ghcformacosx.github.io): 7.10.1 and 7.10.2. The latter always shows me >> one core when running `getNumCapabilities` action: >> >> *GHC 7.10.2* >> > stack ghci +RTS -N8 >> Using resolver: lts-3.0 from global config file: >> /Users/arthurfayzrakhmanov/.stack/global/stack.yaml >> Configuring GHCi with the following packages: >> GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help >> Prelude> :m +Control.Concurrent >> Prelude Control.Concurrent> getNumCapabilities >> 1 >> >> >> *GHC 7.10.1* >> > /Applications/ghc-7.10.1.app/Contents/bin/ghci +RTS -N8 >> GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help >> Prelude> :m +Control.Concurrent >> Prelude Control.Concurrent> getNumCapabilities >> 8 >> >> It looks like a 7.10.2 bug, can some one confirm that? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Aug 24 10:18:36 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 24 Aug 2015 13:18:36 +0300 Subject: [Haskell-cafe] getNumCapabilities always returns 1 with GHC 7.10.2 on OS X In-Reply-To: References: Message-ID: How about --ghc-options: stack ghci --ghc-options "+RTS -N8 -RTS" On Mon, Aug 24, 2015 at 1:14 PM, Geraldus wrote: > Ok, now it shows me eight cores. So, I've passed arguments incorrectly, > what is the correct way to do this? > > *(Also, `$(stack exec which ghci) +RTS -N8` does not work with fish shell > which I'm using by default, but I tested your suggestion in bash)* > > ??, 24 ???. 2015 ?. ? 14:37, Michael Snoyman : > >> It looks like you're sending the RTS options to `stack` in the first one, >> not to ghci itself. What's the result with `$(stack exec which ghci) +RTS >> -N8`? >> >> On Mon, Aug 24, 2015 at 12:32 PM, Geraldus wrote: >> >>> I have OS X Yosemite 10.10.4. There are two bundles of GHC (from >>> ghcformacosx.github.io): 7.10.1 and 7.10.2. The latter always shows me >>> one core when running `getNumCapabilities` action: >>> >>> *GHC 7.10.2* >>> > stack ghci +RTS -N8 >>> Using resolver: lts-3.0 from global config file: >>> /Users/arthurfayzrakhmanov/.stack/global/stack.yaml >>> Configuring GHCi with the following packages: >>> GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help >>> Prelude> :m +Control.Concurrent >>> Prelude Control.Concurrent> getNumCapabilities >>> 1 >>> >>> >>> *GHC 7.10.1* >>> > /Applications/ghc-7.10.1.app/Contents/bin/ghci +RTS -N8 >>> GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help >>> Prelude> :m +Control.Concurrent >>> Prelude Control.Concurrent> getNumCapabilities >>> 8 >>> >>> It looks like a 7.10.2 bug, can some one confirm that? >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Mon Aug 24 10:28:51 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Mon, 24 Aug 2015 20:28:51 +1000 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: <828071440411037@web13h.yandex.ru> References: <828071440411037@web13h.yandex.ru> Message-ID: There's no new data. Class C already exists in another package. Data T already exists in another different package. The options are: a) Create a newtype MyT and an instance MyT of C. b) Just create an orphan instance T of C. c) Create a new class C1, forward its implementation to C, and add an instance T of C1. I'm suggesting (c) is best, but I haven't seen this elsewhere, the debate is usually between (a) and (b). I don't really understand the problems you're proposing with (c), but I'm not sure if that's because I'm misunderstanding you or I'm not explaining myself well. On Monday, 24 August 2015, Miguel Mitrofanov wrote: > If, for your data, you create an instance of the new class ? but not the > original one, then you can't use all the machinery that expects input being > of the old class. Which is the point. > > 24.08.2015, 12:55, "Clinton Mead" >: > > The original class still exists, I can't see how making a new class > based on the old on affects that. Won't existing functions in modules which > import the old class instead of the new class continue to work? > > > > On Monday, 24 August 2015, Erik Hesselink > wrote: > >> On 24 August 2015 at 09:18, Clinton Mead > wrote: > >>> A second approach is an orphan instance. The recommendation here is to > put > >>> the orphan instances in their own module, so the user can choose to > import > >>> them. > >>> > >>> This may works ok if your user is writing an executable. But what if > your > >>> user is writing a library themselves. But once, you, or your user, > directly > >>> uses one of the instances, they need to import it, and they pollute the > >>> global instance namespace for anyone that uses their package. > >> > >> For this reason, I think the recommended course of action is to make a > >> canonical place for the instance, so that everyone can use it. For > >> example, if you have a library 'foo' providing T, and a library 'bar' > >> providing C, put the instance in a new package 'foo-bar' (or > >> 'bar-foo'). Then everyone can use that one instance, since Haskell is > >> built on the assumption that every type has one unique instance per > >> class. > >> > >>> I want to suggest a third option: > >>> > >>> (3) Copying the class. > >> > >> This would make a new distinct class, which means you can't call any > >> methods which have the original class as the context (f :: C a => a -> > >> a) since that class won't exist for type T (you are trying to avoid > >> defining that orphan instance). So I don't think this is usable in > >> most cases, unless I'm missing something. > >> > >> Erik > > , > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Mon Aug 24 10:38:21 2015 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Mon, 24 Aug 2015 13:38:21 +0300 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: <828071440411037@web13h.yandex.ru> Message-ID: <952881440412701@web7m.yandex.ru> OK. There is no point in having a class C, if there is no functions to work with it. So, this "other package" likely contains some functions that take types (of that class) as input. Like this: foo :: C a => a -> Int You don't need class C if you aren't using any functions from the library. So, with your (c), if you try to do a :: T a = ... b :: Int b = foo a you'll get a compile error. THAT is the problem. 24.08.2015, 13:28, "Clinton Mead" : > There's no new data. Class C already exists in another package. Data T already exists in another different package. > > The options are: > > a) Create a newtype MyT and an instance MyT of C. > b) Just create an orphan instance T of C. > c) Create a new class C1, forward its implementation to C, and add an instance T of C1. > > I'm suggesting (c) is best, but I haven't seen this elsewhere, the debate is usually between (a) and (b). > > I don't really understand the problems you're proposing with (c), but I'm not sure if that's because I'm misunderstanding you or I'm not explaining myself well. > > On Monday, 24 August 2015, Miguel Mitrofanov wrote: >> If, for your data, you create an instance of the new class ? but not the original one, then you can't use all the machinery that expects input being of the old class. Which is the point. >> >> 24.08.2015, 12:55, "Clinton Mead" : >>> The original class still exists, I can't see how making a new class based on the old on affects that. Won't existing functions in modules which import the old class instead of the new class?continue to work? >>> >>> On Monday, 24 August 2015, Erik Hesselink wrote: >>>> On 24 August 2015 at 09:18, Clinton Mead wrote: >>>>> A second approach is an orphan instance. The recommendation here is to put >>>>> the orphan instances in their own module, so the user can choose to import >>>>> them. >>>>> >>>>> This may works ok if your user is writing an executable. But what if your >>>>> user is writing a library themselves. But once, you, or your user, directly >>>>> uses one of the instances, they need to import it, and they pollute the >>>>> global instance namespace for anyone that uses their package. >>>> >>>> For this reason, I think the recommended course of action is to make a >>>> canonical place for the instance, so that everyone can use it. For >>>> example, if you have a library 'foo' providing T, and a library 'bar' >>>> providing C, put the instance in a new package 'foo-bar' (or >>>> 'bar-foo'). Then everyone can use that one instance, since Haskell is >>>> built on the assumption that every type has one unique instance per >>>> class. >>>> >>>>> I want to suggest a third option: >>>>> >>>>> (3) Copying the class. >>>> >>>> This would make a new distinct class, which means you can't call any >>>> methods which have the original class as the context (f :: C a => a -> >>>> a) since that class won't exist for type T (you are trying to avoid >>>> defining that orphan instance). So I don't think this is usable in >>>> most cases, unless I'm missing something. >>>> >>>> Erik >>> , >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From clintonmead at gmail.com Mon Aug 24 10:45:29 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Mon, 24 Aug 2015 20:45:29 +1000 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: <952881440412701@web7m.yandex.ru> References: <828071440411037@web13h.yandex.ru> <952881440412701@web7m.yandex.ru> Message-ID: Why does 'foo' fail? The module that 'foo'is defined in still can see C. C still exists. So as long as I import foo it should still work yes? On Monday, 24 August 2015, Miguel Mitrofanov wrote: > OK. There is no point in having a class C, if there is no functions to > work with it. So, this "other package" likely contains some functions that > take types (of that class) as input. Like this: > > foo :: C a => a -> Int > > You don't need class C if you aren't using any functions from the library. > So, with your (c), if you try to do > > a :: T > a = ... > > b :: Int > b = foo a > > you'll get a compile error. THAT is the problem. > > 24.08.2015, 13:28, "Clinton Mead" >: > > There's no new data. Class C already exists in another package. Data T > already exists in another different package. > > > > The options are: > > > > a) Create a newtype MyT and an instance MyT of C. > > b) Just create an orphan instance T of C. > > c) Create a new class C1, forward its implementation to C, and add an > instance T of C1. > > > > I'm suggesting (c) is best, but I haven't seen this elsewhere, the > debate is usually between (a) and (b). > > > > I don't really understand the problems you're proposing with (c), but > I'm not sure if that's because I'm misunderstanding you or I'm not > explaining myself well. > > > > On Monday, 24 August 2015, Miguel Mitrofanov > wrote: > >> If, for your data, you create an instance of the new class ? but not > the original one, then you can't use all the machinery that expects input > being of the old class. Which is the point. > >> > >> 24.08.2015, 12:55, "Clinton Mead" > >: > >>> The original class still exists, I can't see how making a new class > based on the old on affects that. Won't existing functions in modules which > import the old class instead of the new class continue to work? > >>> > >>> On Monday, 24 August 2015, Erik Hesselink > wrote: > >>>> On 24 August 2015 at 09:18, Clinton Mead > wrote: > >>>>> A second approach is an orphan instance. The recommendation here is > to put > >>>>> the orphan instances in their own module, so the user can choose to > import > >>>>> them. > >>>>> > >>>>> This may works ok if your user is writing an executable. But what if > your > >>>>> user is writing a library themselves. But once, you, or your user, > directly > >>>>> uses one of the instances, they need to import it, and they pollute > the > >>>>> global instance namespace for anyone that uses their package. > >>>> > >>>> For this reason, I think the recommended course of action is to make a > >>>> canonical place for the instance, so that everyone can use it. For > >>>> example, if you have a library 'foo' providing T, and a library 'bar' > >>>> providing C, put the instance in a new package 'foo-bar' (or > >>>> 'bar-foo'). Then everyone can use that one instance, since Haskell is > >>>> built on the assumption that every type has one unique instance per > >>>> class. > >>>> > >>>>> I want to suggest a third option: > >>>>> > >>>>> (3) Copying the class. > >>>> > >>>> This would make a new distinct class, which means you can't call any > >>>> methods which have the original class as the context (f :: C a => a -> > >>>> a) since that class won't exist for type T (you are trying to avoid > >>>> defining that orphan instance). So I don't think this is usable in > >>>> most cases, unless I'm missing something. > >>>> > >>>> Erik > >>> , > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Mon Aug 24 10:48:52 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Mon, 24 Aug 2015 20:48:52 +1000 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: <828071440411037@web13h.yandex.ru> <952881440412701@web7m.yandex.ru> Message-ID: After implementing the steps in (c), T is an instance of both C and C1, and both those instances define foo the same way. The only way I see a problem if is a module imports both C1 and C unqualified (they'll clash) but I see no reason to do that. On Monday, 24 August 2015, Clinton Mead wrote: > Why does 'foo' fail? The module that 'foo'is defined in still can see C. C > still exists. So as long as I import foo it should still work yes? > > On Monday, 24 August 2015, Miguel Mitrofanov > wrote: > >> OK. There is no point in having a class C, if there is no functions to >> work with it. So, this "other package" likely contains some functions that >> take types (of that class) as input. Like this: >> >> foo :: C a => a -> Int >> >> You don't need class C if you aren't using any functions from the >> library. So, with your (c), if you try to do >> >> a :: T >> a = ... >> >> b :: Int >> b = foo a >> >> you'll get a compile error. THAT is the problem. >> >> 24.08.2015, 13:28, "Clinton Mead" : >> > There's no new data. Class C already exists in another package. Data T >> already exists in another different package. >> > >> > The options are: >> > >> > a) Create a newtype MyT and an instance MyT of C. >> > b) Just create an orphan instance T of C. >> > c) Create a new class C1, forward its implementation to C, and add an >> instance T of C1. >> > >> > I'm suggesting (c) is best, but I haven't seen this elsewhere, the >> debate is usually between (a) and (b). >> > >> > I don't really understand the problems you're proposing with (c), but >> I'm not sure if that's because I'm misunderstanding you or I'm not >> explaining myself well. >> > >> > On Monday, 24 August 2015, Miguel Mitrofanov >> wrote: >> >> If, for your data, you create an instance of the new class ? but not >> the original one, then you can't use all the machinery that expects input >> being of the old class. Which is the point. >> >> >> >> 24.08.2015, 12:55, "Clinton Mead" : >> >>> The original class still exists, I can't see how making a new class >> based on the old on affects that. Won't existing functions in modules which >> import the old class instead of the new class continue to work? >> >>> >> >>> On Monday, 24 August 2015, Erik Hesselink >> wrote: >> >>>> On 24 August 2015 at 09:18, Clinton Mead >> wrote: >> >>>>> A second approach is an orphan instance. The recommendation here is >> to put >> >>>>> the orphan instances in their own module, so the user can choose to >> import >> >>>>> them. >> >>>>> >> >>>>> This may works ok if your user is writing an executable. But what >> if your >> >>>>> user is writing a library themselves. But once, you, or your user, >> directly >> >>>>> uses one of the instances, they need to import it, and they pollute >> the >> >>>>> global instance namespace for anyone that uses their package. >> >>>> >> >>>> For this reason, I think the recommended course of action is to make >> a >> >>>> canonical place for the instance, so that everyone can use it. For >> >>>> example, if you have a library 'foo' providing T, and a library 'bar' >> >>>> providing C, put the instance in a new package 'foo-bar' (or >> >>>> 'bar-foo'). Then everyone can use that one instance, since Haskell is >> >>>> built on the assumption that every type has one unique instance per >> >>>> class. >> >>>> >> >>>>> I want to suggest a third option: >> >>>>> >> >>>>> (3) Copying the class. >> >>>> >> >>>> This would make a new distinct class, which means you can't call any >> >>>> methods which have the original class as the context (f :: C a => a >> -> >> >>>> a) since that class won't exist for type T (you are trying to avoid >> >>>> defining that orphan instance). So I don't think this is usable in >> >>>> most cases, unless I'm missing something. >> >>>> >> >>>> Erik >> >>> , >> >>> >> >>> _______________________________________________ >> >>> Haskell-Cafe mailing list >> >>> Haskell-Cafe at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chpatrick at gmail.com Mon Aug 24 10:52:30 2015 From: chpatrick at gmail.com (Patrick Chilton) Date: Mon, 24 Aug 2015 11:52:30 +0100 Subject: [Haskell-cafe] Elementary math question: primality test for huge numbers In-Reply-To: References: <20150823213442.66323377@nimrodel> Message-ID: Haskell also includes the primality testing functions of the GMP library on Integers, but they're MagicHashed for some reason so handle with care: https://hackage.haskell.org/package/integer-gmp-1.0.0.0/docs/GHC-Integer-GMP-Internals.html#g:12 On Mon, Aug 24, 2015 at 6:38 AM, William Yager wrote: > See section 4.4. http://cacr.uwaterloo.ca/hac/about/chap4.pdf > > --Will Yager > > On Mon, Aug 24, 2015 at 12:34 AM, Christopher Howard > wrote: > >> Hi. I was working through a math chapter explaining the RSA algorithm, >> and I was implementing it in Haskell for learning sake. However, the >> chapter does not explain how you efficiently pick the two prime >> numbers. I scanned through the WP page on primality tests but it was >> somewhat overwhelming. What would be the standard primality test for >> this sort of application, and is it already built in to Base somewhere? >> >> -- >> Biblical creationism: http://tinyurl.com/qfyeg4a >> Free Bible software: http://xiphos.org >> Software freedom: http://tinyurl.com/qjnpnsm >> Free computer operating system: http://tinyurl.com/7wczchu >> Alternative to MS Office: http://tinyurl.com/aw9p6d4 >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Mon Aug 24 11:07:29 2015 From: sean.leather at gmail.com (Sean Leather) Date: Mon, 24 Aug 2015 13:07:29 +0200 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: <828071440411037@web13h.yandex.ru> <952881440412701@web7m.yandex.ru> Message-ID: On Mon, Aug 24, 2015 at 12:48 PM, Clinton Mead wrote: > After implementing the steps in (c), T is an instance of both C and C1, > and both those instances define foo the same way. The only way I see a > problem if is a module imports both C1 and C unqualified (they'll clash) but > I see no reason to do that. > It's hard to respond with vague details. It may be in your case that what you say works. But this is not true in the general case. Consider the following simple example. -- | A module out of your control module A where data T = T -- | A module out of your control module B where class Show a where show :: a -> String print :: Show a => a -> IO () -- | A module under your control module C where import A import B class Show' a where show' :: a -> String instance Show' T where show' T = "T" Now, you can use "show' T" anywhere you could use "show T" because the result of both functions is the same (monomorphic) type. But you can't use "print T" from module B because you do not have an instance for Show of T. You could define a function "print' :: Show' a => a -> IO ()", but you are not using the functions that rely on Show (a.k.a. the "machinery" mentioned by Miguel). Thus, you lose out on the common functionality that presumably exists for Show. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Mon Aug 24 11:10:46 2015 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Mon, 24 Aug 2015 14:10:46 +0300 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: <828071440411037@web13h.yandex.ru> <952881440412701@web7m.yandex.ru> Message-ID: <1119041440414646@web5j.yandex.ru> Because your type 'T' doesn't have an 'instance C'. 24.08.2015, 13:45, "Clinton Mead" : > Why does 'foo' fail? The module that 'foo'is defined in still can see C. C still exists. So as long as I import foo it should still work yes? > > On Monday, 24 August 2015, Miguel Mitrofanov wrote: >> OK. There is no point in having a class C, if there is no functions to work with it. So, this "other package" likely contains some functions that take types (of that class) as input. Like this: >> >> foo :: C a => a -> Int >> >> You don't need class C if you aren't using any functions from the library. So, with your (c), if you try to do >> >> a :: T >> a = ... >> >> b :: Int >> b = foo a >> >> you'll get a compile error. THAT is the problem. >> >> 24.08.2015, 13:28, "Clinton Mead" : >>> There's no new data. Class C already exists in another package. Data T already exists in another different package. >>> >>> The options are: >>> >>> a) Create a newtype MyT and an instance MyT of C. >>> b) Just create an orphan instance T of C. >>> c) Create a new class C1, forward its implementation to C, and add an instance T of C1. >>> >>> I'm suggesting (c) is best, but I haven't seen this elsewhere, the debate is usually between (a) and (b). >>> >>> I don't really understand the problems you're proposing with (c), but I'm not sure if that's because I'm misunderstanding you or I'm not explaining myself well. >>> >>> On Monday, 24 August 2015, Miguel Mitrofanov wrote: >>>> If, for your data, you create an instance of the new class ? but not the original one, then you can't use all the machinery that expects input being of the old class. Which is the point. >>>> >>>> 24.08.2015, 12:55, "Clinton Mead" : >>>>> The original class still exists, I can't see how making a new class based on the old on affects that. Won't existing functions in modules which import the old class instead of the new class?continue to work? >>>>> >>>>> On Monday, 24 August 2015, Erik Hesselink wrote: >>>>>> On 24 August 2015 at 09:18, Clinton Mead wrote: >>>>>>> A second approach is an orphan instance. The recommendation here is to put >>>>>>> the orphan instances in their own module, so the user can choose to import >>>>>>> them. >>>>>>> >>>>>>> This may works ok if your user is writing an executable. But what if your >>>>>>> user is writing a library themselves. But once, you, or your user, directly >>>>>>> uses one of the instances, they need to import it, and they pollute the >>>>>>> global instance namespace for anyone that uses their package. >>>>>> >>>>>> For this reason, I think the recommended course of action is to make a >>>>>> canonical place for the instance, so that everyone can use it. For >>>>>> example, if you have a library 'foo' providing T, and a library 'bar' >>>>>> providing C, put the instance in a new package 'foo-bar' (or >>>>>> 'bar-foo'). Then everyone can use that one instance, since Haskell is >>>>>> built on the assumption that every type has one unique instance per >>>>>> class. >>>>>> >>>>>>> I want to suggest a third option: >>>>>>> >>>>>>> (3) Copying the class. >>>>>> >>>>>> This would make a new distinct class, which means you can't call any >>>>>> methods which have the original class as the context (f :: C a => a -> >>>>>> a) since that class won't exist for type T (you are trying to avoid >>>>>> defining that orphan instance). So I don't think this is usable in >>>>>> most cases, unless I'm missing something. >>>>>> >>>>>> Erik >>>>> , >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From miguelimo38 at yandex.ru Mon Aug 24 11:11:19 2015 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Mon, 24 Aug 2015 14:11:19 +0300 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: <828071440411037@web13h.yandex.ru> <952881440412701@web7m.yandex.ru> Message-ID: <1122601440414679@web5j.yandex.ru> > T is an instance of both C and C1 Then why the hell do you need C1 at all? 24.08.2015, 13:48, "Clinton Mead" : > After implementing the steps in (c), T is an instance of both C and C1, and both those instances define foo the same way. The only way I see a problem if is a module imports both C1 and C unqualified (they'll clash)?but I see no reason to do that. > > On Monday, 24 August 2015, Clinton Mead wrote: >> Why does 'foo' fail? The module that 'foo'is defined in still can see C. C still exists. So as long as I import foo it should still work yes? >> >> On Monday, 24 August 2015, Miguel Mitrofanov wrote: >>> OK. There is no point in having a class C, if there is no functions to work with it. So, this "other package" likely contains some functions that take types (of that class) as input. Like this: >>> >>> foo :: C a => a -> Int >>> >>> You don't need class C if you aren't using any functions from the library. So, with your (c), if you try to do >>> >>> a :: T >>> a = ... >>> >>> b :: Int >>> b = foo a >>> >>> you'll get a compile error. THAT is the problem. >>> >>> 24.08.2015, 13:28, "Clinton Mead" : >>>> There's no new data. Class C already exists in another package. Data T already exists in another different package. >>>> >>>> The options are: >>>> >>>> a) Create a newtype MyT and an instance MyT of C. >>>> b) Just create an orphan instance T of C. >>>> c) Create a new class C1, forward its implementation to C, and add an instance T of C1. >>>> >>>> I'm suggesting (c) is best, but I haven't seen this elsewhere, the debate is usually between (a) and (b). >>>> >>>> I don't really understand the problems you're proposing with (c), but I'm not sure if that's because I'm misunderstanding you or I'm not explaining myself well. >>>> >>>> On Monday, 24 August 2015, Miguel Mitrofanov wrote: >>>>> If, for your data, you create an instance of the new class ? but not the original one, then you can't use all the machinery that expects input being of the old class. Which is the point. >>>>> >>>>> 24.08.2015, 12:55, "Clinton Mead" : >>>>>> The original class still exists, I can't see how making a new class based on the old on affects that. Won't existing functions in modules which import the old class instead of the new class?continue to work? >>>>>> >>>>>> On Monday, 24 August 2015, Erik Hesselink wrote: >>>>>>> On 24 August 2015 at 09:18, Clinton Mead wrote: >>>>>>>> A second approach is an orphan instance. The recommendation here is to put >>>>>>>> the orphan instances in their own module, so the user can choose to import >>>>>>>> them. >>>>>>>> >>>>>>>> This may works ok if your user is writing an executable. But what if your >>>>>>>> user is writing a library themselves. But once, you, or your user, directly >>>>>>>> uses one of the instances, they need to import it, and they pollute the >>>>>>>> global instance namespace for anyone that uses their package. >>>>>>> >>>>>>> For this reason, I think the recommended course of action is to make a >>>>>>> canonical place for the instance, so that everyone can use it. For >>>>>>> example, if you have a library 'foo' providing T, and a library 'bar' >>>>>>> providing C, put the instance in a new package 'foo-bar' (or >>>>>>> 'bar-foo'). Then everyone can use that one instance, since Haskell is >>>>>>> built on the assumption that every type has one unique instance per >>>>>>> class. >>>>>>> >>>>>>>> I want to suggest a third option: >>>>>>>> >>>>>>>> (3) Copying the class. >>>>>>> >>>>>>> This would make a new distinct class, which means you can't call any >>>>>>> methods which have the original class as the context (f :: C a => a -> >>>>>>> a) since that class won't exist for type T (you are trying to avoid >>>>>>> defining that orphan instance). So I don't think this is usable in >>>>>>> most cases, unless I'm missing something. >>>>>>> >>>>>>> Erik >>>>>> , >>>>>> >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From heraldhoi at gmail.com Mon Aug 24 11:16:41 2015 From: heraldhoi at gmail.com (Geraldus) Date: Mon, 24 Aug 2015 11:16:41 +0000 Subject: [Haskell-cafe] getNumCapabilities always returns 1 with GHC 7.10.2 on OS X In-Reply-To: References: Message-ID: Great, thanks Michael. That was false alarm, please excuse me. ??, 24 ???. 2015 ?. ? 15:19, Michael Snoyman : > How about --ghc-options: > > stack ghci --ghc-options "+RTS -N8 -RTS" > > On Mon, Aug 24, 2015 at 1:14 PM, Geraldus wrote: > >> Ok, now it shows me eight cores. So, I've passed arguments incorrectly, >> what is the correct way to do this? >> >> *(Also, `$(stack exec which ghci) +RTS -N8` does not work with fish shell >> which I'm using by default, but I tested your suggestion in bash)* >> >> ??, 24 ???. 2015 ?. ? 14:37, Michael Snoyman : >> >>> It looks like you're sending the RTS options to `stack` in the first >>> one, not to ghci itself. What's the result with `$(stack exec which ghci) >>> +RTS -N8`? >>> >>> On Mon, Aug 24, 2015 at 12:32 PM, Geraldus wrote: >>> >>>> I have OS X Yosemite 10.10.4. There are two bundles of GHC (from >>>> ghcformacosx.github.io): 7.10.1 and 7.10.2. The latter always shows >>>> me one core when running `getNumCapabilities` action: >>>> >>>> *GHC 7.10.2* >>>> > stack ghci +RTS -N8 >>>> Using resolver: lts-3.0 from global config file: >>>> /Users/arthurfayzrakhmanov/.stack/global/stack.yaml >>>> Configuring GHCi with the following packages: >>>> GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help >>>> Prelude> :m +Control.Concurrent >>>> Prelude Control.Concurrent> getNumCapabilities >>>> 1 >>>> >>>> >>>> *GHC 7.10.1* >>>> > /Applications/ghc-7.10.1.app/Contents/bin/ghci +RTS -N8 >>>> GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help >>>> Prelude> :m +Control.Concurrent >>>> Prelude Control.Concurrent> getNumCapabilities >>>> 8 >>>> >>>> It looks like a 7.10.2 bug, can some one confirm that? >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Mon Aug 24 11:37:19 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Mon, 24 Aug 2015 21:37:19 +1000 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: <828071440411037@web13h.yandex.ru> <952881440412701@web7m.yandex.ru> Message-ID: I see the problem now Sean. So in your example, is this correct: "To use the machinery of 'Show', I have to add and instance Show T. But that would be an orphan instance. So there is no way for T to use show machinery without adding an orphan instance (aside from modifying a module not under your control)?" Even newtype doesn't seem to help in your example. Show has all this machinery, but it seems completely unusable without adding an orphan instance or re-writing other people's modules. Is there no other way? This situation seems incredibly against re-usability, which I thought was Haskell's strength. Am I missing something? On Mon, Aug 24, 2015 at 9:07 PM, Sean Leather wrote: > On Mon, Aug 24, 2015 at 12:48 PM, Clinton Mead wrote: > >> After implementing the steps in (c), T is an instance of both C and C1, >> and both those instances define foo the same way. The only way I see a >> problem if is a module imports both C1 and C unqualified (they'll clash) but >> I see no reason to do that. >> > > It's hard to respond with vague details. It may be in your case that what > you say works. But this is not true in the general case. Consider the > following simple example. > > -- | A module out of your control > module A where > data T = T > > -- | A module out of your control > module B where > class Show a where > show :: a -> String > print :: Show a => a -> IO () > > -- | A module under your control > module C where > import A > import B > class Show' a where > show' :: a -> String > instance Show' T where > show' T = "T" > > Now, you can use "show' T" anywhere you could use "show T" because the > result of both functions is the same (monomorphic) type. > > But you can't use "print T" from module B because you do not have an > instance for Show of T. You could define a function "print' :: Show' a => a > -> IO ()", but you are not using the functions that rely on Show (a.k.a. > the "machinery" mentioned by Miguel). Thus, you lose out on the common > functionality that presumably exists for Show. > > Regards, > Sean > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Mon Aug 24 11:50:55 2015 From: sean.leather at gmail.com (Sean Leather) Date: Mon, 24 Aug 2015 13:50:55 +0200 Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: <828071440411037@web13h.yandex.ru> <952881440412701@web7m.yandex.ru> Message-ID: On Mon, Aug 24, 2015 at 1:37 PM, Clinton Mead wrote: > I see the problem now Sean. So in your example, is this correct: > > "To use the machinery of 'Show', I have to add and instance Show T. But > that would be an orphan instance. So there is no way for T to use show > machinery without adding an orphan instance (aside from modifying a module > not under your control)?" > Correct. Even newtype doesn't seem to help in your example. Show has all this > machinery, but it seems completely unusable without adding an orphan > instance or re-writing other people's modules. Is there no other way? This > situation seems incredibly against re-usability, which I thought was > Haskell's strength. Am I missing something? > Orphan instances are one of unfortunate pain points of Haskell, though they are sometimes a necessary ?evil.? Erik's first response describes a common technique for publishing and sharing orphan instances. See, for example, https://hackage.haskell.org/packages/search?terms=instances . Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Aug 24 12:48:45 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 24 Aug 2015 08:48:45 -0400 Subject: [Haskell-cafe] getNumCapabilities always returns 1 with GHC 7.10.2 on OS X In-Reply-To: References: Message-ID: On Mon, Aug 24, 2015 at 5:32 AM, Geraldus wrote: > > stack ghci +RTS -N8 For the record: stack ghci --RTS +RTS -N8 The first --RTS stops stack's RTS from consuming RTS options but is itself consumed, thus letting ghci's RTS consume +RTS -N8. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Mon Aug 24 14:15:50 2015 From: mike at proclivis.com (Michael Jones) Date: Mon, 24 Aug 2015 08:15:50 -0600 Subject: [Haskell-cafe] [ANN] frpnow-0.12 In-Reply-To: References: Message-ID: Atze, I have a question about Streams. In the Paper Impl the following code: newtype Stream a = S { next :: B (E a) } catMaybesStream :: Stream (Maybe a) -> Stream a catMaybesStream (S s) = S loop where loop = do e <- s join <$> plan (nxt <$> e) -- nxt :: Maybe a -> B (E a) nxt (Just a) = return (return a) nxt Nothing = loop Which I understand. And in the library the following code: newtype EvStream a = S { getEs :: Behavior (Event [a]) } catMaybesEs :: EvStream (Maybe a) -> EvStream a catMaybesEs s = S $ loop where -- loop :: Behavior (Event [a]) loop = do e <- getEs s join <$> plan (nxt <$> e) nxt l = case catMaybes l of [] -> loop l -> return (return l) I assume the new type EvStream the intent is for the stream of ?a? to be an array rather than a recursive data structure, based on the name ?getEs?. But, catMaybeEs is written like the paper version, suggesting it is a recursive data structure arrays. My goal is to write an integrator for a stream, such that the type signature is: EvStream (Double,Double) -> EvStream (Double) where the tuple is (data, time) and the result is (integratedData) and I modeled the function catMaybeEs, but it is not working. So I want to understand the general way to handle the stream in catMaybesEs. Mike > On Jul 15, 2015, at 7:25 AM, Atze van der Ploeg wrote: > > Dear Cafe, > We have released the (nearly) first version of FRPNow, the functional reactive programming library based on the ICFP 2015 paper "Principled Practical FRP: Forget the Past, Change the Future, FRPNow!" (https://www.reddit.com/r/haskell/comments/3ai7hl/principled_practical_frp_forget_the_past_change/ ) > The main package: http://hackage.haskell.org/package/frpnow > Examples: https://github.com/atzeus/FRPNow/tree/master/Examples > Gloss interoperability: http://hackage.haskell.org/package/frpnow-gloss > GTK interoperability: http://hackage.haskell.org/package/frpnow-gtk > (hackage doesn't like the newer GTK docs, so you can read the docs at http://www.cse.chalmers.se/~atze/frpnow-gtk/ ) > > Cheers, > > Atze > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From atzeus at gmail.com Mon Aug 24 14:50:53 2015 From: atzeus at gmail.com (Atze van der Ploeg) Date: Mon, 24 Aug 2015 16:50:53 +0200 Subject: [Haskell-cafe] [ANN] frpnow-0.12 In-Reply-To: References: Message-ID: Hi Mike, cafe, The implementation in the library is essentially the same as in the paper, but B (E [a]) instead of B (E a) allows multiple simultaneous events, whereas the implementation in the paper does not. The result is B (E [a]), where the list is the list of all results in the event stream which occur at that point. Like the implementation in the paper, the behavior switches as soon as the next event occurs. I'm a bit unclear on your question, neither implementation is recursive. If you want to use event streams it's best not to look at their implementation, which is tricky, but just use the combinators that are available. You can create a behavior that always give the integration of the values in the eventstream as follows: integrate :: EvStream (Double,Double) -> Double -> Behavior (Behavior Double) integrate stream startTime = foldEs update (0,startTime) stream where update (total, prevTime) (cur, curTime) = let diff = curTime - prevTime * cur in (total + diff, curTime) Or use Control.FRPNow.Time.integrate :) The result will give a Behavior (Behavior Double), because the result depends on when we start integrating to prevent the space leak. Does that answer your question? Cheers, Atze 2015-08-24 16:15 GMT+02:00 Michael Jones : > Atze, > > I have a question about Streams. > > In the Paper Impl the following code: > > newtype Stream a = S { next :: B (E a) } > > catMaybesStream :: Stream (Maybe a) -> Stream a > catMaybesStream (S s) = S loop where > loop = do e <- s > join <$> plan (nxt <$> e) > -- nxt :: Maybe a -> B (E a) > nxt (Just a) = return (return a) > nxt Nothing = loop > > Which I understand. > > And in the library the following code: > > newtype EvStream a = S { getEs :: Behavior (Event [a]) } > > > catMaybesEs :: EvStream (Maybe a) -> EvStream a > catMaybesEs s = S $ loop where > -- loop :: Behavior (Event [a]) > loop = do e <- getEs s > join <$> plan (nxt <$> e) > nxt l = case catMaybes l of > [] -> loop > l -> return (return l) > > I assume the new type EvStream the intent is for the stream of ?a? to be > an array rather than a recursive data structure, based on the name ?getEs?. > > But, catMaybeEs is written like the paper version, suggesting it is a > recursive data structure arrays. > > My goal is to write an integrator for a stream, such that the type > signature is: > > EvStream (Double,Double) -> EvStream (Double) > > where the tuple is (data, time) and the result is (integratedData) > > and I modeled the function catMaybeEs, but it is not working. So I want to > understand the general way to handle the stream in catMaybesEs. > > Mike > > > On Jul 15, 2015, at 7:25 AM, Atze van der Ploeg wrote: > > Dear Cafe, > We have released the (nearly) first version of FRPNow, the functional > reactive programming library based on the ICFP 2015 paper "Principled > Practical FRP: Forget the Past, Change the Future, FRPNow!" ( > https://www.reddit.com/r/haskell/comments/3ai7hl/principled_practical_frp_forget_the_past_change/ > ) > The main package: http://hackage.haskell.org/package/frpnow > Examples: https://github.com/atzeus/FRPNow/tree/master/Examples > Gloss interoperability: http://hackage.haskell.org/package/frpnow-gloss > GTK interoperability: http://hackage.haskell.org/package/frpnow-gtk > (hackage doesn't like the newer GTK docs, so you can read the docs at > http://www.cse.chalmers.se/~atze/frpnow-gtk/ ) > > Cheers, > > Atze > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodingm at gmail.com Mon Aug 24 14:52:09 2015 From: goodingm at gmail.com (htebalaka) Date: Mon, 24 Aug 2015 07:52:09 -0700 (MST) Subject: [Haskell-cafe] Alternative to newtypes or orphan instances In-Reply-To: References: <828071440411037@web13h.yandex.ru> <952881440412701@web7m.yandex.ru> Message-ID: <1440427929579-5816142.post@n5.nabble.com> Another issues is there's lots of code polymorphic over an instance, which you lose out on if you simply make a new class rather than newtype to support an alternative instance. For instance, lots of datatypes have a second non-trivial Applicative ([] : ZipList, IO : Concurrently , Either : Validation), and there's lots of code that's polymorphic over Applicative (traverse, Data.Functor.Compose, Data.Functor.Product). Using a new class means you still need some newtype and "instance Applicative2 f => Applicative (WrappedA2 f)" to avoid duplicating all this work, so you don't really escape from needing newtypes in non-trivial examples anyway. Sean Leather-2 wrote > On Mon, Aug 24, 2015 at 1:37 PM, Clinton Mead wrote: > >> I see the problem now Sean. So in your example, is this correct: >> >> "To use the machinery of 'Show', I have to add and instance Show T. But >> that would be an orphan instance. So there is no way for T to use show >> machinery without adding an orphan instance (aside from modifying a >> module >> not under your control)?" >> > > Correct. > > Even newtype doesn't seem to help in your example. Show has all this >> machinery, but it seems completely unusable without adding an orphan >> instance or re-writing other people's modules. Is there no other way? >> This >> situation seems incredibly against re-usability, which I thought was >> Haskell's strength. Am I missing something? >> > > Orphan instances are one of unfortunate pain points of Haskell, though > they > are sometimes a necessary ?evil.? Erik's first response describes a common > technique for publishing and sharing orphan instances. See, for example, > https://hackage.haskell.org/packages/search?terms=instances . > > Regards, > Sean > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/Alternative-to-newtypes-or-orphan-instances-tp5816099p5816142.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From mike at proclivis.com Mon Aug 24 15:01:51 2015 From: mike at proclivis.com (Michael Jones) Date: Mon, 24 Aug 2015 09:01:51 -0600 Subject: [Haskell-cafe] [ANN] frpnow-0.12 In-Reply-To: References: Message-ID: <0E8498D7-1AD5-4ABC-918D-989D33ABE842@proclivis.com> Atze, Ah, now it is more clear what the intended representation is. Let me address the point about recursion, which reflects more or less my difficulty understanding how a stream produces values in time. Referencing the paper version: newtype Stream a = S { next :: B (E a) } catMaybesStream :: Stream (Maybe a) -> Stream a catMaybesStream (S s) = S loop where loop = do e <- s join <$> plan (nxt <$> e) -- nxt :: Maybe a -> B (E a) nxt (Just a) = return (return a) nxt Nothing = loop loop references nxt, and nxt references loop, hence my use of the word ?recursion?. But perhaps saying ?data? is incorrect. My intuition says that the ?a? in B (E a) must be a Stream for the ?recursion? to work. What then really twists my mind up is ?e <-s? getting the next value n times. I?m not an expert in how Haskell evaluates these expressions, but I really would like to understand how that works, because my old ?imperative? mind is in need of an upgrade. Mike > On Aug 24, 2015, at 8:50 AM, Atze van der Ploeg wrote: > > Hi Mike, cafe, > > The implementation in the library is essentially the same as in the paper, but B (E [a]) instead of B (E a) allows multiple simultaneous events, whereas the implementation in the paper does not. The result is B (E [a]), where the list is the list of all results in the event stream which occur at that point. Like the implementation in the paper, the behavior switches as soon as the next event occurs. > > I'm a bit unclear on your question, neither implementation is recursive. If you want to use event streams it's best not to look at their implementation, which is tricky, but just use the combinators that are available. > You can create a behavior that always give the integration of the values in the eventstream as follows: > > integrate :: EvStream (Double,Double) -> Double -> Behavior (Behavior Double) > integrate stream startTime = foldEs update (0,startTime) stream where > update (total, prevTime) (cur, curTime) = let diff = curTime - prevTime * cur > in (total + diff, curTime) > > Or use Control.FRPNow.Time.integrate :) > > The result will give a Behavior (Behavior Double), because the result depends on when we start integrating to prevent the space leak. Does that answer your question? > > Cheers, > > Atze > > > > 2015-08-24 16:15 GMT+02:00 Michael Jones >: > Atze, > > I have a question about Streams. > > In the Paper Impl the following code: > > newtype Stream a = S { next :: B (E a) } > > catMaybesStream :: Stream (Maybe a) -> Stream a > catMaybesStream (S s) = S loop where > loop = do e <- s > join <$> plan (nxt <$> e) > -- nxt :: Maybe a -> B (E a) > nxt (Just a) = return (return a) > nxt Nothing = loop > > Which I understand. > > And in the library the following code: > > newtype EvStream a = S { getEs :: Behavior (Event [a]) } > > > catMaybesEs :: EvStream (Maybe a) -> EvStream a > catMaybesEs s = S $ loop where > -- loop :: Behavior (Event [a]) > loop = do e <- getEs s > join <$> plan (nxt <$> e) > nxt l = case catMaybes l of > [] -> loop > l -> return (return l) > > I assume the new type EvStream the intent is for the stream of ?a? to be an array rather than a recursive data structure, based on the name ?getEs?. > > But, catMaybeEs is written like the paper version, suggesting it is a recursive data structure arrays. > > My goal is to write an integrator for a stream, such that the type signature is: > > EvStream (Double,Double) -> EvStream (Double) > > where the tuple is (data, time) and the result is (integratedData) > > and I modeled the function catMaybeEs, but it is not working. So I want to understand the general way to handle the stream in catMaybesEs. > > Mike > > >> On Jul 15, 2015, at 7:25 AM, Atze van der Ploeg > wrote: >> >> Dear Cafe, >> We have released the (nearly) first version of FRPNow, the functional reactive programming library based on the ICFP 2015 paper "Principled Practical FRP: Forget the Past, Change the Future, FRPNow!" (https://www.reddit.com/r/haskell/comments/3ai7hl/principled_practical_frp_forget_the_past_change/ ) >> The main package: http://hackage.haskell.org/package/frpnow >> Examples: https://github.com/atzeus/FRPNow/tree/master/Examples >> Gloss interoperability: http://hackage.haskell.org/package/frpnow-gloss >> GTK interoperability: http://hackage.haskell.org/package/frpnow-gtk >> (hackage doesn't like the newer GTK docs, so you can read the docs at http://www.cse.chalmers.se/~atze/frpnow-gtk/ ) >> >> Cheers, >> >> Atze >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atzeus at gmail.com Mon Aug 24 15:08:55 2015 From: atzeus at gmail.com (Atze van der Ploeg) Date: Mon, 24 Aug 2015 17:08:55 +0200 Subject: [Haskell-cafe] [ANN] frpnow-0.12 In-Reply-To: <0E8498D7-1AD5-4ABC-918D-989D33ABE842@proclivis.com> References: <0E8498D7-1AD5-4ABC-918D-989D33ABE842@proclivis.com> Message-ID: This is the magic of the implementation, as well as Haskell. Very funky indeed. The paper describes it, but I must admit it is all pretty tricky :) 2015-08-24 17:01 GMT+02:00 Michael Jones : > Atze, > > Ah, now it is more clear what the intended representation is. > > Let me address the point about recursion, which reflects more or less my > difficulty understanding how a stream produces values in time. > > Referencing the paper version: > > newtype Stream a = S { next :: B (E a) } > > catMaybesStream :: Stream (Maybe a) -> Stream a > catMaybesStream (S s) = S loop where > loop = do e <- s > join <$> plan (nxt <$> e) > -- nxt :: Maybe a -> B (E a) > nxt (Just a) = return (return a) > nxt Nothing = loop > > loop references nxt, and nxt references loop, hence my use of the word > ?recursion?. But perhaps saying ?data? is incorrect. My intuition says that > the ?a? in B (E a) must be a Stream for the ?recursion? to work. What then > really twists my mind up is ?e <-s? getting the next value n times. I?m not > an expert in how Haskell evaluates these expressions, but I really would > like to understand how that works, because my old ?imperative? mind is in > need of an upgrade. > > Mike > > On Aug 24, 2015, at 8:50 AM, Atze van der Ploeg wrote: > > Hi Mike, cafe, > > The implementation in the library is essentially the same as in the paper, > but B (E [a]) instead of B (E a) allows multiple simultaneous events, > whereas the implementation in the paper does not. The result is B (E [a]), > where the list is the list of all results in the event stream which occur > at that point. Like the implementation in the paper, the behavior switches > as soon as the next event occurs. > > I'm a bit unclear on your question, neither implementation is recursive. > If you want to use event streams it's best not to look at their > implementation, which is tricky, but just use the combinators that are > available. > You can create a behavior that always give the integration of the values > in the eventstream as follows: > > integrate :: EvStream (Double,Double) -> Double -> Behavior (Behavior > Double) > integrate stream startTime = foldEs update (0,startTime) stream where > update (total, prevTime) (cur, curTime) = let diff = curTime - prevTime > * cur > in > (total + diff, curTime) > > Or use Control.FRPNow.Time.integrate :) > > The result will give a Behavior (Behavior Double), because the result > depends on when we start integrating to prevent the space leak. Does that > answer your question? > > Cheers, > > Atze > > > > 2015-08-24 16:15 GMT+02:00 Michael Jones : > >> Atze, >> >> I have a question about Streams. >> >> In the Paper Impl the following code: >> >> newtype Stream a = S { next :: B (E a) } >> >> catMaybesStream :: Stream (Maybe a) -> Stream a >> catMaybesStream (S s) = S loop where >> loop = do e <- s >> join <$> plan (nxt <$> e) >> -- nxt :: Maybe a -> B (E a) >> nxt (Just a) = return (return a) >> nxt Nothing = loop >> >> Which I understand. >> >> And in the library the following code: >> >> newtype EvStream a = S { getEs :: Behavior (Event [a]) } >> >> >> catMaybesEs :: EvStream (Maybe a) -> EvStream a >> catMaybesEs s = S $ loop where >> -- loop :: Behavior (Event [a]) >> loop = do e <- getEs s >> join <$> plan (nxt <$> e) >> nxt l = case catMaybes l of >> [] -> loop >> l -> return (return l) >> >> I assume the new type EvStream the intent is for the stream of ?a? to be >> an array rather than a recursive data structure, based on the name ?getEs?. >> >> But, catMaybeEs is written like the paper version, suggesting it is a >> recursive data structure arrays. >> >> My goal is to write an integrator for a stream, such that the type >> signature is: >> >> EvStream (Double,Double) -> EvStream (Double) >> >> where the tuple is (data, time) and the result is (integratedData) >> >> and I modeled the function catMaybeEs, but it is not working. So I want >> to understand the general way to handle the stream in catMaybesEs. >> >> Mike >> >> >> On Jul 15, 2015, at 7:25 AM, Atze van der Ploeg wrote: >> >> Dear Cafe, >> We have released the (nearly) first version of FRPNow, the functional >> reactive programming library based on the ICFP 2015 paper "Principled >> Practical FRP: Forget the Past, Change the Future, FRPNow!" ( >> https://www.reddit.com/r/haskell/comments/3ai7hl/principled_practical_frp_forget_the_past_change/ >> ) >> The main package: http://hackage.haskell.org/package/frpnow >> Examples: https://github.com/atzeus/FRPNow/tree/master/Examples >> Gloss interoperability: http://hackage.haskell.org/package/frpnow-gloss >> GTK interoperability: http://hackage.haskell.org/package/frpnow-gtk >> (hackage doesn't like the newer GTK docs, so you can read the docs at >> http://www.cse.chalmers.se/~atze/frpnow-gtk/ ) >> >> Cheers, >> >> Atze >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Mon Aug 24 15:14:24 2015 From: mike at proclivis.com (Michael Jones) Date: Mon, 24 Aug 2015 09:14:24 -0600 Subject: [Haskell-cafe] [ANN] frpnow-0.12 In-Reply-To: References: <0E8498D7-1AD5-4ABC-918D-989D33ABE842@proclivis.com> Message-ID: <915AA1C8-35BE-48EC-A683-586AD4B30E11@proclivis.com> Atze, Will the magic be revealed during your presentation next week? I guess I better take the paper on the plane and read it 3 more times before I get there :-) Mike > On Aug 24, 2015, at 9:08 AM, Atze van der Ploeg wrote: > > This is the magic of the implementation, as well as Haskell. Very funky indeed. The paper describes it, but I must admit it is all pretty tricky :) > > 2015-08-24 17:01 GMT+02:00 Michael Jones >: > Atze, > > Ah, now it is more clear what the intended representation is. > > Let me address the point about recursion, which reflects more or less my difficulty understanding how a stream produces values in time. > > Referencing the paper version: > > newtype Stream a = S { next :: B (E a) } > > catMaybesStream :: Stream (Maybe a) -> Stream a > catMaybesStream (S s) = S loop where > loop = do e <- s > join <$> plan (nxt <$> e) > -- nxt :: Maybe a -> B (E a) > nxt (Just a) = return (return a) > nxt Nothing = loop > > loop references nxt, and nxt references loop, hence my use of the word ?recursion?. But perhaps saying ?data? is incorrect. My intuition says that the ?a? in B (E a) must be a Stream for the ?recursion? to work. What then really twists my mind up is ?e <-s? getting the next value n times. I?m not an expert in how Haskell evaluates these expressions, but I really would like to understand how that works, because my old ?imperative? mind is in need of an upgrade. > > Mike > >> On Aug 24, 2015, at 8:50 AM, Atze van der Ploeg > wrote: >> >> Hi Mike, cafe, >> >> The implementation in the library is essentially the same as in the paper, but B (E [a]) instead of B (E a) allows multiple simultaneous events, whereas the implementation in the paper does not. The result is B (E [a]), where the list is the list of all results in the event stream which occur at that point. Like the implementation in the paper, the behavior switches as soon as the next event occurs. >> >> I'm a bit unclear on your question, neither implementation is recursive. If you want to use event streams it's best not to look at their implementation, which is tricky, but just use the combinators that are available. >> You can create a behavior that always give the integration of the values in the eventstream as follows: >> >> integrate :: EvStream (Double,Double) -> Double -> Behavior (Behavior Double) >> integrate stream startTime = foldEs update (0,startTime) stream where >> update (total, prevTime) (cur, curTime) = let diff = curTime - prevTime * cur >> in (total + diff, curTime) >> >> Or use Control.FRPNow.Time.integrate :) >> >> The result will give a Behavior (Behavior Double), because the result depends on when we start integrating to prevent the space leak. Does that answer your question? >> >> Cheers, >> >> Atze >> >> >> >> 2015-08-24 16:15 GMT+02:00 Michael Jones >: >> Atze, >> >> I have a question about Streams. >> >> In the Paper Impl the following code: >> >> newtype Stream a = S { next :: B (E a) } >> >> catMaybesStream :: Stream (Maybe a) -> Stream a >> catMaybesStream (S s) = S loop where >> loop = do e <- s >> join <$> plan (nxt <$> e) >> -- nxt :: Maybe a -> B (E a) >> nxt (Just a) = return (return a) >> nxt Nothing = loop >> >> Which I understand. >> >> And in the library the following code: >> >> newtype EvStream a = S { getEs :: Behavior (Event [a]) } >> >> >> catMaybesEs :: EvStream (Maybe a) -> EvStream a >> catMaybesEs s = S $ loop where >> -- loop :: Behavior (Event [a]) >> loop = do e <- getEs s >> join <$> plan (nxt <$> e) >> nxt l = case catMaybes l of >> [] -> loop >> l -> return (return l) >> >> I assume the new type EvStream the intent is for the stream of ?a? to be an array rather than a recursive data structure, based on the name ?getEs?. >> >> But, catMaybeEs is written like the paper version, suggesting it is a recursive data structure arrays. >> >> My goal is to write an integrator for a stream, such that the type signature is: >> >> EvStream (Double,Double) -> EvStream (Double) >> >> where the tuple is (data, time) and the result is (integratedData) >> >> and I modeled the function catMaybeEs, but it is not working. So I want to understand the general way to handle the stream in catMaybesEs. >> >> Mike >> >> >>> On Jul 15, 2015, at 7:25 AM, Atze van der Ploeg > wrote: >>> >>> Dear Cafe, >>> We have released the (nearly) first version of FRPNow, the functional reactive programming library based on the ICFP 2015 paper "Principled Practical FRP: Forget the Past, Change the Future, FRPNow!" (https://www.reddit.com/r/haskell/comments/3ai7hl/principled_practical_frp_forget_the_past_change/ ) >>> The main package: http://hackage.haskell.org/package/frpnow >>> Examples: https://github.com/atzeus/FRPNow/tree/master/Examples >>> Gloss interoperability: http://hackage.haskell.org/package/frpnow-gloss >>> GTK interoperability: http://hackage.haskell.org/package/frpnow-gtk >>> (hackage doesn't like the newer GTK docs, so you can read the docs at http://www.cse.chalmers.se/~atze/frpnow-gtk/ ) >>> >>> Cheers, >>> >>> Atze >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atzeus at gmail.com Mon Aug 24 15:17:17 2015 From: atzeus at gmail.com (Atze van der Ploeg) Date: Mon, 24 Aug 2015 17:17:17 +0200 Subject: [Haskell-cafe] [ANN] frpnow-0.12 In-Reply-To: <915AA1C8-35BE-48EC-A683-586AD4B30E11@proclivis.com> References: <0E8498D7-1AD5-4ABC-918D-989D33ABE842@proclivis.com> <915AA1C8-35BE-48EC-A683-586AD4B30E11@proclivis.com> Message-ID: Sadly, the presentation is only 20 minutes long, including questions, so I have no time to talk about the implementation at all :( However, I'd be happy to answer any questions you have in person, as well as via mail :) Cheers, Atze 2015-08-24 17:14 GMT+02:00 Michael Jones : > Atze, > > Will the magic be revealed during your presentation next week? I guess I > better take the paper on the plane and read it 3 more times before I get > there :-) > > Mike > > On Aug 24, 2015, at 9:08 AM, Atze van der Ploeg wrote: > > This is the magic of the implementation, as well as Haskell. Very funky > indeed. The paper describes it, but I must admit it is all pretty tricky :) > > 2015-08-24 17:01 GMT+02:00 Michael Jones : > >> Atze, >> >> Ah, now it is more clear what the intended representation is. >> >> Let me address the point about recursion, which reflects more or less my >> difficulty understanding how a stream produces values in time. >> >> Referencing the paper version: >> >> newtype Stream a = S { next :: B (E a) } >> >> catMaybesStream :: Stream (Maybe a) -> Stream a >> catMaybesStream (S s) = S loop where >> loop = do e <- s >> join <$> plan (nxt <$> e) >> -- nxt :: Maybe a -> B (E a) >> nxt (Just a) = return (return a) >> nxt Nothing = loop >> >> loop references nxt, and nxt references loop, hence my use of the word >> ?recursion?. But perhaps saying ?data? is incorrect. My intuition says that >> the ?a? in B (E a) must be a Stream for the ?recursion? to work. What then >> really twists my mind up is ?e <-s? getting the next value n times. I?m not >> an expert in how Haskell evaluates these expressions, but I really would >> like to understand how that works, because my old ?imperative? mind is in >> need of an upgrade. >> >> Mike >> >> On Aug 24, 2015, at 8:50 AM, Atze van der Ploeg wrote: >> >> Hi Mike, cafe, >> >> The implementation in the library is essentially the same as in the >> paper, but B (E [a]) instead of B (E a) allows multiple simultaneous >> events, whereas the implementation in the paper does not. The result is B >> (E [a]), where the list is the list of all results in the event stream >> which occur at that point. Like the implementation in the paper, the >> behavior switches as soon as the next event occurs. >> >> I'm a bit unclear on your question, neither implementation is recursive. >> If you want to use event streams it's best not to look at their >> implementation, which is tricky, but just use the combinators that are >> available. >> You can create a behavior that always give the integration of the values >> in the eventstream as follows: >> >> integrate :: EvStream (Double,Double) -> Double -> Behavior (Behavior >> Double) >> integrate stream startTime = foldEs update (0,startTime) stream where >> update (total, prevTime) (cur, curTime) = let diff = curTime - prevTime >> * cur >> in >> (total + diff, curTime) >> >> Or use Control.FRPNow.Time.integrate :) >> >> The result will give a Behavior (Behavior Double), because the result >> depends on when we start integrating to prevent the space leak. Does that >> answer your question? >> >> Cheers, >> >> Atze >> >> >> >> 2015-08-24 16:15 GMT+02:00 Michael Jones : >> >>> Atze, >>> >>> I have a question about Streams. >>> >>> In the Paper Impl the following code: >>> >>> newtype Stream a = S { next :: B (E a) } >>> >>> catMaybesStream :: Stream (Maybe a) -> Stream a >>> catMaybesStream (S s) = S loop where >>> loop = do e <- s >>> join <$> plan (nxt <$> e) >>> -- nxt :: Maybe a -> B (E a) >>> nxt (Just a) = return (return a) >>> nxt Nothing = loop >>> >>> Which I understand. >>> >>> And in the library the following code: >>> >>> newtype EvStream a = S { getEs :: Behavior (Event [a]) } >>> >>> >>> catMaybesEs :: EvStream (Maybe a) -> EvStream a >>> catMaybesEs s = S $ loop where >>> -- loop :: Behavior (Event [a]) >>> loop = do e <- getEs s >>> join <$> plan (nxt <$> e) >>> nxt l = case catMaybes l of >>> [] -> loop >>> l -> return (return l) >>> >>> I assume the new type EvStream the intent is for the stream of ?a? to be >>> an array rather than a recursive data structure, based on the name ?getEs?. >>> >>> But, catMaybeEs is written like the paper version, suggesting it is a >>> recursive data structure arrays. >>> >>> My goal is to write an integrator for a stream, such that the type >>> signature is: >>> >>> EvStream (Double,Double) -> EvStream (Double) >>> >>> where the tuple is (data, time) and the result is (integratedData) >>> >>> and I modeled the function catMaybeEs, but it is not working. So I want >>> to understand the general way to handle the stream in catMaybesEs. >>> >>> Mike >>> >>> >>> On Jul 15, 2015, at 7:25 AM, Atze van der Ploeg >>> wrote: >>> >>> Dear Cafe, >>> We have released the (nearly) first version of FRPNow, the functional >>> reactive programming library based on the ICFP 2015 paper "Principled >>> Practical FRP: Forget the Past, Change the Future, FRPNow!" ( >>> https://www.reddit.com/r/haskell/comments/3ai7hl/principled_practical_frp_forget_the_past_change/ >>> ) >>> The main package: http://hackage.haskell.org/package/frpnow >>> Examples: https://github.com/atzeus/FRPNow/tree/master/Examples >>> Gloss interoperability: http://hackage.haskell.org/package/frpnow-gloss >>> GTK interoperability: http://hackage.haskell.org/package/frpnow-gtk >>> (hackage doesn't like the newer GTK docs, so you can read the docs at >>> http://www.cse.chalmers.se/~atze/frpnow-gtk/ ) >>> >>> Cheers, >>> >>> Atze >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at functionaljobs.com Mon Aug 24 16:00:01 2015 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 24 Aug 2015 12:00:01 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <55db3f84ce49e@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Haskell Engineer at Wagon http://functionaljobs.com/jobs/8857-haskell-engineer-at-wagon Cheers, Sean Murphy FunctionalJobs.com From tikhon at jelv.is Mon Aug 24 18:26:47 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Mon, 24 Aug 2015 11:26:47 -0700 Subject: [Haskell-cafe] Elementary math question: primality test for huge numbers In-Reply-To: References: <20150823213442.66323377@nimrodel> Message-ID: If you don't mind using an external package, you can take a look Math.NumberTheory.Primes and related modules in the arithmoi[1] package. I've used it successfully for some small tasks, so I haven't come close to stress-testing it, but the interface was fine. [1]: http://hackage.haskell.org/package/arithmoi On Mon, Aug 24, 2015 at 3:52 AM, Patrick Chilton wrote: > Haskell also includes the primality testing functions of the GMP library > on Integers, but they're MagicHashed for some reason so handle with care: > > > https://hackage.haskell.org/package/integer-gmp-1.0.0.0/docs/GHC-Integer-GMP-Internals.html#g:12 > > On Mon, Aug 24, 2015 at 6:38 AM, William Yager > wrote: > >> See section 4.4. http://cacr.uwaterloo.ca/hac/about/chap4.pdf >> >> --Will Yager >> >> On Mon, Aug 24, 2015 at 12:34 AM, Christopher Howard >> wrote: >> >>> Hi. I was working through a math chapter explaining the RSA algorithm, >>> and I was implementing it in Haskell for learning sake. However, the >>> chapter does not explain how you efficiently pick the two prime >>> numbers. I scanned through the WP page on primality tests but it was >>> somewhat overwhelming. What would be the standard primality test for >>> this sort of application, and is it already built in to Base somewhere? >>> >>> -- >>> Biblical creationism: http://tinyurl.com/qfyeg4a >>> Free Bible software: http://xiphos.org >>> Software freedom: http://tinyurl.com/qjnpnsm >>> Free computer operating system: http://tinyurl.com/7wczchu >>> Alternative to MS Office: http://tinyurl.com/aw9p6d4 >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Mon Aug 24 20:44:57 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Mon, 24 Aug 2015 22:44:57 +0200 Subject: [Haskell-cafe] Compilation time Message-ID: Hi guys, I have an application with around 7K loc in 4 packages. It takes 1min30 to compile with stack. Is it a normal compilation time? My computer is fairly recent with Intel i7... I run some music in background :). Is there some statistics about compilation time somewhere? Thanks. Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Aug 24 20:54:29 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 24 Aug 2015 15:54:29 -0500 Subject: [Haskell-cafe] Compilation time In-Reply-To: References: Message-ID: Do you have additional packages other than '.' specified in your stack.yaml? If so, are they specified with extra-dep: true or extra-dep: false or not specified at all? On Mon, Aug 24, 2015 at 3:44 PM, Corentin Dupont wrote: > Hi guys, > I have an application with around 7K loc in 4 packages. It takes 1min30 to > compile with stack. > Is it a normal compilation time? > My computer is fairly recent with Intel i7... I run some music in > background :). > Is there some statistics about compilation time somewhere? > Thanks. > Corentin > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Mon Aug 24 21:15:45 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Mon, 24 Aug 2015 23:15:45 +0200 Subject: [Haskell-cafe] Compilation time In-Reply-To: References: Message-ID: My stack.yaml is like that: flags: {} packages: - '.' - ../Nomyx-Core - ../Nomyx-Language - ../Nomyx-Web extra-deps: - Nomyx-Core-0.7.6 - Nomyx-Language-0.7.6 - Nomyx-Web-0.7.6 - hint-server-1.4.2 - DebugTraceHelpers-0.12 - acid-state-0.12.4 - either-unwrap-1.1 - eprocess-1.7.2 - happstack-authenticate-2.1.4 - reform-0.2.7 - reform-blaze-0.2.4 - reform-happstack-0.2.5 - time-recurrence-0.9.2 - web-routes-0.27.9 - web-routes-happstack-0.23.9 - web-routes-regular-0.19.0 - web-routes-th-0.22.3 - boomerang-1.4.5 - data-ordlist-0.4.7.0 - happstack-hsp-7.3.5 - happstack-jmacro-7.0.10 - hsp-0.10.0 - hsx-jmacro-7.3.6 - hsx2hs-0.13.3.2 - ixset-typed-0.3 - jwt-0.6.0 - pwstore-purehaskell-2.1.4 - web-routes-boomerang-0.28.4 - web-routes-hsp-0.24.6 - harp-0.4.1 resolver: lts-2.19 Is that correct? On Mon, Aug 24, 2015 at 10:54 PM, Christopher Allen wrote: > Do you have additional packages other than '.' specified in your > stack.yaml? If so, are they specified with extra-dep: true or extra-dep: > false or not specified at all? > > On Mon, Aug 24, 2015 at 3:44 PM, Corentin Dupont < > corentin.dupont at gmail.com> wrote: > >> Hi guys, >> I have an application with around 7K loc in 4 packages. It takes 1min30 >> to compile with stack. >> Is it a normal compilation time? >> My computer is fairly recent with Intel i7... I run some music in >> background :). >> Is there some statistics about compilation time somewhere? >> Thanks. >> Corentin >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > Chris Allen > Currently working on http://haskellbook.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Aug 24 21:16:50 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 24 Aug 2015 16:16:50 -0500 Subject: [Haskell-cafe] Compilation time In-Reply-To: References: Message-ID: You need to specify extra-deps: true for Nomyx-* if you to cache the build results and treat them like dependencies rather than core parts of your project. On Mon, Aug 24, 2015 at 4:15 PM, Corentin Dupont wrote: > My stack.yaml is like that: > > flags: {} > packages: > - '.' > - ../Nomyx-Core > - ../Nomyx-Language > - ../Nomyx-Web > extra-deps: > - Nomyx-Core-0.7.6 > - Nomyx-Language-0.7.6 > - Nomyx-Web-0.7.6 > - hint-server-1.4.2 > - DebugTraceHelpers-0.12 > - acid-state-0.12.4 > - either-unwrap-1.1 > - eprocess-1.7.2 > - happstack-authenticate-2.1.4 > - reform-0.2.7 > - reform-blaze-0.2.4 > - reform-happstack-0.2.5 > - time-recurrence-0.9.2 > - web-routes-0.27.9 > - web-routes-happstack-0.23.9 > - web-routes-regular-0.19.0 > - web-routes-th-0.22.3 > - boomerang-1.4.5 > - data-ordlist-0.4.7.0 > - happstack-hsp-7.3.5 > - happstack-jmacro-7.0.10 > - hsp-0.10.0 > - hsx-jmacro-7.3.6 > - hsx2hs-0.13.3.2 > - ixset-typed-0.3 > - jwt-0.6.0 > - pwstore-purehaskell-2.1.4 > - web-routes-boomerang-0.28.4 > - web-routes-hsp-0.24.6 > - harp-0.4.1 > resolver: lts-2.19 > > Is that correct? > > On Mon, Aug 24, 2015 at 10:54 PM, Christopher Allen > wrote: > >> Do you have additional packages other than '.' specified in your >> stack.yaml? If so, are they specified with extra-dep: true or extra-dep: >> false or not specified at all? >> >> On Mon, Aug 24, 2015 at 3:44 PM, Corentin Dupont < >> corentin.dupont at gmail.com> wrote: >> >>> Hi guys, >>> I have an application with around 7K loc in 4 packages. It takes 1min30 >>> to compile with stack. >>> Is it a normal compilation time? >>> My computer is fairly recent with Intel i7... I run some music in >>> background :). >>> Is there some statistics about compilation time somewhere? >>> Thanks. >>> Corentin >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Mon Aug 24 21:38:37 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Mon, 24 Aug 2015 23:38:37 +0200 Subject: [Haskell-cafe] Compilation time In-Reply-To: References: Message-ID: i tried, but the time is still around 1m20s. The syntax is: packages: - '.' - location: ../Nomyx-Core extra-dep: true - location: ../Nomyx-Language extra-dep: true - location: ../Nomyx-Web extra-dep: true Right? It spends a lot of time apparently recompiling dependencies: $ stack install Nomyx-Core-0.7.6-30a37de35e61a9979fabc74d548ee6e6: unregistering Nomyx-Language-0.7.6-06bfc13bf2ab48163968e23e340be801: unregistering Nomyx-Web-0.7.6-b75419b3b0faacbe02c94176b84e0564: unregistering Nomyx-Language-0.7.6: build Nomyx-Language-0.7.6: install Nomyx-Core-0.7.6: build Nomyx-Core-0.7.6: install Nomyx-Web-0.7.6: build Nomyx-Web-0.7.6: install Nomyx-0.7.6: build Building Nomyx-0.7.6... Preprocessing executable 'Nomyx' for Nomyx-0.7.6... Linking .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Nomyx/Nomyx ... Nomyx-0.7.6: install Installing executable(s) in /home/cdupont/Dropbox/Nomyx/Nomyx/.stack-work/install/x86_64-linux/lts-2.19/7.8.4/bin Completed all 4 actions. Copying from /home/cdupont/Dropbox/Nomyx/Nomyx/.stack-work/install/x86_64-linux/lts-2.19/7.8.4/bin/Nomyx to /home/cdupont/.local/bin/Nomyx Installed executables to /home/cdupont/.local/bin/: - Nomyx On Mon, Aug 24, 2015 at 11:16 PM, Christopher Allen wrote: > You need to specify extra-deps: true for Nomyx-* if you to cache the build > results and treat them like dependencies rather than core parts of your > project. > > On Mon, Aug 24, 2015 at 4:15 PM, Corentin Dupont < > corentin.dupont at gmail.com> wrote: > >> My stack.yaml is like that: >> >> flags: {} >> packages: >> - '.' >> - ../Nomyx-Core >> - ../Nomyx-Language >> - ../Nomyx-Web >> extra-deps: >> - Nomyx-Core-0.7.6 >> - Nomyx-Language-0.7.6 >> - Nomyx-Web-0.7.6 >> - hint-server-1.4.2 >> - DebugTraceHelpers-0.12 >> - acid-state-0.12.4 >> - either-unwrap-1.1 >> - eprocess-1.7.2 >> - happstack-authenticate-2.1.4 >> - reform-0.2.7 >> - reform-blaze-0.2.4 >> - reform-happstack-0.2.5 >> - time-recurrence-0.9.2 >> - web-routes-0.27.9 >> - web-routes-happstack-0.23.9 >> - web-routes-regular-0.19.0 >> - web-routes-th-0.22.3 >> - boomerang-1.4.5 >> - data-ordlist-0.4.7.0 >> - happstack-hsp-7.3.5 >> - happstack-jmacro-7.0.10 >> - hsp-0.10.0 >> - hsx-jmacro-7.3.6 >> - hsx2hs-0.13.3.2 >> - ixset-typed-0.3 >> - jwt-0.6.0 >> - pwstore-purehaskell-2.1.4 >> - web-routes-boomerang-0.28.4 >> - web-routes-hsp-0.24.6 >> - harp-0.4.1 >> resolver: lts-2.19 >> >> Is that correct? >> >> On Mon, Aug 24, 2015 at 10:54 PM, Christopher Allen >> wrote: >> >>> Do you have additional packages other than '.' specified in your >>> stack.yaml? If so, are they specified with extra-dep: true or extra-dep: >>> false or not specified at all? >>> >>> On Mon, Aug 24, 2015 at 3:44 PM, Corentin Dupont < >>> corentin.dupont at gmail.com> wrote: >>> >>>> Hi guys, >>>> I have an application with around 7K loc in 4 packages. It takes 1min30 >>>> to compile with stack. >>>> Is it a normal compilation time? >>>> My computer is fairly recent with Intel i7... I run some music in >>>> background :). >>>> Is there some statistics about compilation time somewhere? >>>> Thanks. >>>> Corentin >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> >>> -- >>> Chris Allen >>> Currently working on http://haskellbook.com >>> >> >> > > > -- > Chris Allen > Currently working on http://haskellbook.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Aug 24 21:54:28 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 24 Aug 2015 16:54:28 -0500 Subject: [Haskell-cafe] Compilation time In-Reply-To: References: Message-ID: Please tell us if that solved your problem :) On Mon, Aug 24, 2015 at 4:16 PM, Christopher Allen wrote: > You need to specify extra-deps: true for Nomyx-* if you to cache the build > results and treat them like dependencies rather than core parts of your > project. > > On Mon, Aug 24, 2015 at 4:15 PM, Corentin Dupont < > corentin.dupont at gmail.com> wrote: > >> My stack.yaml is like that: >> >> flags: {} >> packages: >> - '.' >> - ../Nomyx-Core >> - ../Nomyx-Language >> - ../Nomyx-Web >> extra-deps: >> - Nomyx-Core-0.7.6 >> - Nomyx-Language-0.7.6 >> - Nomyx-Web-0.7.6 >> - hint-server-1.4.2 >> - DebugTraceHelpers-0.12 >> - acid-state-0.12.4 >> - either-unwrap-1.1 >> - eprocess-1.7.2 >> - happstack-authenticate-2.1.4 >> - reform-0.2.7 >> - reform-blaze-0.2.4 >> - reform-happstack-0.2.5 >> - time-recurrence-0.9.2 >> - web-routes-0.27.9 >> - web-routes-happstack-0.23.9 >> - web-routes-regular-0.19.0 >> - web-routes-th-0.22.3 >> - boomerang-1.4.5 >> - data-ordlist-0.4.7.0 >> - happstack-hsp-7.3.5 >> - happstack-jmacro-7.0.10 >> - hsp-0.10.0 >> - hsx-jmacro-7.3.6 >> - hsx2hs-0.13.3.2 >> - ixset-typed-0.3 >> - jwt-0.6.0 >> - pwstore-purehaskell-2.1.4 >> - web-routes-boomerang-0.28.4 >> - web-routes-hsp-0.24.6 >> - harp-0.4.1 >> resolver: lts-2.19 >> >> Is that correct? >> >> On Mon, Aug 24, 2015 at 10:54 PM, Christopher Allen >> wrote: >> >>> Do you have additional packages other than '.' specified in your >>> stack.yaml? If so, are they specified with extra-dep: true or extra-dep: >>> false or not specified at all? >>> >>> On Mon, Aug 24, 2015 at 3:44 PM, Corentin Dupont < >>> corentin.dupont at gmail.com> wrote: >>> >>>> Hi guys, >>>> I have an application with around 7K loc in 4 packages. It takes 1min30 >>>> to compile with stack. >>>> Is it a normal compilation time? >>>> My computer is fairly recent with Intel i7... I run some music in >>>> background :). >>>> Is there some statistics about compilation time somewhere? >>>> Thanks. >>>> Corentin >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> >>> -- >>> Chris Allen >>> Currently working on http://haskellbook.com >>> >> >> > > > -- > Chris Allen > Currently working on http://haskellbook.com > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Aug 24 22:04:18 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 24 Aug 2015 17:04:18 -0500 Subject: [Haskell-cafe] Compilation time In-Reply-To: References: Message-ID: Did you run it multiple times and get that output? Also you usually want stack build. My work projects use Stack and it'll *only* build my current project when I run stack build (and be fairly fast) unless I changed the source, a cabal file, or a stack.yaml. If you did run it multiple times and got that output, is something touching those directories between builds? On Mon, Aug 24, 2015 at 4:38 PM, Corentin Dupont wrote: > i tried, but the time is still around 1m20s. > The syntax is: > > packages: > - '.' > - location: ../Nomyx-Core > extra-dep: true > - location: ../Nomyx-Language > extra-dep: true > - location: ../Nomyx-Web > extra-dep: true > > Right? > It spends a lot of time apparently recompiling dependencies: > > $ stack install > Nomyx-Core-0.7.6-30a37de35e61a9979fabc74d548ee6e6: unregistering > Nomyx-Language-0.7.6-06bfc13bf2ab48163968e23e340be801: unregistering > Nomyx-Web-0.7.6-b75419b3b0faacbe02c94176b84e0564: unregistering > Nomyx-Language-0.7.6: build > Nomyx-Language-0.7.6: install > Nomyx-Core-0.7.6: build > Nomyx-Core-0.7.6: install > Nomyx-Web-0.7.6: build > Nomyx-Web-0.7.6: install > Nomyx-0.7.6: build > Building Nomyx-0.7.6... > Preprocessing executable 'Nomyx' for Nomyx-0.7.6... > Linking .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Nomyx/Nomyx ... > Nomyx-0.7.6: install > Installing executable(s) in > > /home/cdupont/Dropbox/Nomyx/Nomyx/.stack-work/install/x86_64-linux/lts-2.19/7.8.4/bin > Completed all 4 actions. > Copying from > /home/cdupont/Dropbox/Nomyx/Nomyx/.stack-work/install/x86_64-linux/lts-2.19/7.8.4/bin/Nomyx > to /home/cdupont/.local/bin/Nomyx > > Installed executables to /home/cdupont/.local/bin/: > - Nomyx > > > > On Mon, Aug 24, 2015 at 11:16 PM, Christopher Allen > wrote: > >> You need to specify extra-deps: true for Nomyx-* if you to cache the >> build results and treat them like dependencies rather than core parts of >> your project. >> >> On Mon, Aug 24, 2015 at 4:15 PM, Corentin Dupont < >> corentin.dupont at gmail.com> wrote: >> >>> My stack.yaml is like that: >>> >>> flags: {} >>> packages: >>> - '.' >>> - ../Nomyx-Core >>> - ../Nomyx-Language >>> - ../Nomyx-Web >>> extra-deps: >>> - Nomyx-Core-0.7.6 >>> - Nomyx-Language-0.7.6 >>> - Nomyx-Web-0.7.6 >>> - hint-server-1.4.2 >>> - DebugTraceHelpers-0.12 >>> - acid-state-0.12.4 >>> - either-unwrap-1.1 >>> - eprocess-1.7.2 >>> - happstack-authenticate-2.1.4 >>> - reform-0.2.7 >>> - reform-blaze-0.2.4 >>> - reform-happstack-0.2.5 >>> - time-recurrence-0.9.2 >>> - web-routes-0.27.9 >>> - web-routes-happstack-0.23.9 >>> - web-routes-regular-0.19.0 >>> - web-routes-th-0.22.3 >>> - boomerang-1.4.5 >>> - data-ordlist-0.4.7.0 >>> - happstack-hsp-7.3.5 >>> - happstack-jmacro-7.0.10 >>> - hsp-0.10.0 >>> - hsx-jmacro-7.3.6 >>> - hsx2hs-0.13.3.2 >>> - ixset-typed-0.3 >>> - jwt-0.6.0 >>> - pwstore-purehaskell-2.1.4 >>> - web-routes-boomerang-0.28.4 >>> - web-routes-hsp-0.24.6 >>> - harp-0.4.1 >>> resolver: lts-2.19 >>> >>> Is that correct? >>> >>> On Mon, Aug 24, 2015 at 10:54 PM, Christopher Allen >>> wrote: >>> >>>> Do you have additional packages other than '.' specified in your >>>> stack.yaml? If so, are they specified with extra-dep: true or extra-dep: >>>> false or not specified at all? >>>> >>>> On Mon, Aug 24, 2015 at 3:44 PM, Corentin Dupont < >>>> corentin.dupont at gmail.com> wrote: >>>> >>>>> Hi guys, >>>>> I have an application with around 7K loc in 4 packages. It takes >>>>> 1min30 to compile with stack. >>>>> Is it a normal compilation time? >>>>> My computer is fairly recent with Intel i7... I run some music in >>>>> background :). >>>>> Is there some statistics about compilation time somewhere? >>>>> Thanks. >>>>> Corentin >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> >>>> >>>> -- >>>> Chris Allen >>>> Currently working on http://haskellbook.com >>>> >>> >>> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Tue Aug 25 01:18:57 2015 From: mike at proclivis.com (Michael Jones) Date: Mon, 24 Aug 2015 19:18:57 -0600 Subject: [Haskell-cafe] [ANN] frpnow-0.12 In-Reply-To: References: Message-ID: <5C3A54C2-5760-446B-8CD6-787BFB53E9BF@proclivis.com> Atze, On why I did not use Control.FRPNow.Time.integrate. Wrt code below, which is a bit contrived, in that I don?t really need to integrate sensor data, but if I can, I can then use the same concept for other algorithms, such as filtering and control: The idea was to make sure that time of any sensor reading was as near as possible to the actual measurement. Assuming there are many streams running in parallel in an application, taking the time with the measurement (in same sync evaluation) was assumed to be more accurate than taking it code that consumes the stream and processes the data, after the event from the sync evaluation. Also, if a stream is treated like a pipe and filter, the time can be passed along for later processing stages. As for what the code does, it measures distance every 10ms, integrates the stream, then stops when it reaches 1000.0. integrateTelemetry :: EvStream (Double,Double) -> Double -> Behavior (Behavior (Double,Double)) integrateTelemetry stream startTime = foldEs update (0,startTime) stream where update (total, prevTime) (cur, curTime) = let diff = (curTime - prevTime) * cur in (total + diff, curTime) makeTimedStream :: ((a -> IO ()) -> IO ()) -> Int -> Now (EvStream a) makeTimedStream conv delayMs = do (res,f) <- callbackStream conn <- sync $ repeatedTimer (conv f) $ msDelay $ fromIntegral delayMs return res createIRStream :: SMBus.SMBus -> Now (EvStream (Double,Double)) createIRStream smbus = do stream <- makeTimedStream (\f -> do d <- getDistance smbus now <- getTime f (d,now)) 10 return stream testFRP :: SMBus.SMBus -> Double -> Now (Event ()) testFRP smbus n = do stream <- createIRStream smbus now <- sync getTime b <- sample $ integrateTelemetry stream now enoughEv <- sample (Control.FRPNow.when (((> n) . fst) <$> b)) let closeMessage i = "Current : " ++ show i let doneMessage i = "Done : " ++ show i let message = (closeMessage <$> b) `switch` (doneMessage <$> b <$ enoughEv) traceChanges "Message : " message return enoughEv main = initializeTime runNowMaster (testFRP smbus 1000.0) > On Aug 24, 2015, at 8:50 AM, Atze van der Ploeg wrote: > > Hi Mike, cafe, > > The implementation in the library is essentially the same as in the paper, but B (E [a]) instead of B (E a) allows multiple simultaneous events, whereas the implementation in the paper does not. The result is B (E [a]), where the list is the list of all results in the event stream which occur at that point. Like the implementation in the paper, the behavior switches as soon as the next event occurs. > > I'm a bit unclear on your question, neither implementation is recursive. If you want to use event streams it's best not to look at their implementation, which is tricky, but just use the combinators that are available. > You can create a behavior that always give the integration of the values in the eventstream as follows: > > integrate :: EvStream (Double,Double) -> Double -> Behavior (Behavior Double) > integrate stream startTime = foldEs update (0,startTime) stream where > update (total, prevTime) (cur, curTime) = let diff = curTime - prevTime * cur > in (total + diff, curTime) > > Or use Control.FRPNow.Time.integrate :) > > The result will give a Behavior (Behavior Double), because the result depends on when we start integrating to prevent the space leak. Does that answer your question? > > Cheers, > > Atze > > > > 2015-08-24 16:15 GMT+02:00 Michael Jones >: > Atze, > > I have a question about Streams. > > In the Paper Impl the following code: > > newtype Stream a = S { next :: B (E a) } > > catMaybesStream :: Stream (Maybe a) -> Stream a > catMaybesStream (S s) = S loop where > loop = do e <- s > join <$> plan (nxt <$> e) > -- nxt :: Maybe a -> B (E a) > nxt (Just a) = return (return a) > nxt Nothing = loop > > Which I understand. > > And in the library the following code: > > newtype EvStream a = S { getEs :: Behavior (Event [a]) } > > > catMaybesEs :: EvStream (Maybe a) -> EvStream a > catMaybesEs s = S $ loop where > -- loop :: Behavior (Event [a]) > loop = do e <- getEs s > join <$> plan (nxt <$> e) > nxt l = case catMaybes l of > [] -> loop > l -> return (return l) > > I assume the new type EvStream the intent is for the stream of ?a? to be an array rather than a recursive data structure, based on the name ?getEs?. > > But, catMaybeEs is written like the paper version, suggesting it is a recursive data structure arrays. > > My goal is to write an integrator for a stream, such that the type signature is: > > EvStream (Double,Double) -> EvStream (Double) > > where the tuple is (data, time) and the result is (integratedData) > > and I modeled the function catMaybeEs, but it is not working. So I want to understand the general way to handle the stream in catMaybesEs. > > Mike > > >> On Jul 15, 2015, at 7:25 AM, Atze van der Ploeg > wrote: >> >> Dear Cafe, >> We have released the (nearly) first version of FRPNow, the functional reactive programming library based on the ICFP 2015 paper "Principled Practical FRP: Forget the Past, Change the Future, FRPNow!" (https://www.reddit.com/r/haskell/comments/3ai7hl/principled_practical_frp_forget_the_past_change/ ) >> The main package: http://hackage.haskell.org/package/frpnow >> Examples: https://github.com/atzeus/FRPNow/tree/master/Examples >> Gloss interoperability: http://hackage.haskell.org/package/frpnow-gloss >> GTK interoperability: http://hackage.haskell.org/package/frpnow-gtk >> (hackage doesn't like the newer GTK docs, so you can read the docs at http://www.cse.chalmers.se/~atze/frpnow-gtk/ ) >> >> Cheers, >> >> Atze >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Tue Aug 25 03:18:52 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Mon, 24 Aug 2015 19:18:52 -0800 Subject: [Haskell-cafe] General Functor and Traversable Message-ID: <55dbdb17.4271440a.22d6a.4647@mx.google.com> Consider this: class (Category c, Category d) => Functor c d f where map :: c a b -> d (f a) (f b) Clearly mapM of Traversable is simply map :: Kleisli m a b -> Kleisli m (f a) (f b). But what is traverse? can it be so defined? I am thinking no, as Kleisli composition is not defined in general, but I know very little category theory so I may easily be wrong. From mike at proclivis.com Tue Aug 25 04:27:39 2015 From: mike at proclivis.com (Michael Jones) Date: Mon, 24 Aug 2015 22:27:39 -0600 Subject: [Haskell-cafe] [ANN] frpnow-0.12 In-Reply-To: References: Message-ID: > > > The implementation in the library is essentially the same as in the paper, but B (E [a]) instead of B (E a) allows multiple simultaneous events, whereas the implementation in the paper does not. The result is B (E [a]), where the list is the list of all results in the event stream which occur at that point. Like the implementation in the paper, the behavior switches as soon as the next event occurs. > It looks like ?merge? will take two streams in, one stream out, such that if the input streams have a simultaneous event, they get put into the same array [a]. nextAll seems to get all the events, and next takes the head, and the remainder is lost. Perhaps with some trick they can be separated back into individual streams. Given this, it seems the array is more about merging and splitting streams so that things that happen at the same time do not have to be forced into some arbitrary order. But, suppose you have a synchronous system of measurements, such that you want to intentionally put simultaneous events into a stream? Say the events are: Sensor 1 Meas (E1) Sensor 2 Meas (E2) Sensor 3 Meas (E3) and we can assume they are measured at the same time (one async call), so they are time correlated. We may then want to filter them as a pair, etc. Or there may be logic that if two events that occur at the same time and are in some relation, it triggers a new event E4 as an output. Or we might combine measurements into estimates, like in an estimator with multiple sensors, etc. Your probably guessing I?m a hardware guy :-) Now we could tuple them, and that would work fine, and merge would work fine, but then the events must be of a fixed number. Suppose some events are sampled at different times, so we might want events in the stream to look like: [E1, E2, E3] [E1, E3] [E1, E2, E3] [E1, E3] And say we want to generate the stream with callbackStream, so that one callback call sends the events, and they are put into the list as simultaneous. Now, I am guessing the answer is going to be that this is an abuse of the design intent, and perhaps the tuple could just be a tuple of Maybes, and that in most systems, the number of simultaneous events is fixed, etc. But in systems where sensors can be added or subtracted, and where the type of events are somewhat arbitrary or there may be optional redundency, I can imagine that adding an arbitrary number of events into a stream and having processing that can examine the contents of the stream and adjust to what is present might be nice. Do you have any advice on how to insert events into the stream simultaneously, and ways to split a stream into parallel streams, etc. Mike From michael at snoyman.com Tue Aug 25 04:55:07 2015 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 25 Aug 2015 07:55:07 +0300 Subject: [Haskell-cafe] Compilation time In-Reply-To: References: Message-ID: This sounds like another manifestation of[1]. tl;dr: stack added a feature in the 0.1.3.0 release that checks if modules or data files are used by your code but not listed in your cabal file. The current implementation will then notice on the *second* build that it didn't know about these files the first time around, and rebuild. In single-package projects, this isn't a big deal, but in multi-package projects, it causes a cascade rebuild. Manny and I discussed yesterday, and we have a plan for fixing this. On the other hand, if the rebuild happens every time you run stack build, without requiring any changes to files to trigger it, that would be a problem. If so, please open a separate Github issue for us to assess and discuss. [1] https://github.com/commercialhaskell/stack/issues/838 On Tue, Aug 25, 2015 at 1:04 AM, Christopher Allen wrote: > Did you run it multiple times and get that output? Also you usually want > stack build. > > My work projects use Stack and it'll *only* build my current project when > I run stack build (and be fairly fast) unless I changed the source, a cabal > file, or a stack.yaml. > > If you did run it multiple times and got that output, is something > touching those directories between builds? > > On Mon, Aug 24, 2015 at 4:38 PM, Corentin Dupont < > corentin.dupont at gmail.com> wrote: > >> i tried, but the time is still around 1m20s. >> The syntax is: >> >> packages: >> - '.' >> - location: ../Nomyx-Core >> extra-dep: true >> - location: ../Nomyx-Language >> extra-dep: true >> - location: ../Nomyx-Web >> extra-dep: true >> >> Right? >> It spends a lot of time apparently recompiling dependencies: >> >> $ stack install >> Nomyx-Core-0.7.6-30a37de35e61a9979fabc74d548ee6e6: unregistering >> Nomyx-Language-0.7.6-06bfc13bf2ab48163968e23e340be801: unregistering >> Nomyx-Web-0.7.6-b75419b3b0faacbe02c94176b84e0564: unregistering >> Nomyx-Language-0.7.6: build >> Nomyx-Language-0.7.6: install >> Nomyx-Core-0.7.6: build >> Nomyx-Core-0.7.6: install >> Nomyx-Web-0.7.6: build >> Nomyx-Web-0.7.6: install >> Nomyx-0.7.6: build >> Building Nomyx-0.7.6... >> Preprocessing executable 'Nomyx' for Nomyx-0.7.6... >> Linking .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Nomyx/Nomyx ... >> Nomyx-0.7.6: install >> Installing executable(s) in >> >> /home/cdupont/Dropbox/Nomyx/Nomyx/.stack-work/install/x86_64-linux/lts-2.19/7.8.4/bin >> Completed all 4 actions. >> Copying from >> /home/cdupont/Dropbox/Nomyx/Nomyx/.stack-work/install/x86_64-linux/lts-2.19/7.8.4/bin/Nomyx >> to /home/cdupont/.local/bin/Nomyx >> >> Installed executables to /home/cdupont/.local/bin/: >> - Nomyx >> >> >> >> On Mon, Aug 24, 2015 at 11:16 PM, Christopher Allen >> wrote: >> >>> You need to specify extra-deps: true for Nomyx-* if you to cache the >>> build results and treat them like dependencies rather than core parts of >>> your project. >>> >>> On Mon, Aug 24, 2015 at 4:15 PM, Corentin Dupont < >>> corentin.dupont at gmail.com> wrote: >>> >>>> My stack.yaml is like that: >>>> >>>> flags: {} >>>> packages: >>>> - '.' >>>> - ../Nomyx-Core >>>> - ../Nomyx-Language >>>> - ../Nomyx-Web >>>> extra-deps: >>>> - Nomyx-Core-0.7.6 >>>> - Nomyx-Language-0.7.6 >>>> - Nomyx-Web-0.7.6 >>>> - hint-server-1.4.2 >>>> - DebugTraceHelpers-0.12 >>>> - acid-state-0.12.4 >>>> - either-unwrap-1.1 >>>> - eprocess-1.7.2 >>>> - happstack-authenticate-2.1.4 >>>> - reform-0.2.7 >>>> - reform-blaze-0.2.4 >>>> - reform-happstack-0.2.5 >>>> - time-recurrence-0.9.2 >>>> - web-routes-0.27.9 >>>> - web-routes-happstack-0.23.9 >>>> - web-routes-regular-0.19.0 >>>> - web-routes-th-0.22.3 >>>> - boomerang-1.4.5 >>>> - data-ordlist-0.4.7.0 >>>> - happstack-hsp-7.3.5 >>>> - happstack-jmacro-7.0.10 >>>> - hsp-0.10.0 >>>> - hsx-jmacro-7.3.6 >>>> - hsx2hs-0.13.3.2 >>>> - ixset-typed-0.3 >>>> - jwt-0.6.0 >>>> - pwstore-purehaskell-2.1.4 >>>> - web-routes-boomerang-0.28.4 >>>> - web-routes-hsp-0.24.6 >>>> - harp-0.4.1 >>>> resolver: lts-2.19 >>>> >>>> Is that correct? >>>> >>>> On Mon, Aug 24, 2015 at 10:54 PM, Christopher Allen >>>> wrote: >>>> >>>>> Do you have additional packages other than '.' specified in your >>>>> stack.yaml? If so, are they specified with extra-dep: true or extra-dep: >>>>> false or not specified at all? >>>>> >>>>> On Mon, Aug 24, 2015 at 3:44 PM, Corentin Dupont < >>>>> corentin.dupont at gmail.com> wrote: >>>>> >>>>>> Hi guys, >>>>>> I have an application with around 7K loc in 4 packages. It takes >>>>>> 1min30 to compile with stack. >>>>>> Is it a normal compilation time? >>>>>> My computer is fairly recent with Intel i7... I run some music in >>>>>> background :). >>>>>> Is there some statistics about compilation time somewhere? >>>>>> Thanks. >>>>>> Corentin >>>>>> >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Chris Allen >>>>> Currently working on http://haskellbook.com >>>>> >>>> >>>> >>> >>> >>> -- >>> Chris Allen >>> Currently working on http://haskellbook.com >>> >> >> > > > -- > Chris Allen > Currently working on http://haskellbook.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Tue Aug 25 11:42:43 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 25 Aug 2015 13:42:43 +0200 Subject: [Haskell-cafe] Compilation time In-Reply-To: References: Message-ID: I think it's working correctly: it doesn't recompile if not necessary. It's just that the compilation is slow: 1m30 to 4m if the system is a bit loaded. On Tue, Aug 25, 2015 at 6:55 AM, Michael Snoyman wrote: > This sounds like another manifestation of[1]. tl;dr: stack added a feature > in the 0.1.3.0 release that checks if modules or data files are used by > your code but not listed in your cabal file. The current implementation > will then notice on the *second* build that it didn't know about these > files the first time around, and rebuild. In single-package projects, this > isn't a big deal, but in multi-package projects, it causes a cascade > rebuild. Manny and I discussed yesterday, and we have a plan for fixing > this. > > On the other hand, if the rebuild happens every time you run stack build, > without requiring any changes to files to trigger it, that would be a > problem. If so, please open a separate Github issue for us to assess and > discuss. > > [1] https://github.com/commercialhaskell/stack/issues/838 > > On Tue, Aug 25, 2015 at 1:04 AM, Christopher Allen > wrote: > >> Did you run it multiple times and get that output? Also you usually want >> stack build. >> >> My work projects use Stack and it'll *only* build my current project when >> I run stack build (and be fairly fast) unless I changed the source, a cabal >> file, or a stack.yaml. >> >> If you did run it multiple times and got that output, is something >> touching those directories between builds? >> >> On Mon, Aug 24, 2015 at 4:38 PM, Corentin Dupont < >> corentin.dupont at gmail.com> wrote: >> >>> i tried, but the time is still around 1m20s. >>> The syntax is: >>> >>> packages: >>> - '.' >>> - location: ../Nomyx-Core >>> extra-dep: true >>> - location: ../Nomyx-Language >>> extra-dep: true >>> - location: ../Nomyx-Web >>> extra-dep: true >>> >>> Right? >>> It spends a lot of time apparently recompiling dependencies: >>> >>> $ stack install >>> Nomyx-Core-0.7.6-30a37de35e61a9979fabc74d548ee6e6: unregistering >>> Nomyx-Language-0.7.6-06bfc13bf2ab48163968e23e340be801: unregistering >>> Nomyx-Web-0.7.6-b75419b3b0faacbe02c94176b84e0564: unregistering >>> Nomyx-Language-0.7.6: build >>> Nomyx-Language-0.7.6: install >>> Nomyx-Core-0.7.6: build >>> Nomyx-Core-0.7.6: install >>> Nomyx-Web-0.7.6: build >>> Nomyx-Web-0.7.6: install >>> Nomyx-0.7.6: build >>> Building Nomyx-0.7.6... >>> Preprocessing executable 'Nomyx' for Nomyx-0.7.6... >>> Linking .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Nomyx/Nomyx >>> ... >>> Nomyx-0.7.6: install >>> Installing executable(s) in >>> >>> /home/cdupont/Dropbox/Nomyx/Nomyx/.stack-work/install/x86_64-linux/lts-2.19/7.8.4/bin >>> Completed all 4 actions. >>> Copying from >>> /home/cdupont/Dropbox/Nomyx/Nomyx/.stack-work/install/x86_64-linux/lts-2.19/7.8.4/bin/Nomyx >>> to /home/cdupont/.local/bin/Nomyx >>> >>> Installed executables to /home/cdupont/.local/bin/: >>> - Nomyx >>> >>> >>> >>> On Mon, Aug 24, 2015 at 11:16 PM, Christopher Allen >>> wrote: >>> >>>> You need to specify extra-deps: true for Nomyx-* if you to cache the >>>> build results and treat them like dependencies rather than core parts of >>>> your project. >>>> >>>> On Mon, Aug 24, 2015 at 4:15 PM, Corentin Dupont < >>>> corentin.dupont at gmail.com> wrote: >>>> >>>>> My stack.yaml is like that: >>>>> >>>>> flags: {} >>>>> packages: >>>>> - '.' >>>>> - ../Nomyx-Core >>>>> - ../Nomyx-Language >>>>> - ../Nomyx-Web >>>>> extra-deps: >>>>> - Nomyx-Core-0.7.6 >>>>> - Nomyx-Language-0.7.6 >>>>> - Nomyx-Web-0.7.6 >>>>> - hint-server-1.4.2 >>>>> - DebugTraceHelpers-0.12 >>>>> - acid-state-0.12.4 >>>>> - either-unwrap-1.1 >>>>> - eprocess-1.7.2 >>>>> - happstack-authenticate-2.1.4 >>>>> - reform-0.2.7 >>>>> - reform-blaze-0.2.4 >>>>> - reform-happstack-0.2.5 >>>>> - time-recurrence-0.9.2 >>>>> - web-routes-0.27.9 >>>>> - web-routes-happstack-0.23.9 >>>>> - web-routes-regular-0.19.0 >>>>> - web-routes-th-0.22.3 >>>>> - boomerang-1.4.5 >>>>> - data-ordlist-0.4.7.0 >>>>> - happstack-hsp-7.3.5 >>>>> - happstack-jmacro-7.0.10 >>>>> - hsp-0.10.0 >>>>> - hsx-jmacro-7.3.6 >>>>> - hsx2hs-0.13.3.2 >>>>> - ixset-typed-0.3 >>>>> - jwt-0.6.0 >>>>> - pwstore-purehaskell-2.1.4 >>>>> - web-routes-boomerang-0.28.4 >>>>> - web-routes-hsp-0.24.6 >>>>> - harp-0.4.1 >>>>> resolver: lts-2.19 >>>>> >>>>> Is that correct? >>>>> >>>>> On Mon, Aug 24, 2015 at 10:54 PM, Christopher Allen >>>> > wrote: >>>>> >>>>>> Do you have additional packages other than '.' specified in your >>>>>> stack.yaml? If so, are they specified with extra-dep: true or extra-dep: >>>>>> false or not specified at all? >>>>>> >>>>>> On Mon, Aug 24, 2015 at 3:44 PM, Corentin Dupont < >>>>>> corentin.dupont at gmail.com> wrote: >>>>>> >>>>>>> Hi guys, >>>>>>> I have an application with around 7K loc in 4 packages. It takes >>>>>>> 1min30 to compile with stack. >>>>>>> Is it a normal compilation time? >>>>>>> My computer is fairly recent with Intel i7... I run some music in >>>>>>> background :). >>>>>>> Is there some statistics about compilation time somewhere? >>>>>>> Thanks. >>>>>>> Corentin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Haskell-Cafe mailing list >>>>>>> Haskell-Cafe at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Chris Allen >>>>>> Currently working on http://haskellbook.com >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Chris Allen >>>> Currently working on http://haskellbook.com >>>> >>> >>> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chneukirchen at gmail.com Tue Aug 25 12:16:00 2015 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Tue, 25 Aug 2015 14:16:00 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2015-08-27 @ 19:30 Augustiner-Keller Biergarten Message-ID: <87fv37zhq7.fsf@gmail.com> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, August 27 at **Augustiner-Keller Biergarten** (Arnulfstr. 52) in the self-service area (rougly here: https://goo.gl/maps/QmnMc) at 19h30. For details see: http://www.haskell-munich.de/dates Please note the changed location this time! The weather will be nice. If you plan to join, please add yourself to this dudle. It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-aug-2015/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From alex323 at gmail.com Tue Aug 25 22:34:29 2015 From: alex323 at gmail.com (Alex) Date: Tue, 25 Aug 2015 18:34:29 -0400 Subject: [Haskell-cafe] 'Scientific' loses significant digits Message-ID: <20150825183429.1abf1ace@gmail.com> Hi: Does anyone know why is this true? ((fromJust . readMaybe) "1.00000000" :: Scientific) == ((fromJust . readMaybe) "1" :: Scientific) -- Alex From lambda.fairy at gmail.com Wed Aug 26 00:00:51 2015 From: lambda.fairy at gmail.com (Chris Wong) Date: Wed, 26 Aug 2015 12:00:51 +1200 Subject: [Haskell-cafe] 'Scientific' loses significant digits In-Reply-To: <20150825183429.1abf1ace@gmail.com> References: <20150825183429.1abf1ace@gmail.com> Message-ID: On Wed, Aug 26, 2015 at 10:34 AM, Alex wrote: > Hi: > > Does anyone know why is this true? > > ((fromJust . readMaybe) "1.00000000" :: Scientific) == ((fromJust . readMaybe) "1" :: Scientific) Hi Alex, This is intended behavior. Scientific's primary use case is as an intermediate type, to be converted to e.g. Double or Integer later. So there's no need for it to account for significant digits. > -- > Alex > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Chris Wong (https://lambda.xyz) "Humans find such fascinating ways to waste their time." -- Steven Universe From winterkoninkje at gmail.com Wed Aug 26 02:46:26 2015 From: winterkoninkje at gmail.com (wren romano) Date: Tue, 25 Aug 2015 22:46:26 -0400 Subject: [Haskell-cafe] Elementary math question: primality test for huge numbers In-Reply-To: References: <20150823213442.66323377@nimrodel> Message-ID: On Mon, Aug 24, 2015 at 1:38 AM, William Yager wrote: > See section 4.4. http://cacr.uwaterloo.ca/hac/about/chap4.pdf If it helps to have a (small) prime number generator, there's an efficient implementation in exact-combinatorics[1] [1] -- Live well, ~wren From ajnsit at gmail.com Wed Aug 26 12:25:45 2015 From: ajnsit at gmail.com (Anupam Jain) Date: Wed, 26 Aug 2015 17:55:45 +0530 Subject: [Haskell-cafe] "Assignment" in do blocks? Message-ID: Hi all, I'd like to propose an inbuilt "assignment" operator for use within do-blocks. Here's a common pattern - do foo <- someaction do something with foo -- Here we "update" the value of foo let foo' = bar foo -- The code from this point onwards shouldn't use foo -- but there is no way to enforce that What I'd like to do instead is something like - let foo = bar foo But to Haskell this is a recursive definition instead of an update to the previous value. I can do this instead - foo <- return $ bar foo which works fine but (I assume) GHC currently can't optimise it for arbitrary monads. Also it won't necessarily work if the monad laws don't hold. It would be nice to have an "assignment arrow", say (<-=), which lets GHC optimise this, so - foo <-= bar foo ... desugars to something like - foo' (bar foo) where foo' foo = ... -- Anupam From fa-ml at ariis.it Wed Aug 26 12:34:52 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 26 Aug 2015 14:34:52 +0200 Subject: [Haskell-cafe] "Assignment" in do blocks? In-Reply-To: References: Message-ID: <20150826123452.GA1278@casa.casa> On Wed, Aug 26, 2015 at 05:55:45PM +0530, Anupam Jain wrote: > Hi all, > > I'd like to propose an inbuilt "assignment" operator for use within > do-blocks. Time to add your proposal here! https://wiki.haskell.org/Nitpicks Honestly, I feel it would break the way I read Haskell programs (i.e. no reassignment surprises). From oleg.grenrus at iki.fi Wed Aug 26 12:55:15 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 26 Aug 2015 15:55:15 +0300 Subject: [Haskell-cafe] "Assignment" in do blocks? In-Reply-To: <20150826123452.GA1278@casa.casa> References: <20150826123452.GA1278@casa.casa> Message-ID: <20E208C5-B341-4206-9C08-CB1100824897@iki.fi> It?s not re-assigment, it?s rather feature request for non-rec-let (as let in Haskell is recursive) and some pragma to say ?yes, I do shadow name on purpose" For example fix f = let x = f x in x -- let is recursive niceTry f = noreclet x = f x in x -- Not in scope: ?x? - Oleg > On 26 Aug 2015, at 15:34, Francesco Ariis wrote: > > On Wed, Aug 26, 2015 at 05:55:45PM +0530, Anupam Jain wrote: >> Hi all, >> >> I'd like to propose an inbuilt "assignment" operator for use within >> do-blocks. > > Time to add your proposal here! > https://wiki.haskell.org/Nitpicks > > Honestly, I feel it would break the way I read Haskell programs > (i.e. no reassignment surprises). > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From fa-ml at ariis.it Wed Aug 26 13:59:38 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 26 Aug 2015 15:59:38 +0200 Subject: [Haskell-cafe] "Assignment" in do blocks? In-Reply-To: <20E208C5-B341-4206-9C08-CB1100824897@iki.fi> References: <20150826123452.GA1278@casa.casa> <20E208C5-B341-4206-9C08-CB1100824897@iki.fi> Message-ID: <20150826135938.GA2852@casa.casa> On Wed, Aug 26, 2015 at 03:55:15PM +0300, Oleg Grenrus wrote: > It?s not re-assigment, it?s rather feature request for non-rec-let > (as let in Haskell is recursive) > and some pragma to say ?yes, I do shadow name on purpose" Ah, I see. Still I feel that, as much as it is easily rewriteable to a `lambda (etc etc` (which will shadow the first `a`) (let ((a 10) (a 5)) (a)) will bite you back as the val-exprs list grows. From tdammers at gmail.com Wed Aug 26 14:44:49 2015 From: tdammers at gmail.com (Tobias Dammers) Date: Wed, 26 Aug 2015 16:44:49 +0200 Subject: [Haskell-cafe] "Assignment" in do blocks? In-Reply-To: References: Message-ID: <20150826144449.GB32085@barbados> IMO, having <- in do syntax look like assignment is bad enough as it is, no need to further enforce the illusion. The variable shadowing that effectively occurs in that example is still just as bad as regular shadowing. On Wed, Aug 26, 2015 at 05:55:45PM +0530, Anupam Jain wrote: > Hi all, > > I'd like to propose an inbuilt "assignment" operator for use within do-blocks. > > Here's a common pattern - > > do > foo <- someaction > do something with foo > -- Here we "update" the value of foo > let foo' = bar foo > -- The code from this point onwards shouldn't use foo > -- but there is no way to enforce that > > What I'd like to do instead is something like - > > let foo = bar foo > > But to Haskell this is a recursive definition instead of an update to > the previous value. > > I can do this instead - > > foo <- return $ bar foo > > which works fine but (I assume) GHC currently can't optimise it for > arbitrary monads. Also it won't necessarily work if the monad laws > don't hold. > > It would be nice to have an "assignment arrow", say (<-=), which lets > GHC optimise this, so - > > foo <-= bar foo > ... > > desugars to something like - > > foo' (bar foo) > where > foo' foo = ... > > > -- Anupam > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From corentin.dupont at gmail.com Wed Aug 26 15:09:26 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Wed, 26 Aug 2015 17:09:26 +0200 Subject: [Haskell-cafe] Stack transitive dependencies Message-ID: Hello, I have a package depending on another: Foo/stack.yaml: flags: {} packages: - '.' - location: ../Bar extra-dep: true extra-deps: - Bar-0.7.6 resolver: lts-2.19 When I compile (stack build), I obtain: -- While attempting to add dependency, Could not find package DebugTraceHelpers in known packages -- Failure when adding dependencies: DebugTraceHelpers: needed (==0.12.*), but not present in build plan, latest is 0.12 needed for package: Bar-0.7.6 I find it strange that it asks for DebugTraceHelpers because it's not a direct dependency of my package, but a dependency of a dependency. It is correctly mentioned in Bar/stack.yml: flags: {} packages: - '.' extra-deps: - DebugTraceHelpers-0.12 resolver: lts-2.19 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Wed Aug 26 16:09:20 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 26 Aug 2015 23:09:20 +0700 Subject: [Haskell-cafe] "Assignment" in do blocks? In-Reply-To: References: Message-ID: On Wed, Aug 26, 2015 at 7:25 PM, Anupam Jain wrote: > What I'd like to do instead is something like - > > let foo = bar foo > > But to Haskell this is a recursive definition instead of an update to > the previous value. > This is a chestnut at least two years old. Last time I remember, the discussion frothed under the rubric of "non-recursive let": https://mail.haskell.org/pipermail/haskell-cafe/2013-July/109116.html -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.carnecky at gmail.com Wed Aug 26 21:57:04 2015 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Wed, 26 Aug 2015 21:57:04 +0000 Subject: [Haskell-cafe] Google Cloud API Message-ID: I recently migrated some infrastructure from AWS to Google Cloud and needed a way to upload a file to a storage bucket. For AWS there's an awesome Haskell library (aws), but I couldn't find anything comparable for interacting with the Google Cloud APIs. While it wouldn't be difficult to write a standalone function for that simple task, I decided to package it up in a library. Currently implemented is uploading a ByteString to a bucket and some metadata server queries. That's all I need currently, but I may add a few more selected APIs in the near future (mostly around managing compute instances). Adding support for new APIs should be relatively easy, even without having to change the library itself. All the internals are exposed to users of the library. There is nothing private or hidden. The library gives you access to convenience functions to send HTTP requests. That, coupled with a bit of JSON/aeson parsing, should cover most use cases. http://hackage.haskell.org/package/google-cloud https://github.com/wereHamster/google-cloud#readme -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.fine at gmail.com Wed Aug 26 22:37:54 2015 From: mark.fine at gmail.com (Mark Fine) Date: Wed, 26 Aug 2015 15:37:54 -0700 Subject: [Haskell-cafe] Google Cloud API In-Reply-To: References: Message-ID: Great! Would love to hear if anyone's pursuing generating the API's from the discovery service in a manner similar to the excellent amazonka for AWS. Mark On Wed, Aug 26, 2015 at 2:57 PM, Tomas Carnecky wrote: > I recently migrated some infrastructure from AWS to Google Cloud and > needed a way to upload a file to a storage bucket. For AWS there's an > awesome Haskell library (aws), but I couldn't find anything comparable for > interacting with the Google Cloud APIs. > > While it wouldn't be difficult to write a standalone function for that > simple task, I decided to package it up in a library. Currently implemented > is uploading a ByteString to a bucket and some metadata server queries. > That's all I need currently, but I may add a few more selected APIs in the > near future (mostly around managing compute instances). > > Adding support for new APIs should be relatively easy, even without having > to change the library itself. All the internals are exposed to users of the > library. There is nothing private or hidden. The library gives you access > to convenience functions to send HTTP requests. That, coupled with a bit of > JSON/aeson parsing, should cover most use cases. > > http://hackage.haskell.org/package/google-cloud > https://github.com/wereHamster/google-cloud#readme > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.cameron at covenanteyes.com Thu Aug 27 04:44:21 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Thu, 27 Aug 2015 04:44:21 +0000 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: References: <55D84DB7.1070002@htwk-leipzig.de> , Message-ID: <1440650666129.89913@covenanteyes.com> I stumbled upon this old proposal which seems hauntingly relevant: http://repetae.net/recent/out/classalias.html ________________________________________ From: Haskell-Cafe on behalf of Bardur Arantsson Sent: Saturday, August 22, 2015 10:31 AM To: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] List of nitpicks On 08/22/2015 03:33 PM, Brandon Allbery wrote: > On Sat, Aug 22, 2015 at 6:23 AM, Johannes Waldmann < > johannes.waldmann at htwk-leipzig.de> wrote: > >> I believe that (PatternSignatures and) ScopedTypeVariables >> should be on by default. It is currently off only to help those >> that are too lazy to write "forall t . " in (inner) declarations? >> > > More because the language committee is ridiculously conservative. I think > this is Public Enemy Number One as far as extensions that really ought to > be part of the standard by now. > > I can only second that. I seems to me that trying to have the default experience in GHC be some sort of Haskell2010 pseudo-standard is not useful[1]. I happen to believe that standards without more than one serious implementor are a terrible way to move things along. Let's *exploit* the fact that there is only one[2] really viable compiler at this precise moment in time, and move things forward more rapidly! [1] I believe there were some AMP things in base/Prelude which mean that GHC-by-default is not technically Haskell2010. [2] I realize that there's JHC, UHC, etc., but let's face it... unless those compilers implement most of the GHC extensions, then you're not going to get anything substantial (e.g. lens) to compile with those compilers. Regards, _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From konn.jinro at gmail.com Thu Aug 27 04:55:13 2015 From: konn.jinro at gmail.com (Hiromi ISHII) Date: Thu, 27 Aug 2015 13:55:13 +0900 Subject: [Haskell-cafe] Template Haskell and packages using Obj-C FFI Message-ID: Hi cafe, I'm currently writing objc specific marshaller for inline-c, and faced with strange behaviour of Template Haskell and FFI. It turns out that it's irrelevant to inline-c and matter of GHC. Here is minimal example package for failure: https://github.com/konn/objcth This tiny package is built up with two parts: 1. A wrapper library to call NSLog function with Haskell's String value. This uses FFI interface, 2. An executable which calls the above library to say hello. If 2. does not contain any Template Haskell macros, everything works fine. But if any TH macro presents, even only top level splice `$(return [])`, then compiler halts with following error: ``` : can't load .so/.DLL for: /Users/myname/Documents/Programming/Haskell/lab/ghcbugs/objcth/.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/libHSobjcth-0.1.0.0-IBzJnZWD04lEmS0Ot4HRVO-ghc7.10.2.dylib (dlopen(/Users/myname/Documents/Programming/Haskell/lab/ghcbugs/objcth/.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/libHSobjcth-0.1.0.0-IBzJnZWD04lEmS0Ot4HRVO-ghc7.10.2.dylib, 5): Symbol not found: _OBJC_CLASS_$_NSString Referenced from: /Users/myname/Documents/Programming/Haskell/lab/ghcbugs/objcth/.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/libHSobjcth-0.1.0.0-IBzJnZWD04lEmS0Ot4HRVO-ghc7.10.2.dylib Expected in: flat namespace in /Users/myname/Documents/Programming/Haskell/lab/ghcbugs/objcth/.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/libHSobjcth-0.1.0.0-IBzJnZWD04lEmS0Ot4HRVO-ghc7.10.2.dylib) ``` I used stack to build automatically, but cabal-install produces almost the same result (modulo paths to dist files). TH uses GHCi internally, so perhaps it's related to GHCi? If I replace the call for NSLog and [NSSring stringWith...] with puts c-function, everything gets fine. Is there any workaround, or it's the bug of GHC? Here is my environment: * OS X Yosemite 10.10.5 * Haskell Platform 7.10.2a * llvm-3.5 (installed via brew install llvm35) $ tail -n3 /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/lib/ghc-7.10.2/settings , ("LLVM llc command","llc-3.5") , ("LLVM opt command","opt-3.5") ] -- Hiromi ISHII konn.jinro at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brendan.g.hay at gmail.com Thu Aug 27 06:14:52 2015 From: brendan.g.hay at gmail.com (Brendan Hay) Date: Thu, 27 Aug 2015 08:14:52 +0200 Subject: [Haskell-cafe] Google Cloud API In-Reply-To: References: Message-ID: I'd recently generated a limited operation set for personal use. I had no plans to continue with the entire API surface, but I'll tidy up what I have and put it on GitHub if others are interested. On 27 August 2015 at 00:37, Mark Fine wrote: > Great! > > Would love to hear if anyone's pursuing generating the API's from the discovery > service in a manner > similar to the excellent amazonka for AWS. > > Mark > > On Wed, Aug 26, 2015 at 2:57 PM, Tomas Carnecky > wrote: > >> I recently migrated some infrastructure from AWS to Google Cloud and >> needed a way to upload a file to a storage bucket. For AWS there's an >> awesome Haskell library (aws), but I couldn't find anything comparable for >> interacting with the Google Cloud APIs. >> >> While it wouldn't be difficult to write a standalone function for that >> simple task, I decided to package it up in a library. Currently implemented >> is uploading a ByteString to a bucket and some metadata server queries. >> That's all I need currently, but I may add a few more selected APIs in the >> near future (mostly around managing compute instances). >> >> Adding support for new APIs should be relatively easy, even without >> having to change the library itself. All the internals are exposed to users >> of the library. There is nothing private or hidden. The library gives you >> access to convenience functions to send HTTP requests. That, coupled with a >> bit of JSON/aeson parsing, should cover most use cases. >> >> http://hackage.haskell.org/package/google-cloud >> https://github.com/wereHamster/google-cloud#readme >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrien at haxaire.org Thu Aug 27 07:07:42 2015 From: adrien at haxaire.org (Adrien Haxaire) Date: Thu, 27 Aug 2015 09:07:42 +0200 Subject: [Haskell-cafe] Google Cloud API In-Reply-To: References: Message-ID: <4b40356811ef90c014bfcc72bb73a0f9@haxaire.org> Hi, thank you both, it's going to be helpful! Cheers, Adrien On 2015-08-27 08:14, Brendan Hay wrote: > I'd recently generated a limited operation set for personal use. I had > no plans to continue with the entire API surface, but I'll tidy up > what I have and put it on GitHub if others are interested. > > On 27 August 2015 at 00:37, Mark Fine wrote: > >> Great! >> >> Would love to hear if anyone's pursuing generating the API's from >> the?discovery service [4]?in a manner similar to the excellent >> amazonka for AWS. >> >> Mark >> >> On Wed, Aug 26, 2015 at 2:57 PM, Tomas Carnecky >> wrote: >> >>> I recently migrated some infrastructure from AWS to Google Cloud >>> and needed a way to upload a file to a storage bucket. For AWS >>> there's an awesome Haskell library (aws), but I couldn't find >>> anything comparable for interacting with the Google Cloud APIs. >>> >>> While it wouldn't be difficult to write a standalone function for >>> that simple task, I decided to package it up in a library. >>> Currently implemented is uploading a ByteString to a bucket and >>> some metadata server queries. That's all I need currently, but I >>> may add a few more selected APIs in the near future (mostly around >>> managing compute instances). >>> >>> Adding support for new APIs should be relatively easy, even >>> without having to change the library itself. All the internals are >>> exposed to users of the library. There is nothing private or >>> hidden. The library gives you access to convenience functions to >>> send HTTP requests. That, coupled with a bit of JSON/aeson >>> parsing, should cover most use cases. >>> >>> http://hackage.haskell.org/package/google-cloud [1] >>> >>> https://github.com/wereHamster/google-cloud#readme [2] >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe [3] >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe [3] > > > > Links: > ------ > [1] http://hackage.haskell.org/package/google-cloud > [2] https://github.com/wereHamster/google-cloud#readme > [3] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > [4] https://developers.google.com/discovery/libraries > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Adrien Haxaire www.adrienhaxaire.org | @adrienhaxaire From tomas.carnecky at gmail.com Thu Aug 27 07:22:02 2015 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Thu, 27 Aug 2015 07:22:02 +0000 Subject: [Haskell-cafe] Google Cloud API In-Reply-To: <4b40356811ef90c014bfcc72bb73a0f9@haxaire.org> References: <4b40356811ef90c014bfcc72bb73a0f9@haxaire.org> Message-ID: I wasn't aware of the discovery service. I'd be open to adding it to my library (though then it becomes more a google-api library rather than google-cloud). I see that there is no description of the internal metadata service. Maybe it doesn't count as a google api? On Thu, Aug 27, 2015 at 9:07 AM Adrien Haxaire wrote: > Hi, > > thank you both, it's going to be helpful! > > Cheers, > Adrien > > > On 2015-08-27 08:14, Brendan Hay wrote: > > I'd recently generated a limited operation set for personal use. I had > > no plans to continue with the entire API surface, but I'll tidy up > > what I have and put it on GitHub if others are interested. > > > > On 27 August 2015 at 00:37, Mark Fine wrote: > > > >> Great! > >> > >> Would love to hear if anyone's pursuing generating the API's from > >> the discovery service [4] in a manner similar to the excellent > >> amazonka for AWS. > >> > >> Mark > >> > >> On Wed, Aug 26, 2015 at 2:57 PM, Tomas Carnecky > >> wrote: > >> > >>> I recently migrated some infrastructure from AWS to Google Cloud > >>> and needed a way to upload a file to a storage bucket. For AWS > >>> there's an awesome Haskell library (aws), but I couldn't find > >>> anything comparable for interacting with the Google Cloud APIs. > >>> > >>> While it wouldn't be difficult to write a standalone function for > >>> that simple task, I decided to package it up in a library. > >>> Currently implemented is uploading a ByteString to a bucket and > >>> some metadata server queries. That's all I need currently, but I > >>> may add a few more selected APIs in the near future (mostly around > >>> managing compute instances). > >>> > >>> Adding support for new APIs should be relatively easy, even > >>> without having to change the library itself. All the internals are > >>> exposed to users of the library. There is nothing private or > >>> hidden. The library gives you access to convenience functions to > >>> send HTTP requests. That, coupled with a bit of JSON/aeson > >>> parsing, should cover most use cases. > >>> > >>> http://hackage.haskell.org/package/google-cloud [1] > >>> > >>> https://github.com/wereHamster/google-cloud#readme [2] > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe [3] > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe [3] > > > > > > > > Links: > > ------ > > [1] http://hackage.haskell.org/package/google-cloud > > [2] https://github.com/wereHamster/google-cloud#readme > > [3] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > [4] https://developers.google.com/discovery/libraries > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- > Adrien Haxaire > www.adrienhaxaire.org | @adrienhaxaire > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Aug 27 09:36:51 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 27 Aug 2015 09:36:51 +0000 Subject: [Haskell-cafe] Stack transitive dependencies In-Reply-To: References: Message-ID: Currently, stack doesn't do any importing of settings between stack.yaml files, so the contents of bar's extra-deps are irrelevant. stack is just looking at bar's cabal file, detecting that it needs another package as a dependency, and suggesting you add it. There are discussions on the issue tracker about allowing some kind of include syntax, but it would still be a separate syntax to what we have today, since they're different use cases. On Wed, Aug 26, 2015, 6:09 PM Corentin Dupont wrote: > Hello, > I have a package depending on another: > > Foo/stack.yaml: > > flags: {} > packages: > - '.' > - location: ../Bar > extra-dep: true > extra-deps: > - Bar-0.7.6 > resolver: lts-2.19 > > When I compile (stack build), I obtain: > > -- While attempting to add dependency, > Could not find package DebugTraceHelpers in known packages > > -- Failure when adding dependencies: > DebugTraceHelpers: needed (==0.12.*), but not present in build plan, > latest is 0.12 > needed for package: Bar-0.7.6 > > I find it strange that it asks for DebugTraceHelpers because it's not a > direct dependency of my package, but a dependency of a dependency. > It is correctly mentioned in Bar/stack.yml: > > flags: {} > packages: > - '.' > extra-deps: > - DebugTraceHelpers-0.12 > resolver: lts-2.19 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajnsit at gmail.com Thu Aug 27 13:21:57 2015 From: ajnsit at gmail.com (Anupam Jain) Date: Thu, 27 Aug 2015 18:51:57 +0530 Subject: [Haskell-cafe] "Assignment" in do blocks? In-Reply-To: <20150826123452.GA1278@casa.casa> References: <20150826123452.GA1278@casa.casa> Message-ID: On Wed, Aug 26, 2015 at 6:04 PM, Francesco Ariis wrote: > On Wed, Aug 26, 2015 at 05:55:45PM +0530, Anupam Jain wrote: >> Hi all, >> >> I'd like to propose an inbuilt "assignment" operator for use within >> do-blocks. > > Time to add your proposal here! > https://wiki.haskell.org/Nitpicks I just requested access to the wiki. > Honestly, I feel it would break the way I read Haskell programs > (i.e. no reassignment surprises). How is this any worse than using `foo <- return $ bar foo` or `let foo = something completely unrelated`? From mike at barrucadu.co.uk Thu Aug 27 13:30:23 2015 From: mike at barrucadu.co.uk (Michael Walker) Date: Thu, 27 Aug 2015 14:30:23 +0100 Subject: [Haskell-cafe] [ANN] dejafu-0.1.0.0: Overloadable primitives for testable, potentially non-deterministic, concurrency. Message-ID: <20150827133023.GA1719@localhost> Hi cafe, For the past few months I've been working on a library for concurrency testing in Haskell, which I'll be giving a talk on at the Haskell Symposium next week. Now it's on Hackage! --- D?j? Fu is a library for developing and testing concurrent Haskell programs, it provides a typeclass-abstraction over GHC?s regular concurrency API, allowing the concrete implementation to be swapped out. Why do we need this? Well, concurrency is really hard to get right. Empirical studies have found that many real-world concurrency bugs can be exhibited with small test cases using as few as two threads: so it?s not just big concurrent programs that are hard, small ones are too. We as programmers just don?t seem to have a very good intuition for traditional threads-and-shared-memory-style concurrency. The typical approach to testing concurrent programs is to just run them lots of times, but that doesn?t provide any hard coverage guarantees, and then we need to wonder: how many runs do we need? Fortunately, there has been a lot of research into testing concurrency in the past several years. Systematic concurrency testing is an approach where the source of nondeterminism, the actual scheduler, is swapped out for one under the control of the testing framework. This allows possible schedules to be systematically explored, giving real coverage guarantees for our tests. This is a library implementing systematic concurrency testing. It provides two typeclasses, MonadConc to abstract over much of Control.Concurrent and related modules, and MonadSTM, to similarly abstract over Control.Monad.STM. ## How to use it: If you?re not making use of any IO in your code other than for concurrency, the transition to using MonadConc and MonadSTM will probably just be a textual substitution: - IO is replaced with MonadConc m => m - STM with MonadSTM m => m - *IORef with *CRef - *MVar with *CVar - *TVar with *CTVar - Most other things have the same name, and so can be replaced by just swapping imports around. If you are using other IO, you will need a gentle sprinkling of MonadIO and liftIO in your code as well. ## Is this really just a drop-in replacement for IO/STM? That?s the idea, yes. More specifically, the IO instance of MonadConc and the STM instance of MonadSTM just use the regular IO and STM functions, and so should have no noticeable change in behaviour, except for CRef, the IORef equivalent, where modifyCRef behaves like atomicModifyIORef, not modifyIORef. There are some other differences which can lead to incorrect results when testing, but which should not affect code when used in an IO or STM context. Specifically: Control.Monad.Conc.Class.getNumCapabilities can lie to encourage more concurrency when testing; and Control.Exception.catch can catch exceptions from pure code, but Control.Monad.Conc.Class.catch can?t (except for the IO instance). --- There is a blog post with references to prior posts and related papers here: http://www.barrucadu.co.uk/posts/2015-08-27-announce-dejafu.html -- Michael Walker (http://www.barrucadu.co.uk) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From ajnsit at gmail.com Thu Aug 27 13:30:22 2015 From: ajnsit at gmail.com (Anupam Jain) Date: Thu, 27 Aug 2015 19:00:22 +0530 Subject: [Haskell-cafe] "Assignment" in do blocks? In-Reply-To: References: Message-ID: On Wed, Aug 26, 2015 at 9:39 PM, Kim-Ee Yeoh wrote: > > On Wed, Aug 26, 2015 at 7:25 PM, Anupam Jain wrote: >> >> What I'd like to do instead is something like - >> >> let foo = bar foo >> >> But to Haskell this is a recursive definition instead of an update to >> the previous value. > > > This is a chestnut at least two years old. Last time I remember, the > discussion frothed under the rubric of "non-recursive let": > > https://mail.haskell.org/pipermail/haskell-cafe/2013-July/109116.html Thanks for linking to that discussion. However that discussion seems to be revolving around the non-recursive let. What I propose is only an extension to the do-notation desugaring, which seems more benign. I wrote this email yesterday when I ran into a rather hard-to-find bug because I used `foo` where I should have used `foo'`. I think it's an unnecessary wart that can easily go away with a little bit of syntactic sugar. From ajnsit at gmail.com Thu Aug 27 14:09:29 2015 From: ajnsit at gmail.com (Anupam Jain) Date: Thu, 27 Aug 2015 19:39:29 +0530 Subject: [Haskell-cafe] "Assignment" in do blocks? In-Reply-To: <20150826144449.GB32085@barbados> References: <20150826144449.GB32085@barbados> Message-ID: On Wed, Aug 26, 2015 at 8:14 PM, Tobias Dammers wrote: > IMO, having <- in do syntax look like assignment is bad enough as it is, > no need to further enforce the illusion. The syntax could be anything, it doesn't have to be an arrow. For example it could simply be an inbuilt function say `liftIdentity`. i.e. foo <- liftIdentity $ bar foo This makes sense if we think of every monad as a transformer around the Identity monad. Analogous to liftIO, except automatically defined for all Monads. Of course GHC would have to implement it in such a way so as to not use `return`. > > The variable shadowing that effectively occurs in that example is still > just as bad as regular shadowing. I'm not sure how "shadowing" is bad. It is certainly safer than a string of foo, foo', foo'' etc. From fa-ml at ariis.it Thu Aug 27 14:39:10 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 27 Aug 2015 16:39:10 +0200 Subject: [Haskell-cafe] "Assignment" in do blocks? In-Reply-To: References: <20150826123452.GA1278@casa.casa> Message-ID: <20150827143910.GA5127@casa.casa> On Thu, Aug 27, 2015 at 06:51:57PM +0530, Anupam Jain wrote: > How is this any worse than using `foo <- return $ bar foo` or `let foo > = something completely unrelated`? I happen to prefer foo = something foo' = bar foo to foo = something foo <- return $ bar foo because if on line 147 I find `x = foo` then I have to scan the source file (or function) only to the point where I find `foo`, while with 'reassignment'/shadowing this doesn't hold. "The code from this point onwards shouldn't use foo but there is no way to enforce that" is indeed an annoyance, which can only be awkwardly expressed as: ?> (let a = 1 in 2) + a :5:20: Not in scope: ?a? But don't mind me, I prefer to use `>>= \var ->` instead of do notation! > > Time to add your proposal here! > > https://wiki.haskell.org/Nitpicks > > I just requested access to the wiki. Thank you for taking time to add your proposal and peace be upon William Yager for coming up with the List of Nitpicks, having them in one place is a great way to assess the issues in an organic manner. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From mantkiew at gsd.uwaterloo.ca Thu Aug 27 14:42:30 2015 From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca) Date: Thu, 27 Aug 2015 10:42:30 -0400 Subject: [Haskell-cafe] [ANN] dejafu-0.1.0.0: Overloadable primitives for testable, potentially non-deterministic, concurrency. In-Reply-To: <20150827133023.GA1719@localhost> References: <20150827133023.GA1719@localhost> Message-ID: <20150827144230.5476436.64396.11337@gsd.uwaterloo.ca> Why not keep the original names? If it is a drop in replacement, wouldn't it be best to just have a flag in cabal depend on dejafu for testing and just recompile. ?The various *-compat could provide inspiration.? Sorry if I'm missing the point... Micha? ? Original Message ? From: Michael Walker Sent: Thursday, August 27, 2015 9:30 AM To: haskell-cafe at haskell.org Subject: [Haskell-cafe] [ANN] dejafu-0.1.0.0: Overloadable primitives for testable, potentially non-deterministic, concurrency. Hi cafe, For the past few months I've been working on a library for concurrency testing in Haskell, which I'll be giving a talk on at the Haskell Symposium next week. Now it's on Hackage! --- D?j? Fu is a library for developing and testing concurrent Haskell programs, it provides a typeclass-abstraction over GHC?s regular concurrency API, allowing the concrete implementation to be swapped out. Why do we need this? Well, concurrency is really hard to get right. Empirical studies have found that many real-world concurrency bugs can be exhibited with small test cases using as few as two threads: so it?s not just big concurrent programs that are hard, small ones are too. We as programmers just don?t seem to have a very good intuition for traditional threads-and-shared-memory-style concurrency. The typical approach to testing concurrent programs is to just run them lots of times, but that doesn?t provide any hard coverage guarantees, and then we need to wonder: how many runs do we need? Fortunately, there has been a lot of research into testing concurrency in the past several years. Systematic concurrency testing is an approach where the source of nondeterminism, the actual scheduler, is swapped out for one under the control of the testing framework. This allows possible schedules to be systematically explored, giving real coverage guarantees for our tests. This is a library implementing systematic concurrency testing. It provides two typeclasses, MonadConc to abstract over much of Control.Concurrent and related modules, and MonadSTM, to similarly abstract over Control.Monad.STM. ## How to use it: If you?re not making use of any IO in your code other than for concurrency, the transition to using MonadConc and MonadSTM will probably just be a textual substitution: - IO is replaced with MonadConc m => m - STM with MonadSTM m => m - *IORef with *CRef - *MVar with *CVar - *TVar with *CTVar - Most other things have the same name, and so can be replaced by just swapping imports around. If you are using other IO, you will need a gentle sprinkling of MonadIO and liftIO in your code as well. ## Is this really just a drop-in replacement for IO/STM? That?s the idea, yes. More specifically, the IO instance of MonadConc and the STM instance of MonadSTM just use the regular IO and STM functions, and so should have no noticeable change in behaviour, except for CRef, the IORef equivalent, where modifyCRef behaves like atomicModifyIORef, not modifyIORef. There are some other differences which can lead to incorrect results when testing, but which should not affect code when used in an IO or STM context. Specifically: Control.Monad.Conc.Class.getNumCapabilities can lie to encourage more concurrency when testing; and Control.Exception.catch can catch exceptions from pure code, but Control.Monad.Conc.Class.catch can?t (except for the IO instance). --- There is a blog post with references to prior posts and related papers here: http://www.barrucadu.co.uk/posts/2015-08-27-announce-dejafu.html -- Michael Walker (http://www.barrucadu.co.uk) From goodingm at gmail.com Thu Aug 27 18:59:36 2015 From: goodingm at gmail.com (htebalaka) Date: Thu, 27 Aug 2015 11:59:36 -0700 (MST) Subject: [Haskell-cafe] General Functor and Traversable In-Reply-To: <55dbdb17.4271440a.22d6a.4647@mx.google.com> References: <55dbdb17.4271440a.22d6a.4647@mx.google.com> Message-ID: <1440701976952-5816351.post@n5.nabble.com> I'm not sure what the more category-theoretic version of Traversable is, though I don't think mapM is actually an instance of a Functor in a Kleisli category in the first place. Consider the Functor laws: mapM return = return mapM (f <=< g) = mapM f <=< mapM g It's easy to show the second law doesn't hold, as in the RHS we have to run all the effects from "mapM g" before any of the effects from "mapM f" can start, while in the LHS the effects will be interleaved. Consider: printId = print a *> pure a mapM (printId <=< printId) [1,2,3] 1 1 2 2 3 3 (mapM printId <=< mapM printId) [1,2,3] 1 2 3 1 2 3 Using traverse/mapM has to hold onto the entire list (thus the need for pipes/conduit). M Farkas-Dyck wrote > Consider this: > > class (Category c, Category d) => Functor c d f where > map :: c a b -> d (f a) (f b) > > Clearly mapM of Traversable is simply map :: Kleisli m a b -> Kleisli m (f > a) (f b). But what is traverse? can it be so defined? I am thinking no, as > Kleisli composition is not defined in general, but I know very little > category theory so I may easily be wrong. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/General-Functor-and-Traversable-tp5816194p5816351.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From kei at lanl.gov Thu Aug 27 19:32:45 2015 From: kei at lanl.gov (Kei Davis) Date: Thu, 27 Aug 2015 13:32:45 -0600 Subject: [Haskell-cafe] Haskell hacking internships at Los Alamos National Laboratory (Spring 2016, undergraduate) Message-ID: <55DF65DD.2080907@lanl.gov> Hello, We have an ongoing project developing an auto-parallelizing pure functional language implementation based loosely on Haskell/STG. If you are a United States citizen or permanent resident alien studying computer science or mathematics at the undergraduate level with strong interests in Haskell programming, compiler/runtime development, and pursuing a spring semester (2016) internship at a national laboratory this could be for you. We don't expect applicants to necessarily already be highly accomplished Haskell programmers--such an internship is expected to be a combination of (further) developing your programming/Haskell skills and putting them to good use. If you're already a strong C hacker we could use that too. The application process for spring semester internships is open here http://science.energy.gov/wdts/suli/. Note the deadline of Oct. 9. Email me if interested, and feel free to pass this along. -- Kei Davis Applied Computer Science Group CCS-7, Mail Stop B287 Los Alamos National Laboratory Los Alamos, NM 87545, U.S.A. From corentin.dupont at gmail.com Thu Aug 27 19:59:33 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Thu, 27 Aug 2015 21:59:33 +0200 Subject: [Haskell-cafe] Stack transitive dependencies In-Reply-To: References: Message-ID: Thanks for the explanation! On Thu, Aug 27, 2015 at 11:36 AM, Michael Snoyman wrote: > Currently, stack doesn't do any importing of settings between stack.yaml > files, so the contents of bar's extra-deps are irrelevant. stack is just > looking at bar's cabal file, detecting that it needs another package as a > dependency, and suggesting you add it. > > There are discussions on the issue tracker about allowing some kind of > include syntax, but it would still be a separate syntax to what we have > today, since they're different use cases. > > On Wed, Aug 26, 2015, 6:09 PM Corentin Dupont > wrote: > >> Hello, >> I have a package depending on another: >> >> Foo/stack.yaml: >> >> flags: {} >> packages: >> - '.' >> - location: ../Bar >> extra-dep: true >> extra-deps: >> - Bar-0.7.6 >> resolver: lts-2.19 >> >> When I compile (stack build), I obtain: >> >> -- While attempting to add dependency, >> Could not find package DebugTraceHelpers in known packages >> >> -- Failure when adding dependencies: >> DebugTraceHelpers: needed (==0.12.*), but not present in build >> plan, latest is 0.12 >> needed for package: Bar-0.7.6 >> >> I find it strange that it asks for DebugTraceHelpers because it's not a >> direct dependency of my package, but a dependency of a dependency. >> It is correctly mentioned in Bar/stack.yml: >> >> flags: {} >> packages: >> - '.' >> extra-deps: >> - DebugTraceHelpers-0.12 >> resolver: lts-2.19 >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Thu Aug 27 21:08:09 2015 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 27 Aug 2015 23:08:09 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice Message-ID: Dear cafe, please correct me if questions like this should not go via this mailing list. Presumably everyone on this list agrees that Haskell stands out as a beautiful and pleasant language to have. The recent nitpicking and real-world problems like cabal hell don't change that. However, statements supporting Haskell's beauty usually involve: "In Haskell it is so much clearer/easier/faster to ... than in another language." That is, the beauty of Haskell presents itself to those who can compare it to other imperative or not strongly typed languages that one learned before Haskell. My question is, for what reason should anyone not acquainted with any programming language find Haskell beautiful? Maybe it does not look beautiful at all to the novice. The novice can not draw on the comparison, unless he takes the effort to learn more than one language in parallel. The novice likely also does not have the mathematical background to see the beautiful correspondence between the language and its semantics. (My reason to love FP is because it is executable domain theory.) One might argue that it is not the language itself that is beautiful, but rather the concepts (data structures, algorithms, recursion) and Haskell does a great job to preserve their beauty into the implementation. Do you agree? Disclaimer: I am about to start teaching a first course in computer science in secondary school. I can teach whatever I want, since this is the first CS course the school ever had. I want to teach beautiful things. I love functional programming. I need not start teaching programming right away. But I am reluctant to expose the pupils to something whose beauty escapes them completely. -- Olaf From elliot.cameron at covenanteyes.com Thu Aug 27 22:05:21 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Thu, 27 Aug 2015 22:05:21 +0000 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: <1440713126590.95983@covenanteyes.com> Bear in mind that the ugliness of other things will *also* escape them. It escapes many professionals too! ________________________________________ From: Haskell-Cafe on behalf of Olaf Klinke Sent: Thursday, August 27, 2015 5:08 PM To: haskell-cafe at haskell.org Subject: [Haskell-cafe] Why Haskell is beautiful to the novice Dear cafe, please correct me if questions like this should not go via this mailing list. Presumably everyone on this list agrees that Haskell stands out as a beautiful and pleasant language to have. The recent nitpicking and real-world problems like cabal hell don't change that. However, statements supporting Haskell's beauty usually involve: "In Haskell it is so much clearer/easier/faster to ... than in another language." That is, the beauty of Haskell presents itself to those who can compare it to other imperative or not strongly typed languages that one learned before Haskell. My question is, for what reason should anyone not acquainted with any programming language find Haskell beautiful? Maybe it does not look beautiful at all to the novice. The novice can not draw on the comparison, unless he takes the effort to learn more than one language in parallel. The novice likely also does not have the mathematical background to see the beautiful correspondence between the language and its semantics. (My reason to love FP is because it is executable domain theory.) One might argue that it is not the language itself that is beautiful, but rather the concepts (data structures, algorithms, recursion) and Haskell does a great job to preserve their beauty into the implementation. Do you agree? Disclaimer: I am about to start teaching a first course in computer science in secondary school. I can teach whatever I want, since this is the first CS course the school ever had. I want to teach beautiful things. I love functional programming. I need not start teaching programming right away. But I am reluctant to expose the pupils to something whose beauty escapes them completely. -- Olaf _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From hjgtuyl at chello.nl Thu Aug 27 23:14:12 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Fri, 28 Aug 2015 01:14:12 +0200 Subject: [Haskell-cafe] ANN: wxHaskell 0.92 Message-ID: L.S., I am happy to announce a new version of wxHaskell (0.92). What is it? ----------- wxHaskell[1] is a portable and native GUI library for Haskell. The goal of the project is to provide an industrial strength GUI library for Haskell, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore built on top of wxWidgets ? a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with the native look-and-feel. What's new? ----------- - wxc/setup.hs now stops searching for wxWidgets when a compatible version is found (this solves bug ticket 96) - Support for simple Wizards added - Calendar support added - GCC > 4.5 can now be used on Windows, which is a big improvement, as wxWidgets and wxHaskell must use the exact same GCC, to prevent compatibility problems - wxAui is added to wxc, wxAuiNotebook events are added to wxcore and wx - Missing GLAttributes added - Packet version limits adapted to the newest Haskell Platform - Bitness check on Windows no longer uses an external executable - wxHaskell can now be installed with MSYS2 - wxc/Setup.hs is modified to also link to the wx OpenGL libraries for wxGLCanvas - The "warning: Adding duplicate image handler for '... file'" messages are removed - Created a new class Updating with corresponding event "update". Provided instances for TextCtrl and ComboBox: update gets called when the text changes. - Support for wxSplashScreen in wxc and wxcore is added - Many warnings are solved Links ----- See the homepage of wxHaskell for more information: https://wiki.haskell.org/WxHaskell The packages are: - wxc https://hackage.haskell.org/package/wxc - wxdirect https://hackage.haskell.org/package/wxdirect - wxcore https://hackage.haskell.org/package/wxcore - wx https://hackage.haskell.org/package/wx Regards, Henk-Jan van Tuyl [0] https://www.wxwidgets.org [1] https://wiki.haskell.org/WxHaskell -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From agocorona at gmail.com Thu Aug 27 23:36:49 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Fri, 28 Aug 2015 01:36:49 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: My impression is that a programming is a tool for solving problems and the perceived beauty of a tool is a mix of many impression: One is the personal level of mastering of the tool, but also what the tool promises to achieve when you reach the next levels. Otherwise when you master it completely, it looses his interest. This second part is what makes haskell attractive: it has no limits 2015-08-27 23:08 GMT+02:00 Olaf Klinke : > Dear cafe, > > please correct me if questions like this should not go via this mailing > list. > Presumably everyone on this list agrees that Haskell stands out as a > beautiful and pleasant language to have. The recent nitpicking and > real-world problems like cabal hell don't change that. However, statements > supporting Haskell's beauty usually involve: "In Haskell it is so much > clearer/easier/faster to ... than in another language." That is, the beauty > of Haskell presents itself to those who can compare it to other imperative > or not strongly typed languages that one learned before Haskell. > My question is, for what reason should anyone not acquainted with any > programming language find Haskell beautiful? Maybe it does not look > beautiful at all to the novice. The novice can not draw on the comparison, > unless he takes the effort to learn more than one language in parallel. The > novice likely also does not have the mathematical background to see the > beautiful correspondence between the language and its semantics. (My reason > to love FP is because it is executable domain theory.) One might argue that > it is not the language itself that is beautiful, but rather the concepts > (data structures, algorithms, recursion) and Haskell does a great job to > preserve their beauty into the implementation. Do you agree? > > Disclaimer: I am about to start teaching a first course in computer > science in secondary school. I can teach whatever I want, since this is the > first CS course the school ever had. I want to teach beautiful things. I > love functional programming. I need not start teaching programming right > away. But I am reluctant to expose the pupils to something whose beauty > escapes them completely. > > -- Olaf > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Thu Aug 27 23:37:19 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Fri, 28 Aug 2015 01:37:19 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: a programming -> a programming language 2015-08-28 1:36 GMT+02:00 Alberto G. Corona : > My impression is that a programming is a tool for solving problems and the > perceived beauty of a tool is a mix of many impression: One is the personal > level of mastering of the tool, but also what the tool promises to achieve > when you reach the next levels. Otherwise when you master it completely, it > looses his interest. > > This second part is what makes haskell attractive: it has no limits > > 2015-08-27 23:08 GMT+02:00 Olaf Klinke : > >> Dear cafe, >> >> please correct me if questions like this should not go via this mailing >> list. >> Presumably everyone on this list agrees that Haskell stands out as a >> beautiful and pleasant language to have. The recent nitpicking and >> real-world problems like cabal hell don't change that. However, statements >> supporting Haskell's beauty usually involve: "In Haskell it is so much >> clearer/easier/faster to ... than in another language." That is, the beauty >> of Haskell presents itself to those who can compare it to other imperative >> or not strongly typed languages that one learned before Haskell. >> My question is, for what reason should anyone not acquainted with any >> programming language find Haskell beautiful? Maybe it does not look >> beautiful at all to the novice. The novice can not draw on the comparison, >> unless he takes the effort to learn more than one language in parallel. The >> novice likely also does not have the mathematical background to see the >> beautiful correspondence between the language and its semantics. (My reason >> to love FP is because it is executable domain theory.) One might argue that >> it is not the language itself that is beautiful, but rather the concepts >> (data structures, algorithms, recursion) and Haskell does a great job to >> preserve their beauty into the implementation. Do you agree? >> >> Disclaimer: I am about to start teaching a first course in computer >> science in secondary school. I can teach whatever I want, since this is the >> first CS course the school ever had. I want to teach beautiful things. I >> love functional programming. I need not start teaching programming right >> away. But I am reluctant to expose the pupils to something whose beauty >> escapes them completely. >> >> -- Olaf >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > Alberto. > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Fri Aug 28 04:26:34 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 28 Aug 2015 16:26:34 +1200 Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> Message-ID: I note that Haskell is not the only language to link identifiers with types using '::' rather than ':'. Apart from the obvious (Clean), there's Fortran. From the file ATMDYN.f in a system that NASA helpfully make available, LOGICAL :: HAVE_SOUTH_POLE, HAVE_NORTH_POLE This puts the type before the identifiers, but still... Didn't Miranda use '::=' to declare sum-of-product types? From goodingm at gmail.com Fri Aug 28 04:57:45 2015 From: goodingm at gmail.com (htebalaka) Date: Thu, 27 Aug 2015 21:57:45 -0700 (MST) Subject: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` In-Reply-To: <20150818064940.GA2735@machine> References: <0CBE6150-E790-445F-A192-54592168AD12@gmail.com> <20150808150306.GA27353@brick> <0EB2F628-9032-4040-B81B-5EECEB4E9C62@cs.otago.ac.nz> <20150818064940.GA2735@machine> Message-ID: <1440737865049-5816380.post@n5.nabble.com> It sort of should I think. In Idris I believe closed type families just use regular function syntax, can be declared inside of let-bindings, have type signatures themselves, and otherwise syntactically behave just like the value level equivalents. I'm hoping at some point goldfire's dependent Haskell work will eventually lead to the same in Haskell, though I know from his comments on reddit that this is very far off from being a reality. Daniel Trstenjak-2 wrote > But with this point of view 'type Sequence t = [t]' is also somehow > bogus and should just be 'Sequence t = [t]'. > > > Greetings, > Daniel > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/an-idea-for-modifiyng-data-newtype-syntax-use-instead-of-tp5815331p5816380.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From ch.howard at zoho.com Fri Aug 28 08:19:14 2015 From: ch.howard at zoho.com (Christopher Howard) Date: Fri, 28 Aug 2015 00:19:14 -0800 Subject: [Haskell-cafe] LaTeX question: interpreter examples Message-ID: <20150828001914.01d53f31@nimrodel> Hi. I'm doing a lot of Literate Haskell lately, with proofs and commentary in each module. I'm not very familiar with LaTeX, but I'm learning. (I'm using lhs2tex and texi2pdf.) However, in my commentary, I occasionally have blocks of example interpreter interaction, and I'm not sure what to do with it. Is there a certain command enclosure that would be appropriate? Ideally, it would treat the text like monospace, and also preserve line breaks. Example text would be: *GCD> extEuclidean 546 2022 (6,100,-27) *GCD> 546 * 100 + 2022 * (-27) == 6 True But this does not come out looking similar in the final output. -- http://justonemoremathproblem.wordpress.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From chris at witte.net.au Fri Aug 28 08:32:57 2015 From: chris at witte.net.au (Christopher Witte) Date: Fri, 28 Aug 2015 10:32:57 +0200 Subject: [Haskell-cafe] LaTeX question: interpreter examples In-Reply-To: <20150828001914.01d53f31@nimrodel> References: <20150828001914.01d53f31@nimrodel> Message-ID: Maybe try the listings package https://en.wikibooks.org/wiki/LaTeX/Source_Code_Listings Chris. On 28 August 2015 at 10:19, Christopher Howard wrote: > Hi. I'm doing a lot of Literate Haskell lately, with proofs and > commentary in each module. I'm not very familiar with LaTeX, but I'm > learning. (I'm using lhs2tex and texi2pdf.) However, in my commentary, > I occasionally have blocks of example interpreter interaction, and I'm > not sure what to do with it. Is there a certain command enclosure that > would be appropriate? Ideally, it would treat the text like monospace, > and also preserve line breaks. Example text would be: > > *GCD> extEuclidean 546 2022 > (6,100,-27) > *GCD> 546 * 100 + 2022 * (-27) == 6 > True > > But this does not come out looking similar in the final output. > > -- > http://justonemoremathproblem.wordpress.com/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Fri Aug 28 08:38:33 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 28 Aug 2015 20:38:33 +1200 Subject: [Haskell-cafe] LaTeX question: interpreter examples In-Reply-To: <20150828001914.01d53f31@nimrodel> References: <20150828001914.01d53f31@nimrodel> Message-ID: <3A91A05E-459E-447E-95F8-F8B9CCBEBB48@cs.otago.ac.nz> On 28/08/2015, at 8:19 pm, Christopher Howard wrote: > I occasionally have blocks of example interpreter interaction, and I'm > not sure what to do with it. Is there a certain command enclosure that > would be appropriate? Ideally, it would treat the text like monospace, > and also preserve line breaks. Example text would be: > > *GCD> extEuclidean 546 2022 > (6,100,-27) > *GCD> 546 * 100 + 2022 * (-27) == 6 > True > > But this does not come out looking similar in the final output. The absolute minimum here is \begin{verbatim} ... \end{verbatim} but do be careful that there are no TAB characters there. The next step up would be to use something like the `listings' package; see http://texdoc.net/texmf-dist/doc/latex/listings/listings.pdf verbatim will make the output look exactly like the input; listings can make the output look like Haskell, if that's what you want. From mail at joachim-breitner.de Fri Aug 28 08:51:58 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 28 Aug 2015 10:51:58 +0200 Subject: [Haskell-cafe] LaTeX question: interpreter examples In-Reply-To: <20150828001914.01d53f31@nimrodel> References: <20150828001914.01d53f31@nimrodel> Message-ID: <1440751918.22927.25.camel@joachim-breitner.de> Hi, Am Freitag, den 28.08.2015, 00:19 -0800 schrieb Christopher Howard: > Hi. I'm doing a lot of Literate Haskell lately, with proofs and > commentary in each module. I'm not very familiar with LaTeX, but I'm > learning. (I'm using lhs2tex and texi2pdf.) However, in my > commentary, > I occasionally have blocks of example interpreter interaction, and > I'm > not sure what to do with it. Is there a certain command enclosure > that > would be appropriate? Ideally, it would treat the text like > monospace, > and also preserve line breaks. Example text would be: > > *GCD> extEuclidean 546 2022 > (6,100,-27) > *GCD> 546 * 100 + 2022 * (-27) == 6 > True > > But this does not come out looking similar in the final output. I have a hack used for http://www.joachim-breitner.de/publications/haskell_bytes_portland_2014-06-13.pdf where in interpreter sessions, everything is in mono-spaced fonts but the line following a >. This is the relevant LaTeX code: \usepackage{listings} \definecolor{light-gray}{gray}{0.95} \lstdefinestyle{basic}{ ,columns=flexible ,basewidth={.365em} ,keepspaces=True ,belowskip=0pt ,backgroundcolor=\color{light-gray} ,frame=single ,xleftmargin=1em ,xrightmargin=1em ,basicstyle=\small\sffamily ,stringstyle=\itshape } \lstdefinestyle{shell}{ ,style=basic ,basicstyle=\footnotesize\ttfamily } \lstdefinestyle{haskell}{ style=basic ,language=Haskell ,literate= {?}{{\"o}}1 {?}{{\"a}}1 {?}{{\"u}}1 ,texcl=true ,showstringspaces=false ,keywords={module,where,open,import,using,renaming,to,data,let,in,with,deriving} } \newcommand{\mylabel}[1]{\raisebox{2em}[0pt][0pt]{\makebox[0pt][l]{\makebox[\linewidth][r]{\color{gray}{\sffamily #1}\hspace{1em}}}}\ignorespaces} \lstnewenvironment{haskell}{\pagebreak[3]\lstset{style=haskell}}{\mylabel{Haskell}\pagebreak[2]} %\lstnewenvironment{ghci}{\lstset{style=haskell}}{\mylabel{GHCi}\pagebreak[2]} \lstnewenvironment{shell}{\lstset{style=shell}}{\mylabel{Shell}\pagebreak[2]} \begingroup \gdef\savedgt{>}% \catcode`\>=\active% \catcode`\^^M=\active% \gdef\foo{% \catcode`\>=\active% \catcode`^^M=\active% \def > ##1^^M{\savedgt{} \li!##1!\par}% \def ^^M{\par}% }% \endgroup \newlength{\mylength} \newenvironment{ghci}{ \par \setlength{\mylength}{\linewidth} \addtolength{\mylength}{-2em} \addtolength{\mylength}{-\fboxrule} \addtolength{\mylength}{-\fboxrule} \strut\hspace{1em}\hspace{-\fboxsep}\begin{adjustbox}{minipage={\mylength},valign=b,margin*=\fboxsep,bgcolor=light-gray,frame}% \begingroup \small\ttfamily% \foo }{ \endgroup \end{adjustbox}%\par \adjustbox{lap=-\width}{\color{gray}{\sffamily GHCi}\hspace{\fboxsep}\hspace{\fboxrule}} \par } \newcommand{\inputhaskell}[1]{\lstinputlisting[style=haskell]{#1}\mylabel{Haskell}} \newcommand{\li}{\lstinline[style=haskell]} Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From nicola.gigante at gmail.com Fri Aug 28 10:12:45 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Fri, 28 Aug 2015 12:12:45 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: > Il giorno 27/ago/2015, alle ore 23:08, Olaf Klinke ha scritto: > > Dear cafe, > > please correct me if questions like this should not go via this mailing list. > Presumably everyone on this list agrees that Haskell stands out as a beautiful and pleasant language to have. The recent nitpicking and real-world problems like cabal hell don't change that. However, statements supporting Haskell's beauty usually involve: "In Haskell it is so much clearer/easier/faster to ... than in another language." That is, the beauty of Haskell presents itself to those who can compare it to other imperative or not strongly typed languages that one learned before Haskell. > My question is, for what reason should anyone not acquainted with any programming language find Haskell beautiful? Maybe it does not look beautiful at all to the novice. The novice can not draw on the comparison, unless he takes the effort to learn more than one language in parallel. The novice likely also does not have the mathematical background to see the beautiful correspondence between the language and its semantics. (My reason to love FP is because it is executable domain theory.) One might argue that it is not the language itself that is beautiful, but rather the concepts (data structures, algorithms, recursion) and Haskell does a great job to preserve their beauty into the implementation. Do you agree? > > Disclaimer: I am about to start teaching a first course in computer science in secondary school. I can teach whatever I want, since this is the first CS course the school ever had. I want to teach beautiful things. I love functional programming. I need not start teaching programming right away. But I am reluctant to expose the pupils to something whose beauty escapes them completely. > In my opinion, the first CS course in school (and to some extent the math and physics courses as well) should aim, more than teaching specific skills or knowledge, to transmit to student the beauty of programming _itself_ (respectively math and physics). The student should be able to perceive the feelings of wonder and enlightenment that rise from solving a challenging problem, or to understand some previously obscure phenomenon, by applying math and reasoning. This objective is well suited for a CS course because students can also be initially motivated by the promise of learning something really useful. Haskell is particularly well suited for this task, not because the student would necessarily be able to perceive the beauty of Haskell itself, but because Haskell does not obscure, and in some ways enhance, the beauty of programming as a whole. In contrast, when first CS courses start with convoluted or low level languages such as C or Java, students loose the point of everything, overwhelmed by pointers, useless OOP, obscure syntax, low-level technical details. Wonder and enlightenment become pain and frustration. Btw, if you want to _also_ teach computer architecture in addition to programming, I think that is best suited to a different part of the course and does not need to be interleaved with learning programming, so I wouldn?t bother with C and the like. Or better, you can explain C as a tool to better understand computers and operating systems, but after they?ve learnt how to program, not as a tool to learn programming. Using Haskell (specifically some kind of concepts, e.g. equational reasoning) will also make easier for students to see the connection between math and programming, making them more motivated to learn math as well. To me, your choice to start the CS course by teaching Haskell is a wonderful choice and your students will thank you in a few years. Go ahead! > ? Olaf Greetings, Nicola From romain.gehrig at gmail.com Fri Aug 28 11:26:35 2015 From: romain.gehrig at gmail.com (Romain Gehrig) Date: Fri, 28 Aug 2015 13:26:35 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: To add to Nicola's mail, I think what would be cool is to provide the "complex" parts to students, ie: IO handling, complex structure manipulation,... well, all that is not the focus of the current lesson nor a thing they learned in a previous course. For example, you can provide this kind of program: isSquare :: Int -> Bool isSquare n = undefined -- Don't touch for the moment main :: IO () main = do putStrLn "Square checker: check that an integer is the square of another integer." putStrLn "Input the integer to check: " input <- getLine let number = (read input :: Int) if (isSquare number) then putStrLn (show number ++ " is a square!") else putStrLn (show number ++ " is not a square!") (Maybe isSquare is not the best function for a student to create for a first time, but you get the idea) What can be a good idea is to make the students create their own set of functions as exercise and then create a bigger project reusing these. I can remember my own programming course where the code I created was then ditched for the reason it was only for an exercise. It was a bit disappointing. My whole point is: show your students the immense reusability of Haskell code and the enjoyment of its composability. -- Romain 2015-08-28 12:12 GMT+02:00 Nicola Gigante : > > > Il giorno 27/ago/2015, alle ore 23:08, Olaf Klinke < > olf at aatal-apotheke.de> ha scritto: > > > > Dear cafe, > > > > please correct me if questions like this should not go via this mailing > list. > > Presumably everyone on this list agrees that Haskell stands out as a > beautiful and pleasant language to have. The recent nitpicking and > real-world problems like cabal hell don't change that. However, statements > supporting Haskell's beauty usually involve: "In Haskell it is so much > clearer/easier/faster to ... than in another language." That is, the beauty > of Haskell presents itself to those who can compare it to other imperative > or not strongly typed languages that one learned before Haskell. > > My question is, for what reason should anyone not acquainted with any > programming language find Haskell beautiful? Maybe it does not look > beautiful at all to the novice. The novice can not draw on the comparison, > unless he takes the effort to learn more than one language in parallel. The > novice likely also does not have the mathematical background to see the > beautiful correspondence between the language and its semantics. (My reason > to love FP is because it is executable domain theory.) One might argue that > it is not the language itself that is beautiful, but rather the concepts > (data structures, algorithms, recursion) and Haskell does a great job to > preserve their beauty into the implementation. Do you agree? > > > > Disclaimer: I am about to start teaching a first course in computer > science in secondary school. I can teach whatever I want, since this is the > first CS course the school ever had. I want to teach beautiful things. I > love functional programming. I need not start teaching programming right > away. But I am reluctant to expose the pupils to something whose beauty > escapes them completely. > > > > > In my opinion, the first CS course in school (and to some extent > the math and physics courses as well) should aim, more than teaching > specific > skills or knowledge, to transmit to student the beauty of programming > _itself_ > (respectively math and physics). > The student should be able to perceive the feelings of wonder and > enlightenment > that rise from solving a challenging problem, or to understand some > previously obscure phenomenon, by applying math and reasoning. > > This objective is well suited for a CS course because students can also > be initially motivated by the promise of learning something really useful. > > Haskell is particularly well suited for this task, not because the student > would > necessarily be able to perceive the beauty of Haskell itself, but because > Haskell does not obscure, and in some ways enhance, the beauty of > programming as a whole. In contrast, when first CS courses start with > convoluted or low level languages such as C or Java, students loose > the point of everything, overwhelmed by pointers, useless OOP, > obscure syntax, low-level technical details. Wonder and enlightenment > become pain and frustration. > > Btw, if you want to _also_ teach computer architecture in addition to > programming, I think that is best suited to a different part of the course > and does not need to be interleaved with learning programming, so > I wouldn?t bother with C and the like. Or better, you can explain C > as a tool to better understand computers and operating systems, but > after they?ve learnt how to program, not as a tool to learn programming. > > Using Haskell (specifically some kind of concepts, e.g. equational > reasoning) > will also make easier for students to see the connection between math > and programming, making them more motivated to learn math as well. > > To me, your choice to start the CS course by teaching Haskell is > a wonderful choice and your students will thank you in a few years. > > Go ahead! > > > ? Olaf > > Greetings, > Nicola > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Fri Aug 28 13:27:02 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Fri, 28 Aug 2015 15:27:02 +0200 Subject: [Haskell-cafe] List of nitpicks Message-ID: <55E061A6.6040101@htwk-leipzig.de> Re: http://repetae.net/recent/out/classalias.html Prelude> :set -XConstraintKinds Prelude> class C a; class D a; type E a = (C a, D a); instance E a => C (Maybe a) https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/constraint-kind.html - J.W. From nicola.gigante at gmail.com Fri Aug 28 14:04:28 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Fri, 28 Aug 2015 16:04:28 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: > Il giorno 28/ago/2015, alle ore 15:37, Torsten Otto ha scritto: > > What an interesting topic to discuss! > >> Am 28.08.2015 um 12:12 schrieb Nicola Gigante : >> >> Using Haskell (specifically some kind of concepts, e.g. equational reasoning) >> will also make easier for students to see the connection between math >> and programming, making them more motivated to learn math as well. > > Can you elaborate on that? What would you do in class in terms of ?equational reasoning?? > It depends on the age of the students and the math they already know. I don?t have specific examples of in-class exercises or things like that. However, the point is that writing Haskell code you can often come up with shorter or more elegant solutions by manipulating terms exactly as done in elementary algebra. Starting from a 10lines function and coming up with a simple and readable oneliner is fun and rewarding, and shows one of the possible connections to math, especially if you can make them reason about types, in which case the task becomes very similar to theorem proving than to algebraic manipulations alone. Another possible connection arise when you teach things such as the Monoid typeclass. Even if students have not been exposed to abstract mathematics, they can still appreciate the usefulness of abstracting similar operations (addition in this case) to being able to uniformly reason about apparently different concepts. Abstraction is the core of mathematics, but is also a fundamental concept in programming, of course, so you?re implicitly teaching two things at once. > Regards, > Torsten Greetings, Nicola From mike at barrucadu.co.uk Fri Aug 28 15:27:22 2015 From: mike at barrucadu.co.uk (Michael Walker) Date: Fri, 28 Aug 2015 16:27:22 +0100 Subject: [Haskell-cafe] [ANN] dejafu-0.1.0.0: Overloadable primitives for testable, potentially non-deterministic, concurrency. In-Reply-To: <20150827144230.5476436.64396.11337@gsd.uwaterloo.ca> References: <20150827133023.GA1719@localhost> <20150827144230.5476436.64396.11337@gsd.uwaterloo.ca> Message-ID: <20150828152722.GA3232@localhost> Actually that's a good suggestion! The differing names for the mutable variable types is a holdover from when my approach was different: I started out thinking I was going to make something like the Par monad, but with multiple-write variables. The only issue would be picking module names to avoid conflicts, but that's hardly an insurmountable problem. On 27/08/15 at 10:42am, mantkiew at gsd.uwaterloo.ca wrote: > Why not keep the original names? If it is a drop in replacement, wouldn't it be best to just have a flag in cabal depend on dejafu for testing and just recompile. ?The various *-compat could provide inspiration.? > > Sorry if I'm missing the point... > > Micha? -- Michael Walker (http://www.barrucadu.co.uk) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From silvio.frischi at gmail.com Fri Aug 28 15:45:45 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Fri, 28 Aug 2015 17:45:45 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: <55E08229.5050602@gmail.com> Hi, In my opinion, Haskell is a terrible first language to learn. It has a very complicated type-system, and it's restriction to purely functional programming does not convey very well how (current) computers work. Current computers work by you giving them an step by step guide what to do. This I think is what should be at the base of any beginners-programming course. There are also a lot of very basic data structures that can simply not be used in purely functional code like hash tables, pipes or random access arrays. Haskell also requires quite a bit of intelligence and perseverance to master. So unless your kids are all geniuses I would not recommend it. Python would by my language of choice. You won't have to worry about low level stuff or typing, but can still write those step by step programs. Cheers Silvio From rustompmody at gmail.com Fri Aug 28 15:55:09 2015 From: rustompmody at gmail.com (Rustom Mody) Date: Fri, 28 Aug 2015 21:25:09 +0530 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: On Fri, Aug 28, 2015 at 2:38 AM, Olaf Klinke wrote: > Dear cafe, > > please correct me if questions like this should not go via this mailing > list. > Presumably everyone on this list agrees that Haskell stands out as a > beautiful and pleasant language to have. The recent nitpicking and > real-world problems like cabal hell don't change that. However, statements > supporting Haskell's beauty usually involve: "In Haskell it is so much > clearer/easier/faster to ... than in another language." That is, the beauty > of Haskell presents itself to those who can compare it to other imperative > or not strongly typed languages that one learned before Haskell. > My question is, for what reason should anyone not acquainted with any > programming language find Haskell beautiful? Maybe it does not look > beautiful at all to the novice. The novice can not draw on the comparison, > unless he takes the effort to learn more than one language in parallel. The > novice likely also does not have the mathematical background to see the > beautiful correspondence between the language and its semantics. (My reason > to love FP is because it is executable domain theory.) One might argue that > it is not the language itself that is beautiful, but rather the concepts > (data structures, algorithms, recursion) and Haskell does a great job to > preserve their beauty into the implementation. Do you agree? > > Disclaimer: I am about to start teaching a first course in computer > science in secondary school. I can teach whatever I want, since this is the > first CS course the school ever had. I want to teach beautiful things. I > love functional programming. I need not start teaching programming right > away. But I am reluctant to expose the pupils to something whose beauty > escapes them completely. > Similar questions are of much interest to me. Haskell is beautiful but functional programming is more beautiful and too much emphasis on the former loses (can lose) focus on the latter. Here is my list of things that all programmers would do well to know: http://blog.languager.org/2012/10/functional-programming-lost-booty.html Haskell is a nice ? but not necessarily the only ? vehicle for these. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.gigante at gmail.com Fri Aug 28 16:23:35 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Fri, 28 Aug 2015 18:23:35 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E08229.5050602@gmail.com> References: <55E08229.5050602@gmail.com> Message-ID: > Il giorno 28/ago/2015, alle ore 17:45, Silvio Frischknecht ha scritto: > > Hi, > > In my opinion, Haskell is a terrible first language to learn. > > It has a very complicated type-system, and it's restriction to purely > functional programming does not convey very well how (current) computers > work. Current computers work by you giving them an step by step guide > what to do. This I think is what should be at the base of any > beginners-programming course. > I kindly disagree. If the focus is to teach computer architecture, you are not teaching programming. If the focus is on programming, then it should focus on the conceptual aspects of programming, not on computers. A course at school should of course teach both, but in my opinion not concurrently. There?s no point in teaching something implicitly by using the teaching of something else. We are not talking about undergraduates here, but kids or teenagers. Think about which is the reason why you are teaching something to them. It is not to teach some specific skill or to make them be advantaged in future undergraduate courses. It is to teach them to reason. Functional programming is just more reasoning than technicalities. That?s also why I don?t agree with the math curriculum in high-school (only elementary algebra, trigonometry and basic calculus, at least here in Italy). If a student doesn?t go to college or studies something non-scientific (or even some low-math science), he?ll never see an abstract mathematical concept (see e.g. groups) in all his lives, thus living forever by completely ignoring what math is all about. (and this is really connected with the record-low public trust in science that we are suffering). My reasoning applies to any functional language, not just Haskell. If you don?t want to worry with the type system, you can turn to Common Lisp or Racket. I started with scheme and it was indeed pretty amazing. > There are also a lot of very basic data structures that can simply not > be used in purely functional code like hash tables, pipes or random > access arrays. Why do you think that manipulating arrays is a better skill to teach to kids than manipulating linked lists? > > Haskell also requires quite a bit of intelligence and perseverance to > master. So unless your kids are all geniuses I would not recommend it. > There was a nice article on reddit of a parent that was in progress of teaching Haskell to his/her 10-years old, and it was a great experience. I cannot find it anymore. Remember, kids (motivated kids, at least) are way smarter than what school usually seems to think. > Python would by my language of choice. You won't have to worry about low > level stuff or typing, but can still write those step by step programs. > Python would be also my first choice if I had to choose an imperative language, that?s granted. > Cheers > > Silvio Cheers, Nicola From mwm at mired.org Fri Aug 28 16:46:43 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 28 Aug 2015 16:46:43 +0000 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E08229.5050602@gmail.com> References: <55E08229.5050602@gmail.com> Message-ID: On Fri, Aug 28, 2015 at 10:45 AM Silvio Frischknecht < silvio.frischi at gmail.com> wrote: > Hi, > > In my opinion, Haskell is a terrible first language to learn. > > It has a very complicated type-system, and it's restriction to purely > functional programming does not convey very well how (current) computers > work. Current computers work by you giving them an step by step guide > what to do. This I think is what should be at the base of any > beginners-programming course. > I have to disagree, and for much the same reason that Nicola does: these details matter if you're teaching computer architecture, but not if you are teaching programming. At least, not in an introductory course. > Python would by my language of choice. You won't have to worry about low > level stuff or typing, but can still write those step by step programs. > Python is a good language if you want an imperative language, but like Haskell it isn't a good choice for teaching computer architecture. For instance, computers manipulate values in a store. But Python and Haskell work with labels on values. A Python assignment statement doesn't change the value in storage as a computer would, but puts a label on a value. Manipulating storage is as fundamental to common computers as sequential operation, so if you're going to drop Haskell for not having one, you should also drop Python for not having the other. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Fri Aug 28 16:55:36 2015 From: will.yager at gmail.com (Will Yager) Date: Fri, 28 Aug 2015 11:55:36 -0500 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E08229.5050602@gmail.com> References: <55E08229.5050602@gmail.com> Message-ID: https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20concerning%20Haskell.pdf > On Aug 28, 2015, at 10:45, Silvio Frischknecht wrote: > > Hi, > In my opinion, Haskell is a terrible first language to learn. > From mwm at mired.org Fri Aug 28 17:19:17 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 28 Aug 2015 17:19:17 +0000 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: On Fri, Aug 28, 2015 at 11:23 AM Nicola Gigante wrote: > That?s also why I don?t agree with the math curriculum in high-school > (only elementary algebra, trigonometry and basic calculus, at least here > in Italy). > If a student doesn?t go to college or studies something non-scientific > (or even some low-math science), he?ll never see an abstract > mathematical concept (see e.g. groups) in all his lives, thus living > forever by completely ignoring what math is all about. > (and this is really connected with the record-low public trust in science > that we are suffering). > Have you seen this? https://www.maa.org/external_archive/devlin/LockhartsLament.pdf It pretty much hits the nail on the head for most high school math curricula. -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvio.frischi at gmail.com Fri Aug 28 17:37:30 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Fri, 28 Aug 2015 19:37:30 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: <55E09C5A.1000600@gmail.com> > I kindly disagree. This being a haskell mailing list, I expected that :) > If the focus is to teach computer architecture, you are > not teaching programming. If the focus is on programming, then it should > focus on the conceptual aspects of programming, not on computers. > A course at school should of course teach both, but in my opinion not > concurrently. There?s no point in teaching something implicitly by using > the teaching of something else. It's more about algorithms than computer architecture. An imperative program very clearly describes algorithms; Haskell does not. Unless you have a very good understanding of things like lazyness, non-strictness and tail recursion, you wont know what happens when and how. > We are not talking about undergraduates here, but kids or teenagers. > Think about which is the reason why you are teaching something to them. > It is not to teach some specific skill or to make them be advantaged in > future undergraduate courses. It is to teach them to reason. > Functional programming is just more reasoning than technicalities. All the more reason not to teach Haskell. To CS undergraduates you might teach your favorite programming paradigm. They can take it, and they will also learn others anyway. To teenagers who might never learn another language, it is not a good idea. >> There are also a lot of very basic data structures that can simply not >> be used in purely functional code like hash tables, pipes or random >> access arrays. > > Why do you think that manipulating arrays is a better skill to teach > to kids than manipulating linked lists? What about double linked lists then. Most updatable data structures are just clumsy in Haskell. > There was a nice article on reddit of a parent that was in progress of teaching > Haskell to his/her 10-years old, and it was a great experience. I cannot find it anymore. > Remember, kids (motivated kids, at least) are way smarter than what school > usually seems to think. Some kids are smarter, some less so. In secondary school you should have a curriculum that most students can follow. Cheers Silvio From donn at avvanta.com Fri Aug 28 17:45:31 2015 From: donn at avvanta.com (Donn Cave) Date: Fri, 28 Aug 2015 10:45:31 -0700 (PDT) Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: <20150828174531.DEB4A93C2E@mail.avvanta.com> Quoth Mike Meyer , ... > Manipulating storage is as fundamental to common computers as sequential > operation, so if you're going to drop Haskell for not having one, you > should also drop Python for not having the other. For sure. That `step by step, like computers' argument seems more like a rationalization, for the basic proposition that Python is easier to deal with. Which may be true, but that wasn't the question. I've never used Smalltalk, but assuming that its virtues had something to do with the large number of subsequent OOP languages, that might be one to look at. I think it's fair to say that Haskell is an exceptionally interesting language, for those who are interested in such things. I wouldn't bet my life that a novice would see anything beautiful about it. Historically, many of the guys I worked with, I guess including myself, were attracted to assembly language for reasons that were in no way practical. It's terrible for productivity and even worse for maintenance, but we looked forward to the chance to write a few lines of it now and then. I'm not proposing an assembly language course, maybe just trying to shed some light on the distinction between a "good" (practical) programming choice and an esthetic choice. Donn From fa-ml at ariis.it Fri Aug 28 18:04:38 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 28 Aug 2015 20:04:38 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E08229.5050602@gmail.com> References: <55E08229.5050602@gmail.com> Message-ID: <20150828180438.GA13468@casa.casa> On Fri, Aug 28, 2015 at 05:45:45PM +0200, Silvio Frischknecht wrote: > Python would by my language of choice. You won't have to worry about low > level stuff or typing, but can still write those step by step programs. Amen brother! It's secondary school and I strongly suspect there won't be much time available. I love Haskell, but let's compare the time/effort to program a simple game in Python/Lua and in Haskell and you'll see it just makes more sense in this situation. From rustompmody at gmail.com Fri Aug 28 18:12:47 2015 From: rustompmody at gmail.com (Rustom Mody) Date: Fri, 28 Aug 2015 23:42:47 +0530 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E09C5A.1000600@gmail.com> References: <55E08229.5050602@gmail.com> <55E09C5A.1000600@gmail.com> Message-ID: On Fri, Aug 28, 2015 at 11:07 PM, Silvio Frischknecht < silvio.frischi at gmail.com> wrote: > > I kindly disagree. > > This being a haskell mailing list, I expected that :) > > > If the focus is to teach computer architecture, you are > > not teaching programming. If the focus is on programming, then it should > > focus on the conceptual aspects of programming, not on computers. > > A course at school should of course teach both, but in my opinion not > > concurrently. There?s no point in teaching something implicitly by using > > the teaching of something else. > > It's more about algorithms than computer architecture. An imperative > program very clearly describes algorithms; Haskell does not. Unless you > have a very good understanding of things like lazyness, non-strictness > and tail recursion, you wont know what happens when and how. > ?It is easier to optimize correct code than to correct optimized code.? --Bill Harlan More heretically I draw your attention to Bob Harper's SECP ?everyone knows that algorithms as welearned them at school are irrelevant to practice. ? http://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf In my view ?CS is the science of algorithms? is one of those memes that has held back our field because it underplays data. And traditional programming pedagogy (aka imperative programming) is wrong because it emphasizes code at the cost of data > > We are not talking about undergraduates here, but kids or teenagers. > > Think about which is the reason why you are teaching something to them. > > It is not to teach some specific skill or to make them be advantaged in > > future undergraduate courses. It is to teach them to reason. > > Functional programming is just more reasoning than technicalities. > > All the more reason not to teach Haskell. To CS undergraduates you might > teach your favorite programming paradigm. They can take it, and they > will also learn others anyway. To teenagers who might never learn > another language, it is not a good idea. > > >> There are also a lot of very basic data structures that can simply not > >> be used in purely functional code like hash tables, pipes or random > >> access arrays. > > > > Why do you think that manipulating arrays is a better skill to teach > > to kids than manipulating linked lists? > > What about double linked lists then. Most updatable data structures are > just clumsy in Haskell. > I see a lot of naivete in this thread (not just your claims). Every programming language will do some things niftily and (many) others clumsily. And when as teachers we consider the importance of Law of Primacy we need to carefully consider the order in which we introduce material. A case could be made [as Donn Cave does below] for assembly. >From my pov getting Hindley-Milner intuitions right should take primacy over updatable data structures. Likewise the best language of your choice will be based on what you consider primary. How do we come to an objective evaluation of that??? Dunno... > > There was a nice article on reddit of a parent that was in progress of > teaching > > Haskell to his/her 10-years old, and it was a great experience. I cannot > find it anymore. > > Remember, kids (motivated kids, at least) are way smarter than what > school > > usually seems to think. > > Some kids are smarter, some less so. In secondary school you should have > a curriculum that most students can follow. > Just to be clear I'd be pleasantly surprised if someone can show haskell is a good thing for school children. I dont know what is... Depends on the school and the child I guess?? On FP finally (50 years after Lisp!) making it to the abc level of CS-curricula: http://blog.languager.org/2015/06/functional-programming-moving-target.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Fri Aug 28 18:46:03 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 28 Aug 2015 13:46:03 -0500 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> <55E09C5A.1000600@gmail.com> Message-ID: My coauthor Julie has written about running her 10 year old son through our Haskell book, though the book was written for adults. He's only gotten stuck arithmetical concepts he hasn't learned yet, nothing specific to Haskell or functional programming. https://superginbaby.wordpress.com/2015/04/08/teaching-haskell-to-a-10-year-old-day-1/ He'll resume learning Haskell soon. He wants to get back to the Haskell and hasn't asked at all about the Minecraft modding tutorials he was doing because he feels like with Haskell he is being taught how things actually work, whereas the Minecraft modding was copy-pasta with little/no explanation. Haskell is also Julie's first programming language. I've cc'd her so she can say more about this if she wants. Haskell is great for teaching kids logic, math, data structures - you just can't skip details the way you can with experienced programmers. This isn't that much different from teaching adults who aren't experienced programmers. On Fri, Aug 28, 2015 at 1:12 PM, Rustom Mody wrote: > > > On Fri, Aug 28, 2015 at 11:07 PM, Silvio Frischknecht < > silvio.frischi at gmail.com> wrote: > >> > I kindly disagree. >> >> This being a haskell mailing list, I expected that :) >> >> > If the focus is to teach computer architecture, you are >> > not teaching programming. If the focus is on programming, then it should >> > focus on the conceptual aspects of programming, not on computers. >> > A course at school should of course teach both, but in my opinion not >> > concurrently. There?s no point in teaching something implicitly by using >> > the teaching of something else. >> >> It's more about algorithms than computer architecture. An imperative >> program very clearly describes algorithms; Haskell does not. Unless you >> have a very good understanding of things like lazyness, non-strictness >> and tail recursion, you wont know what happens when and how. >> > > ?It is easier to optimize correct code than to correct optimized code.? > --Bill Harlan > > More heretically I draw your attention to Bob Harper's SECP > > ?everyone knows that algorithms as welearned them at school are > irrelevant to practice. ? > http://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf > > In my view ?CS is the science of algorithms? is one of those memes that > has held back our field because it underplays data. > And traditional programming pedagogy (aka imperative programming) is wrong > because it emphasizes code at the cost of data > > >> > We are not talking about undergraduates here, but kids or teenagers. >> > Think about which is the reason why you are teaching something to them. >> > It is not to teach some specific skill or to make them be advantaged in >> > future undergraduate courses. It is to teach them to reason. >> > Functional programming is just more reasoning than technicalities. >> >> All the more reason not to teach Haskell. To CS undergraduates you might >> teach your favorite programming paradigm. They can take it, and they >> will also learn others anyway. To teenagers who might never learn >> another language, it is not a good idea. >> >> >> There are also a lot of very basic data structures that can simply not >> >> be used in purely functional code like hash tables, pipes or random >> >> access arrays. >> > >> > Why do you think that manipulating arrays is a better skill to teach >> > to kids than manipulating linked lists? >> >> What about double linked lists then. Most updatable data structures are >> just clumsy in Haskell. >> > > I see a lot of naivete in this thread (not just your claims). > Every programming language will do some things niftily and (many) others > clumsily. > And when as teachers we consider the importance of Law of Primacy > we need to > carefully consider the order in which we introduce material. > A case could be made [as Donn Cave does below] for assembly. > From my pov getting Hindley-Milner intuitions right should take primacy > over updatable data structures. > Likewise the best language of your choice will be based on what you > consider primary. > How do we come to an objective evaluation of that??? Dunno... > > > >> > There was a nice article on reddit of a parent that was in progress of >> teaching >> > Haskell to his/her 10-years old, and it was a great experience. I >> cannot find it anymore. >> > Remember, kids (motivated kids, at least) are way smarter than what >> school >> > usually seems to think. >> >> Some kids are smarter, some less so. In secondary school you should have >> a curriculum that most students can follow. >> > > > Just to be clear I'd be pleasantly surprised if someone can show haskell > is a good thing for school children. > I dont know what is... Depends on the school and the child I guess?? > > On FP finally (50 years after Lisp!) making it to the abc level of > CS-curricula: > http://blog.languager.org/2015/06/functional-programming-moving-target.html > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Fri Aug 28 19:10:12 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Fri, 28 Aug 2015 12:10:12 -0700 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> <55E09C5A.1000600@gmail.com> Message-ID: Personally, I would try to start with something with immediate feedback. Introduce functions on numbers with the REPL, something they are presumably familiar with. Then go on to show how we can use and manipulate things other than numbers in exactly the same way. A fun place to go quickly is the diagrams package. Just like we can have functions and operations with numbers, we can have them with shapes. Hook it up to something like IHaskell so that students can render shapes in the REPL just like they did with numbers. It'll take some setup: IHaskell is a pain to install and you might want to create your own wrapper around diagrams to have simpler types. But I think it would be worth it: you'll get an intuitive example of functions producing more complex outputs with immediate feedback in the form of pictures, made up by putting shapes together. The students will be able to produce designs that look cool by experimenting with the library while getting the hang of Haskell. On Aug 28, 2015 7:46 PM, "Christopher Allen" wrote: > My coauthor Julie has written about running her 10 year old son through > our Haskell book, though the book was written for adults. He's only gotten > stuck arithmetical concepts he hasn't learned yet, nothing specific to > Haskell or functional programming. > > > https://superginbaby.wordpress.com/2015/04/08/teaching-haskell-to-a-10-year-old-day-1/ > > He'll resume learning Haskell soon. He wants to get back to the Haskell > and hasn't asked at all about the Minecraft modding tutorials he was doing > because he feels like with Haskell he is being taught how things actually > work, whereas the Minecraft modding was copy-pasta with little/no > explanation. Haskell is also Julie's first programming language. I've cc'd > her so she can say more about this if she wants. > > Haskell is great for teaching kids logic, math, data structures - you just > can't skip details the way you can with experienced programmers. This isn't > that much different from teaching adults who aren't experienced programmers. > > On Fri, Aug 28, 2015 at 1:12 PM, Rustom Mody > wrote: > >> >> >> On Fri, Aug 28, 2015 at 11:07 PM, Silvio Frischknecht < >> silvio.frischi at gmail.com> wrote: >> >>> > I kindly disagree. >>> >>> This being a haskell mailing list, I expected that :) >>> >>> > If the focus is to teach computer architecture, you are >>> > not teaching programming. If the focus is on programming, then it >>> should >>> > focus on the conceptual aspects of programming, not on computers. >>> > A course at school should of course teach both, but in my opinion not >>> > concurrently. There?s no point in teaching something implicitly by >>> using >>> > the teaching of something else. >>> >>> It's more about algorithms than computer architecture. An imperative >>> program very clearly describes algorithms; Haskell does not. Unless you >>> have a very good understanding of things like lazyness, non-strictness >>> and tail recursion, you wont know what happens when and how. >>> >> >> ?It is easier to optimize correct code than to correct optimized code.? >> --Bill Harlan >> >> More heretically I draw your attention to Bob Harper's SECP >> >> ?everyone knows that algorithms as welearned them at school are >> irrelevant to practice. ? >> http://www.cs.cmu.edu/~rwh/papers/secp/secp.pdf >> >> In my view ?CS is the science of algorithms? is one of those memes that >> has held back our field because it underplays data. >> And traditional programming pedagogy (aka imperative programming) is >> wrong because it emphasizes code at the cost of data >> >> >>> > We are not talking about undergraduates here, but kids or teenagers. >>> > Think about which is the reason why you are teaching something to them. >>> > It is not to teach some specific skill or to make them be advantaged in >>> > future undergraduate courses. It is to teach them to reason. >>> > Functional programming is just more reasoning than technicalities. >>> >>> All the more reason not to teach Haskell. To CS undergraduates you might >>> teach your favorite programming paradigm. They can take it, and they >>> will also learn others anyway. To teenagers who might never learn >>> another language, it is not a good idea. >>> >>> >> There are also a lot of very basic data structures that can simply not >>> >> be used in purely functional code like hash tables, pipes or random >>> >> access arrays. >>> > >>> > Why do you think that manipulating arrays is a better skill to teach >>> > to kids than manipulating linked lists? >>> >>> What about double linked lists then. Most updatable data structures are >>> just clumsy in Haskell. >>> >> >> I see a lot of naivete in this thread (not just your claims). >> Every programming language will do some things niftily and (many) others >> clumsily. >> And when as teachers we consider the importance of Law of Primacy >> we need >> to carefully consider the order in which we introduce material. >> A case could be made [as Donn Cave does below] for assembly. >> From my pov getting Hindley-Milner intuitions right should take primacy >> over updatable data structures. >> Likewise the best language of your choice will be based on what you >> consider primary. >> How do we come to an objective evaluation of that??? Dunno... >> >> >> >>> > There was a nice article on reddit of a parent that was in progress of >>> teaching >>> > Haskell to his/her 10-years old, and it was a great experience. I >>> cannot find it anymore. >>> > Remember, kids (motivated kids, at least) are way smarter than what >>> school >>> > usually seems to think. >>> >>> Some kids are smarter, some less so. In secondary school you should have >>> a curriculum that most students can follow. >>> >> >> >> Just to be clear I'd be pleasantly surprised if someone can show haskell >> is a good thing for school children. >> I dont know what is... Depends on the school and the child I guess?? >> >> On FP finally (50 years after Lisp!) making it to the abc level of >> CS-curricula: >> http://blog.languager.org/2015/06/functional-programming-moving-target.html >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > Chris Allen > Currently working on http://haskellbook.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Fri Aug 28 19:54:17 2015 From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=) Date: Fri, 28 Aug 2015 21:54:17 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: References: <55ACF281.6020707@nh2.me> Message-ID: <55E0BC69.4020404@nh2.me> On 25/07/15 00:29, Alexander Kjeldaas wrote: > I think CLOEXEC should be the default, but it doesn't seem to solve your > problem. What if thread 2 executes "myBinary" before thread 1 called exec()? I'm not sure I understand your scenario - does it change the problem? From allbery.b at gmail.com Fri Aug 28 20:14:37 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 28 Aug 2015 16:14:37 -0400 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: References: <55ACF281.6020707@nh2.me> Message-ID: On Fri, Jul 24, 2015 at 6:29 PM, Alexander Kjeldaas < alexander.kjeldaas at gmail.com> wrote: > I think CLOEXEC should be the default, but it doesn't seem to solve your > problem. What if thread 2 executes "myBinary" before thread 1 called exec()? > I think you missed that each thread is using its own temporary directory --- they're not all running at the same time in the same directory, which would be pretty much guaranteed to fail. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Fri Aug 28 20:17:33 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Fri, 28 Aug 2015 22:17:33 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: Exactly Mike, The destruction of pedagogy and innovation by Rationalism: http://nocorrecto.blogspot.com.es/2014/05/the-destruction-of-pedagogy-and.html 2015-08-28 19:19 GMT+02:00 Mike Meyer : > On Fri, Aug 28, 2015 at 11:23 AM Nicola Gigante > wrote: > >> That?s also why I don?t agree with the math curriculum in high-school >> (only elementary algebra, trigonometry and basic calculus, at least here >> in Italy). >> If a student doesn?t go to college or studies something non-scientific >> (or even some low-math science), he?ll never see an abstract >> mathematical concept (see e.g. groups) in all his lives, thus living >> forever by completely ignoring what math is all about. >> (and this is really connected with the record-low public trust in science >> that we are suffering). >> > > Have you seen this? > > https://www.maa.org/external_archive/devlin/LockhartsLament.pdf > > It pretty much hits the nail on the head for most high school math > curricula. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From _deepfire at feelingofgreen.ru Fri Aug 28 21:26:04 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Sat, 29 Aug 2015 00:26:04 +0300 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <20150828180438.GA13468@casa.casa> (sfid-20150828_222642_820804_87C06BE3) (Francesco Ariis's message of "Fri, 28 Aug 2015 20:04:38 +0200") References: <55E08229.5050602@gmail.com> <20150828180438.GA13468@casa.casa> Message-ID: <8737z3gl5f.fsf@andromedae.feelingofgreen.ru> Francesco Ariis writes: > I love Haskell, but let's compare the time/effort to program a simple > game in Python/Lua and in Haskell and you'll see it just makes more sense > in this situation. Now, how is this different from a comparison of the amount of effort spent on the relevant libraries? ..where the difference is still enormous, like multiple orders of magnitude. -- ? ???????e? / respectfully, ??????? ?????? -- ?And those who were seen dancing were thought to be insane by those who could not hear the music.? ? Friedrich Wilhelm Nietzsche From fa-ml at ariis.it Fri Aug 28 21:43:45 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 28 Aug 2015 23:43:45 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <8737z3gl5f.fsf@andromedae.feelingofgreen.ru> References: <55E08229.5050602@gmail.com> <20150828180438.GA13468@casa.casa> <8737z3gl5f.fsf@andromedae.feelingofgreen.ru> Message-ID: <20150828214345.GA1275@casa.casa> On Sat, Aug 29, 2015 at 12:26:04AM +0300, Kosyrev Serge wrote: > Now, how is this different from a comparison of the amount of effort > spent on the relevant libraries? > > ..where the difference is still enormous, like multiple orders of magnitude. That's exactly the point (amusingly illustrated in this comic [1]). I must say the suggestion to use `diagrams` (made by Tikhon Jelvis) makes really sense: it's fun, it's easy/quick to set up, it's powerful. [1] http://gaspull.geeksaresexytech.netdna-cdn.com/wp-content/uploads/2011/02/essays.png From agocorona at gmail.com Fri Aug 28 21:50:43 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Fri, 28 Aug 2015 23:50:43 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <20150828214345.GA1275@casa.casa> References: <55E08229.5050602@gmail.com> <20150828180438.GA13468@casa.casa> <8737z3gl5f.fsf@andromedae.feelingofgreen.ru> <20150828214345.GA1275@casa.casa> Message-ID: I think that Haskell has a lot of accidental complexity in many areas. There is a kind of pseudo-mathematical cargo cult that make some problems artificially difficult. 2015-08-28 23:43 GMT+02:00 Francesco Ariis : > On Sat, Aug 29, 2015 at 12:26:04AM +0300, Kosyrev Serge wrote: > > Now, how is this different from a comparison of the amount of effort > > spent on the relevant libraries? > > > > ..where the difference is still enormous, like multiple orders of > magnitude. > > That's exactly the point (amusingly illustrated in this comic [1]). > > I must say the suggestion to use `diagrams` (made by Tikhon Jelvis) > makes really sense: it's fun, it's easy/quick to set up, it's powerful. > > > [1] > http://gaspull.geeksaresexytech.netdna-cdn.com/wp-content/uploads/2011/02/essays.png > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Fri Aug 28 22:24:03 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 28 Aug 2015 22:24:03 +0000 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <20150828214345.GA1275@casa.casa> References: <55E08229.5050602@gmail.com> <20150828180438.GA13468@casa.casa> <8737z3gl5f.fsf@andromedae.feelingofgreen.ru> <20150828214345.GA1275@casa.casa> Message-ID: On Fri, Aug 28, 2015 at 4:44 PM Francesco Ariis wrote: > On Sat, Aug 29, 2015 at 12:26:04AM +0300, Kosyrev Serge wrote: > > Now, how is this different from a comparison of the amount of effort > > spent on the relevant libraries? > > > > ..where the difference is still enormous, like multiple orders of > magnitude. > > That's exactly the point (amusingly illustrated in this comic [1]). > And that's what programming these days should be like: finding the right libraries to use, and the connecting them properly. Python does this really well because it comes bundled with a well-curated set of libraries, and excellent libraries built on top of those. Haskell should do it well because the language makes building composable functions easier than OOP languages, and the community encourages people who do so. In general, I've found combining Haskell libraries - where they exist - easier than doing the same for Python libraries. > I must say the suggestion to use `diagrams` (made by Tikhon Jelvis) > makes really sense: it's fun, it's easy/quick to set up, it's powerful. > Part of it's power comes from having well-defined composable functions. It's also fairly complete, so I haven't really had a chance to integrate it with other libraries. This may be a module that favors Haskell the way PyGame favors Python. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donn at avvanta.com Fri Aug 28 22:31:01 2015 From: donn at avvanta.com (Donn Cave) Date: Fri, 28 Aug 2015 15:31:01 -0700 (PDT) Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: <20150828223101.B544A276D62@mail.avvanta.com> quoth "Alberto G. Corona " > I think that Haskell has a lot of accidental complexity in many areas. > There is a kind of pseudo-mathematical cargo cult that make some problems > artificially difficult. Perhaps that's an esthetic thing, does this struggle make it more beautiful? Donn From agocorona at gmail.com Fri Aug 28 23:01:20 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Sat, 29 Aug 2015 01:01:20 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <20150828223101.B544A276D62@mail.avvanta.com> References: <20150828223101.B544A276D62@mail.avvanta.com> Message-ID: Not exactly aesthetic. if any, the effect is an aestetic recharged and baroque. I think that all programming languages fall in a kind of religion when they are in fashion. And religion this is not what a languages are is made for. A language is a tool whose rules of beauty must be simplicity and understandability as well as composability. It is not a tool for personal exhibition neither an excuse for the formation of closed groups of initiated. In which case, simplicity, understandability and composability is what that second kind of people will oppose as much as they can. In practice everything is a mix of both, and programming languages are not an exception. Haskell is in fashion so... 2015-08-29 0:31 GMT+02:00 Donn Cave : > quoth "Alberto G. Corona " > > > I think that Haskell has a lot of accidental complexity in many areas. > > There is a kind of pseudo-mathematical cargo cult that make some problems > > artificially difficult. > > Perhaps that's an esthetic thing, does this struggle make it more > beautiful? > > Donn > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpglover64 at gmail.com Fri Aug 28 23:13:35 2015 From: rpglover64 at gmail.com (Alex Rozenshteyn) Date: Fri, 28 Aug 2015 19:13:35 -0400 Subject: [Haskell-cafe] List of nitpicks In-Reply-To: <55E061A6.6040101@htwk-leipzig.de> References: <55E061A6.6040101@htwk-leipzig.de> Message-ID: But you can't do something like instance E a On Fri, Aug 28, 2015 at 9:27 AM, Johannes Waldmann < johannes.waldmann at htwk-leipzig.de> wrote: > Re: http://repetae.net/recent/out/classalias.html > > Prelude> :set -XConstraintKinds > Prelude> class C a; class D a; type E a = (C a, D a); instance E a => C > (Maybe a) > > > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/constraint-kind.html > > - J.W. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody at gmail.com Sat Aug 29 04:15:48 2015 From: rustompmody at gmail.com (Rustom Mody) Date: Sat, 29 Aug 2015 09:45:48 +0530 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: On Fri, Aug 28, 2015 at 10:25 PM, Will Yager wrote: > > https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budget%20Council%20concerning%20Haskell.pdf > > > Thanks for that Will Added a 2001 entry to my FP-timeline http://blog.languager.org/2015/04/cs-history-1.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Sat Aug 29 04:17:25 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Fri, 28 Aug 2015 20:17:25 -0800 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E08229.5050602@gmail.com> References: <55E08229.5050602@gmail.com> Message-ID: On 28/08/2015, Silvio Frischknecht wrote: > It has a very complicated type-system, and it's restriction to purely > functional programming does not convey very well how (current) computers > work. Current computers work by you giving them an step by step guide > what to do. This I think is what should be at the base of any > beginners-programming course. So assembly. Actually we ought to start with semiconductor physics, VLSI fabrication, and such. cuz that's how current computers work. > There are also a lot of very basic data structures that can simply not > be used in purely functional code like hash tables, pipes or random > access arrays. Wrong about hash tables [0] and random-access arrays [1] at least. > Haskell also requires quite a bit of intelligence Oh no, the student might have to think! That won't do. > and perseverance to > master. Unlike imperative languages, which require no perseverance to master, yeah? > Python would by my language of choice. You won't have to worry about low > level stuff or typing, but can still write those step by step programs. Yep, one needn't worry about typing, one can freely pass a widget to a function what wants a gizmo and have it cheerfully barf some cryptic exception and stack trace at one, what fun! Oh, by the way, Python isn't how computers work either. On 28/08/2015, Mike Meyer wrote: > Python is a good language if you want an imperative language Python is a good language if you want pain. I see much praise of Python, while Haskell mostly performs better, is less verbose, and catches type errors. Worse yet, I see counsel to learn it as a first language. On 28/08/2015, Silvio Frischknecht wrote: > Some kids are smarter, some less so. In secondary school you should have > a curriculum that most students can follow. This does the smarter and more interested students a great wrong. If someone needs extra help, they ought to get it, but not while boring others partly to death like they do in Ontario at least. Ideally each student would have their own program, but that's practically difficult, so some stratification may be needed, but not teaching the more stimulating at all lest some slower folks need to work harder is toxic. [0] https://hackage.haskell.org/package/hashtables [1] https://hackage.haskell.org/package/array From mwm at mired.org Sat Aug 29 05:35:49 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 29 Aug 2015 05:35:49 +0000 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: On Fri, Aug 28, 2015, 23:17 M Farkas-Dyck wrote: > Python is a good language if you want an imperative language Python is a good language if you want pain. Probably better to use the more exact language in the original. -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Sat Aug 29 05:56:55 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Fri, 28 Aug 2015 21:56:55 -0800 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: On 28/08/2015, Mike Meyer wrote: > Probably better to use the more exact language in the original. What more exact language? From donn at avvanta.com Sat Aug 29 06:09:50 2015 From: donn at avvanta.com (Donn Cave) Date: Fri, 28 Aug 2015 23:09:50 -0700 (PDT) Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: <20150829060950.83DCB276D62@mail.avvanta.com> quoth M Farkas-Dyck > ... I see much praise of > Python, while Haskell mostly performs better, is less verbose, and > catches type errors. Worse yet, I see counsel to learn it as a first > language. Sure - "Programming for Everybody" is practically a Python trademark! It is kind of embarrassing when Haskell enthusiasts see Python as a better language for beginners. But in either case I think we'd expect only a fairly superficial treatment of the language, right? I mean, for example, back in the day, one of my colleagues picked up Python for random minor utilitarian purposes, and when I talked to him he hadn't used classes for anything, so for him it was only incidentally OOP inasmuch as some of the built in functions were addressed as object member functions. A beginning student doesn't need to learn OOP in any kind of depth. He or she would need to learn about the IO monad, but maybe not monads in general. I suppose that might somewhat limit one's potential appreciation of Haskell's beauty, if we're still talking about that. Donn From mwm at mired.org Sat Aug 29 06:24:46 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 29 Aug 2015 06:24:46 +0000 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: On Sat, Aug 29, 2015, 00:57 M Farkas-Dyck wrote: On 28/08/2015, Mike Meyer wrote: > Probably better to use the more exact language in the original. What more exact language? "Imperative language" instead of "pain". -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Sat Aug 29 06:50:37 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Fri, 28 Aug 2015 22:50:37 -0800 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: On 28/08/2015, Mike Meyer wrote: > "Imperative language" instead of "pain". It's no more exact. I'm not disputing whether Python is an imperative language; I'm rather disputing whether it's good ? On 28/08/2015, Mike Meyer wrote: > I have to disagree, and for much the same reason that Nicola does: these > details matter if you're teaching computer architecture, but not if you are > teaching programming. At least, not in an introductory course. Here I fully agree. If one is teaching computer architecture, assembly is uniquely appropriate. If one is teaching programming, Haskell is non-uniquely appropriate, but I would not consider Python appropiate. Haskell is a better imperative programming language than Python. It has mutable state where needed, in the ST monad. Beautiful is better than ugly. Explicit is better than implicit. Haskell is better than Python. From strake888 at gmail.com Sat Aug 29 07:03:15 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Fri, 28 Aug 2015 23:03:15 -0800 Subject: [Haskell-cafe] General Functor and Traversable In-Reply-To: <1440701976952-5816351.post@n5.nabble.com> References: <55dbdb17.4271440a.22d6a.4647@mx.google.com> <1440701976952-5816351.post@n5.nabble.com> Message-ID: On 27/08/2015, htebalaka wrote: > I'm not sure what the more category-theoretic version of Traversable is, > though I don't think mapM is actually an instance of a Functor in a Kleisli > category in the first place. Consider the Functor laws: > > mapM return = return > mapM (f <=< g) = mapM f <=< mapM g > > It's easy to show the second law doesn't hold, as in the RHS we have to run > all the effects from "mapM g" before any of the effects from "mapM f" can > start, while in the LHS the effects will be interleaved. Yes, sorry about the noise, and thanks ? From mwm at mired.org Sat Aug 29 07:03:33 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 29 Aug 2015 07:03:33 +0000 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: On Sat, Aug 29, 2015, 01:50 M Farkas-Dyck wrote: Haskell is a better imperative programming language than Python. Except that teaching beginners to write imperative code in Haskell is doing both them and Haskell a grave disservice. If you're going to do that, you ought to pick a language that was designed for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Sat Aug 29 08:41:52 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Sat, 29 Aug 2015 01:41:52 -0700 (PDT) Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <20150829060950.83DCB276D62@mail.avvanta.com> References: <20150829060950.83DCB276D62@mail.avvanta.com> Message-ID: <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> IMO, what attracts a big part of kids to programming is the possibility to program side effects. It seems to me that Haskell takes a big care to "seal off" the side effects and does it in a nontrivial way. This may complicate introduction to programming. Telling the kids to "just use the IO monad and don't worry want a 'monad' is, it is just a magic word, it comes from Category Theory, don't try to understand, just follow me" might not be a good way to teach. I've seen assembly language mentioned here, and what attracted me to it, when i was a kid, was the possibility to program "side effects" explicitly. Even if i could not observe those side effects, like change of a register value, directly, they could be tested indirectly. Alexey. On Saturday, August 29, 2015 at 8:10:58 AM UTC+2, Donn Cave wrote: > > quoth M Farkas-Dyck > > > > ... I see much praise of > > Python, while Haskell mostly performs better, is less verbose, and > > catches type errors. Worse yet, I see counsel to learn it as a first > > language. > > Sure - "Programming for Everybody" is practically a Python trademark! > > It is kind of embarrassing when Haskell enthusiasts see Python as a > better language for beginners. But in either case I think we'd expect > only a fairly superficial treatment of the language, right? I mean, > for example, back in the day, one of my colleagues picked up Python > for random minor utilitarian purposes, and when I talked to him he > hadn't used classes for anything, so for him it was only incidentally > OOP inasmuch as some of the built in functions were addressed as object > member functions. A beginning student doesn't need to learn OOP in > any kind of depth. He or she would need to learn about the IO monad, > but maybe not monads in general. I suppose that might somewhat limit > one's potential appreciation of Haskell's beauty, if we're still > talking about that. > > Donn > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.gigante at gmail.com Sat Aug 29 09:49:39 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Sat, 29 Aug 2015 11:49:39 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: <65456F0B-49FE-46A9-92A3-31FE8B4FB88F@gmail.com> > Il giorno 28/ago/2015, alle ore 22:17, Alberto G. Corona ha scritto: > > Exactly Mike, > > The destruction of pedagogy and innovation by Rationalism: > > http://nocorrecto.blogspot.com.es/2014/05/the-destruction-of-pedagogy-and.html Wright brothers and Watt were tinkerers, not scientists? Well, maybe they were not _formally educated theoretical_ scientists. Science is every bit about trial-error experimentation as is about rational thinking. Science lives on the curiosity of a human being that wants to know what happens if he does something of which he cannot anticipate the effects. So 19th and 20th century pioneers were scientists, and good ones indeed. That post misses it. And talking about formalism, I?d like to ask the author of that post who he thinks has brought humanity from Wright?s flying patch of metal pieces to the Apollo 11 mission, and from Watt?s experiments to 15nm intel CPUs. Certainly not other tinkering, but engineers that do hard physics backed by a strong mathematical background. It is true that naked formalism is not pedagogical, but even when you start learning at young age you have to learn that to do new things, _in this century_, you have to understand how things work. Easy tinkering things have already all been discovered, we missed that train. Anyway I?m sorry, this was a bit OT, so I promise to not talk further about it. Bye :) Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Sat Aug 29 10:00:43 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Sat, 29 Aug 2015 12:00:43 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> References: <20150829060950.83DCB276D62@mail.avvanta.com> <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> Message-ID: In general the haskell community is helpful with novice programmers interested in learning concepts, but it is very hostile to novice programmers with a practical standpoint. It is not acceptable for many practical programmers that for a simple console program it would be necessary to chain three monad transformers when this is not really necessary. Unless the newcomer is willing to accept it. That reinforces the prejudice of the community against practicality in solving real problems. The result is a community that can discuss for hours how to calculate the factorial of a number or what kind of fold-map is more pretty or if lenses are comonadic metafunctors. It is an error to introduce people to program in haskell using category theory. Is like if you teach your kid to handle his money starting with "John let me say you something: money is isomorphic to the rational numbers and rational numbers form an algebra. son consider a structure {N,+.*} where...." It is the same that teaching music by first imposing three years learning musical notation. Or teaching a language by his grammar. If so, all other languages should also be teached using CT, since the underlying structure of imperative programming is also CT. Moreover it happens that the practical people are the ones that tend to think out of the box. Innovation requires some kind of disrespect for what is settled. Solving problems that nobody has solved already requires this kind of disrespect too. An excessive formalistic mind lives in a box from which it can not scape. It is like a bureaucracy of the mind. This creates the atmosphere for a kind of cargo cult religion that I mentioned above. If this is a religi?n, it is not mine. I think that the Haskell community has to think seriously the reasons for his incredible success and influence as well as his almost complete failure in practical application in the Industry. And why, if some haskellers have success in the real world, they almost invariably disconnect from the haskell community. 2015-08-29 10:41 GMT+02:00 Alexey Muranov : > IMO, what attracts a big part of kids to programming is the possibility to > program side effects. It seems to me that Haskell takes a big care to "seal > off" the side effects and does it in a nontrivial way. This may complicate > introduction to programming. Telling the kids to "just use the IO monad and > don't worry want a 'monad' is, it is just a magic word, it comes from > Category Theory, don't try to understand, just follow me" might not be a > good way to teach. > > I've seen assembly language mentioned here, and what attracted me to it, > when i was a kid, was the possibility to program "side effects" explicitly. > Even if i could not observe those side effects, like change of a register > value, directly, they could be tested indirectly. > > Alexey. > > On Saturday, August 29, 2015 at 8:10:58 AM UTC+2, Donn Cave wrote: >> >> quoth M Farkas-Dyck >> >> > ... I see much praise of >> > Python, while Haskell mostly performs better, is less verbose, and >> > catches type errors. Worse yet, I see counsel to learn it as a first >> > language. >> >> Sure - "Programming for Everybody" is practically a Python trademark! >> >> It is kind of embarrassing when Haskell enthusiasts see Python as a >> better language for beginners. But in either case I think we'd expect >> only a fairly superficial treatment of the language, right? I mean, >> for example, back in the day, one of my colleagues picked up Python >> for random minor utilitarian purposes, and when I talked to him he >> hadn't used classes for anything, so for him it was only incidentally >> OOP inasmuch as some of the built in functions were addressed as object >> member functions. A beginning student doesn't need to learn OOP in >> any kind of depth. He or she would need to learn about the IO monad, >> but maybe not monads in general. I suppose that might somewhat limit >> one's potential appreciation of Haskell's beauty, if we're still >> talking about that. >> >> Donn >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskel... at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benno.fuenfstueck at gmail.com Sat Aug 29 10:09:47 2015 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Sat, 29 Aug 2015 10:09:47 +0000 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <65456F0B-49FE-46A9-92A3-31FE8B4FB88F@gmail.com> References: <55E08229.5050602@gmail.com> <65456F0B-49FE-46A9-92A3-31FE8B4FB88F@gmail.com> Message-ID: In my opinion, the focus on beauty of the language is simply inappropriate for a teaching language. An experienced programmer or mathematician might enjoy transforming a ten line function into a simple one with only one line, but I think for many students, it won't be so interesting to transform one working program into a nicer one. Not all people see simplicity of math as a beautiful thing, for them a simpler formula is not much more interesting than an equal more complicated one. I believe that you need some experience to appreciate simplicity and elegance. Just my two cents, Benno Nicola Gigante schrieb am Sa., 29. Aug. 2015 11:49: > > Il giorno 28/ago/2015, alle ore 22:17, Alberto G. Corona < > agocorona at gmail.com> ha scritto: > > Exactly Mike, > > The destruction of pedagogy and innovation by Rationalism: > > > http://nocorrecto.blogspot.com.es/2014/05/the-destruction-of-pedagogy-and.html > > > Wright brothers and Watt were tinkerers, not scientists? Well, maybe they > were not > _formally educated theoretical_ scientists. Science is every bit about > trial-error experimentation > as is about rational thinking. Science lives on the curiosity of a human > being that wants to > know what happens if he does something of which he cannot anticipate the > effects. > So 19th and 20th century pioneers were scientists, and good ones indeed. > That post misses it. > > And talking about formalism, I?d like to ask the author of that post who > he thinks has > brought humanity from Wright?s flying patch of metal pieces to the Apollo > 11 mission, > and from Watt?s experiments to 15nm intel CPUs. Certainly not other > tinkering, but > engineers that do hard physics backed by a strong mathematical background. > It is true that naked formalism is not pedagogical, but even when you > start learning > at young age you have to learn that to do new things, _in this century_, > you have to > understand how things work. > Easy tinkering things have already all been discovered, we missed that > train. > > Anyway I?m sorry, this was a bit OT, so I promise to not talk further > about it. > > Bye :) > Nicola > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Sat Aug 29 10:28:58 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Sat, 29 Aug 2015 03:28:58 -0700 (PDT) Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: Message-ID: <2f1db42d-b6b3-4d9f-86ef-95d96a408299@googlegroups.com> I would like to mention, maybe somewhat off-topick, that the question "what to teach first, functional or imperative programming?" looks to me a bit similar to the question "what to teach first, lambda calculus or Turing machine?". While lambda calculus looks like a deep and exciting rewriting system, with interesting algebraic and combinatorial properties and a simpler and more satisfying definition than that of a Turing machine, it might be not the best model of algorithm to introduce kids to for the first time. At the very least, it would be necessary to prove confluence or to restrict to one evaluation strategy (so no laziness, or the other way around). Justifying Church-Turing thesis with lambda calculus instead of Turing machine is intuitively difficult, if at all possible. I have heard from a colleague (but do not have a reference for this, so not quite sure) that it was the Turing's solution of Hilbert's decision problem, and not the Church's, that was fully accepted by the community. Alexey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdammers at gmail.com Sat Aug 29 11:59:14 2015 From: tdammers at gmail.com (Tobias Dammers) Date: Sat, 29 Aug 2015 13:59:14 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> References: <20150829060950.83DCB276D62@mail.avvanta.com> <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> Message-ID: <20150829115913.GA13159@nibbler> On Sat, Aug 29, 2015 at 01:41:52AM -0700, Alexey Muranov wrote: > IMO, what attracts a big part of kids to programming is the possibility to > program side effects. What attracts them are the effects. Implementing them as side effects is largely a choice the designers of their language have made for them. > It seems to me that Haskell takes a big care to "seal off" the side > effects and does it in a nontrivial way. This may complicate > introduction to programming. Haskell simply refuses to allow side effects at all (aside from loopholes like unsafePerformIO). Making effects explicit complicates some things and simplifies others. > Telling the kids to "just use the IO monad and don't worry want a > 'monad' is, it is just a magic word, it comes from Category Theory, > don't try to understand, just follow me" might not be a good way to > teach. IO being a monad and IO being the type we use to describe real-world effects are orthogonal concerns. What we should teach people is that: - IO is the type we use to describe real-world actions - IO actions can be combines to construct complex effectful programs from simple building blocks - Many of the ways in which we can combine IO actions follow the Monad pattern, just like we can combine Strings in ways that follow the Monoid pattern. - You don't need to fully grasp the Monad pattern in order to use it with IO; just get used to how monad operations work for IO and go from there. The more general intuitions will follow in due time. > I've seen assembly language mentioned here, and what attracted me to it, > when i was a kid, was the possibility to program "side effects" explicitly. > Even if i could not observe those side effects, like change of a register > value, directly, they could be tested indirectly. The value of teaching assembly language is that it's close to the metal, and thus suitable for a learning trajectory that roughly follows the way programming language design has unraveled over the past 60 years or so. Assembly language is, in fact, an abstraction already: by mapping mnemoics to machine instructions, we make them more palatable for humans. The observation that instead of looking up the bit patterns for machine instructions in a printed manual ourselves, we could have the computer do it for us, is what I consider the spark that bootstrapped the entire field of programming language design. That doesn't mean, however, that this is the only possible trajectory - it's a thorough one, and a very suitable one for people like me who want to understand it all before moving to the next level of abstraction, but most people, I realize, aren't like me. > > Alexey. > > On Saturday, August 29, 2015 at 8:10:58 AM UTC+2, Donn Cave wrote: > > > > quoth M Farkas-Dyck > > > > > > ... I see much praise of > > > Python, while Haskell mostly performs better, is less verbose, and > > > catches type errors. Worse yet, I see counsel to learn it as a first > > > language. > > > > Sure - "Programming for Everybody" is practically a Python trademark! > > > > It is kind of embarrassing when Haskell enthusiasts see Python as a > > better language for beginners. But in either case I think we'd expect > > only a fairly superficial treatment of the language, right? I mean, > > for example, back in the day, one of my colleagues picked up Python > > for random minor utilitarian purposes, and when I talked to him he > > hadn't used classes for anything, so for him it was only incidentally > > OOP inasmuch as some of the built in functions were addressed as object > > member functions. A beginning student doesn't need to learn OOP in > > any kind of depth. He or she would need to learn about the IO monad, > > but maybe not monads in general. I suppose that might somewhat limit > > one's potential appreciation of Haskell's beauty, if we're still > > talking about that. > > > > Donn > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskel... at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Tobias Dammers - tdammers at gmail.com From _deepfire at feelingofgreen.ru Sat Aug 29 13:18:07 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Sat, 29 Aug 2015 16:18:07 +0300 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <20150829115913.GA13159@nibbler> (sfid-20150829_162022_079266_2DB01B51) (Tobias Dammers's message of "Sat, 29 Aug 2015 13:59:14 +0200") References: <20150829060950.83DCB276D62@mail.avvanta.com> <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> <20150829115913.GA13159@nibbler> Message-ID: <87twrifd2o.fsf@andromedae.feelingofgreen.ru> Tobias Dammers writes: > On Sat, Aug 29, 2015 at 01:41:52AM -0700, Alexey Muranov wrote: >> IMO, what attracts a big part of kids to programming is the possibility to >> program side effects. > > What attracts them are the effects. Implementing them as side effects is > largely a choice the designers of their language have made for them. How very nicely put! Alexey's statement had bugged me quite the same, and your formulation is just about exactly what I would have said. -- ? ???????e? / respectfully, ??????? ?????? From donn at avvanta.com Sat Aug 29 14:23:03 2015 From: donn at avvanta.com (Donn Cave) Date: Sat, 29 Aug 2015 07:23:03 -0700 (PDT) Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <20150829115913.GA13159@nibbler> References: <20150829060950.83DCB276D62@mail.avvanta.com> <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> <20150829115913.GA13159@nibbler> Message-ID: <20150829142303.0DFAB276D62@mail.avvanta.com> Quoth Tobias Dammers , [... re assembly language] > That doesn't mean, however, that this is the only possible trajectory - > it's a thorough one, and a very suitable one for people like me who want > to understand it all before moving to the next level of abstraction, but > most people, I realize, aren't like me. Indeed, I think most people would have different reasons for finding assembly language interesting. Believe me, we truly wanted to write programs in assembly language. If we're out walking in the woods, and I jump up on a fallen log, do you think I must have done this because I want to strengthen my thighs and buttocks? At some primal unconscious level, perhaps that really is part of the motivation for such behaviors, but if so, we can let nature take care of itself. Similarly, some people have a natural compulsion to grapple with bits that can be combined in certain ways to make something that spins around and makes noises. These people (maybe anyone, to some degree) can satisfy this urge with computer programming. I can't say for sure why assembly language would delight such a person, but just guessing, it's the complete transparency - you aren't making some deal with a compiler to translate your notional program into instructions, rather you see exactly what you're doing in the computer's own language. I think Haskell has a peculiar appeal of its own, at this level, but of course it's quite different, and shows up in compulsive refinement. Donn From silvio.frischi at gmail.com Sat Aug 29 15:19:51 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sat, 29 Aug 2015 17:19:51 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> <55E09C5A.1000600@gmail.com> Message-ID: <55E1CD97.5090204@gmail.com> > Haskell is great for teaching kids logic, math, data structures - you > just can't skip details the way you can with experienced programmers. > This isn't that much different from teaching adults who aren't > experienced programmers. Most people on this list (me included) are probably people enjoying math and logic. But I know a lot of people who love CS and even do it professionally who think of math as a bit of a chore. Most of those take one look at Haskell and say "I'm not interested". With Python or Javascript/HTML you will be able to motivate a much bigger part of your audience. HTML was one of the first things I learned in CS. Also just wanted to add an example of how Haskell can be really tricky for very simple things. Let's consider the simplest loop I can think of. The function to sum up all the numbers up to N. Anyone new to Haskell will implement this in the straight forward way. sumToN 0 = 0 sumToN n = sumToN (n-1) + n It's very elegant. It's more of a definition than an algorithm, really. The equivalent python code would probably do a loop (4-5 lines). Now, if you run your python code for a billion, it will eventually return the correct result because you specified the algorithm more clearly. If you run the Haskell function for a billion however, it will crash your computer and set your house on fire. Now, you will have to explain tail recursion and why you won't get a StackOverflow despite the fact that you build up a huge stack. I have done Haskell for a quite a while, and I'm still unsure sometimes if something will work in constant space or not. Cheers, Silvio From targen at gmail.com Sat Aug 29 18:30:08 2015 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Sat, 29 Aug 2015 14:00:08 -0430 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E1CD97.5090204@gmail.com> References: <55E08229.5050602@gmail.com> <55E09C5A.1000600@gmail.com> <55E1CD97.5090204@gmail.com> Message-ID: On Sat, Aug 29, 2015 at 10:49 AM, Silvio Frischknecht wrote: > Also just wanted to add an example of how Haskell can be really tricky > for very simple things. > > Let's consider the simplest loop I can think of. The function to sum up > all the numbers up to N. Anyone new to Haskell will implement this in > the straight forward way. > > sumToN 0 = 0 > sumToN n = sumToN (n-1) + n > > It's very elegant. It's more of a definition than an algorithm, really. > The equivalent python code would probably do a loop (4-5 lines). > > Now, if you run your python code for a billion, it will eventually > return the correct result because you specified the algorithm more > clearly. If you run the Haskell function for a billion however, it will > crash your computer and set your house on fire. > > Now, you will have to explain tail recursion and why you won't get a > StackOverflow despite the fact that you build up a huge stack. I have > done Haskell for a quite a while, and I'm still unsure sometimes if > something will work in constant space or not. I understand what you?re trying to get at, and why this simplified example is supposed to stand in for a more general, complex, elaborate situation. However, I believe a more thorough, explicit description of this sort of situation may reveal such a simplified example is not adequately representative of the general problem. The function to sum up all the naturals up to N is most commonly written thus, in Haskell and Python: sumToN n = n * (n + 1) `div` 2 def sum_to_n(n): return n * (n + 1) / 2 No loops, no worries about stacks, no recursion or induction or intuition about computational processes supporting complexity. Depending on the student?s background, this may be the first solution that is attempted for the given problem. The general point of this observation is that it often happens in computer programming that a programming-oriented solution is accidentally complex because it goes for a brute-force approach that ignores important qualities of the underlying problem space that enable solutions that avoid complexity. Granted, alternate strategies with lower complexity are not always available, and sometimes you do need some kind of aggregation. These are likewise easy in Haskell and Python: sumToN n = sum [1..n] def sum_to_n(n): return reduce(add, range(n + 1)) It?s noteworthy that both of these solutions have terrible performance for somewhat similar reasons unless you specifically go out of your way to avoid the issue. In GHCi, asking for the value of this sum at one billion seems to produce a very large list, and it depletes my machine?s RAM quite quickly. Doing the same in Python also creates a very large list and likewise starves my machine for memory. These issues can be solved by both programming environments. If you test the Haskell bit in a simple complete program compiled with `-O2`, it takes a while to run with a billion as `n`, but it does finish in a few seconds without consuming memory in proportion to `n`. GHC can optimize that list away, but you need to be aware of the issue to understand how to solve it: some things fuse away in compilation and stay around in interpreted code. The Python bit isn?t magically optimized by CPython 2.7. However, the recommended approach to these issues is to use `xrange` instead, which returns a generator object that produces results lazily, one by one, much like the list in Haskell, and `reduce` doesn?t need to hold onto the whole list of results since it?s actually working like a strict left fold. In fact, new versions of Python altogether skip the old list-building `range` function, and their `range` is Python 2.7?s `xrange`, so this issue goes away if you can use a new version of the language. Perhaps a future version of GHC may fuse lists away in GHCi. You may now argue that summing is only meant to stand in for some more elaborate computation, so this whole deal misses the point. I agree. In fact, this is a much more fair comparison: sumToN n = foldl1 (+) [1..n] def sum_to_n(n): return reduce(add, xrange(n + 1)) Indeed, both of these fail on empty ranges, and they have similar performance if the Haskell version is compiled with optimisation. There are many variations of these solutions, such as enabling them to use 0 as the result for empty summations or expressing them in terms of different primitives. But indeed these are two somewhat representative ways of expressing processes that need to perform aggregation of results over a range, both expressed in ways that are a natural fix **for the problem** as specified, ignoring issues related to language communities, preferences and idioms. You may now argue that the point of your original statements is precisely about idioms. I don?t know what the recommended, dominant idiom may be for any given portion of the Python community. I suppose it largely depends on the background of the sample you take from the Python community. This StackOverflow answer seems to suggest some people recommend `reduce` with lambdas for this sort of construct, yet others recommend `for` loops: http://stackoverflow.com/questions/13840379/python-multiply-all-items-in-a-list-together Perhaps this solution is even more representative of common idioms in a way that is somewhat less specific to the toy problem of performing simple summations: sumToN n = foldl1 (\ x y ? x + y) [1..n] def sum_to_n(n): return reduce(lambda x, y: x + y, xrange(n + 1)) Do these perform the same as before? I don?t know about the one in Haskell; I didn?t check. I suppose it may possibly depend on whether tests are performed in GHCi or compiled code with various optimization options. It should be absolutely trivial for the GHC simplifier to reduce both into the same code, but does it work quite the same in GHCi? I don?t know. The Python versions do appear to differ a bit in performance according to comments in that StackOverflow post. In any case, loops are also a common, recommended idiom in Python: sumToN n = runST $ do s <- newSTRef 0 for_ [1..n] $ \ i -> do modifySTRef' s (+ i) readSTRef s def sum_to_n(n): s = 0 for i in xrange(n + 1): s += i return s I?m pretty sure most Haskell novices wouldn?t write this one, just as I?m pretty sure most Python novices wouldn?t use `reduce`. These two behave more or less the same: they don?t leak space. They would leak space if you didn?t know you had to use `xrange` instead of `range`, or if you didn?t know you had to use `modifySTRef'` instead of `modifySTRef` (although the specific mechamism for the space leak is not precisely the same, but the causes are quite similar). Python solved this issue in recent versions by getting rid of the one that?s arguably less useful; in Haskell, there are warnings in the documentation: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-STRef.html#v:modifySTRef I must confess I fell into the trap when I wrote the Haskell version: I forgot to use `modifySTRef'`. I also fell into the `range` trap a few days ago writing Python 2.7 at work; the only reason I avoided it today is that it bit me very recently. I?ve been programming for 16 years and writing Haskell and Python for work and leisure for about 6 years. My point is that understanding these subtleties is important and you cannot be an effective software engineer if you don?t know how to avoid these sorts of pitfalls in whatever technology and style of expression you pick. Moreover, a modern, ?multi-paradigm? language will support and provide incentives for various styles of expression to varying degrees, and they come with code quality and performance tradeoffs that are not necessarily clear-cut. Programming is tricky and abstractions leak. Python uses fewer abstractions than Haskell, and Haskell?s abstractions (of comparable abstractness) leak less, and that?s how they both manage to be used successfully by practitioners. I prefer Haskell, because in the long run, having abstractions leak less allows me to compose taller towers of abstraction, which gives me more power as a software engineer. Whether this is relevant for a novice depends, I suppose, on where the novice wishes to go. Note: Some imports and pragmas may be necessary to make these examples work in their respective languages. I believe it?s fair to leave them out in all cases; providing a batteries-included default namespace is a significant issue, but it?s somewhat independent of these musings. From mantkiew at gsd.uwaterloo.ca Sat Aug 29 18:59:53 2015 From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca) Date: Sat, 29 Aug 2015 14:59:53 -0400 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> <55E09C5A.1000600@gmail.com> <55E1CD97.5090204@gmail.com> Message-ID: <20150829185953.5476436.58167.11415@gsd.uwaterloo.ca> @Manuel, beautifully laid out!? Going through your email I was wondering which one is "more beautiful" for each case and it's clear that Haskell is optimized for functional style and Python for imperative style, and things in their respective opposite styles look clumsy. That's it, end of story. Micha? ? Original Message ? From: Manuel G?mez Sent: Saturday, August 29, 2015 2:30 PM To: Silvio Frischknecht Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Why Haskell is beautiful to the novice On Sat, Aug 29, 2015 at 10:49 AM, Silvio Frischknecht wrote: > Also just wanted to add an example of how Haskell can be really tricky > for very simple things. > > Let's consider the simplest loop I can think of. The function to sum up > all the numbers up to N. Anyone new to Haskell will implement this in > the straight forward way. > > sumToN 0 = 0 > sumToN n = sumToN (n-1) + n > > It's very elegant. It's more of a definition than an algorithm, really. > The equivalent python code would probably do a loop (4-5 lines). > > Now, if you run your python code for a billion, it will eventually > return the correct result because you specified the algorithm more > clearly. If you run the Haskell function for a billion however, it will > crash your computer and set your house on fire. > > Now, you will have to explain tail recursion and why you won't get a > StackOverflow despite the fact that you build up a huge stack. I have > done Haskell for a quite a while, and I'm still unsure sometimes if > something will work in constant space or not. I understand what you?re trying to get at, and why this simplified example is supposed to stand in for a more general, complex, elaborate situation. However, I believe a more thorough, explicit description of this sort of situation may reveal such a simplified example is not adequately representative of the general problem. The function to sum up all the naturals up to N is most commonly written thus, in Haskell and Python: sumToN n = n * (n + 1) `div` 2 def sum_to_n(n): return n * (n + 1) / 2 No loops, no worries about stacks, no recursion or induction or intuition about computational processes supporting complexity. Depending on the student?s background, this may be the first solution that is attempted for the given problem. The general point of this observation is that it often happens in computer programming that a programming-oriented solution is accidentally complex because it goes for a brute-force approach that ignores important qualities of the underlying problem space that enable solutions that avoid complexity. Granted, alternate strategies with lower complexity are not always available, and sometimes you do need some kind of aggregation. These are likewise easy in Haskell and Python: sumToN n = sum [1..n] def sum_to_n(n): return reduce(add, range(n + 1)) It?s noteworthy that both of these solutions have terrible performance for somewhat similar reasons unless you specifically go out of your way to avoid the issue. In GHCi, asking for the value of this sum at one billion seems to produce a very large list, and it depletes my machine?s RAM quite quickly. Doing the same in Python also creates a very large list and likewise starves my machine for memory. These issues can be solved by both programming environments. If you test the Haskell bit in a simple complete program compiled with `-O2`, it takes a while to run with a billion as `n`, but it does finish in a few seconds without consuming memory in proportion to `n`. GHC can optimize that list away, but you need to be aware of the issue to understand how to solve it: some things fuse away in compilation and stay around in interpreted code. The Python bit isn?t magically optimized by CPython 2.7. However, the recommended approach to these issues is to use `xrange` instead, which returns a generator object that produces results lazily, one by one, much like the list in Haskell, and `reduce` doesn?t need to hold onto the whole list of results since it?s actually working like a strict left fold. In fact, new versions of Python altogether skip the old list-building `range` function, and their `range` is Python 2.7?s `xrange`, so this issue goes away if you can use a new version of the language. Perhaps a future version of GHC may fuse lists away in GHCi. You may now argue that summing is only meant to stand in for some more elaborate computation, so this whole deal misses the point. I agree. In fact, this is a much more fair comparison: sumToN n = foldl1 (+) [1..n] def sum_to_n(n): return reduce(add, xrange(n + 1)) Indeed, both of these fail on empty ranges, and they have similar performance if the Haskell version is compiled with optimisation. There are many variations of these solutions, such as enabling them to use 0 as the result for empty summations or expressing them in terms of different primitives. But indeed these are two somewhat representative ways of expressing processes that need to perform aggregation of results over a range, both expressed in ways that are a natural fix **for the problem** as specified, ignoring issues related to language communities, preferences and idioms. You may now argue that the point of your original statements is precisely about idioms. I don?t know what the recommended, dominant idiom may be for any given portion of the Python community. I suppose it largely depends on the background of the sample you take from the Python community. This StackOverflow answer seems to suggest some people recommend `reduce` with lambdas for this sort of construct, yet others recommend `for` loops: http://stackoverflow.com/questions/13840379/python-multiply-all-items-in-a-list-together Perhaps this solution is even more representative of common idioms in a way that is somewhat less specific to the toy problem of performing simple summations: sumToN n = foldl1 (\ x y ? x + y) [1..n] def sum_to_n(n): return reduce(lambda x, y: x + y, xrange(n + 1)) Do these perform the same as before? I don?t know about the one in Haskell; I didn?t check. I suppose it may possibly depend on whether tests are performed in GHCi or compiled code with various optimization options. It should be absolutely trivial for the GHC simplifier to reduce both into the same code, but does it work quite the same in GHCi? I don?t know. The Python versions do appear to differ a bit in performance according to comments in that StackOverflow post. In any case, loops are also a common, recommended idiom in Python: sumToN n = runST $ do s <- newSTRef 0 for_ [1..n] $ \ i -> do modifySTRef' s (+ i) readSTRef s def sum_to_n(n): s = 0 for i in xrange(n + 1): s += i return s I?m pretty sure most Haskell novices wouldn?t write this one, just as I?m pretty sure most Python novices wouldn?t use `reduce`. These two behave more or less the same: they don?t leak space. They would leak space if you didn?t know you had to use `xrange` instead of `range`, or if you didn?t know you had to use `modifySTRef'` instead of `modifySTRef` (although the specific mechamism for the space leak is not precisely the same, but the causes are quite similar). Python solved this issue in recent versions by getting rid of the one that?s arguably less useful; in Haskell, there are warnings in the documentation: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-STRef.html#v:modifySTRef I must confess I fell into the trap when I wrote the Haskell version: I forgot to use `modifySTRef'`. I also fell into the `range` trap a few days ago writing Python 2.7 at work; the only reason I avoided it today is that it bit me very recently. I?ve been programming for 16 years and writing Haskell and Python for work and leisure for about 6 years. My point is that understanding these subtleties is important and you cannot be an effective software engineer if you don?t know how to avoid these sorts of pitfalls in whatever technology and style of expression you pick. Moreover, a modern, ?multi-paradigm? language will support and provide incentives for various styles of expression to varying degrees, and they come with code quality and performance tradeoffs that are not necessarily clear-cut. Programming is tricky and abstractions leak. Python uses fewer abstractions than Haskell, and Haskell?s abstractions (of comparable abstractness) leak less, and that?s how they both manage to be used successfully by practitioners. I prefer Haskell, because in the long run, having abstractions leak less allows me to compose taller towers of abstraction, which gives me more power as a software engineer. Whether this is relevant for a novice depends, I suppose, on where the novice wishes to go. Note: Some imports and pragmas may be necessary to make these examples work in their respective languages. I believe it?s fair to leave them out in all cases; providing a batteries-included default namespace is a significant issue, but it?s somewhat independent of these musings. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From silvio.frischi at gmail.com Sat Aug 29 20:32:55 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sat, 29 Aug 2015 22:32:55 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> <55E09C5A.1000600@gmail.com> <55E1CD97.5090204@gmail.com> Message-ID: <55E216F7.5020202@gmail.com> Nice comparison indeed. > They would leak space if you didn?t know you had to use `xrange` > instead of `range`. I might have run into that as well. I don't really know Python that well. It is a problem I never came across in any imperative languages, so I foolishly assumed it wouldn't happen in Python either. But as you said they seem to have fixed it. Still, I would think the python space leak is relatively easy to spot and explain. Esp. when compared to tail-recursion modulo Constructors. Silvio From gautier.difolco at gmail.com Sat Aug 29 23:12:03 2015 From: gautier.difolco at gmail.com (Gautier DI FOLCO) Date: Sun, 30 Aug 2015 01:12:03 +0200 Subject: [Haskell-cafe] Idiomatic way to parse bytecodes Message-ID: Hello all, I have some bytecodes to parse and I look for the most idiomatic way to do it. It's mostly JVM Bytecode, long story short, I have some embedded JVM Bytecodes: * one part is specification-defined, from 0x00 to 0xB8, differ from the regular JVM Bytecode * and the other part is proprietary and changes often I have two main goals: * print the signification of each bytecodes (a more explicit one than the hexadecimal value of the bytecode) * Do some analysis on it, spot patterns, apply markov model on it and so on. The issue with JVM Bytecode in general is that each bytecode hasn't been made equal. Some of them requires parameters, some of them modify the length of the next bytecode, etc. I'm not looking for a way to parse bytecode quickly, or for a library doing it for me. I look for a simple/composable/idiomatic way to do it. So if you have any thoughts, papers, articles or even code snippets (part of a library of not) that is done in the Haskell-way, please, share it :) Thanks in advance for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerzy.karczmarczuk at unicaen.fr Sat Aug 29 23:32:04 2015 From: jerzy.karczmarczuk at unicaen.fr (JK) Date: Sun, 30 Aug 2015 01:32:04 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <20150829185953.5476436.58167.11415@gsd.uwaterloo.ca> References: <55E08229.5050602@gmail.com> <55E09C5A.1000600@gmail.com> <55E1CD97.5090204@gmail.com> <20150829185953.5476436.58167.11415@gsd.uwaterloo.ca> Message-ID: <55E240F4.3050402@unicaen.fr> Le 29/08/2015 20:59, mantkiew at gsd.uwaterloo.ca a ?crit : > it's clear that Haskell is optimized for functional style and Python for imperative style, and things in their respective opposite styles look clumsy. I am not entirely sure what is the real meaning of "optimized for" in your phrasing, but what is clear is that Python 'optimizes' without being asked for, e.g. when you use generators in order to cascade some sequence processing, as in the "sum" example, nothing wrong happens, while lazy lists reserve several nasty surprises. -O2 optimization, or explicit strictness annotations (and BangPatterns) are there, and may save our lives, but "what is clear" is that teaching Haskell as a practical language usable for large data, is quite non-trivial, and its beauty for novices evaporates quite fast. [This 'sum' example under GHCi will be problematic anyway]. I taught Haskell so long, that I became reckless, and my students got a rather tiresome project based on Haskell OpenGL. It was a massacre, a general unhappiness... Two years later my dept. decided to abandon advanced Haskell (with monads of all sorts), and left only the 2nd year introduction to functional programming, its style and algorithmics. I couldn't defend the "professional Haskell" too hard, the gap between the elementary FP, and the "true stuff" became too big in the context of our curriculum. Just my three cents... Anyway this threads degenerates a bit, and begins to contain statements I find dubious, or too restricted, e.g., > A beginning student doesn't need to learn OOP in > any kind of depth. etc. I suspect that the author of this phrase was not yet born when I began to teach programming... Now, I would never dare to declare what a beginning student *really needs*. Programming is a kind of art, a fragment of culture, a vision of the world, and the Pursuit of Happiness is different for different people. Linguists (or historians, etc.) may *begin* with logic/relational programming, biologists with objects, and mathematically-oriented yougsters, with FP. Or not. Jerzy Karczmarczuk /Caen, France/ From capn.freako at gmail.com Sat Aug 29 23:45:31 2015 From: capn.freako at gmail.com (David Banas) Date: Sat, 29 Aug 2015 16:45:31 -0700 Subject: [Haskell-cafe] Question, re: type class syntax. Message-ID: <60076DD2-D24D-4C4F-ADF0-7558698A3818@gmail.com> Hi all, I can?t figure out why this is invalid: class (Show a, Num a) => LogTree2 a where evaluator :: (LogTree2 a) t => t -> SizedVector a -> SizedVector a error| ?LogTree2? is applied to too many type arguments In the type ?(LogTree2 a) t => t -> SizedVector a -> SizedVector a? In the class declaration for ?LogTree2? Can anyone help me understand? Thanks, -db -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Sun Aug 30 00:22:01 2015 From: will.yager at gmail.com (William Yager) Date: Sat, 29 Aug 2015 19:22:01 -0500 Subject: [Haskell-cafe] Idiomatic way to parse bytecodes In-Reply-To: References: Message-ID: Based on what you've said, I would define a Serial or Binary instance for single bytecodes, and then use this to write a function :: ByteString -> [Bytecode]. Then, you can convert raw JVM bytecode into some convenient Haskell data, and then do whatever processing you want to this. --Will On Sat, Aug 29, 2015 at 6:12 PM, Gautier DI FOLCO wrote: > Hello all, > > I have some bytecodes to parse and I look for the most idiomatic way to do > it. > It's mostly JVM Bytecode, long story short, I have some embedded JVM > Bytecodes: > * one part is specification-defined, from 0x00 to 0xB8, differ from the > regular JVM Bytecode > * and the other part is proprietary and changes often > > I have two main goals: > * print the signification of each bytecodes (a more explicit one than the > hexadecimal value of the bytecode) > * Do some analysis on it, spot patterns, apply markov model on it and so > on. > > The issue with JVM Bytecode in general is that each bytecode hasn't been > made equal. Some of them requires parameters, some of them modify the > length of the next bytecode, etc. > I'm not looking for a way to parse bytecode quickly, or for a library > doing it for me. > I look for a simple/composable/idiomatic way to do it. > So if you have any thoughts, papers, articles or even code snippets (part > of a library of not) that is done in the Haskell-way, please, share it :) > > Thanks in advance for your help. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Sun Aug 30 00:27:37 2015 From: will.yager at gmail.com (William Yager) Date: Sat, 29 Aug 2015 19:27:37 -0500 Subject: [Haskell-cafe] Question, re: type class syntax. In-Reply-To: <60076DD2-D24D-4C4F-ADF0-7558698A3818@gmail.com> References: <60076DD2-D24D-4C4F-ADF0-7558698A3818@gmail.com> Message-ID: If you want the "LogTree2" typeclass to have multiple type arguments (which it looks like you do, from the definition of "evaluator"), you need to define it as class (Show a, Num a) => LogTree2 a t where --Will On Sat, Aug 29, 2015 at 6:45 PM, David Banas wrote: > Hi all, > > I can?t figure out why this is invalid: > > class (Show a, Num a) => LogTree2 a where > evaluator :: (LogTree2 a) t => t -> SizedVector a -> SizedVector a > > error| ?LogTree2? is applied to too many type arguments In the type > ?(LogTree2 a) t => t -> SizedVector a -> SizedVector a? In the class > declaration for ?LogTree2? > > Can anyone help me understand? > > Thanks, > -db > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Sun Aug 30 00:30:35 2015 From: capn.freako at gmail.com (David Banas) Date: Sat, 29 Aug 2015 17:30:35 -0700 Subject: [Haskell-cafe] Question, re: type class syntax. In-Reply-To: References: <60076DD2-D24D-4C4F-ADF0-7558698A3818@gmail.com> Message-ID: <60CBBEF1-B1DA-44D9-9B36-F4C1AC1213AE@gmail.com> Thanks, Will. Maybe I?ve got the syntax all wrong, but my intent is just to constrain the type ?t? to be of class 'LogTree2 a?. -db On Aug 29, 2015, at 5:27 PM, William Yager wrote: > If you want the "LogTree2" typeclass to have multiple type arguments (which it looks like you do, from the definition of "evaluator"), you need to define it as > > class (Show a, Num a) => LogTree2 a t where > > --Will > > On Sat, Aug 29, 2015 at 6:45 PM, David Banas wrote: > Hi all, > > I can?t figure out why this is invalid: > > class (Show a, Num a) => LogTree2 a where > evaluator :: (LogTree2 a) t => t -> SizedVector a -> SizedVector a > > error| ?LogTree2? is applied to too many type arguments In the type ?(LogTree2 a) t => t -> SizedVector a -> SizedVector a? In the class declaration for ?LogTree2? > > Can anyone help me understand? > > Thanks, > -db > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Aug 30 00:36:00 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 29 Aug 2015 20:36:00 -0400 Subject: [Haskell-cafe] Question, re: type class syntax. In-Reply-To: <60CBBEF1-B1DA-44D9-9B36-F4C1AC1213AE@gmail.com> References: <60076DD2-D24D-4C4F-ADF0-7558698A3818@gmail.com> <60CBBEF1-B1DA-44D9-9B36-F4C1AC1213AE@gmail.com> Message-ID: On Sat, Aug 29, 2015 at 8:30 PM, David Banas wrote: > Maybe I?ve got the syntax all wrong, but my intent is just to constrain > the type ?t? to be of class 'LogTree2 a? That doesn't seem to make a lot of sense; "LogTree2 a" means that the type a is of class LogTree2. "LogTree2 a" is not something that a type can be an instance of. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Sun Aug 30 00:39:57 2015 From: will.yager at gmail.com (William Yager) Date: Sat, 29 Aug 2015 19:39:57 -0500 Subject: [Haskell-cafe] Question, re: type class syntax. In-Reply-To: <60CBBEF1-B1DA-44D9-9B36-F4C1AC1213AE@gmail.com> References: <60076DD2-D24D-4C4F-ADF0-7558698A3818@gmail.com> <60CBBEF1-B1DA-44D9-9B36-F4C1AC1213AE@gmail.com> Message-ID: Hey David, I think there might be a bit of confusion here. When you say "LogTree2 a", that means "a" is an instance of "LogTree2". Maybe you want something like this? evaluator :: LogTree2 a => a -> SizedVector a -> SizedVector a Some context might help us to understand what you're going for. --Will On Sat, Aug 29, 2015 at 7:30 PM, David Banas wrote: > Thanks, Will. > Maybe I?ve got the syntax all wrong, but my intent is just to constrain > the type ?t? to be of class 'LogTree2 a?. > -db > > On Aug 29, 2015, at 5:27 PM, William Yager wrote: > > If you want the "LogTree2" typeclass to have multiple type arguments > (which it looks like you do, from the definition of "evaluator"), you need > to define it as > > class (Show a, Num a) => LogTree2 a t where > > --Will > > On Sat, Aug 29, 2015 at 6:45 PM, David Banas > wrote: > >> Hi all, >> >> I can?t figure out why this is invalid: >> >> class (Show a, Num a) => LogTree2 a where >> evaluator :: (LogTree2 a) t => t -> SizedVector a -> SizedVector a >> >> error| ?LogTree2? is applied to too many type arguments In the type >> ?(LogTree2 a) t => t -> SizedVector a -> SizedVector a? In the class >> declaration for ?LogTree2? >> >> Can anyone help me understand? >> >> Thanks, >> -db >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Sun Aug 30 01:07:09 2015 From: capn.freako at gmail.com (David Banas) Date: Sat, 29 Aug 2015 18:07:09 -0700 Subject: [Haskell-cafe] Question, re: type class syntax. In-Reply-To: References: <60076DD2-D24D-4C4F-ADF0-7558698A3818@gmail.com> <60CBBEF1-B1DA-44D9-9B36-F4C1AC1213AE@gmail.com> Message-ID: Thank you, both, for responding. What I was trying to express was that the particular type of LogTree2, t, would determine the type of SizedVector, a, apropos to the ?evaluator? function, for a particular instance. It looks like functional dependencies is the right way to achieve this, because this type checks: class LogTree2 t a | t -> a where evaluator :: LogTree2 t a => t -> SizedVector a -> SizedVector a -db On Aug 29, 2015, at 5:39 PM, William Yager wrote: > Hey David, > > I think there might be a bit of confusion here. When you say "LogTree2 a", that means "a" is an instance of "LogTree2". Maybe you want something like this? > > evaluator :: LogTree2 a => a -> SizedVector a -> SizedVector a > > Some context might help us to understand what you're going for. > > --Will > > > On Sat, Aug 29, 2015 at 7:30 PM, David Banas wrote: > Thanks, Will. > Maybe I?ve got the syntax all wrong, but my intent is just to constrain the type ?t? to be of class 'LogTree2 a?. > -db > > On Aug 29, 2015, at 5:27 PM, William Yager wrote: > >> If you want the "LogTree2" typeclass to have multiple type arguments (which it looks like you do, from the definition of "evaluator"), you need to define it as >> >> class (Show a, Num a) => LogTree2 a t where >> >> --Will >> >> On Sat, Aug 29, 2015 at 6:45 PM, David Banas wrote: >> Hi all, >> >> I can?t figure out why this is invalid: >> >> class (Show a, Num a) => LogTree2 a where >> evaluator :: (LogTree2 a) t => t -> SizedVector a -> SizedVector a >> >> error| ?LogTree2? is applied to too many type arguments In the type ?(LogTree2 a) t => t -> SizedVector a -> SizedVector a? In the class declaration for ?LogTree2? >> >> Can anyone help me understand? >> >> Thanks, >> -db >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From donn at avvanta.com Sun Aug 30 01:29:52 2015 From: donn at avvanta.com (Donn Cave) Date: Sat, 29 Aug 2015 18:29:52 -0700 (PDT) Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E240F4.3050402@unicaen.fr> References: <55E240F4.3050402@unicaen.fr> Message-ID: <20150830012952.AAEDF93C7D@mail.avvanta.com> quoth JK ... > Anyway this threads degenerates a bit, and begins to contain statements > I find dubious, or too restricted, e.g., > >> A beginning student doesn't need to learn OOP in >> any kind of depth. > > I suspect that the author of this phrase was not yet born when I began > to teach programming... Now, I would never dare to declare what a > beginning student *really needs*. Then at least, you don't disagree! FYI, I was already 4 when Lisp was invented, so computer programming pedagogy when I was born - that must have been a dry job, my hat is off to fellows like you! > ... Programming is a kind of art, a > fragment of culture, a vision of the world, and the Pursuit of Happiness > is different for different people. Linguists (or historians, etc.) may > *begin* with logic/relational programming, biologists with objects, and > mathematically-oriented yougsters, with FP. > > Or not. Is it a stretch, to hope that they will find beauty in it? Donn From ky3 at atamo.com Sun Aug 30 03:46:40 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sun, 30 Aug 2015 10:46:40 +0700 Subject: [Haskell-cafe] Idiomatic way to parse bytecodes In-Reply-To: References: Message-ID: On Sun, Aug 30, 2015 at 6:12 AM, Gautier DI FOLCO wrote: > I have two main goals: > * print the signification of each bytecodes (a more explicit one than the > hexadecimal value of the bytecode) > * Do some analysis on it, spot patterns, apply markov model on it and so > on. > Work backwards, a piece at a time. The output of parsing is a piece of structured data. So you need to design your data type. Start with the bare minimum. Write the pretty printing code. What do the type signatures of your analysis functions look like? E.g. "Apply markov model" is way too vague. The key thing is to iterate and improve on the design of your data type. Once the data type looks good, the implementation of parsing becomes clear as day. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg at okmij.org Sun Aug 30 08:08:00 2015 From: oleg at okmij.org (Oleg) Date: Sun, 30 Aug 2015 17:08:00 +0900 Subject: [Haskell-cafe] Final CFP: FLOPS 2016, International Symposium on Functional and Logic Programming Message-ID: <20150830080800.GA701@Magus.wifi-cloud.jp> NEW: revised submission deadlines (Sep 21 for abstracts, Sep 25 for papers) FLOPS 2016: March 3-6, 2016, Kochi, Japan Final Call For Papers http://www.info.kochi-tech.ac.jp/FLOPS2016/ Writing down detailed computational steps is not the only way of programming. The alternative, being used increasingly in practice, is to start by writing down the desired properties of the result. The computational steps are then (semi-)automatically derived from these higher-level specifications. Examples of this declarative style include functional and logic programming, program transformation and re-writing, and extracting programs from proofs of their correctness. FLOPS aims to bring together practitioners, researchers and implementors of the declarative programming, to discuss mutually interesting results and common problems: theoretical advances, their implementations in language systems and tools, and applications of these systems in practice. The scope includes all aspects of the design, semantics, theory, applications, implementations, and teaching of declarative programming. FLOPS specifically aims to promote cross-fertilization between theory and practice and among different styles of declarative programming. Scope FLOPS solicits original papers in all areas of the declarative programming: * functional, logic, functional-logic programming, re-writing systems, formal methods and model checking, program transformations and program refinements, developing programs with the help of theorem provers or SAT/SMT solvers; * foundations, language design, implementation issues (compilation techniques, memory management, run-time systems), applications and case studies. FLOPS promotes cross-fertilization among different styles of declarative programming. Therefore, submissions must be written to be understandable by the wide audience of declarative programmers and researchers. Submission of system descriptions and declarative pearls are especially encouraged. Submissions should fall into one of the following categories: * Regular research papers: they should describe new results and will be judged on originality, correctness, and significance. * System descriptions: they should contain a link to a working system and will be judged on originality, usefulness, and design. * Declarative pearls: new and excellent declarative programs or theories with illustrative applications. System descriptions and declarative pearls must be explicitly marked as such in the title. Submissions must be unpublished and not submitted for publication elsewhere. Work that already appeared in unpublished or informally published workshops proceedings may be submitted. See also ACM SIGPLAN Republication Policy. The proceedings will be published by Springer International Publishing in the Lecture Notes in Computer Science (LNCS) series, as a printed volume as well as online in the digital library SpringerLink. Post-proceedings: The authors of 4-7 best papers will be invited to submit the extended version of their FLOPS paper to a special issue of the journal Science of Computer Programming (SCP). Important dates Monday, September 21, 2015 (any time zone): Abstract Submission Friday, September 25, 2015 (any time zone): Submission deadline (FIRM) Monday, November 16, 2015: Author notification March 3-6, 2016: FLOPS Symposium March 7-9, 2016: PPL Workshop Invited Talks - Kazunori UEDA (Waseda University) The exciting time and hard-won lessons of the Fifth Generation Computer Project - Atze Dijkstra (Utrecht University) UHC: Coping with Compiler Complexity Submission Submissions must be written in English and can be up to 15 pages long including references, though pearls are typically shorter. The formatting has to conform to Springer's guidelines. Regular research papers should be supported by proofs and/or experimental results. In case of lack of space, this supporting information should be made accessible otherwise (e.g., a link to a Web page, or an appendix). Papers should be submitted electronically at https://easychair.org/conferences/?conf=flops2016 Program Committee Andreas Abel Gothenburg University, Sweden Lindsay Errington USA Makoto Hamana Gunma University, Japan Michael Hanus CAU Kiel, Germany Jacob Howe City University London, UK Makoto Kanazawa National Institute of Informatics, Japan Andy King University of Kent, UK (PC Co-Chair) Oleg Kiselyov Tohoku University, Japan (PC Co-Chair) Hsiang-Shang Ko National Institute of Informatics, Japan Julia Lawall Inria-Whisper, France Andres Loeh Well-Typed LLP, UK Anil Madhavapeddy Cambridge University, UK Jeff Polakow USA Marc Pouzet Ecole normale superieure, France Vitor Santos Costa Universidade do Porto, Portugal Tom Schrijvers KU Leuven, Belgium Zoltan Somogyi Australia Alwen Tiu Nanyang Technological University, Singapore Sam Tobin-Hochstadt Indiana University, USA Hongwei Xi Boston University, USA Neng-Fa Zhou CUNY Brooklyn College and Graduate Center, USA Organizers Andy King University of Kent, UK (PC Co-Chair) Oleg Kiselyov Tohoku University, Japan (PC Co-Chair) Yukiyoshi Kameyama University of Tsukuba, Japan (General Chair) Kiminori Matsuzaki Kochi University of Technology, Japan (Local Chair) flops2016 at logic.cs.tsukuba.ac dot jp From jerzy.karczmarczuk at unicaen.fr Sun Aug 30 09:43:01 2015 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Sun, 30 Aug 2015 11:43:01 +0200 Subject: [Haskell-cafe] Some historical remarks [Was: Why Haskell is beautiful...] In-Reply-To: <20150830012952.AAEDF93C7D@mail.avvanta.com> References: <55E240F4.3050402@unicaen.fr> <20150830012952.AAEDF93C7D@mail.avvanta.com> Message-ID: <55E2D025.6000502@unicaen.fr> Le 30/08/2015 03:29, Donn Cave a ?crit : > I was already 4 when Lisp was > invented, so computer programming pedagogy when I was born - that must > have been a dry job Dry job?... I don't think so. It was a glorious period, I think. Some years later as well. My first language (learnt and also taught some years later) was Algol60 [replaced very soon by Fortran]. The relationship between our computation needs and the coding styles, paradigms, algorithm structuring, etc. was quite obscure at the time, and our main source of inspiration was the collection of algorithms in CACM, published in Algol. I suspect strongly that those - fundamental AND practical - materials conditioned the opinion of the community (at least mine: physicists) about "what is needed, and what should be taught" (and perhaps also "what is elegant"). Moreover, they played (I am not certain) a significant role in specifying what should be the "main stream" of languages, and gave a strong push to the development of compilers of all them -- Jovial, Pascal, C, Java... If, at the beginning of the '60ties, the Lisp community had published more code recipes, more algorithm presentations, more practical functional codes, perhaps the evolution of programming languages would be different. Perhaps the evolution of computer architectures would be also a bit different (more importance for hardware stack architectures) We have seen some nice psychological paradoxes. Anthony Hearn told me that he recognized the importance of Lisp for the symbolic computations very early, but he found out that his colleagues abhorred its syntax so strongly, that his Computer Algebra package Reduce became Lisp disguised in an Algolish language... Now, the Beauty and the Beast, where were they?... On the other hand, around 1963, Martinus Veltman (his Nobel had to wait more 36 years...) found out that the "fast", and low level Fortran for such needs was useful as well, but as an implementation platform, not the front-end. He conceived his computer algebra system Schoonschip (name chosen "among others to annoy everybody not Dutch", quote from Wikipedia, probably authentic, knowing the personal character of Veltman) upon Fortran, and assembly language, but he manufactured a *rewriting system*, completely different from any other language! The result was that for many years only theoretical physicists used it, because it worked, but others (e.g. people from an engineering school to whom I proposed a course of Schoonschip) refused to touch the "monster". Well..., this "monster" evolved to FORM of Jos Vermaseren (also initially coded in Fortran, it still exists and is used). It inspired Cole and Wolfram at Caltech in their work on the computer algebra rewriting system SMP, that you know well. Oh, you don't? Yes, you do, only that it is called now "Mathematica". You don't use it? But you *DO USE* another rewriting system, only perhaps you don't know that it is one. It is called TeX... I repeat again: Programming languages evolve as the Culture does, with redundancies, inspirations, contradictions, and re-discoveries of the same paradigms several times. (Some people teach Prolog and say that it was the first known language which used logical non-determinism. But Colmerauer began to work on it at the beginning of '70, while Snobol was there for almost 10 years, and Griswold introduced into it the non-deterministic string-processing algorithms since the beginning.) I find it pityful that nowadays some young people learn 2 - 3 programming languages, and quarrel about which one is "better" or "worse"... Recall please one silly discussion between Van Gogh and Gauguin, when Van Gogh accused Gauguin that he gets everything false, that his world is flat, which is ugly and silly. Gauguin answered that the world *IS* flat, and that all these pointilistic details of Van Gogh are useless, false, and go nowhere. Well, both masters are great and they are still with us. Their discussion, perhaps invented, is almost forgotten, but it can be used as a /memento/. Their colours remain. Be colourful! == Jerzy Karczmarczuk /Caen, France/ From alexander.kjeldaas at gmail.com Sun Aug 30 13:19:13 2015 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Sun, 30 Aug 2015 15:19:13 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: References: <55ACF281.6020707@nh2.me> Message-ID: The directory is irrelevant. fork() + exec() is not an atomic operation: * Thread 1 writes its file completely (opens and closes an Fd 1, using O_CLOEXEC) * Thread 2 starts writing its file (Fd 2 open for writing, using O_CLOEXEC) * Thread 1 starts executing "myBinary" by calling *fork()*. Fd 2 is inherited by the child process * Thread 2 finishes writing (closes its Fd 2) * Thread 2 executes "myBinary", which fails with `Text file busy` because an Fd is still open to it in the child of Process 1 * Thread 1 executes "myBinary" (calling exec()). Fd 2 is automatically closed during exec(), but it's too late. You need the file descriptor to not be inherited by a child process, which is != from O_CLOEXEC. Alexander On Fri, Aug 28, 2015 at 10:14 PM, Brandon Allbery wrote: > On Fri, Jul 24, 2015 at 6:29 PM, Alexander Kjeldaas < > alexander.kjeldaas at gmail.com> wrote: > >> I think CLOEXEC should be the default, but it doesn't seem to solve your >> problem. What if thread 2 executes "myBinary" before thread 1 called exec()? >> > > I think you missed that each thread is using its own temporary directory > --- they're not all running at the same time in the same directory, which > would be pretty much guaranteed to fail. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Sun Aug 30 13:42:07 2015 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Sun, 30 Aug 2015 15:42:07 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: References: <55ACF281.6020707@nh2.me> Message-ID: <55E3082F.3080301@nh2.me> On 30/08/15 15:19, Alexander Kjeldaas wrote: > The directory is irrelevant. fork() + exec() is not an atomic operation: > > * Thread 1 writes its file completely (opens and closes an Fd 1, using > O_CLOEXEC) > * Thread 2 starts writing its file (Fd 2 open for writing, using O_CLOEXEC) > * Thread 1 starts executing "myBinary" by calling *fork()*. Fd 2 is > inherited by the child process > * Thread 2 finishes writing (closes its Fd 2) > * Thread 2 executes "myBinary", which fails with `Text file busy` > because an Fd is still open to it in the child of Process 1 > * Thread 1 executes "myBinary" (calling exec()). Fd 2 is automatically > closed during exec(), but it's too late. > > You need the file descriptor to not be inherited by a child process, > which is != from O_CLOEXEC. You are right. This makes solving my original problem impossible, and * writing the file * then renaming it * then executing it seems to be the only way to do it safely. Let us then move the discussion back to whether CLOEXEC by default or not. From mwm at mired.org Sun Aug 30 13:53:12 2015 From: mwm at mired.org (Mike Meyer) Date: Sun, 30 Aug 2015 13:53:12 +0000 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: References: <55ACF281.6020707@nh2.me> Message-ID: On Sun, Aug 30, 2015 at 9:19 AM Alexander Kjeldaas < alexander.kjeldaas at gmail.com> wrote: > The directory is irrelevant. fork() + exec() is not an atomic operation: > This creates problems for all resources that act as locks. IIRC (it's been a few years since I looked through it thoroughly), it's been shown that there isn't a general fix for this. I.e - that the POSIX threading model & fork() will having timing issues of some sort or another no matter what you do. The work-around is to only fork when no such resources are held. So you do things like fork all your processes before starting a thread, or fork a server that will do all further forks upon request before starting a thread, etc. So the question should not be whether CLO_EXEC "fixes everything", but whether having it as the default is a good enough idea to be worth the pain of changing. I suspect the answer is yes, as most cases where it isn't set are probably because it's the default, so won't need changing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Sun Aug 30 13:58:33 2015 From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=) Date: Sun, 30 Aug 2015 15:58:33 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <20150725190911.ABEFD276CB6@mail.avvanta.com> References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> <20150725190911.ABEFD276CB6@mail.avvanta.com> Message-ID: <55E30C09.2090609@nh2.me> On 25/07/15 21:09, Donn Cave wrote: > But there are other things that could turn up. > For example, you could use flock(2) (Berkeley, not POSIX fcntl > lock) to keep an advisory file lock until the exec exits. If the > file is closed prematurely, you lose the lock, and ... whatever > happens then. This is a very valid point. Applications that rely on this will break by changing the default here. I'm wondering though whether this is an acceptable price to pay for better (in my opinion) defaults. Given enough announcement and time, it should not be too difficult to find Berkeley flock() invocations, and explicitly fnctl their FDs to CLOEXEC=False, or open() them with CLOEXEC=False. I would even be surprised if there is a single Haskell program out there that uses this; I know of one that uses file locking, bu that's using fnctl style locks. From allbery.b at gmail.com Sun Aug 30 14:18:24 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 30 Aug 2015 10:18:24 -0400 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <55E30C09.2090609@nh2.me> References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> <20150725190911.ABEFD276CB6@mail.avvanta.com> <55E30C09.2090609@nh2.me> Message-ID: On Sun, Aug 30, 2015 at 9:58 AM, Niklas Hamb?chen wrote: > I would even be surprised if there is a single Haskell program out there > that uses this; I know of one that uses file locking, bu that's using > fnctl style locks. > Also note that many systems emulate flock() with fcntl() locks, so that trick is nonportable anyway. (Linux used to do that, but stopped; unless you're holding onto a system with a pre-2.0 kernel or a weird Linux distribution whose glibc has been modified to do emulation, you should have real flock().) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From donn at avvanta.com Sun Aug 30 14:59:27 2015 From: donn at avvanta.com (Donn Cave) Date: Sun, 30 Aug 2015 07:59:27 -0700 (PDT) Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <55E30C09.2090609@nh2.me> References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> <20150725190911.ABEFD276CB6@mail.avvanta.com> <55E30C09.2090609@nh2.me> Message-ID: <20150830145927.64DD5F3946@mail.avvanta.com> Quoth Niklas Hamb??chen , > On 25/07/15 21:09, Donn Cave wrote: >> But there are other things that could turn up. >> For example, you could use flock(2) (Berkeley, not POSIX fcntl >> lock) to keep an advisory file lock until the exec exits. If the >> file is closed prematurely, you lose the lock, and ... whatever >> happens then. > This is a very valid point. Applications that rely on this will break by > changing the default here. ... and you go on to demonstrate that you didn't really take the point I was trying to make. How did you find out about this flock(2) scenario? Do you suppose that this is the only one, because you and I don't know of any more? My point is not that the whole thing might hinge on whether we can deal with flock locking in this scenario, it is that when we think about reversing ancient defaults in the underlying system, we have to assume the risk of obscure breakage as a result. To worry about the flock problem now is to miss the point. And again, this half-a-fix inconsistently applies to only files created by open(2), and not to pipes, sockets and whatever else creates a file descriptor in some other way, so if it's a real problem, it seems you must address it in some other way anyway. Donn From J.Hage at uu.nl Sun Aug 30 16:02:53 2015 From: J.Hage at uu.nl (Jurriaan Hage) Date: Sun, 30 Aug 2015 18:02:53 +0200 Subject: [Haskell-cafe] Haskell related talks at Curry On! Message-ID: Dear Haskell-minded, Curry On! in Prague was co-located with Ecoop and had some Haskell-oriented talks. In case you were not there, and had not noticed: video?s of the talks are available on YouTube. Of particular note are Julian Arny?s talk on Servant, url at https://www.youtube.com/watch?v=snOBI8PcbMQ Then there is the entertaining discussion by Thomas Arts of Quviq on awakening industry to the use of QuickCheck (it?s Erlang, I know, but coming from Haskell): https://www.youtube.com/watch?v=Ar0FPW2GSgo and finally my own on domain-specific type error diagnosis in Haskell: https://www.youtube.com/watch?v=bPrM1gONdII And when you?ve seen these, YouTube is bound to suggest many others. enjoy, Jurriaan Hage PS. Curry On! was in fact a great event with many interesting talks. It is going on repeat it seems, so catch it if you can. From olf at aatal-apotheke.de Sun Aug 30 19:16:54 2015 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 30 Aug 2015 21:16:54 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice Message-ID: <15B9471D-BF50-4DB7-BE01-50EED0091693@aatal-apotheke.de> Dear cafe inhabitants, first of all thanks for all the elaborate answers. I did not imagine to trigger such an avalanche of opinions. Let me try to steer away from the Python/Haskell comparison (as comparison is what I wanted to avoid) and collect some points I found important in the past discussion. 1. There is a difference between teaching how the machines we call computers work and how computers are used to solve problems. What is computer science? The science about computers or science that can be executed on a computer? Both subjects are beautiful, in different ways. Haskell, I used to think, was designed explicitly to abstract away from how its programs are actually run on the hardware, to the point where one can not even tell (and care) what order certain computations are executed in, or whether they are executed at all. Therefore Haskell is certainly not the best language to teach about the mechanics of computing. Similarly, there are practical problems that may be more difficult to express in a functional language, because the problem may be already of a sequential, mutable, effect-full nature (e.g. writing an adventure game). 2. For teaching purposes, the remark that kids want something they can show off to others should not not be under-estimated. In order to quickly obtain showable results, one might choose a toy language (DSL?) or program robots. For this reason I considered HTML as a first introduction to syntax, even if it is not a programming language as such. But there exist syntax checkers and one can create and view HTML on every modern device. By the way, is there a live CD (not DVD) image that contains the Haskell platform and some other languages? 3. One skill/revelation that I want to install in the students of both math and CS, and which I believe Haskell is more suitable for than imperative languages, is the fact that in mathematics and computer science there are no hidden layers/aspects, no mysteries. Everything is composed of smaller, simpler parts. And if one wishes, one can unwrap one layer and look inside. How deeply one wishes to look inside is a question of audience, then. The layering might consist of recursion, classes, objects. It does not matter. The important point is that the path to a solution must descend the layers to the simple parts. This is in contrast with arts and humanities, where one can study the same piece of art, the same novel, several times in a lifetime and each time discover new things, and probably still miss others which require expert education. Mergesort, once grasped, is there in all its completeness, simplicity and beauty, there is no further interpretation. As others have remarked in this discussion, the `no mysteries' only applies to the denotational semantics, but not the operational semantics in case of Haskell. For assembler it might very well be the other way around. Thanks, Olaf From silvio.frischi at gmail.com Sun Aug 30 20:17:39 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sun, 30 Aug 2015 22:17:39 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <15B9471D-BF50-4DB7-BE01-50EED0091693@aatal-apotheke.de> References: <15B9471D-BF50-4DB7-BE01-50EED0091693@aatal-apotheke.de> Message-ID: <55E364E3.1030007@gmail.com> Olaf, glad to see you're still here :) > 2. For teaching purposes, the remark that kids want something they > can show off to others should not not be under-estimated. I once overheard a conversation of highschool kids who had done a sudoku solver. The seemed pretty impressed by that, and it seems a problem that is relatively well suited for Haskell. You might want to try that. Cheers Silvio From silvio.frischi at gmail.com Sun Aug 30 21:45:18 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sun, 30 Aug 2015 23:45:18 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E364E3.1030007@gmail.com> References: <15B9471D-BF50-4DB7-BE01-50EED0091693@aatal-apotheke.de> <55E364E3.1030007@gmail.com> Message-ID: <55E3796E.40905@gmail.com> > I once overheard a conversation of highschool kids who had done a sudoku > solver. The seemed pretty impressed by that, and it seems a problem that > is relatively well suited for Haskell. You might want to try that. Just for fun I tried to do the sudoku solver and as you can see it took me a bit over an hour. Not everything is trivial to program. But the consistency checks should be easy to do even for relatively new programmers. Code appended Silvio -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.hs Type: text/x-haskell Size: 1765 bytes Desc: not available URL: From charles at voleon.com Sun Aug 30 21:54:39 2015 From: charles at voleon.com (Charles Weitzer) Date: Sun, 30 Aug 2015 21:54:39 +0000 Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning Startup Message-ID: Voleon Capital Management LP is a startup quantitative hedge fund located in Berkeley, California. We would like to hire a senior software engineer with strong functional programming experience as soon as possible. Voleon's founders previously worked together at one of the most successful quantitative hedge funds in the world. Our CEO has a PhD in Computer Science from Stanford and has been CEO and founder of a successful Internet infrastructure startup. Our Chief Investment Officer has a PhD in Statistics from Berkeley. Voleon's team includes PhD's from leading departments in statistics, computer science, and mathematics. We have made several unpublished advances in the field of machine learning and in other areas as well. Here is our formal job description: ********************************************************** * Senior Software Engineer * Technology-driven investment firm employing cutting-edge statistical machine learning techniques seeks an exceptionally capable software engineer. You will architect and implement new production trading systems, machine learning infrastructure, data integration pipelines, and large-scale storage systems. The firm researches and deploys systematic trading strategies designed to generate attractive returns without being dependent on the performance of the overall market. Join a team of under 30 people that includes a Berkeley statistics professor as well as over ten PhD's from Berkeley, Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and CEO of a successful Internet infrastructure technology firm. The firm's offices are walking distance from BART and the UC Berkeley campus in downtown Berkeley, California. We have a casual and collegial office environment, catered lunches, and competitive benefits packages. We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems, and delivering complex projects on time. You should preferably have experience designing and implementing fault-tolerant distributed systems. Experience with building large-scale data infrastructure, stream processing systems, or latency-sensitive programs is a bonus. We are growing rapidly. Willingness to take initiative and a gritty determination to productize are essential. Required experience: - strong experience developing in a functional programming environment (Haskell, Erlang, others). - developing with C/C++/Python/Go in a Linux environment with a focus on performance, concurrency, and correctness. - working in TCP/IP networking, multi-threading, and server development. - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP, SNMP, etc.). - architecting and designing highly available systems. - architecting and designing large-scale data management infrastructure. - working in large codebases and building modular, manageable code. Preferred experience.: - debugging and performance profiling, including the use of tools such as strace, valgrind, gdb, tcpdump, etc. - working with build and test automation tools. - working with well-defined change management processes. - diagnosing RDBMS performance problems, exploiting indexing, using EXPLAIN PLAN, optimizing at the code layer, etc. - working with messaging queues (RabbitMQ, Redis, etc.) as well as distributed caching systems. Interest in financial applications is essential, but experience in finance is not a primary factor in our hiring. Benefits and compensation are highly competitive. ********************************************************** The above job description is just a starting point in terms of possible duties and seniority. We can be very flexible for the right person. If you are interested or if you know of anyone who might be interested, let us know the best way to get in touch and we can discuss details. Thank you, Charles Weitzer Senior Recruiter Voleon Capital Management LP Charles at Voleon.com Office: 510.704.9870 x 7012 Mobile: (510) 558-9182 www.Voleon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Sun Aug 30 22:16:49 2015 From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=) Date: Mon, 31 Aug 2015 00:16:49 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <20150830145927.64DD5F3946@mail.avvanta.com> References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> <20150725190911.ABEFD276CB6@mail.avvanta.com> <55E30C09.2090609@nh2.me> <20150830145927.64DD5F3946@mail.avvanta.com> Message-ID: <55E380D1.2090308@nh2.me> On 30/08/15 16:59, Donn Cave wrote: > Quoth Niklas Hamb??chen , > ... and you go on to demonstrate that you didn't really take the point > I was trying to make. How did you find out about this flock(2) scenario? > Do you suppose that this is the only one, because you and I don't know > of any more? No, I do take your point, and I admit that more things may break when changing the default. What I'm saying is that such cases are relatively easy to find. When you rely on inheriting FDs, you know it. It is exotic enough that when you've built something that needs it, you'll remember it. This leads me to think that the damage done / cost to fix introduced by breaking the backwards compatibility here might be smaller than the damage / fixing that will arise in the future from surprising behaviour and security/privilege problems through leaked FDs in all non-exotic programs that want to exec() something. I'd assume the Python and Perl people came to this conclusion. Further, our community is small, and if you announce something loud and long-term via mailing list and Reddit, it will go a long way and make it unlikely that somebody will be unaware of such a change. Your point that we may break things that we don't know of / understand still stands though. Regarding pipes and sockets, pipe()/socket() accept CLOEXEC as well. From gautier.difolco at gmail.com Sun Aug 30 22:35:26 2015 From: gautier.difolco at gmail.com (Gautier DI FOLCO) Date: Mon, 31 Aug 2015 00:35:26 +0200 Subject: [Haskell-cafe] Idiomatic way to parse bytecodes In-Reply-To: References: Message-ID: 2015-08-30 5:46 GMT+02:00 Kim-Ee Yeoh : > > On Sun, Aug 30, 2015 at 6:12 AM, Gautier DI FOLCO < > gautier.difolco at gmail.com> wrote: > > >> I have two main goals: >> * print the signification of each bytecodes (a more explicit one than >> the hexadecimal value of the bytecode) >> * Do some analysis on it, spot patterns, apply markov model on it and so >> on. >> > > Work backwards, a piece at a time. > > The output of parsing is a piece of structured data. So you need to design > your data type. Start with the bare minimum. Write the pretty printing > code. What do the type signatures of your analysis functions look like? > > E.g. "Apply markov model" is way too vague. > > The key thing is to iterate and improve on the design of your data type. > > Once the data type looks good, the implementation of parsing becomes clear > as day. > > -- Kim-Ee > Hello, Thanks for your answer. I think I have misled you in the expression of my needs. I don't have any representation issues, I'm just looking for a good design for the parsing phase. Here's some naive iterative tries: 0. We only have one bytecode per instruction a simple HashMap is enough: import Data.Word import Data.Maybe import qualified Data.Map as H type Byte = Word8 data ByteCodeSimpleInstruction = Astore_0 -- 0x4B | Astore_1 -- 0x4C | Astore_2 -- 0x4D | Astore_3 -- 0x4E deriving (Eq, Show) sampleSI :: [Byte] sampleSI = [0x4B, 0x4C, 0x4D, 0x4E] convertTableSI :: H.Map Byte ByteCodeSimpleInstruction convertTableSI = H.fromList $ [ (0x4B, Astore_0), (0x4C, Astore_1), (0x4D, Astore_2), (0x4E, Astore_3) ] parserSI :: [Byte] -> [ByteCodeSimpleInstruction] parserSI = map $ fromJust . flip H.lookup convertTableSI 1. We add instruction with different lengths, I'm "forced" to introduce pattern matching and it makes me sad: data ByteCodeVariableLengthInstruction = Astore' Byte -- 0x19 | Astore_0' -- 0x4B | Astore_1' -- 0x4C | Astore_2' -- 0x4D | Astore_3' -- 0x4E deriving (Eq, Show) sampleVLI :: [Byte] sampleVLI = [0x4B, 0x4C, 0x19, 0x2A, 0x4D, 0x4E] parserVLI :: [Byte] -> [ByteCodeVariableLengthInstruction] parserVLI b = case b of (0x19:p:n) -> (Astore' p):parserVLI n (0x4B:n) -> Astore_0':parserVLI n (0x4C:n) -> Astore_1':parserVLI n (0x4D:n) -> Astore_2':parserVLI n (0x4E:n) -> Astore_3':parserVLI n [] -> [] 2. We add instructions that change the next instruction's length, we are "forced" to add different parsing strategies: data ByteCodeVariableLengthParameterInstruction = Astore'' ByteParameter -- 0x19 | Astore_0'' -- 0x4B | Astore_1'' -- 0x4C | Astore_2'' -- 0x4D | Astore_3'' -- 0x4E | Wide'' -- 0xDD deriving (Eq, Show) data ByteParameter = Simple Byte | Double Byte Byte deriving (Eq, Show) sampleVLPI :: [Byte] sampleVLPI = [0x4B, 0x4C, 0xDD, 0x19, 0xA2, 0x2A, 0x4D, 0x4E] parserVLPI :: [Byte] -> [ByteCodeVariableLengthParameterInstruction] parserVLPI = parserVLPISimple parserVLPISimple :: [Byte] -> [ByteCodeVariableLengthParameterInstruction] parserVLPISimple b = case b of (0x19:p:n) -> (Astore'' (Simple p)):parserVLPISimple n (0x4B:n) -> Astore_0'':parserVLPISimple n (0x4C:n) -> Astore_1'':parserVLPISimple n (0x4D:n) -> Astore_2'':parserVLPISimple n (0x4E:n) -> Astore_3'':parserVLPISimple n (0xDD:n) -> Wide'':parserVLPIDouble n [] -> [] parserVLPIDouble :: [Byte] -> [ByteCodeVariableLengthParameterInstruction] parserVLPIDouble b = case b of (0x19:p:q:n) -> (Astore'' (Double p q)):parserVLPISimple n _ -> parserVLPISimple b I feel that are too "ad-hoc" tactics and I'm looking for an higher-order way to do it. I don't know if I'm clearer now. Thanks in advance for you help. Regards. PS: For the Markov part, Markov models will help me to spot the most common sequences of bytecodes. Then I'll be able to create proprietary byte that will be the most likely to decrease my code's size. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Mon Aug 31 01:20:53 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 31 Aug 2015 13:20:53 +1200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> References: <20150829060950.83DCB276D62@mail.avvanta.com> <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> Message-ID: <2C44F34C-EED7-43D2-908C-F70813470D9D@cs.otago.ac.nz> On 29/08/2015, at 8:41 pm, Alexey Muranov wrote: > IMO, what attracts a big part of kids to programming is the possibility to program side effects. Language changes. Sometimes it changes in obfuscatory ways. Take this example: PRINT *, 'HELLO WORLD!' END That's a complete Fortran (77, 90, 95, '04, '08) program. The print statement has an EFFECT. That effect is not a *SIDE* effect. Here's the definition of "side effect": 1. A subsidiary consequence of an action, occurrence, or state of affairs; an unintended secondary result. 2. An effect (usually for the worse) of a drug or other chemical other than that for which it is administered In the case of the little program above, the fact that output is sent to a destination is neither subsidiary, nor unintended, nor secondary, nor other than that for which the program was constructed. I flatly deny that "UNINTENDED ... results" are what attracts ANYONE to programming. Effects, *YES*; *side* effects, NO. As a young programmer, decades ago, I learned to be perfectly happy with *effects* but wary of *side effects*. (By getting it wrong of course, how else?) Confusion of *words* leads to confusion of *thought*: I didn't want anyone taking my READ and PRINT statements away but I *loved* the idea of languages where you told the compiler "this procedure can read these variables and write those variables", as in SPLint for C. To call the main, principal, intended consequences of a program element, the entire reason for its existence in the program, to call *that* a "side effect" is just to blue a vital distinction. You see, when people in the programming world got worried about side effects, they were not in the least worried about known, intended effects. They were worried about "functions" that printed output, "functions" that changed hidden variables. Nobody minded things like CALL RANDOM_NUMBER(HARVEST = X) or even U = NRAND(SEED) ! update SEED They were worried about things like lu = random(); which *purports* to be a function call, and is called in order to obtain a value, but *also* has a "subsidiary consequence" which is hidden from the programmer, the compiler, or both. Now what Haskell does is to banish side effects completely. You can have all the effects you want, but *something* about the scope of the effects must be visible in the type, and effectful operations have to be explicitly chained in a way that "pure" operations do not. If we screw up our language by calling all effects "side effects", we can't even *think* "Haskell makes effects easy but side effects hard". To anyone who wants to defend the abuse of "side effect", what do you think is the point of the word "side" in that phrase if not to distinguish side effects from some other kind of effects? From ok at cs.otago.ac.nz Mon Aug 31 01:28:00 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 31 Aug 2015 13:28:00 +1200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: On 29/08/2015, at 4:17 pm, M Farkas-Dyck wrote: > > Actually we ought to start with semiconductor physics, VLSI > fabrication, and such. > cuz that's how current computers work. I did start a computer architecture lecture once with a 10 minute explanation of what a field effect transistor does. The physicist in me was only partly appeased by the consideration that this was all the students were _ever_ going to be told about what was really going on underneath. Some of the students thanked me for it. Some, didn't. As for Python, remember that the people who are praising Python as an initial language are probably comparing it with Java or C++. From will.yager at gmail.com Mon Aug 31 02:47:45 2015 From: will.yager at gmail.com (William Yager) Date: Sun, 30 Aug 2015 21:47:45 -0500 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <2C44F34C-EED7-43D2-908C-F70813470D9D@cs.otago.ac.nz> References: <20150829060950.83DCB276D62@mail.avvanta.com> <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> <2C44F34C-EED7-43D2-908C-F70813470D9D@cs.otago.ac.nz> Message-ID: On Sun, Aug 30, 2015 at 8:20 PM, Richard A. O'Keefe wrote: > > The print statement has an EFFECT. That effect is not a > *SIDE* effect. Here's the definition of "side effect": > > 1. A subsidiary consequence of an action, occurrence, > or state of affairs; an unintended secondary result. > 2. An effect (usually for the worse) of a drug or other > chemical other than that for which it is administered > > In the case of the little program above, the fact that > output is sent to a destination is neither subsidiary, > nor unintended, nor secondary, nor other than that for > which the program was constructed. > > I flatly deny that "UNINTENDED ... results" are what > attracts ANYONE to programming. Effects, *YES*; > *side* effects, NO. > Wrong definition, my friend. https://en.wikipedia.org/wiki/Side_effect_(computer_science) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Mon Aug 31 02:59:36 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 31 Aug 2015 14:59:36 +1200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <55E08229.5050602@gmail.com> Message-ID: I wonder if we aren't all missing something. In another mailing list I have been trying to explain to someone how to write a JSON parser in a functional language. If anything unexpected comes up, like an error message, he freezes, then calls the mailing list for help. The error messages will say things like foobar is unused fooBar is undefined and he'll sit there baffled. I know a bright statistician who *hated* programming because of the compiler error messages (for a fairly simple imperative language, too). For *some* novice programmers, the quality of the error messages may be more important than almost anything else, which means that for *them*, the language as such may be almost irrelevant, except indirectly as it makes it easier or harder to generate really clear error messages. From ok at cs.otago.ac.nz Mon Aug 31 03:43:46 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 31 Aug 2015 15:43:46 +1200 Subject: [Haskell-cafe] Idiomatic way to parse bytecodes In-Reply-To: References: Message-ID: <6440B9E3-B094-4F61-A3C4-8E9C50ED447C@cs.otago.ac.nz> On 31/08/2015, at 10:35 am, Gautier DI FOLCO wrote: > Thanks for your answer. > I think I have misled you in the expression of my needs. > I don't have any representation issues, I'm just looking for a good design for the parsing phase. Depending on what you mean by "parsing", a very simple answer may suffice. Use a TABLE-DRIVEN approach. Let me take a Smalltalk byte code as an example. Instructions fall into a number of groups. For example, we have push_local where might be encoded in 2 bytes, in 1 byte, or it might be implied in the opcode. So we'd have something like data Operator = Push_Local | Store_Local | ... data Operand = None | Implied Int | One_Byte | Two_Byte | ... decode :: Array Int (Operator, Operand) decode = array (0,255) [ (0, (Push_Local, Implied 0)), (1, (Push_Local, Implied 1)), ... (8, (Push_Local, One_Byte)), (9, (Push_Local, Two_Byte)), ... Or even make it a function: decode :: Int -> (Operator,Operand) decode 0 = ... ... decode 255 = ... then for example extract :: Operand -> Bytes -> Int -> (Simple_Operand, Int) extract None b i = (No_Operand, i) extract (Implied n) b i = (Int_Operand n, i) extract (One_Byte) b i = (Int_Operand (byte b i), i+1) extract (Two_Byte) b i = (Int_Operand (byte b i * 256 + byte b (i+1)),i+2) ... Ideally, you'd switch to a different variant of the instruction set by simply changing the table. When you have "portmanteau instructions", it gets a bit trickier. For example, Smalltalk systems typically have Store_Local -- store the TOS in that variable Pop -- remove the TOS combined in Pop_Into_Local -- store TOS into variable and remove it > PS: For the Markov part, Markov models will help me to spot the most common sequences of bytecodes. Then I'll be able to create proprietary byte that will be the most likely to decrease my code's size. There's a Xerox blue-and-white report. Ah, here we go. http://www.textfiles.com/bitsavers/pdf/xerox/parc/techReports/CSL-82-2_An_Analysis_of_a_Mesa_Instruction_Set.pdf Mesa was an "industrial strength Pascal" running on the Alto and the D-machines. The author collected dynamic frequencies of byte pairs. "It is hard to learn much of general interest by examining individual instruction frequencies of a small set of programs, since those statistics may highlight idiosyncratic behavior of the programs. For example, only three of the top eight most frequently executed instructions in both VlsiCheck and the compiler are the same." There's also the companion paper from ASPLOS'82, "Static Analysis of the Mesa Instruction Set". R.Sweet, J.Sandman. The obvious question is WHY you want to compress your code size in this way. That report (if only I could remember title or author, sigh, pointed out that STATIC instruction (and operand) frequencies and DYNAMIC instruction (and operand) frequencies can be quite different. A fair bit of fiddling has gone on in the Smalltalk world, so that although practically everyone started with something like the Blue Book model (which is still probably *the* reference for how byte code systems work). Those people are trying to balance *compact* encoding against *efficient* decoding. If you just want to reduce size you might think in terms of just compressing everything, with decompression of code that's actually executed as "Level 0 JIT". From ok at cs.otago.ac.nz Mon Aug 31 03:48:16 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 31 Aug 2015 15:48:16 +1200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: <55E09C5A.1000600@gmail.com> References: <55E08229.5050602@gmail.com> <55E09C5A.1000600@gmail.com> Message-ID: <2F41467E-06EC-42D7-BAEF-420364D75737@cs.otago.ac.nz> On 29/08/2015, at 5:37 am, Silvio Frischknecht wrote: >> Why do you think that manipulating arrays is a better skill to teach >> to kids than manipulating linked lists? > > What about double linked lists then. Most updatable data structures are > just clumsy in Haskell. Doubly linked lists are an exotic advanced data structure which are appropriate *FAR* less often (and I'm thinking of imperative languages like Pascal, C, Ada, &c here) than people who have been taught them believe. I've sometimes thought that teaching doubly linked lists in CS1 or CS2 should be a punishable offence. From ok at cs.otago.ac.nz Mon Aug 31 03:49:37 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 31 Aug 2015 15:49:37 +1200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <20150829060950.83DCB276D62@mail.avvanta.com> <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> <2C44F34C-EED7-43D2-908C-F70813470D9D@cs.otago.ac.nz> Message-ID: On 31/08/2015, at 2:47 pm, William Yager wrote: > > Wrong definition, my friend. > > https://en.wikipedia.org/wiki/Side_effect_(computer_science) Nope, in this case it's Wikipedia that's wrong. From ok at cs.otago.ac.nz Mon Aug 31 04:11:55 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 31 Aug 2015 16:11:55 +1200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <20150829060950.83DCB276D62@mail.avvanta.com> <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> <2C44F34C-EED7-43D2-908C-F70813470D9D@cs.otago.ac.nz> Message-ID: On 31/08/2015, at 2:47 pm, William Yager wrote: > On Sun, Aug 30, 2015 at 8:20 PM, Richard A. O'Keefe wrote: > > The print statement has an EFFECT. That effect is not a > *SIDE* effect. Here's the definition of "side effect": > > 1. A subsidiary consequence of an action, occurrence, > or state of affairs; an unintended secondary result. > 2. An effect (usually for the worse) of a drug or other > chemical other than that for which it is administered > > In the case of the little program above, the fact that > output is sent to a destination is neither subsidiary, > nor unintended, nor secondary, nor other than that for > which the program was constructed. > > I flatly deny that "UNINTENDED ... results" are what > attracts ANYONE to programming. Effects, *YES*; > *side* effects, NO. > > > Wrong definition, my friend. > > https://en.wikipedia.org/wiki/Side_effect_(computer_science) Sorry, cliekd the wrong button. If you had troubled to read the Wikipedia article with care, you'd have seen this right at the beginning: In computer science, a function or expression is VVVVVVVVVVVVVVVVVVVVVVVV said to have a side effect if, in addition to returning ^^^^^^^^^^^^^^^^^^^^^^^^ a value, it also modifies some state or has an observable interaction with calling functions or the outside world. You have a function, whose purported effect is to return a value. "IN ADDITION TO" that, it has "A SUBSIDIARY CONSEQUENCE", "A SECONDARY RESULT". The Wikipedia definition is slightly wonky in that if you take it literally, a Fortran subroutine = Pascal or Ada procedure = C 'void function' can't have a side effect, which is obviously wrong. A subprogram that does not return a value *CAN* have a second result other than the one it is declared to have, and the need to consider history in reasoning about resultless procedures is none the less because of this glitch in the Wikipedia's definition. From donn at avvanta.com Mon Aug 31 04:54:58 2015 From: donn at avvanta.com (Donn Cave) Date: Sun, 30 Aug 2015 21:54:58 -0700 (PDT) Subject: [Haskell-cafe] side effects (Why Haskell is beautiful to the novice) In-Reply-To: References: Message-ID: <20150831045458.24C07F3935@mail.avvanta.com> > In computer science, a function or expression is > VVVVVVVVVVVVVVVVVVVVVVVV > said to have a side effect if, in addition to returning > ^^^^^^^^^^^^^^^^^^^^^^^^ > a value, it also modifies some state or has an observable > interaction with calling functions or the outside world. > > You have a function, whose purported effect is to return a > value. "IN ADDITION TO" that, it has "A SUBSIDIARY CONSEQUENCE", > "A SECONDARY RESULT". The Wikipedia definition is slightly > wonky in that if you take it literally, a Fortran subroutine = > Pascal or Ada procedure = C 'void function' can't have a side > effect, which is obviously wrong. A subprogram that does not > return a value *CAN* have a second result other than the one it > is declared to have, and the need to consider history in > reasoning about resultless procedures is none the less because > of this glitch in the Wikipedia's definition. Ha ha, I think this may be the first time I've seen a wikipedia page change as a side effect of a discussion that references it. But the modified definition seems to make even less sense. If I understand your objection above, the answer could simply be that these subprograms return a value like our (), for the sake of semantics. But the new definition requires us to identify a "purported main effect" in order to say what's a side effect. If foo :: IO Int prints a string and returns the string's length, do we need to know how important the string length is to the caller, or is that as the function type automatically its purported main effect? I'm sure I've encountered real life subprograms with two or more main effects. I'm also troubled by the change from "In functional programming, side effects are rarely used" to "In functional programming, effects are rarely used." This must be an error. Donn From ok at cs.otago.ac.nz Mon Aug 31 06:19:18 2015 From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz) Date: Mon, 31 Aug 2015 18:19:18 +1200 Subject: [Haskell-cafe] side effects (Why Haskell is beautiful to the novice) In-Reply-To: <20150831045458.24C07F3935@mail.avvanta.com> References: <20150831045458.24C07F3935@mail.avvanta.com> Message-ID: > Ha ha, I think this may be the first time I've seen a wikipedia page > change as a side effect of a discussion that references it. How long did you say you've been around? > I'm also troubled by the change from "In functional programming, > side effects are rarely used" to "In functional programming, > effects are rarely used." This must be an error. This can ONLY be an error if the original text was an error. Because it means EXACTLY what the original text was meant to mean; the only difference is that the original text used "side effect" to mean "effect". I see someone has changed it back to the old muddled wreck, sigh. From dct25-561bs at mythic-beasts.com Mon Aug 31 07:28:19 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Mon, 31 Aug 2015 08:28:19 +0100 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <55E380D1.2090308@nh2.me> References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> <20150725190911.ABEFD276CB6@mail.avvanta.com> <55E30C09.2090609@nh2.me> <20150830145927.64DD5F3946@mail.avvanta.com> <55E380D1.2090308@nh2.me> Message-ID: Exactly. As I said earlier, if you forget to clear FD_CLOEXEC when you meant to then your program breaks loudly and obviously; if you forget to *set* FD_CLOEXEC then the bug is much quieter and more subtle. I asked for a specific example of some existing code that would be broken by this, but none was forthcoming. I understand why, in theory, changing this would be a problem (indeed, changing anything is similarly problematic) but in practice the pros enormously outweigh the cons here. On 30 Aug 2015 11:17 pm, "Niklas Hamb?chen" wrote: > On 30/08/15 16:59, Donn Cave wrote: > > Quoth Niklas Hamb??chen , > > ... and you go on to demonstrate that you didn't really take the point > > I was trying to make. How did you find out about this flock(2) scenario? > > Do you suppose that this is the only one, because you and I don't know > > of any more? > > No, I do take your point, and I admit that more things may break when > changing the default. > > What I'm saying is that such cases are relatively easy to find. When you > rely on inheriting FDs, you know it. > It is exotic enough that when you've built something that needs it, > you'll remember it. > > This leads me to think that the damage done / cost to fix introduced by > breaking the backwards compatibility here might be smaller than the > damage / fixing that will arise in the future from surprising behaviour > and security/privilege problems through leaked FDs in all non-exotic > programs that want to exec() something. I'd assume the Python and Perl > people came to this conclusion. > > Further, our community is small, and if you announce something loud and > long-term via mailing list and Reddit, it will go a long way and make it > unlikely that somebody will be unaware of such a change. Your point that > we may break things that we don't know of / understand still stands though. > > Regarding pipes and sockets, pipe()/socket() accept CLOEXEC as well. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Mon Aug 31 08:05:46 2015 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Mon, 31 Aug 2015 10:05:46 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> <20150725190911.ABEFD276CB6@mail.avvanta.com> <55E30C09.2090609@nh2.me> <20150830145927.64DD5F3946@mail.avvanta.com> <55E380D1.2090308@nh2.me> Message-ID: <55E40ADA.2060301@nh2.me> On 31/08/15 09:28, David Turner wrote: > Exactly. As I said earlier, if you forget to clear FD_CLOEXEC when you > meant to then your program breaks loudly and obviously; if you forget to > *set* FD_CLOEXEC then the bug is much quieter and more subtle. I think the example given by Donn (a lock silently being cleared too early) is a case where it does not break loudly and obviously. I agree with the second part though that bugs related to leaking tend to be quieter and more subtle in general. From alexey.muranov at gmail.com Mon Aug 31 08:27:36 2015 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Mon, 31 Aug 2015 10:27:36 +0200 Subject: [Haskell-cafe] Why Haskell is beautiful to the novice In-Reply-To: References: <20150829060950.83DCB276D62@mail.avvanta.com> <2adb3bf5-eeab-4fe0-9009-9246826badef@googlegroups.com> <2C44F34C-EED7-43D2-908C-F70813470D9D@cs.otago.ac.nz> Message-ID: On 31 ao?t 2015, at 06:11, Richard A. O'Keefe wrote: > Sorry, cliekd the wrong button. > If you had troubled to read the Wikipedia article with care, > you'd have seen this right at the beginning: > > In computer science, a function or expression is > VVVVVVVVVVVVVVVVVVVVVVVV > said to have a side effect if, in addition to returning > ^^^^^^^^^^^^^^^^^^^^^^^^ > a value, it also modifies some state or has an observable > interaction with calling functions or the outside world. > > You have a function, whose purported effect is to return a > value. "IN ADDITION TO" that, it has "A SUBSIDIARY CONSEQUENCE", > "A SECONDARY RESULT". In my opinion, with such interpretation there can be no documented side effects: if some effect is documented, it is purported (an probably used by someone), so not secondary. Alexey. From dct25-561bs at mythic-beasts.com Mon Aug 31 08:46:43 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Mon, 31 Aug 2015 09:46:43 +0100 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <55E40ADA.2060301@nh2.me> References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> <20150725190911.ABEFD276CB6@mail.avvanta.com> <55E30C09.2090609@nh2.me> <20150830145927.64DD5F3946@mail.avvanta.com> <55E380D1.2090308@nh2.me> <55E40ADA.2060301@nh2.me> Message-ID: Yes, sure, but what actually does that? i.e. what locks a FD opened by the Haskell runtime and then expects to preserve the lock across a fork? I see that this is a problem in theory, but in practice is it? The point is, how much code would really have to change to fix the fallout from this? On 31/08/15 09:28, David Turner wrote: > Exactly. As I said earlier, if you forget to clear FD_CLOEXEC when you > meant to then your program breaks loudly and obviously; if you forget to > *set* FD_CLOEXEC then the bug is much quieter and more subtle. I think the example given by Donn (a lock silently being cleared too early) is a case where it does not break loudly and obviously. I agree with the second part though that bugs related to leaking tend to be quieter and more subtle in general. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Mon Aug 31 13:18:15 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Mon, 31 Aug 2015 15:18:15 +0200 Subject: [Haskell-cafe] Thread-safe GHC Message-ID: Hello, I am wondering if GHC itself is thread-safe. I am using Hint, and it reports that GHC is not thread-safe, and that I can't safely run two instances of the interpreter simultaneously. Is that still the case? Thanks! Corentin ---------- Forwarded message ---------- From: Daniel Gor?n Date: Thu, Aug 27, 2015 at 5:09 PM Subject: Re: Thread-safe Hint To: Corentin Dupont Hi Corentin, sorry for the late reply. Until relatively recently, the problem was still on. But I too remember seeing something related to this issue being fixed (iirc, the problem was the runtime linker, which used global state), so perhaps it is already fixed in 7.10. If you can verify this, it shouldn?t be hard to show the error message only on old versions of ghc. I?ll be away for a couple of weeks, but if you want to look into this and send a patch, I?ll merge it when I return. Cheers, Daniel > On 24 Aug 2015, at 10:43 am, Corentin Dupont wrote: > > Hello Daniel, > I noticed the following message in Hint: > This version of GHC is not thread-safe,can't safely run two instances of the interpreter simultaneously. > > Is it still the case with recent versions of GHC? > It would be neat to be able to launch several instances of the interpreter. In my game Nomyx I have several "match-up" going on and having one instance of the interpreter would be nicer. Otherwise I am obliged to reset the interpret each time I want to interpret something, which is time consuming (2-3 seconds). > > Thanks, > C -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Mon Aug 31 15:20:28 2015 From: capn.freako at gmail.com (David Banas) Date: Mon, 31 Aug 2015 08:20:28 -0700 Subject: [Haskell-cafe] Compiling non-registered packages into a sandbox? Message-ID: Hi all, How do I compile a non-Hackage registered package into a local sandbox? Let?s say I have: /proj_dir/ - .cabal-sandbox/ - cabal.sandbox.config - dep_pkg/ - dep_pkg.cabal - Setup.lhs - ? I?d like to compile the dep_pkg package into my proj_dir sandbox; can I do this, if dep_pkg is NOT registered with Hackage? If so, how? Thanks, -db -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at functionaljobs.com Mon Aug 31 16:00:01 2015 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 31 Aug 2015 12:00:01 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <55e47a1fc8aea@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Full Stack Haskell Software Engineer at Linkqlo Inc http://functionaljobs.com/jobs/8859-full-stack-haskell-software-engineer-at-linkqlo-inc Cheers, Sean Murphy FunctionalJobs.com From martin.drautzburg at web.de Mon Aug 31 16:48:01 2015 From: martin.drautzburg at web.de (martin) Date: Mon, 31 Aug 2015 18:48:01 +0200 Subject: [Haskell-cafe] How to combine simulations Message-ID: <55E48541.2030402@web.de> Hello all, I've been trying hard to come up with an idea how to build a DES from smaller parts. So far, I came to the conclusion, that somewhere there must be an operation which takes an Event and maybe emits an Event (and appends to a log and updates some state). Those Events whould come from and go to the "environment" the simulation runs in. My mental model is two billiard tables, which are connected through a hole in the cushion and which each have a player. When I look at one such table, it would have to respond to Events from its player and from the other table and it would send events to its player ("all balls at rest") and to the other table. If I add the other table and the two players then the combined simulation would not emit any events at all and it would not respond to any events except maybe as START event. It would only depend on its initial state. But if I add only the player, but not the other table, it would still send events to the other table and respond to events from that other table. My problem is the type of Events. I could create a type which encompasses all possible events, but that violates the idea of composablitly. Somehow I would need to be able to take a system which accepts "player events" and "other table events", compose it with an other table and end up with a system which only accepts "player events" but no more "other table events" and similarly for the emitted events. And I don't quite know how to do this. Hope this makes some sense. Any pointers (which go beyond "aivika has a simulation component") would also be much appreciated. From hesselink at gmail.com Mon Aug 31 18:08:28 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 31 Aug 2015 20:08:28 +0200 Subject: [Haskell-cafe] Compiling non-registered packages into a sandbox? In-Reply-To: References: Message-ID: Doesn't a simple 'cabal install dep_pkg/' when in 'proj_dir' work? Additionally, you can do 'cabal sandbox add-source dep_pkg/', which will make it available to be installed as a dependency automatically (and reinstall when it's changed). Erik On 31 August 2015 at 17:20, David Banas wrote: > Hi all, > > How do I compile a non-Hackage registered package into a local sandbox? > > Let?s say I have: > > /proj_dir/ > - .cabal-sandbox/ > - cabal.sandbox.config > - dep_pkg/ > - dep_pkg.cabal > - Setup.lhs > - ? > > I?d like to compile the dep_pkg package into my proj_dir sandbox; can I do > this, if dep_pkg is NOT registered with Hackage? > If so, how? > > Thanks, > -db > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From capn.freako at gmail.com Mon Aug 31 20:38:38 2015 From: capn.freako at gmail.com (David Banas) Date: Mon, 31 Aug 2015 13:38:38 -0700 Subject: [Haskell-cafe] Backing up ghc version, just for one sandbox? Message-ID: Hi all, Is it possible to back up the ghc version, just for a single sandbox? Thanks, -db -------------- next part -------------- An HTML attachment was scrubbed... URL: