RE: Polymorphic implicit parameters
Generally speaking ALL constraints (class constraints, equality constraints,
implicit parameters) range only over monotypes.
The apparatus should extend to polymorphic types, be it's somewhat uncharted
territory. I doubt there'd be much problem in the case of implicit parameters.
In short, in principle it might be possible, but it would take a little careful
thought and I have too few careful-thought electrons available right now.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Roman Cheplyaka
| Sent: 20 March 2013 08:58
| To: glasgow-haskell-users@haskell.org
| Subject: Polymorphic implicit parameters
|
| I'm curious as to why GHC doesn't accept the following (contrived)
| module:
|
|{-# LANGUAGE ImplicitParams, RankNTypes #-}
|
|f :: (?g :: (forall a . a - a)) = a - a
|f = ?g
|
| The error message is:
|
|Illegal polymorphic or qualified type: forall a. a - a
|In the type signature for `f':
| f :: ?g :: (forall a. a - a) = a - a
|
| It's not a big deal since one can wrap the polymorphism in a newtype,
| but it's somewhat unexpected.
|
| Roman
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Polymorphic implicit parameters
That makes sense, thank you.
Roman
* Simon Peyton-Jones simo...@microsoft.com [2013-03-21 08:25:03+]
Generally speaking ALL constraints (class constraints, equality constraints,
implicit parameters) range only over monotypes.
The apparatus should extend to polymorphic types, be it's somewhat uncharted
territory. I doubt there'd be much problem in the case of implicit
parameters.
In short, in principle it might be possible, but it would take a little
careful thought and I have too few careful-thought electrons available right
now.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Roman Cheplyaka
| Sent: 20 March 2013 08:58
| To: glasgow-haskell-users@haskell.org
| Subject: Polymorphic implicit parameters
|
| I'm curious as to why GHC doesn't accept the following (contrived)
| module:
|
|{-# LANGUAGE ImplicitParams, RankNTypes #-}
|
|f :: (?g :: (forall a . a - a)) = a - a
|f = ?g
|
| The error message is:
|
|Illegal polymorphic or qualified type: forall a. a - a
|In the type signature for `f':
| f :: ?g :: (forall a. a - a) = a - a
|
| It's not a big deal since one can wrap the polymorphism in a newtype,
| but it's somewhat unexpected.
|
| Roman
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Polymorphic implicit parameters
I'm curious as to why GHC doesn't accept the following (contrived)
module:
{-# LANGUAGE ImplicitParams, RankNTypes #-}
f :: (?g :: (forall a . a - a)) = a - a
f = ?g
The error message is:
Illegal polymorphic or qualified type: forall a. a - a
In the type signature for `f':
f :: ?g :: (forall a. a - a) = a - a
It's not a big deal since one can wrap the polymorphism in a newtype,
but it's somewhat unexpected.
Roman
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Will implicit parameters survive?
I don't have any active plans to remove implicit parameters. I think they are not heavily used, but for those that do use them they seem to be quite helpful, and (important for me) their effect on the compiler is quite localised, so they cause little trouble. Still, I'm always interested to know how much interest there is in particular features. Maybe we should do a new GHC survey! S | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Wolfgang Jeltsch | Sent: 06 February 2008 19:25 | To: glasgow-haskell-users@haskell.org | Subject: Will implicit parameters survive? | | Hello, | | what are the plans for implicit parameters? Will GHC continue to support them | or could it be that they will be removed at some time? | | I think that implicit parameters can be very useful for implementing global | variables as described in http://www.cs.chalmers.se/~rjmh/Globals.ps. | Surprisingly, the interest in implicit parameters seems to be rather low as | the GHC survey from 2005 suggests. Despite this, I’d propose that support | for implicit parameters continues. But what do the GHC developers think? | | Best wishes, | Wolfgang | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Will implicit parameters survive?
Hello, what are the plans for implicit parameters? Will GHC continue to support them or could it be that they will be removed at some time? I think that implicit parameters can be very useful for implementing global variables as described in http://www.cs.chalmers.se/~rjmh/Globals.ps. Surprisingly, the interest in implicit parameters seems to be rather low as the GHC survey from 2005 suggests. Despite this, I’d propose that support for implicit parameters continues. But what do the GHC developers think? Best wishes, Wolfgang ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Will implicit parameters survive?
Hello Wolfgang, Wednesday, February 6, 2008, 10:24:44 PM, you wrote: I think that implicit parameters can be very useful for implementing global variables as described in i everyday face the problems with global variables (that are too global, especial when you going to make your program multithreading/multiwindow/multi...) and explicit parameters which need to be passed to every serious function called. i think that implicit parameters (or at least this idea) is highly useful feature and its importance will increase as we switch to more multithreaded style of programming so, please add me to (potential) users of these feature -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1124080 ] Implicit Parameters and monomorphism
Feature Requests item #1124080, was opened at 2005-02-16 17:01 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1124080group_id=8032 Category: None Group: None Status: Open Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Implicit Parameters and monomorphism Initial Comment: http://www.haskell.org/pipermail/haskell-cafe/2005-January/008571.html Notes some oddness with recursive binding of implicit parameters. Roughly, giving a type signature to a function with implicit params causes its bindings to act recursively, despite what section 7.4.5.2 of the user's guide says. -- Comment By: Simon Marlow (simonmar) Date: 2005-03-08 10:35 Message: Logged In: YES user_id=48280 This bug is just to record the strange interaction between implicit parameters and monomorphism. [adding text of original message] Jim Apple wrote: Does anyone have examples of these? This one scares the foo out of me: * It's not even safe in general to add a signature giving the same type that the compiler would infer anyway Here's an example: len :: [a] - Int len xs = let ?accum = 0 in len' xs len' [] = ?accum len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs *Main :t len' len' :: forall a. (?accum :: Int) = [a] - Int *Main len hello 0 len :: [a] - Int len xs = let ?accum = 0 in len' xs len' :: forall a. (?accum :: Int) = [a] - Int len' [] = ?accum len' (x:xs) = let ?accum = ?accum + (1::Int) in len' xs *Main :t len' len' :: forall a. (?accum :: Int) = [a] - Int *Main len hello 5 This happens as a side effect of the way that type inference currently works on recursive binding groups. It happens with typeclass dictionaries too, but it isn't observable because they can't be rebound in a local scope. -- Ben -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1124080group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Implicit parameters:
Question regarding implicit parameters... The GHC manual says: Dynamic binding constraints behave just like other type class constraints in that they are automatically propagated. But the following code produces an error: - main = do var - newIORef (0::Int) let ?global_counter = var in f f = do a - get_unique putStr (showInt a \n) b - get_unique putStr (showInt b \n) c - get_unique putStr (showInt c \n) get_unique :: (?global_counter :: IORef Int) = IO Int get_unique = readIORef ?global_counter -- If (?global_counter :: IORef Int) were a class constraint the type signature for 'f' could be derived automatically... but we get: Unbound implicit parameter (?global_counter::IORef a) arising from use of `get_unique' at Test.hs:17:13-22 Is this a bug? Is there some reason why this is not possible? (and if it is not possible shouldn't the documentation be changed to reflect this)... Keean. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Implicit parameters:
Isn't it just the monomorphism restriction at work? This works fine: f () = do a - get_unique putStr (showInt a \n) b - get_unique putStr (showInt b \n) c - get_unique putStr (showInt c \n) get_unique :: (?global_counter :: IORef Int) = IO Int get_unique = readIORef ?global_counter J.A. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Implicit parameters:
Yes, adding -fno-monomorphism-restriction allows the example to compile. I guess I got confused by the error message, expecting it to mention the monomorphism restriction directly... I'm sure it does sometimes. Any chance of improving the error message for this? Jorge Adriano Aires wrote: Isn't it just the monomorphism restriction at work? This works fine: ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Making implicit parameters explicit
I thought about this issue a little more, and I think I see clearer now. Usually, you can reference a function in two ways: * apply f to an argument: f x * pass f as a first-class object: f A function taking an implicit parameter (let's call them IP functions for brevity) is applied to the (invisible) parameter as soon as you write its name, so we are only left with one option: * apply f to an argument: f * pass f as a first-class object: [not possible] This explains why my idea to collect controller functions in a list - Haskell doesn't offer a syntax to talk about an unapplied IP function. Can we change that? There are two possible ways: a) Let the compiler figure out whether a mention of an IP function is meant to be an application or just a reference. This approach can probably be dismissed right away because the only condition to distinguish the two variants that I can imagine is whether the caller's context contains the required implicit parameter. This, in turn, is only decidable if the current function has a type signature. We clearly cannot require a mandatory type signature for all functions using implicit parameters. b) Introduce a syntax for deferring appliation of IP functions, e.g.: * apply f to an argument: f * pass f as a first-class object: ??f If an unapplied IP function such as ??f is passed to another function, depending on how that function references it - with ?? or without -, either the implicit parameter is finally applied or its application is being deferred once again. This might have problematic implications on the type system; I'm not sure if it could handle unapplied IP functions being freely moved around. Hm. It seems to me that implicit parameters are somewhat at odds with functional programming spirit. In a way, IP functions are more like macros than like first-class functions. They also tend to blur referential transparency. They should probably be used sparingly and with care. -Stefan Stefan Reich wrote: Hi, I discovered implicit parameters today and I'm very excited about them because they allow to express certain code constructs more elegantly. However, I stumbled upon a problem. Suppose I have these definitions (the definition of Request is irrelevant): type Controller = (?req :: Request) = String controller1 :: Controller controller2 :: Controller controllerList = [controller1, controller2] GHC complains with: Unbound implicit parameter (?req :: Request) arising from use of `controller1' In the list element: controller1 In the definition of `controllerList': controllerList = [controller1, controller2] I can see why this isn't allowed; controllerList requires an implicit parameter ?req because it references functions needing this parameter. But I want it to be parameterless - it's just a static list of controller functions after all. The actual request shouldn't be supplied when selecting a controller from the list, but rather later, when invoking it. A solution is to make the parameter explicit by binding it: controllerList = [\req - let ?req = req in controller1, \req - let ?req = req in controller2] This works, but can't really be called elegant (the binding has to be repeated for every controller). So I tried to at least move the rebinding into a function: explicitRequest controller req = let ?req = req in controller controllerList = [explicitRequest controller1, explicitRequest controller2] This, however, is rejected by GHC. GHC doesn't seem to infer that explicitRequest hides the implicit parameter required by the controllers. Am I confused here or is this a bug in GHC? Thanks in advance, -Stefan -- [ADV] http://superversion.sf.net [/ADV] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Making implicit parameters explicit
On Wed, Nov 05, 2003 at 09:13:12PM +0100, Stefan Reich wrote: Hi, I discovered implicit parameters today and I'm very excited about them because they allow to express certain code constructs more elegantly. However, I stumbled upon a problem. Suppose I have these definitions (the definition of Request is irrelevant): type Controller = (?req :: Request) = String controller1 :: Controller controller2 :: Controller controllerList = [controller1, controller2] GHC complains with: Unbound implicit parameter (?req :: Request) arising from use of `controller1' In the list element: controller1 In the definition of `controllerList': controllerList = [controller1, controller2] You have just been bitten by monomorphism restriction. Write a type signature for controllerList and it should work: controllerList :: (?req :: Request) = [String] Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Making implicit parameters explicit
On Thu, Nov 06, 2003 at 10:02:26PM +0100, Tomasz Zielonka wrote: GHC complains with: Unbound implicit parameter (?req :: Request) arising from use of `controller1' In the list element: controller1 In the definition of `controllerList': controllerList = [controller1, controller2] You have just been bitten by monomorphism restriction. Write a type signature for controllerList and it should work: controllerList :: (?req :: Request) = [String] Maybe in such situation GHC could suggest that the problem can be caused by monomorphism restriction ? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
infixed implicit parameters
in the cannonical sort with implicit params, i we write something like: mySort :: (?cmp :: a - a - Ordering) = [a] - [a] mySort [] = [] mySort (x:xs) = insert x (mySort xs) where insert x [] = [x] insert x (y:ys) | ?cmp x y == GT = y : insert x ys | otherwise = x : y : ys but we cannot write for the second-to-last line: x `?cmp` y or x ?`cmp` y any chance this will be changed (my preference would be for the first one. - hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
weird (bug?) in linear implicit parameters
(guess who finally decided to learn about imp params :P)
this looks like a bug to me, but of course i may be wrong.
consider these definitions:
data BLSupply = BLSupply [Bool]
instance Splittable BLSupply where
split (BLSupply l) = (BLSupply (True:l), BLSupply (False:l))
newBL (BLSupply bl) = bl
basically we can name things by lists of bools
we name lists using this function:
number :: (%ns :: BLSupply) = [a] - [(a,[Bool])]
number [] = []
number (x:xs) = (x,n) : number xs
where n = newBL %ns
which works fine. in ghci:
*ImpParam let %ns = BLSupply [] in number hello
[('h',[False]),('e',[False,True]),('l',[False,True,True]),('l',[False,True,True,True]),('o',[False,True,True,True,True])]
Whee. now here's the wierd thing. suppose we remove the type signature
from the number function. then, in ghci:
*ImpParam :t number
forall a. (%ns :: BLSupply) = [a] - [(a, [Bool])]
*ImpParam let %ns = BLSupply [] in number hello
[('h',[]),('e',[]),('l',[]),('l',[]),('o',[])]
what gives? why did it suddenly break even though it gets the type right?
- hal
--
Hal Daume III
Computer science is no more about computers| [EMAIL PROTECTED]
than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Passing values taking implicit parameters
I'd like write a function taking values with implicit parameters.
This may not be exactly what you're after, but ..
I understand the need for implicit parameters
(sometimes when my functions seem to need A LOT of parameters,
the code looks really messy, and adding another parameter is a mess as well,
especially since it often affects unrelated functions
that have to pass down the additional parameter)
but often I use the following work-around: I define a container type
data Parameters = Parameters { foo :: .., bar :: , .. }
and then my functions just read
fun :: Parameters - ..
BEGIN wishlist:
Now, can we please have defaults in data declarations? As in
data Foo = { host :: String, port = :: Int }
Better still, can we construct default values,
using values of other components, as in
data Tree = { top :: Item , left :: Tree, ..
, size = size (left self) + .. }
This would require some means to refer to the record under construction
(e. g. `self')
The above example also shows that it should in fact be forbidden
to override the `size' component.
Perhaps it would be even better if we could define `size' later
(not inside the data declaration).
Note that some (most?) of the above is available for type *classes*,
instead of types.
Best regards,
--
-- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ --
-- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 --
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Passing values taking implicit parameters
From: Johannes Waldmann:
[reply to Mike Gunter snipped]
BEGIN wishlist:
Now, can we please have defaults in data declarations? As in
data Foo = { host :: String, port = :: Int }
Better still, can we construct default values,
using values of other components, as in
data Tree = { top :: Item , left :: Tree, ..
, size = size (left self) + .. }
This would require some means to refer to the record under construction
(e. g. `self')
The above example also shows that it should in fact be forbidden
to override the `size' component.
Perhaps it would be even better if we could define `size' later
(not inside the data declaration).
Note that some (most?) of the above is available for type *classes*,
instead of types.
I think that what you want here are 'smart constructors', i.e. functions
that create a new value but also perform other initializations.
In the Tree example above, the code could look like:
data Tree = Tree { item :: Item, ... }
tree :: Item - Tree - Tree - Tree
tree item' left' right' = Tree
{ item = item'
, left = left'
, right = right'
, size = size left' + size right' + 1
, whatever more computations you need ... }
If you define Tree and the smart constructors in a separate module and then
only export the type Tree (*not* the real constructors!), the smart constrs
and suitable accessor functions, you can guarantee that the size is always
correct.
The Foo example could be turned into something like
data Foo = Foo { host :: String, port :: Int }
defaultFoo = Foo { port = }
myFoo = defaultFoo { host = haskell.org }
yourFoo = defaultFoo { host = haskell.org, port = 80 }
HTH,
Jan de Wit
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Passing values taking implicit parameters
You don't point it out explicitly, but you are using rank-2 types here!
This is indeed a bug in 5.02, fixed in the current release 5.02.2
Simon
| -Original Message-
| From: Mike Gunter [mailto:[EMAIL PROTECTED]]
| Sent: 31 January 2002 05:36
| To: [EMAIL PROTECTED]
| Subject: Passing values taking implicit parameters
|
|
|
| I'd like write a function taking values with implicit
| parameters. I can't get this to work in a straightforward
| way in GHC 5.02 (with -fno-monomorphism-restriction.) In
| particular, if I try:
|
| wF :: ((?x :: Int) = a) - Int - a-- compiles but
| tf won't work
| wF s z = s with ?x = z
|
| f :: (?x :: Int) = Int
| f = (?x + 3)
| -- tf :: Int-- If
| uncommented GHC fails because can't deduce context (?x::Int)
| -- tf :: (?x :: Int) = Int -- Type GHC assigns to tf
| tf = wF f 8 -- Trying to evaluate
| gives: Unbound implicit parameter (?x :: Int)
|
| Trying to evaluate tf gives: Unbound implicit parameter (?x :: Int)
|
|
| On the other hand, if the passed value has another class in
| its context, things work as expected:
|
| wF' :: Integral a = (forall a . (Integral a, ?x :: Int) =
| a) - Int - a
| wF' s z = s with ?x = z
| f' :: (Integral a, ?x :: Int) = a
| f' = fromIntegral (?x + 3)
| tf' = wF' f' 8 -- GHCi gives me 11, as expected
|
|
| At the cost of having to wrap each value with an extra call
| (to dummy here), I seem to be able to get the
| desired effect for general types with this code:
|
| class DummyCl c where dummy :: a - c a
| newtype Dummy a = Dummy { unDummy :: a }
| instance DummyCl Dummy where dummy = Dummy
|
| wF'' :: (forall c . (DummyCl c, ?x :: Int) = c a) - Int - a
| wF'' s z = unDummy (s with ?x = z)
|
| -- f'' :: (DummyCl c, ?x :: Int) = c Int -- Type
| signature unnecessary
| f'' = dummy f
|
| tf''= wF'' f'' 100 -- evaluates
|
| fHO = dummy (?x +)
| tfHO= (wF'' fHO 31) 22 -- evaluates
|
| tf''' = wF'' (dummy f) 1000 -- gets:
| Unbound implicit parameter (?x :: Int)
| tf4 = wF'' (dummy (?x + 7)) 300 -- evaluates
| tfHO' = (wF'' (dummy (show . (?x +))) 50) 63 -- evaluates
|
|
|
| So my questions are: Is there a straightforward way to pass
| values taking implicit parameters in GHC? And, if
| not, is there a better workaround than my dummy code above?
|
| thanks,
| mike
|
|
| ___
| Glasgow-haskell-users mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Passing values taking implicit parameters / smart constructors
Jan de Wit writes: I think that what you want here are 'smart constructors', i.e. functions that create a new value but also perform other initializations. .. If you define Tree and the smart constructors in a separate module and then only export the type Tree (*not* the real constructors!), OK, I see how this would achieve what I want. But then I cannot use record sytax (updates, pattern matching) outside the defining module. This would essentially mean Haskell-1.0 or thereabouts. Perhaps I need `views' ? OTOH my suggestion does not seem terribly difficult to implement (to me - being *not* an Haskell implementor, of course :-) Best regards, -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 -- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Passing values taking implicit parameters / smart constructors
I think that what you want here are 'smart constructors', i.e. functions
that create a new value but also perform other initializations.
..
If you define Tree and the smart constructors in a separate module and then
only export the type Tree (*not* the real constructors!),
But then I cannot use record sytax (updates, pattern matching)
outside the defining module.
Actually, you *can* use named field syntax for updates (provided the
field names are exported from the defining module).
e.g.
f tree = tree { top=..., left=... }
although it is true that you then lose the `smart constructor'
property that ensures (for instance) that the size field is calculated
automatically.
Pattern matching does indeed remain impossible (because the constructor
is not exported). However, you could use the field names as selectors,
which is a little more cumbersome, but not too bad.
e.g.
f tree =
where t = top tree
l = left tree
s = size tree
instead of
f (Tree {top=t, left=l, size=s}) =
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Passing values taking implicit parameters
I'd like write a function taking values with implicit parameters.
This may not be exactly what you're after, but ..
I understand the need for implicit parameters
(sometimes when my functions seem to need A LOT of parameters,
the code looks really messy, and adding another parameter is a mess as
well, especially since it often affects unrelated functions
that have to pass down the additional parameter)
but often I use the following work-around: I define a container type
data Parameters = Parameters { foo :: .., bar :: , .. }
and then my functions just read
fun :: Parameters - ..
I using that same strategy, but instead I'm passing that Parameters datatype
as an implicit parameter. Like you said, sometimes the code gets really
messy, many times you also have to add Parameters as a return value...
fun :: Parameters - ... - (ReturnValue,Parameters)
And sometimes I rather define more than one container because the Parameters
have completely different purposes (and that would make the code even
uglier).
BEGIN wishlist:
snip
My whilist for records. 'Records' provide projection functions, but IMO that
is not enough, it would be really handy to have some 'update' and 'apply
field' functions provided automaticly for each field.
I always find myself having to write this functions by hand for each field,
because I just can't do without them, and if you have 2 records with 6 fields
each, that means 2*2*6 functions = 24 functions... wasted time, more
oputunities to make dumb mistakes defining similar functions, tiresome to add
and delete record fields... you get the picture.
I think it i spretty ovious why you need them, anyway the two main reasons
are,
1.)
Imagine you have:
data Somedata = C{c1, c2, c3, c4, c5, c6 :: Int}
Every time you want to apply some function to a field you'll have to write
something like:
c{c1=f (c1 c)} -- now how ugly is this :-)
2.)
I keep finding myself defining functions like
someChange::((Int-Int)-Somedata-Somedata)-...-Somedata
The idea is to recieve a 'apply field function', a couple of other
parameters, and update the field defined by the apply field function acording
to those other parameters. Without the 'apply field' functions, you'd have to
write the same code for each of the fields.
J.A.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Passing values taking implicit parameters
BEGIN wishlist: snip My whilist for records. 'Records' provide projection functions, but IMO that is not enough, it would be really handy to have some 'update' and 'apply field' functions provided automaticly for each field. I always find myself having to write this functions by hand for each field, because I just can't do without them, and if you have 2 records with 6 fields each, that means 2*2*6 functions = 24 functions... wasted time, more oputunities to make dumb mistakes defining similar functions, tiresome to add and delete record fields... you get the picture. Forgot to mention that a particular case in which these functions are extremely useful, is when using implicit parameters as John Huges describes in http://www.md.chalmers.se/~rjmh/Combinators/MonadTransformers.hs If you follow his sugestion and use group parameters in a record, and then pass around an STRef to that record as an implicit parameter, then in order to change the fields of the record it's nice to be able to use modifySTRef. Not having 'update/apply field' functions for records, and having to (either not provide a signature or) define the whole context makes the whole experience a lot more painful than it actually has to be... J.A. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Passing values taking implicit parameters
Forgot to mention that a particular case in which these functions are extremely useful, is when using implicit parameters as John Huges describes in http://www.md.chalmers.se/~rjmh/Combinators/MonadTransformers.hs opsss wrong link, correct one is: http://www.md.chalmers.se/~rjmh/Globals.ps J.A. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Passing values taking implicit parameters
I'd like write a function taking values with implicit parameters. I can't get this to
work in a
straightforward way in GHC 5.02 (with -fno-monomorphism-restriction.) In particular,
if I try:
wF :: ((?x :: Int) = a) - Int - a -- compiles but tf won't work
wF s z = s with ?x = z
f :: (?x :: Int) = Int
f = (?x + 3)
-- tf :: Int -- If uncommented GHC fails because can't
deduce context (?x::Int)
-- tf :: (?x :: Int) = Int -- Type GHC assigns to tf
tf = wF f 8 -- Trying to evaluate gives: Unbound implicit
parameter (?x :: Int)
Trying to evaluate tf gives: Unbound implicit parameter (?x :: Int)
On the other hand, if the passed value has another class in its context, things work
as expected:
wF' :: Integral a = (forall a . (Integral a, ?x :: Int) = a) - Int - a
wF' s z = s with ?x = z
f' :: (Integral a, ?x :: Int) = a
f' = fromIntegral (?x + 3)
tf' = wF' f' 8-- GHCi gives me 11, as expected
At the cost of having to wrap each value with an extra call (to dummy here), I seem
to be able to get the
desired effect for general types with this code:
class DummyCl c where dummy :: a - c a
newtype Dummy a = Dummy { unDummy :: a }
instance DummyCl Dummywhere dummy = Dummy
wF'' :: (forall c . (DummyCl c, ?x :: Int) = c a) - Int - a
wF'' s z = unDummy (s with ?x = z)
-- f'' :: (DummyCl c, ?x :: Int) = c Int -- Type signature unnecessary
f'' = dummy f
tf'' = wF'' f'' 100 -- evaluates
fHO = dummy (?x +)
tfHO = (wF'' fHO 31) 22 -- evaluates
tf''' = wF'' (dummy f) 1000 -- gets: Unbound implicit parameter
(?x :: Int)
tf4 = wF'' (dummy (?x + 7)) 300 -- evaluates
tfHO' = (wF'' (dummy (show . (?x +))) 50) 63 -- evaluates
So my questions are: Is there a straightforward way to pass values taking implicit
parameters in GHC? And, if
not, is there a better workaround than my dummy code above?
thanks,
mike
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
