Re: lifting functions to tuples?
Abraham Egnor wrote:
> The classic way to write a lift function for tuples is, of course:
> liftTup f (a, b) = (f a, f b)
> which has a type of (a -> b) -> (a, a) -> (b, b). I've been wondering if
> it would be possible to write a function that doesn't require the types in
> the tuple to be the same, just that the types in the second tuple are the
> result of applying the type transformation implied in the function to be
> lifted to the types in the first tuple.
Well, it is possible in Haskell. It works even in Hugs!
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
class Funnable a b | a->b where
f:: a -> b
instance Funnable Bool Int where
f = fromEnum
instance Funnable Char Float where
f = fromRational . toRational . fromEnum
class LP a b c d where
liftf:: (a, b) -> (c, d)
instance (Funnable a c, Funnable b d) => LP a b c d where
liftf (a,b) = (f a, f b)
Main> liftf (True,'z')
(1,122.0)
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
COORD04: List of accepted papers
[[ -- Apologies for multiple copies of this message -- ]] Please, find attached the list of accepted papers to COORDINATION 2004. -- *** Emilio Tuosto Universita' di Pisa Dipartimento di informatica Via F. Buonarroti 2, 56127 Pisa -- Italy Tel. +39 050 2212 799 Fax. +39 050 2212 726 homepage -> http://www.di.unipi.it/~etuosto *** id Title Authors 7 Evolving Problem Frames: a Case for Coordination Leonor Barroca, Jose Fiadeiro, Michael Jackson, Robin Laney 8 Visual Programming of Agents with Agent Factory Colm Rooney, Rem Collier, Gregory O`Hare 14 On the Expressiveness of Absolute-time Coordination Languages Isabelle Linden, Jean-Marie Jacquet 15 O`Klaim: a coordination language with mobile mixins Lorenzo Bettini, Viviana Bono, Betti Venneri 16 Active Coordination in Ad Hoc Networks Christine Julien, Gruia-Catalin Roman 17 A Component-Based Parallel Constraint Solver Farhad Arbab, Peter Zoeteweij 19 Using Coordination Middleware for Location-Aware Computing: A LIME Case study Amy L. Murphy, Gian Pietro Picco 23 On calculi for contex-aware coordination Pietro Braione, Gian Pietro Picco 24 Social Control Mechanisms to Coordinate an Unreliable Agent Society Hamid Haidarian Shahri, Ahmad Abdolahzadeh Barforush, Mohammad Reza Meybodi 28 From Endogenous to Exogenous Coordination Using Aspect-Oriented Programming Sirio Capizzi, Riccardo Solmi, Gianluigi Zavattaro 32 Enforcement of Communal Policies for Peer-to-Peer Systems Mihail Ionescu, Naftaly Minsky, Thu Nguyen 43 Measuring component adaptation Antonio Brogi, Carlos Canal, Ernesto Pimentel 51 Probabilistic KLAIM Alessandra Di Pierro, Chris Hankin, Herbert Wiklicky 54 Logic Based Coordination for Event-Driven Self-Healing Distributed Systems C. Montangero, L. Semini, S. Semprini 57 CoorSet: A Development Environment for Associatively Coordinated Components Kevin Kane, J. C. Browne 58 A Lightweight Coordination Middleware for Mobile Computing Chien-Liang Fok, Gruia-Catalin Roman, Gregory Hackmann 59 Optimistic Concurrency Semantics for Coordination Languages Suresh Jagannathan, Jan Vitek 65 An Infrastructure for Building Secure Grid Shared Spaces Javier Jaen, Elena Navarro 66 An Operational Semantics for StAC, a Language for Modelling Long-running Business Transactions Michael Butler, Carla Ferreira 69 Priorities, Probabilities and Security in theLinda Coordination Model Mario Bravetti, Roberto Gorrieri, Roberto Lucchi, Gianluigi Zavattaro ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lifting functions to tuples?
On Tue, Nov 18, 2003 at 04:34:43PM +, Jon Fairbairn wrote: > On 2003-11-18 at 10:46EST "Abraham Egnor" wrote: > > The classic way to write a lift function for tuples is, of course: > > > > liftTup f (a, b) = (f a, f b) > > > > which has a type of (a -> b) -> (a, a) -> (b, b). I've been wondering if > > it would be possible to write a function that doesn't require the types in > > the tuple to be the same, just that the types in the second tuple are the > > result of applying the type transformation implied in the function to be > > lifted to the types in the first tuple. > > What you want is that f be applicable to both b and c, > giving results b' and c', but if b and c happen to be the > same type then f need not be polymorphic. > > I don't think you can express this in ghc's type system. You'd have > to have bounded quantification: > > lifTup :: > forall c, a >= c, b >= c, d, a'<=d, b'<= d. (c -> d) -> (a,b)->(a',b') It can also be straightforwardly expressed in a type system that has intersection types: liftTup :: ((b -> b') ^ (c -> c')) -> (b, c) -> (b', c') where '^' is the intersection type constructor. That is in fact the principal typing for liftTup, and it can be automatically inferred. -- Sebastien signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: How to best add logging/debugging code?
hello, Ben Escoto wrote: Maybe eventually I will see a need for mapWriter. As a passing thought, I wonder how many programmers can read the mapWriterT documentation: mapWriterT :: (m (a, w) -> n (b, w')) -> WriterT w m a -> WriterT w' n b and start pounding the code out? Anyway, once I get this all sorted out, I figure my program will have really nice logging, better than fprintf(stderr, ...) even. you should not use mapWriterT, usually you can get the same behaviour in a different way (i think it should not be exported by the module). by the way once you learn how the tranformers work, you'll be able to guess what that does from its type. however i think it is nice if you can use the transformers witout knowing how they are implemented. if you have access to cvs you might want to look at the revamped monad transformer library in the haskell cvs (fptools/libraries/monads). it is more docuemnted then the current one, but otherwise it is very similar. bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lifting functions to tuples?
On 2003-11-18 at 10:46EST "Abraham Egnor" wrote: > The classic way to write a lift function for tuples is, of course: > > liftTup f (a, b) = (f a, f b) > > which has a type of (a -> b) -> (a, a) -> (b, b). I've been wondering if > it would be possible to write a function that doesn't require the types in > the tuple to be the same, just that the types in the second tuple are the > result of applying the type transformation implied in the function to be > lifted to the types in the first tuple. Now, in Haskell98, this isn't > possible because of the monomorphism restriction; however, ghc > conveniently has a way to disable that. However, I'm still having > problems figuring out if it's even doable within the current constraints > of the glasgow-extended type system. One possibility I tried is: > > liftTup (f :: forall a b. a -> b) (p, q) = (f p, f q) Note that the type you are requiring for f is equivalent to forall a . a -> forall b . b which rather limits the possible values for f. Another possibility would be lifTup:: (forall a. a -> b) -> (c, d) -> (b,b) but that requires the f to be polymorphic and that the result has elements of the same type. What you want is that f be applicable to both b and c, giving results b' and c', but if b and c happen to be the same type then f need not be polymorphic. I don't think you can express this in ghc's type system. You'd have to have bounded quantification: lifTup :: forall c, a >= c, b >= c, d, a'<=d, b'<= d. (c -> d) -> (a,b)->(a',b') which is monstrous even if I've managed to get it right! Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
lifting functions to tuples?
The classic way to write a lift function for tuples is, of course: liftTup f (a, b) = (f a, f b) which has a type of (a -> b) -> (a, a) -> (b, b). I've been wondering if it would be possible to write a function that doesn't require the types in the tuple to be the same, just that the types in the second tuple are the result of applying the type transformation implied in the function to be lifted to the types in the first tuple. Now, in Haskell98, this isn't possible because of the monomorphism restriction; however, ghc conveniently has a way to disable that. However, I'm still having problems figuring out if it's even doable within the current constraints of the glasgow-extended type system. One possibility I tried is: liftTup (f :: forall a b. a -> b) (p, q) = (f p, f q) which does, in fact, compile. A very odd type is inferred: liftTup :: forall b1 b a1 a. (forall a2 b2. a2 -> b2) -> (a, a1) -> (b, b1) I call this odd because there's no mention of the type dependencies inherent in the actual function. However, any attempt to apply it to a polymorphic function results in the following errors: random.hs:17: Could not deduce (Num b) from the context () arising from use of `inc' at random.hs:17 Probable fix: Add (Num b) to the expected type of an expression In the first argument of `liftTup', namely `inc' In the definition of `tupInc': tupInc = liftTup inc random.hs:17: Inferred type is less polymorphic than expected Quantified type variable `b' is unified with another quantified type variable `a' In the first argument of `liftTup', namely `inc' In the definition of `tupInc': tupInc = liftTup inc which seems to be a direct consequence of the odd derived type. However, I can't think of a way to write a better one. The problem, as far as I can tell, is that there's no way in the type system to deal in type transformations, i.e. apply the conversion implied by (a -> b) to a given type a' to produce the appropriate b'. Thoughts? Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
