In article <41EE22BE.80302@imperial.ac.uk>, Keean Schupke wrote:

Do you think implicit parameters could replace top-level-things-with-identity?

I hadn't really thought of it before (and I don't use implicit parameters much).

Yes, but I think people are clamouring for top-level-things-with-identity because they don't like implicit parameters. Not me, though. I have been musing on the connection between data-types, modules, classes, and implicit parameters, and wondering if there might be some grand scheme to tie it all together. For instance, a module is very similar to class with no type parameters and all members defined. You'll notice that class members have different declared types inside and outside the class: class C a where foo :: a -> a -- inside foo :: (C a) => a -> a -- outside Perhaps one could have top-level implicit parameters (or top-level contexts in general): module (?myvar :: IORef Int) => Random where random :: IO Int -- inside random = do i <- readIORef ?myvar ... writeIORef i' return i' module (?myvar :: IORef Int) => MyMain where import Random -- random :: IO Int -- also inside mymain :: IO () mymain = do ... i <- random ... module Main where import MyMain -- mymain :: (?myvar :: IORef Int) => IO () -- outside main = do var <- newIORef 1 -- initialisers in the order you want let ?myvar = var in mymain -- Ashley Yakeley, Seattle WA

I may have got this wrong, but I think you can do named instances without any extensions, by using datatypes and fundeps: data Instance0 data Instance1 instance0 :: Instance0 instance0 = undefined instance1 :: Instance1 instance1 = undefined class Named a b | a -> b test :: a -> b -> b instance Named Instance0 Int test _ a = a + a instance Named Instance1 Float test _ a = a * a test instance0 1 test instance1 1.5 Keean. Benjamin Franksen wrote:

You will probably find this paper interesting: Wolfram Kahl and Jan Scheffczyk: "Named Instances for Haskell Type Classes", http://www.informatik.uni-bonn.de/~ralf/hw2001/4.pdf

Benjamin Franksen wrote:

Neither I nor the authors claim that their proposal is the ultimate "grand scheme", yet. Still I think there are very interesting ideas in there that should be considered for experimental implementation or further research.

But thats interesting isn't it. If one extension can be defined in terms of the other, then only one of the extensions is necessary. There is obviously some connection between functional dependancies and named instances. Maybe there is a better mechanism that both can be defined in terms of?

Perhaps one could have top-level implicit parameters (or top-level contexts in general):

module (?myvar :: IORef Int) => Random where

Hi! I suggested something very similar to this some months ago, syntax and all. Nice to see I'm not the only one thinking along this lines. http://www.mail-archive.com/haskell%40haskell.org/msg14884.html

module Main where import MyMain

-- mymain :: (?myvar :: IORef Int) => IO () -- outside

main = do var <- newIORef 1 -- initialisers in the order you want let ?myvar = var in mymain

By then I also suggest that maybe we could also bind the implicit on import, something like:

module (?par :: Parameter) => A where ...

module B where import A -- simple, ?par unbound import qualified A as Ak where ?par = k -- ?par bound to k import qualified A as Am where ?par = m -- ?par bound to m

Seemed fine as long as the parameters didn't depend on the imported modules. But on hindsight, making an import depend on valued defined in the body of the module is probably quite clumsy, unfortunately (right?). Still,

import qualified A as Ak where ?par = 1 or import qualified A as Ak where ?par = newIORef or even import C(k) import qualified A as Ak where ?par = k

Doesn't sound that bad though. J.A.

In article <200501192149.11831.benjamin.franksen@bessy.de>, Benjamin Franksen wrote:

Please note that implicit parameters -- at least as currently implemented in GHC -- have a number of severe problems. A good summary was given by Ben Rudiak-Gould in http://www.mail-archive.com/haskell%40haskell.org/msg15595.html (although in a different context):

This is mostly ambiguity due to missing type-signatures, isn't it? That's not so severe in my view. But maybe the compiler can issue a warning in such cases. -- Ashley Yakeley, Seattle WA

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