Re: [Haskell-cafe] Retrospective type-class extension
On 20 May 2010 14:42, Tony Morris tonymor...@gmail.com wrote: We all know that class (Functor f) = Monad f is preferable but its absence is a historical mistake. We've all probably tried once: instance (Functor f) = Monad f where Do you mean the reverse of this (instance (Monad m) = Functor m where) ? ... However, is there a type system extension (even proposed but not implemented) that allows me to retrospectively apply such a notion? Ideally something like this would be handy if it could somehow be retrospectively applied: Monad - Applicative - Pointed - Functor -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrospective type-class extension
Ivan Miljenovic wrote: On 20 May 2010 14:42, Tony Morris tonymor...@gmail.com wrote: We all know that class (Functor f) = Monad f is preferable but its absence is a historical mistake. We've all probably tried once: instance (Functor f) = Monad f where Do you mean the reverse of this (instance (Monad m) = Functor m where) ? Yes. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Devices and Webcams, The Basics
OpenCV and its Haskell bindings http://hackage.haskell.org/package/HOpenCV should be able to talk to a webcam. There's an O'Reilly book about OpenCV. Tom On Wed, May 19, 2010 at 10:06 PM, Eitan Goldshtrom thesource...@gmail.com wrote: Hi everyone, I would like to start working on a program that requires access to a camera attached to the computer probably via USB or otherwise internally. Unfortunately I don't know anything about using devices in haskell. I tried looking up how to access the microphone one too and had little success. Could someone just point me in the direction of tutorials for learning the basics of both devices in general as well as the webcam more specifically? The webcam is a bit more of a priority. -Eitan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrospective type-class extension
Then it would be: class Functor f where fmap :: (a - b) - f a - f b class (Functor f) = Pointed f where pure :: a - f a class (Pointed f) = Applicative f where (*) :: f (a - b) - f a - f b class (Applicative f) = Monad f where join :: f (f a) - f a This would be a great idea, for the sake of logic, first (a monad which is not a functor doesn't make sense), and also to eliminate redudancy (fmap = liftM, ap = (*), etc.) 2010/5/20 Tony Morris tonymor...@gmail.com Ivan Miljenovic wrote: On 20 May 2010 14:42, Tony Morris tonymor...@gmail.com wrote: We all know that class (Functor f) = Monad f is preferable but its absence is a historical mistake. We've all probably tried once: instance (Functor f) = Monad f where Do you mean the reverse of this (instance (Monad m) = Functor m where) ? Yes. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrospective type-class extension
That won't be a great idea; if I just want my monad to be declared as one, I would have to write instance Functor MyMonad where fmap = ... instance Pointed MyMonad where pure = ... instance Applicative MyMonad where (*) = ... instance Monad MyMonad where join = ... Compare this with instance Monad MyMonad where return = ... (=) = ... and take into account that (=) is usually easier to write than join. Limestraël wrote: Then it would be: class Functor f where fmap :: (a - b) - f a - f b class (Functor f) = Pointed f where pure :: a - f a class (Pointed f) = Applicative f where (*) :: f (a - b) - f a - f b class (Applicative f) = Monad f where join :: f (f a) - f a This would be a great idea, for the sake of logic, first (a monad which is not a functor doesn't make sense), and also to eliminate redudancy (fmap = liftM, ap = (*), etc.) 2010/5/20 Tony Morris tonymor...@gmail.com mailto:tonymor...@gmail.com Ivan Miljenovic wrote: On 20 May 2010 14:42, Tony Morris tonymor...@gmail.com mailto:tonymor...@gmail.com wrote: We all know that class (Functor f) = Monad f is preferable but its absence is a historical mistake. We've all probably tried once: instance (Functor f) = Monad f where Do you mean the reverse of this (instance (Monad m) = Functor m where) ? Yes. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrospective type-class extension
I've compared and clearly the former is significantly superior :) I'm rather interested if there are any sound suggestions to resolve the general issue of retrospective type-class extension. Miguel Mitrofanov wrote: That won't be a great idea; if I just want my monad to be declared as one, I would have to write instance Functor MyMonad where fmap = ... instance Pointed MyMonad where pure = ... instance Applicative MyMonad where (*) = ... instance Monad MyMonad where join = ... Compare this with instance Monad MyMonad where return = ... (=) = ... and take into account that (=) is usually easier to write than join. Limestraël wrote: Then it would be: class Functor f where fmap :: (a - b) - f a - f b class (Functor f) = Pointed f where pure :: a - f a class (Pointed f) = Applicative f where (*) :: f (a - b) - f a - f b class (Applicative f) = Monad f where join :: f (f a) - f a This would be a great idea, for the sake of logic, first (a monad which is not a functor doesn't make sense), and also to eliminate redudancy (fmap = liftM, ap = (*), etc.) 2010/5/20 Tony Morris tonymor...@gmail.com mailto:tonymor...@gmail.com Ivan Miljenovic wrote: On 20 May 2010 14:42, Tony Morris tonymor...@gmail.com mailto:tonymor...@gmail.com wrote: We all know that class (Functor f) = Monad f is preferable but its absence is a historical mistake. We've all probably tried once: instance (Functor f) = Monad f where Do you mean the reverse of this (instance (Monad m) = Functor m where) ? Yes. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Devices and Webcams, The Basics
Ah thanks. Just what I'm looking for. Also thanks for the info about the USB bindings -Eitan On 5/20/2010 12:06 PM, Tom Nielsen wrote: OpenCV and its Haskell bindings http://hackage.haskell.org/package/HOpenCV should be able to talk to a webcam. There's an O'Reilly book about OpenCV. Tom On Wed, May 19, 2010 at 10:06 PM, Eitan Goldshtrom thesource...@gmail.com wrote: Hi everyone, I would like to start working on a program that requires access to a camera attached to the computer probably via USB or otherwise internally. Unfortunately I don't know anything about using devices in haskell. I tried looking up how to access the microphone one too and had little success. Could someone just point me in the direction of tutorials for learning the basics of both devices in general as well as the webcam more specifically? The webcam is a bit more of a priority. -Eitan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrospective type-class extension
With retrospective type-class extension in place whatever they look like, wouldn't everyone would have to import the same retrospectively extended instances (orphan retrospective extensions anyone?). Thus there seems no benefit over recoding the hierarchy directly and importing it, vis: import NewHierachyPrelude Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] String rewriting
Hi,
I'm looking for a simple way to rewrite strings according to simple
composable rules like:
replace _ by \\(\\hole\\)
replace -n where n matches an integer by ^{n}
so that I can import some pretty-printed output into a LaTeX alltt
environment. I'm guessing that this nice functional stream
transformation problem has been solved thousands of times. Could
anyone point me to a simple package that would do this for me?
many thanks,
Roly
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrospective type-class extension
Am 20.05.2010 um 14:16 schrieb Tony Morris: I've compared and clearly the former is significantly superior :) I'm rather interested if there are any sound suggestions to resolve the general issue of retrospective type-class extension. I would like to have something like parent class Functor f = Applicative f where fmap f x = pure f * x Then one could write instance Applicative MyApplicative deriving parent Functor where (*) = ... pure = ... as an abbreviation for instance Functor MyApplicative where fmap f x = pure f * x This way, we do not only save some keystrokes, but now it is clear that (fmap f x == pure f * x) is expected to hold for type MyApplicative. One could also write parent class Applicative a = Monad a deriving parent Functor where (*) = ap pure = return fmap = liftM overriding the default definition of Functor's fmap. Then instance Monad MyMonad deriving parent Applicative where (=) = ... return = ... would be an abbreviation for instance Functor MyMonad where fmap = liftM instance Applicative MyMonad where (*) = ap pure = return Now the compiler can even conclude that (liftM f x == pure f * x) is expected to hold for type MyMonad. But there is an ambiguity if one also defines parent class Functor f = Monad f where fmap f x = trace boo! (liftM f x) Then it might not be clear which definition of fmap should be used, because there are two possible paths: (Monad = Applicative = Functor) and (Monad = Functor). But then the programmer has to decide whether he writes 'deriving parent Applicative' or 'deriving parent Functor'. Thus, as long as every class or instance declaration contains at most one 'deriving parent' statement, there will always be one unambiguous path, so that this will not become a problem. This extension would have three advantages: - it is merely syntactic sugar, so that it can easily be implemented, - it does not involve tricky resolution of methods or types, so that it is easy to comprehend, and - it allows to encode knowledge about the laws class instances (should) follow. Miguel Mitrofanov wrote: That won't be a great idea; if I just want my monad to be declared as one, I would have to write instance Functor MyMonad where fmap = ... instance Pointed MyMonad where pure = ... instance Applicative MyMonad where (*) = ... instance Monad MyMonad where join = ... Compare this with instance Monad MyMonad where return = ... (=) = ... and take into account that (=) is usually easier to write than join. Limestraël wrote: Then it would be: class Functor f where fmap :: (a - b) - f a - f b class (Functor f) = Pointed f where pure :: a - f a class (Pointed f) = Applicative f where (*) :: f (a - b) - f a - f b class (Applicative f) = Monad f where join :: f (f a) - f a This would be a great idea, for the sake of logic, first (a monad which is not a functor doesn't make sense), and also to eliminate redudancy (fmap = liftM, ap = (*), etc.) 2010/5/20 Tony Morris tonymor...@gmail.com mailto:tonymor...@gmail.com Ivan Miljenovic wrote: On 20 May 2010 14:42, Tony Morris tonymor...@gmail.com mailto:tonymor...@gmail.com wrote: We all know that class (Functor f) = Monad f is preferable but its absence is a historical mistake. We've all probably tried once: instance (Functor f) = Monad f where Do you mean the reverse of this (instance (Monad m) = Functor m where) ? Yes. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
This message presents, informally, a proposal to solve Haskell's MPTC
(multi-parameter type class) dilemma. If this informal proposal turns
out to be acceptable, we (I am a volunteer) can proceed and make a
concrete proposal.
The proposal has been published in the SBLP'2009 proceedings and is
available at
www.dcc.ufmg.br/~camarao/CT/solution-to-MPTC-dilemma.pdf
The well-known dilemma
(hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma)
is that it is generally accepted that MPTCs are very useful, but their
introduction is thought to require the introduction also of FDs
(Functional Dependencies) or another mechanism like ATs (Associated
Types) and FDs are tricky and ATs, somewhat in a similar situation,
have been defined more recently and there is less experience with its
use.
In
www.haskell.org/ghc/dist/current/docs/html/users_guide/type-class-extensions.html
there exists a solution to the termination problem related to the
introduction of MPTCs in Haskell. In our proposal, neither FDs nor any
other mechanism like ATs are needed in order to introduce MPTCs in
Haskell; the only change we have to make is in the ambiguity
rule. This is explained below. The termination problem is essentially
ortogonal and can be dealt with, with minor changes, as described in
the solution presented in the above mentioned (type-class-extensions)
web page.
Let us review the ambiguity rule used in Haskell-98 and after that the
ambiguity rule used in GHC. Haskell-98 ambiguity rule (which is
adequate for Haskell-98's single parameter type classes) is: a type
C = T is ambiguous iff there is a type variable v that occurs in the
context (constraint set) C but not in the simple (unconstrained)
type T.
For example: forall a.(Show a, Read a)=String is ambiguous, because
a occurs in the constraints (Show a,Read a) but not in the simple
type (String).
In the context of MPTCs, this rule alone is not enough. Consider, for
example (Example 1):
class F a b where f:: a-b
class O a where o:: a
and
k = f o:: (C a b,O a) = b
Type forall a b. (C a b,O a) = b can be considered to be not
ambiguos, since overloading resolution can be defined so that
instantiation of b can determine that a should also be
instantiated (as FD b|-a does), thus resolving the overloading.
GHC, since at least version 6.8, makes significant progress towards a
definition of ambiguity in the context of MPTCs; GHC 6.10.3 Users
Guide says (section 7.8.1.1):
GHC imposes the following restrictions on the constraints in a type
signature. Consider the type: forall tv1..tvn (c1, ...,cn) = type. ...
Each universally quantified type variable tvi must be reachable from type.
A type variable a is reachable if it appears in the same constraint as
either a type variable free in the type, or another reachable type
variable.
For example, type variable a in constraint (O a) in the example
above is reachable, because it appears in (C a b) (the same constraint
as type variable b, which occurs in the simple type).
Our proposal is: consider unreachability not as indication of
ambiguity but as a condition to trigger overloading resolution (in a
similar way that FDs trigger overloading resolution): when there is at
least one unreachable variable and overloading is found not to be
resolved, then we have ambiguity. Overloading is resolved iff there is
a unique substitution that can be used to specialize the constraint
set to one, available in the current context, such that the
specialized constraint does not contain unreachable type variables.
(A formal definition, with full details, is in the cited SBLP'09 paper.)
Consider, in Example 1, that we have a single instance of F and
O, say:
instance F Bool Bool where f = not
instance O Bool where o = True
and consider also that k is used as in e.g.:
kb = not k
According to our proposal, kb is well-typed. Its type is Bool. This
occurs because (F a b, O a)=Bool can be simplified to Bool, since
there exists a single substitution that unifies the constraints with
instances (F Bool Bool) and (O Bool) available in the current context,
namely S = (a|-Bool,b|-Bool).
As another example (Example 2), consider:
{-# NoMonomorphismRestriction, MultiParameterTypeClasses #-}
data Matrix = ...
data Vector = ...
class Mult a b c where (*):: a ! b ! c
instance Mult Matrix Vector Matrix where (*) = ...
instance Mult Matrix Vector Vector where (*) = ...
m1:: Matrix = ...
m2:: Vector = ...
m3:: Vector = ...
m = (m1 * m2) * m3
GHC gives the following type to m:
m :: forall a, b. (Mult Matrix Vector a, Mult a Vector b) = b
However, m cannot be used effectively in a program compiled with
GHC: if we annotate m::Matrix, a type error is reported. This occurs
because the type inferred for m includes constraints (Mult Matrix
Vector a, Mult a Vector Matrix) and, with b|-Matrix, type variable a
appears only in the constraint set, and this type is considered
ambiguous. Similarly, if m is annotated with type Vector,
Re: [Haskell-cafe] String rewriting
On Thursday 20 May 2010 15:49:59, Roly Perera wrote:
Hi,
I'm looking for a simple way to rewrite strings according to simple
composable rules like:
replace _ by \\(\\hole\\)
replace -n where n matches an integer by ^{n}
so that I can import some pretty-printed output into a LaTeX alltt
environment. I'm guessing that this nice functional stream
transformation problem has been solved thousands of times. Could
anyone point me to a simple package that would do this for me?
many thanks,
Roly
Hmm, I'm a little surprised that the Regex libraries don't seem to provide
replacing functions (at least my short search didn't find any).
Still, shouldn't be too hard to use one of their matching functions to
write a replacing function.
Or start from scratch:
repFun :: (String - Maybe (String, String)) - (String - String)
- String - String
repFun test repl str@(c:cs)
= case test str of
Nothing - c : repFun test repl cs
Just (match, rest) - repl match ++ repFun test repl rest
repFun _ _ [] = []
-- uses:
repFun uscore (const \\(\\hole\\))
where
uscore ('_':rest) = Just (_,rest)
uscore _ = Nothing
repFun dashDigs expo
where
dashDigs ('-':rest@(d:_))
| isDigit d = Just (span isDigit rest)
dashDigs _ = Nothing
expo digs = '^':'{':digs ++ }
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String rewriting
Hello Roly As Daniel Fischer says, there might not be a library to do this. I would be tempted to start with a simple parser combinator library and do something with the 'answer type' so it supports string rewriting. Dave Bayer was working with one in this thread on Beginners: http://www.haskell.org/pipermail/beginners/2010-February/003399.html See my comment here: http://www.haskell.org/pipermail/beginners/2010-February/003433.html Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
On Thursday 20 May 2010 16:34:17, Carlos Camarao wrote: In the context of MPTCs, this rule alone is not enough. Consider, for example (Example 1): class F a b where f:: a-b class O a where o:: a and k = f o:: (C a b,O a) = b Type forall a b. (C a b,O a) = b can be considered to be not ambiguos, since overloading resolution can be defined so that instantiation of b can determine that a should also be instantiated (as FD b|-a does), thus resolving the overloading. snip Our proposal is: consider unreachability not as indication of ambiguity but as a condition to trigger overloading resolution (in a similar way that FDs trigger overloading resolution): when there is at least one unreachable variable and overloading is found not to be resolved, then we have ambiguity. Overloading is resolved iff there is a unique substitution that can be used to specialize the constraint set to one, available in the current context, such that the specialized constraint does not contain unreachable type variables. (A formal definition, with full details, is in the cited SBLP'09 paper.) Consider, in Example 1, that we have a single instance of F and O, say: instance F Bool Bool where f = not instance O Bool where o = True and consider also that k is used as in e.g.: kb = not k According to our proposal, kb is well-typed. Its type is Bool. This occurs because (F a b, O a)=Bool can be simplified to Bool, since there exists a single substitution that unifies the constraints with instances (F Bool Bool) and (O Bool) available in the current context, namely S = (a|-Bool,b|-Bool). But then somebody defines instance F Int Bool where f = even instance O Int where o = 0 What then? Using the available instances to resolve overloading is a tricky thing, it's very easy to make things break that way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
On Thu, May 20, 2010 at 11:54 AM, Daniel Fischer daniel.is.fisc...@web.dewrote: On Thursday 20 May 2010 16:34:17, Carlos Camarao wrote: In the context of MPTCs, this rule alone is not enough. Consider, for example (Example 1): class F a b where f:: a-b class O a where o:: a and k = f o:: (C a b,O a) = b ... Our proposal is: consider unreachability not as indication of ambiguity but as a condition to trigger overloading resolution (in a similar way that FDs trigger overloading resolution): when there is at least one unreachable variable and overloading is found not to be resolved, then we have ambiguity. Overloading is resolved iff there is a unique substitution that can be used to specialize the constraint set to one, available in the current context, such that the specialized constraint does not contain unreachable type variables. ... Consider, in Example 1, that we have a single instance of F and O, say: instance F Bool Bool where f = not instance O Bool where o = True and consider also that k is used as in e.g.: kb = not k According to our proposal, kb is well-typed. Its type is Bool. This occurs because (F a b, O a)=Bool can be simplified to Bool, since there exists a single substitution that unifies the constraints with instances (F Bool Bool) and (O Bool) available in the current context, namely S = (a|-Bool,b|-Bool). But then somebody defines instance F Int Bool where f = even instance O Int where o = 0 What then? Then (F a b, O a)=Bool is ambiguous. There are two substitutions that unify (F a b, O a) with instances in the current context. Using the available instances to resolve overloading is a tricky thing, it's very easy to make things break that way. Using the available instances is the natural, in fact the only way, to resolve overloading. Our proposal cannot make any well-typed program break, any program whatsoever. What it can do is to make programs that *were not well-typed* --- because there existed an ambiguity error --- to be either: i) well-typed (because overloading is resolved), or ii) not well-typed (because overloading cannot in fact be resolved), and in this case the ambiguity error may be deferred, to the point where the unreachability occurs, if there was a FD annotated. Cheers, Carlos ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intuitive function given type signature
On Thu, May 20, 2010 at 11:53:09AM +1200, Richard O'Keefe wrote: On May 20, 2010, at 3:18 AM, Brent Yorgey wrote: On Wed, May 19, 2010 at 04:27:14AM +, R J wrote: What are some simple functions that would naturally have the following type signatures: f :: (Integer - Integer) - Integer The key point is the 'that would NATURALLY have', which I take to mean as a result of type inference without any forcibly imposed type signatures. Given that this is an exercise in Chapter 1, I kind of doubt this is really what it is supposed to mean. Are people reading chapter 1 really expected to understand the intricacies of type inference and the Num class? And to know about 'toInteger' and the fact that numeric constants are polymorphic? I really doubt it. I read the question much more simply, with naturally having a much more informal meaning than you suggest. I interpret the question as simply getting the reader some practice with basic higher-order types. I haven't read the Bird book though, so I could be wrong. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
On 20 May 2010 16:50, Carlos Camarao carlos.cama...@gmail.com wrote: Using the available instances to resolve overloading is a tricky thing, it's very easy to make things break that way. Using the available instances is the natural, in fact the only way, to resolve overloading. AFAIK no other Haskell feature is defined in terms of available instance information. Overloaded functions are resolved by at least these mechanisms: * Defaulting * Information from unification (including from user-defined type signatures) * Functional dependencies propagating information Available instances are not a natural addition to this list. In particular, using that information can cause programs to become untypeable when the module or *any module it imports transitively* defines a new instance. This leads to programs that are extremely fragile in the face of changes in the libraries! (Admittedly you can get the same issue with GHC Haskell as it is right now if you define an orphan instance in your module) The situation is even worse if you consider available instances to also include orphans defined in non-imported modules (as a whole-program compiler way very well do), because then you don't even need to have transitively imported the module which has added an instance for your program to stop type-checking. Furthermore, if you intend to use an overloaded function at *one particular instance*, you could just have written the monomorphic type to begin with and not even bothered with overload resolution. Our proposal cannot make any well-typed program break, any program whatsoever. That is true, but it makes extra things type check in a really fragile way. I'm not keen. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
On Thu, May 20, 2010 at 12:25 PM, Max Bolingbroke batterseapo...@hotmail.com wrote: Available instances are not a natural addition to this list. In particular, using that information can cause programs to become untypeable when the module or *any module it imports transitively* defines a new instance. This leads to programs that are extremely fragile in the face of changes in the libraries! This is an unavoidable consequence of MPTCs being open, is it not? If data types or function declarations permitted the post facto addition of new constructors or pattern matches, similar headaches would ensue due to non-locality of transitive propagation. Clearly open type classes are useful; open data types and functions would be useful as well, actually, but it would be madness to permit *only* open declarations. Yet, that is the situation with type classes. I wonder: Of cases where overload resolution via available instances would be reasonable, how many would also make sense as a closed type class? By comparison, it seems that many uses of OverlappingInstances are really just trying to express a closed type class with one or more default instances, akin to functions with _ patterns. I think, though I'm not certain, that both would be straightforward and non-fragile for a closed type class. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No copy XML parser (rough idea only)
Hi Joachim, I have been playing around with this idea myself in TagSoup (http://community.haskell.org/~ndm/tagsoup). The largest conceptual problem I came across was that TagSoup decodes entities (i.e. gt; becomes ). However, I think that's a minor issue, and entity resolution can be turned off in TagSoup to guarantee copy-free parsing. The practical problem is that writing an HTML parser is hard, and that writing it in a way that works on both String/ByteString/LBS and gets the copy-free behaviour in the right places is tricky. I am still working on program optimisation techniques that I think will make this feasible (based around the idea of supercompilation, to expose the underlying structure of the parser, without writing it in too painful a manner). So with any luck your copy-free XML parser will happen sooner or later. Thanks, Neil On Fri, May 14, 2010 at 8:20 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Freitag, den 14.05.2010, 15:31 -0300 schrieb Felipe Lessa: On Fri, May 14, 2010 at 08:57:42AM -0700, John Millikin wrote: Additionally, since the original bytestring is shared in your types, potentially very large buffers could be locked in memory due to references held by only a small portion of the document. Chopping a document up into events or nodes creates some overhead due to the extra pointers, but allows unneeded portions to be freed. However, if your bytestring comes from mmap'ed memory this drawback wouldn't apply :D. exactly. Of course such a library would not be a general-purpose tool, but in cases where you know that you need most of the document for most of the time, e.g. when doing statistics on it, this would be acceptable. Also note that even after chopping into nodes, if you don’t make sure you drop the reference to root in a timely manner, the same thing would happen. Am Freitag, den 14.05.2010, 08:57 -0700 schrieb John Millikin: The primary problem I see with this is that XML content is fundamentally text, not bytes. Using your types, two XML documents with identical content but different encodings will have different Haskell values (and thus be incorrect regarding Eq, Ord, etc). The instances could be adapted... but this will be expensive, of course. One could also convert documents that are not utf-8 encoded as a whole and then work on that. If you'd like memory-efficient text storage, using Bryan O'Sullivan's text package[1] is probably the best option. It uses packed Word16 buffers to store text as UTF-16. Probably not as efficient as a type backed by UTF-8, but it's much much better than String. Right. For arbtt, I tried to switch from String to text, and it actually got slower. The reason (I think) was that besides passing strings around, it mainly runs pcre-light on them – which wants utf8-encoded bytestrings. I ended up creating a newtype¹ around utf8-encoded ByteStrings and the result was quite satisfying, both memory- and runtime-wise. I wish we had a package providing a standard type for this type that would become similarly popular. There is at least one more packages on hackage that defines this type: http://hackage.haskell.org/packages/archive/regex-tdfa-utf8/1.0/doc/html/Text-Regex-TDFA-UTF8.html Greetings, Joachim ¹ http://darcs.nomeata.de/arbtt/src/Data/MyText.hs -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] making the GHC Api not write to stderr
I was wondering how to forcibly quiet down the API. I have a custom handler
in place, but when I call the function on failure both my handler gets
called and somewhere somehow errors get printed to the stderr, which I
really need to avoid.
My current code looks like
getModInfo :: Bool - String - String - IO (ApiResults ModuleInfo)
getModInfo qual file path = handleSourceError processErrors $
runGhc (Just libdir) $ do
dflags - getSessionDynFlags
setSessionDynFlags $ configureDynFlags dflags
target - guessTarget file Nothing
addTarget target
setSessionDynFlags $ dflags { importPaths = [path] }
load LoadAllTargets
graph - depanal [] False
let modifier = moduleName . ms_mod
modName = modifier $ head graph
includes = includePaths dflags
imports = importPaths dflags
dflags' - Debug.trace (moduleNameString modName) getSessionDynFlags
setSessionDynFlags $ dflags' { includePaths = path:includes
, importPaths = path:imports
}
parsed - parse modName
checked - typecheckModule parsed
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
On Thu, May 20, 2010 at 1:25 PM, Max Bolingbroke batterseapo...@hotmail.com wrote: On 20 May 2010 16:50, Carlos Camarao carlos.cama...@gmail.com wrote: Using the available instances to resolve overloading is a tricky thing, it's very easy to make things break that way. Using the available instances is the natural, in fact the only way, to resolve overloading. AFAIK no other Haskell feature is defined in terms of available instance information. Overloaded functions are resolved by at least these mechanisms: * Defaulting * Information from unification (including from user-defined type signatures) * Functional dependencies propagating information Available instances are not a natural addition to this list. In particular, using that information can cause programs to become untypeable when the module or *any module it imports transitively* defines a new instance. This leads to programs that are extremely fragile in the face of changes in the libraries! Replace Using the available instances is the natural, in fact the only way, to resolve overloading. by All overloading resolution has to consider the available instances, after unification, user-defined type signatures, defaulting and FDs have been considered. Extremely fragile is debatable; the important fact, highlighted, is that if overloading resolution depends on the existence of a unique substitution, then the program may become untypeable when other instances are defined in the visible typing context. (Admittedly you can get the same issue with GHC Haskell as it is right now if you define an orphan instance in your module) Yes. Just to emphasize, with our proposal the issue (of transforming a well-typed program into a program which is not well-typed) is relevant only when unreachable variables exist (for existing programs this never occurs, since they are unambiguous according to the existing ambiguity rule). The situation is even worse if you consider available instances to also include orphans defined in non-imported modules (as a whole-program compiler way very well do), because then you don't even need to have transitively imported the module which has added an instance for your program to stop type-checking. Consider instances defined in non-imported modules to be visible in the current context is not correct, I think... Furthermore, if you intend to use an overloaded function at *one particular instance*, you could just have written the monomorphic type to begin with and not even bothered with overload resolution. Sorry, I do not follow you here (why *at one particular instance*?). A polymorphic (overloaded or not) function is defined and then used at specific cases, with different (instance) types. Our proposal cannot make any well-typed program break, any program whatsoever. That is true, but it makes extra things type check in a really fragile way. I'm not keen. Really fragile meaning: Overloading resolution depends on the set of available instances in the following way: if a constraint on the type of an expression *contains unreachable variables* and these type variables can be instantiated, by a single substitution(*), to instances in the current context, then the constraint/overloading is resolved, and the type is not ambiguous). then yes, ok. (*) Single restricted to the domain of unreachable type variables... Also, the same fragilty occurs if FDs are used. Cheers, Max Cheers, Carlos ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] making the GHC Api not write to stderr
hi,
i tried this too, but i did not get it. a very nice workaround is to use
hint [1].
have fun
martin
[1]: http://hackage.haskell.org/package/hint
On 20.05.2010 20:05, Phyx wrote:
I was wondering how to forcibly quiet down the API. I have a custom
handler in place, but when I call the function on failure both my
handler gets called and somewhere somehow errors get printed to the
stderr, which I really need to avoid.
My current code looks like
getModInfo :: Bool - String - String - IO (ApiResults ModuleInfo)
getModInfo qual file path = handleSourceError processErrors $
runGhc (Just libdir) $ do
dflags - getSessionDynFlags
setSessionDynFlags $ configureDynFlags dflags
target - guessTarget file Nothing
addTarget target
setSessionDynFlags $ dflags { importPaths = [path] }
load LoadAllTargets
graph - depanal [] False
let modifier = moduleName . ms_mod
modName = modifier $ head graph
includes = includePaths dflags
imports = importPaths dflags
dflags' - Debug.trace (moduleNameString modName) getSessionDynFlags
setSessionDynFlags $ dflags' { includePaths = path:includes
, importPaths = path:imports
}
parsed - parse modName
checked - typecheckModule parsed
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrospective type-class extension
On Thu, May 20, 2010 at 10:16:29PM +1000, Tony Morris wrote: I've compared and clearly the former is significantly superior :) I'm rather interested if there are any sound suggestions to resolve the general issue of retrospective type-class extension. Hi, my 'class aliases' proposal was meant to solve this issue with type classes. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] making the GHC Api not write to stderr
I've thought about that, but my specific problem is that I'm calling the
Haskell code compiled to a shared lib and then hPutStr is failing,
presumable because there is no valid stderr (and I would image also no stdin
or out).
So in order for me to use that method I would have to create a new file
handle and direct stderr to that. Or somehow create a fake Handle and pass
it that.
Or another alternative is on the side where I call the lib, create and
attach some hidden console to the process and have it write there.
But that all seems like a hackish way out, It would be best if the API just
allowed me to turn off this behavior of writing to stderr.
From: Jean-Denis Koeck [mailto:jdko...@gmail.com]
Sent: Thursday, May 20, 2010 21:59
To: Phyx
Subject: Re: [Haskell-cafe] making the GHC Api not write to stderr
Maybe this
http://nominolo.blogspot.com/2010/04/haskell-tip-redirect-stdout-in-haskell
.html could help you ?
2010/5/20 Phyx loneti...@gmail.com
I was wondering how to forcibly quiet down the API. I have a custom handler
in place, but when I call the function on failure both my handler gets
called and somewhere somehow errors get printed to the stderr, which I
really need to avoid.
My current code looks like
getModInfo :: Bool - String - String - IO (ApiResults ModuleInfo)
getModInfo qual file path = handleSourceError processErrors $
runGhc (Just libdir) $ do
dflags - getSessionDynFlags
setSessionDynFlags $ configureDynFlags dflags
target - guessTarget file Nothing
addTarget target
setSessionDynFlags $ dflags { importPaths = [path] }
load LoadAllTargets
graph - depanal [] False
let modifier = moduleName . ms_mod
modName = modifier $ head graph
includes = includePaths dflags
imports = importPaths dflags
dflags' - Debug.trace (moduleNameString modName) getSessionDynFlags
setSessionDynFlags $ dflags' { includePaths = path:includes
, importPaths = path:imports
}
parsed - parse modName
checked - typecheckModule parsed
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] making the GHC Api not write to stderr
Hi,
Unfortunately hint does not provide the functionality I require, and from
what I remember about hint they also use the GHC API, I guess the problem
here is the defaultErrorhandlers that is in initGhcMonad . I've been
wondering if I give my own implementation, one that doesn't do any printing
at all and reimplement initGhcMonad I can maybe get the desired result but
I'm not sure
-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Martin Hilbig
Sent: Thursday, May 20, 2010 21:45
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] making the GHC Api not write to stderr
hi,
i tried this too, but i did not get it. a very nice workaround is to use
hint [1].
have fun
martin
[1]: http://hackage.haskell.org/package/hint
On 20.05.2010 20:05, Phyx wrote:
I was wondering how to forcibly quiet down the API. I have a custom
handler in place, but when I call the function on failure both my
handler gets called and somewhere somehow errors get printed to the
stderr, which I really need to avoid.
My current code looks like
getModInfo :: Bool - String - String - IO (ApiResults ModuleInfo)
getModInfo qual file path = handleSourceError processErrors $
runGhc (Just libdir) $ do
dflags - getSessionDynFlags
setSessionDynFlags $ configureDynFlags dflags
target - guessTarget file Nothing
addTarget target
setSessionDynFlags $ dflags { importPaths = [path] }
load LoadAllTargets
graph - depanal [] False
let modifier = moduleName . ms_mod
modName = modifier $ head graph
includes = includePaths dflags
imports = importPaths dflags
dflags' - Debug.trace (moduleNameString modName) getSessionDynFlags
setSessionDynFlags $ dflags' { includePaths = path:includes
, importPaths = path:imports
}
parsed - parse modName
checked - typecheckModule parsed
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
I wonder: Of cases where overload resolution via available instances would be reasonable, how many would also make sense as a closed type class? By comparison, it seems that many uses of OverlappingInstances are really just trying to express a closed type class with one or more default instances, akin to functions with _ patterns. I think, though I'm not certain, that both would be straightforward and non-fragile for a closed type class. Someone recently described the HASP project, at http://hasp.cs.pdx.edu/. It describes habit, a haskell like language with some additions and subtractions. There are a couple interesting extensions to 'instance' declarations: -- explicitly declare that there is no instance, halting the compiler's search instance xyz fails -- declares instances along with search order instance abc ... else def The result is that if you put 'fails' at the end, you can make a closed typeclass. Presumably you could also make typeclasses open but only in a restricted way. Also presumably the compiler would then be able to make better decisions about overlapping instances and you could avoid a lot of overlapping problems. Of course, it's just a paper with no compiler, so it's all presumably for the moment... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
On 20 May 2010 21:16, Evan Laforge qdun...@gmail.com wrote: Someone recently described the HASP project, at http://hasp.cs.pdx.edu/. It describes habit, a haskell like language with some additions and subtractions. There are a couple interesting extensions to 'instance' declarations: -- explicitly declare that there is no instance, halting the compiler's search instance xyz fails -- declares instances along with search order instance abc ... else def The result is that if you put 'fails' at the end, you can make a closed typeclass. Presumably you could also make typeclasses open but only in a restricted way. Also presumably the compiler would then be able to make better decisions about overlapping instances and you could avoid a lot of overlapping problems. Of course, it's just a paper with no compiler, so it's all presumably for the moment... Hi Evan, hasn't EHC had something like this for a while with 'type class directives'? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrospective type-class extension
On 20 May 2010 13:10, Miguel Mitrofanov miguelim...@yandex.ru wrote: That won't be a great idea; if I just want my monad to be declared as one, I would have to write instance Functor MyMonad where fmap = ... instance Pointed MyMonad where pure = ... instance Applicative MyMonad where (*) = ... instance Monad MyMonad where join = ... There are also some Monads where a Functor instance wouldn't add anything useful, Andy Gill's Dot monad is one (Text.Dot), Oleg Kiselyov's RenderMonad in the CSXML library is another. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: threads-0.1.0.1
Dear all, I uploaded threads-0.1.0.1 to hackage. Threads is a small package that lets you fork threads and wait for their result. The basic interface is simply: module Control.Concurrent.Thread where data ThreadId α forkIO ∷ IO α → IO (ThreadId α) wait ∷ ThreadId α → IO (Either SomeException α) threadId ∷ ThreadId α → Control.Concurrent.ThreadId I hope the names and types speak for themselves. Additionally the following module is provided that lets you wait for a group of threads to terminate: module Control.Concurrent.Thread.Group where data ThreadGroup new ∷ IO ThreadGroup forkIO ∷ ThreadGroup → IO α → IO (ThreadId α) wait ∷ ThreadGroup → IO () Installation: $ cabal update $ cabal install threads API docs: http://hackage.haskell.org/package/threads-0.1.0.1 Development: darcs get http://code.haskell.org/~basvandijk/code/threads Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
On 20 May 2010 20:30, Carlos Camarao carlos.cama...@gmail.com wrote: Consider instances defined in non-imported modules to be visible in the current context is not correct, I think... I was under the impression that this was not specified, because orphans are a bit of an oddity. But naturally the Haskell spec says what to do (Sec 5.4, http://www.haskell.org/onlinereport/modules.html): Thus, an instance declaration is in scope if and only if a chain of import declarations leads to the module containing the instance declaration. So you are correct. Sorry, I do not follow you here (why *at one particular instance*?). A polymorphic (overloaded or not) function is defined and then used at specific cases, with different (instance) types. I got carried away here and didn't think that comment through, sorry for the error. You propose delaying the (possible) lack of a unique instantiation of the type variables to the overloaded definitions use site, but that *does not mean* that there is only one possible instantiation at the *original definition site* because some of the type variables in the possibly-ambiguous context are still free in the type and hence subject to further unification. Also, the same fragilty occurs if FDs are used. This remark is surprising to me. I thought the point of the FDs being declared on the original class (and the subsequent coverage condition check on instances) was to ensure that this fragility couldn't happen. Can you show an example (without using orphan instances) so I can get the idea? Thanks, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
On Thu, May 20, 2010 at 7:54 PM, Max Bolingbroke batterseapo...@hotmail.com wrote: On 20 May 2010 20:30, Carlos Camarao carlos.cama...@gmail.com wrote: ... Also, the same fragilty occurs if FDs are used. This remark is surprising to me. I thought the point of the FDs being declared on the original class (and the subsequent coverage condition check on instances) was to ensure that this fragility couldn't happen. Can you show an example (without using orphan instances) so I can get the idea? Thanks, Max Well, what I meant is just that the same would happen if we had a FD a-b in Example 1... (maybe I am not following you). That is: the same would happen if Example 1 was written with a FD as follows: class F a b | a - b where f:: a - b instance O a where o:: a And we had the same context: instance F Bool Bool where f = not instance O Bool where o = True k = f o kb = not k Then: kb is well-typed, because FD a |-b closes the world, causing type (F a b, O a)=Bool to be simplified (improved) to Bool. But this type-correct program would become not typeable if instances such as the ones referred to before (by Daniel Fischer) instance F Int Bool where f = even instance O Int where o = 0 were later introduced, or imported... Cheers, Carlos ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type famillies Lifting IO
Maciej Piechotka wrote: class (Monad m, Monad (IO' m)) = MonadIO m where type IO' m :: * - * liftIO :: IO a - IO' m a liftM :: m a - IO' m a The signature for liftIO betrays a problem. Since liftIO is a member of a type class, when liftIO is used in code, the type checker has to find the appropriate instance (i.e., resolve the overloading). Suppose we have this piece of code: tt :: FooIO () tt = liftIO (return () :: IO ()) How to find the appropriate instance of MonadIO and resolve the liftIO overloading? The argument type of liftIO does not mention the type class parameter m at all, and so it is of no guidance for overloading resolution. We know that the return type of liftIO in the tt code is FooIO (). Thus we have to find such instance of the MonadIO class that its associated type IO' m is equal to FooIO. In other words, we have to find m as a solution of the equation IO' m = FooIO Or, we have to invert the type function IO' m. Alas, type functions are not generally injective and hence not invertible. Indeed, nothing prevents the user from defining two instances of MonadIO, for types m1 and m2, such that IO' m1 = IO' m2 = FooIO. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
Hi Evan, hasn't EHC had something like this for a while with 'type class directives'? I dunno, I don't even know what ehc is. Is it this? http://www.cs.uu.nl/wiki/Ehc/WebHome I turned up a paper that mentioned type class directives, but I haven't read it yet. In any case, the EHC page says nearing first release! so had something like this for a while depends on your perspective of has :) In any case, I thought the habit paper was fun and had a number of things it would be nice to have in haskell (even simple sugar like case- and if-). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
