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'
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)
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' 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' 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' > 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 res_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' 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: