Re: Hugs plugin, Haskell Browser
Vim can produce HTML from any source code it has highlighting rules for, which includes Haskell. Dunno about the browser plugin, though. Abe On Wed, 13 Mar 2002, Robert Giegerich wrote: > Teachers in Haskell, > > I often use Haskell demos in teaching algorithms. The problem is that this > does not integrate well with the rest of the material, e.g. lecture > notes or slides in PDF or HTML. I'd like to integrate explanations and > demos and explorative changes to algorithms. This needs better support. > > Is there something like a Hugs plugin for Netscape? > > Is there something like a Haskell source browser producing XML or HTML? > > Thanks for all hints > > Robert Giegerich > > ___ > Haskell mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
typeclass relations
I have two typeclasses, Foo and Bar, with some instances, defined as such: module Test where class Foo a where foo :: a -> String class Bar a where bar :: a -> String instance Foo Int where foo = show instance Bar Int where bar a = (show a) ++ " bar!" instance Foo Char where foo = show instance Foo a => Bar a where bar = foo If I try to compile this via GHC it complains loudly unless I feed it "-fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances", in which case it seems to do the right thing. However, the warnings (and the names of the flags - "undecidable instances" doesn't sound good) make me nervous, and confused. Why is there a problem with saying "every instance of Foo is also an instance of Bar, and here's how"? Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
type fine until you try to use it
In a project I'm working on, one data type I've defined is this:
data FilterIS = FilterIS { source :: (InputStream s) => s, filter ::
Filter }
which, to me, just means it holds any instance of the InputStream class
and a Filter value. Sure, says ghci, fine by me. However, if I try to do
anything with that datatype, even something as simple as
newFilterIS = FilterIS
I get the following error, or something very like it:
Stream.hs:96:
Inferred type is less polymorphic than expected
Quantified type variable `s' escapes
Expected type: s -> t
Inferred type: (forall s1. (InputStream s1) => s1)
-> (forall fs. (InputStream fs) => fs -> IO Word8)
-> FilterIS
In the definition of `newFilterIS': FilterIS
I've gotten used to having to spend a while figuring out what error
messages mean, but it bugs me that there seems to be some problem with the
type that's "brought out" by just making a synonym for the constructor. I
know there's nothing wrong with the line where I define a synonym; there's
practically nothing there to *be* wrong, so the problem has to be in the
type... and yet the compiler didn't catch it until I added that synonym
line. What's up?
Abe
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Conway's Life
I'm implementing Conway's Life in Haskell; my basic implementation is attached. Does anyone have suggestions for optimizations (or alternative representations)? It's interesting to note that the difference between this with no ghc optimization, -O, and -O2 is pretty striking; on my computer, it's about seven seconds, two seconds, and one second runtime, respectively. Abe module Main where import Data.Array.IArray import Data.Array.Unboxed import Data.Ix import System.Random type Grid = UArray (Int, Int) Int randomGrid :: (RandomGen g) => g -> Int -> Grid randomGrid g s = listArray b $ map (\x -> if x then 1 else 0) $ take (rangeSize b) $ randoms g where b = ((0,0),(s-1,s-1)) getCell :: Grid -> (Int, Int) -> Int getCell g c@(x,y) = if (x < xmin) || (x > xmax) || (y < ymin) || (y >= ymax) then 0 else g ! c where ((xmin, ymin), (xmax, ymax)) = bounds g update :: Grid -> Grid update g = array (bounds g) $ map aux $ assocs g where aux (c@(x,y),e) = let around = map (getCell g) $ filter (/= (x,y)) $ range ((x-1,y-1),(x+1,y+1)) in (c,rule (sum around) e) rule 2 e = e rule 3 e = 1 rule _ _ = 0 printGrid :: Grid -> IO () printGrid g = do let ((xmin, ymin), (xmax, ymax)) = bounds g mapM_ aux $ map (\x -> range ((x,ymin),(x,ymax))) [xmin..xmax] putStrLn "" where aux ixs = do mapM_ (putStr . show) $ map (g!) ixs putStrLn "" main :: IO () main = printGrid $ (iterate update (randomGrid (mkStdGen 0) 50)) !! 100
Re: Conway's Life
I'll answer my own question; I've got a much better implementation, along with an HOpenGL-based frontend, at "http://ofb.net/~abe/hlife/hlife-0.1.tar.gz";. It uses a FiniteMap of 5x5 UArrays that are created and destroyed as needed; this gives it a good balance of size (the grid is only bounded by the max values of an Int) and speed (my test program runs 100 generations in about three seconds). Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
C++ class structure mapping
I'd like to make a haskell binding for a C++ library. Most of the tools out there seem oriented towards c bindings, so it looks like I'll be writing the FFI code generator myself. While I'm at it I figure I might as well just make a general C++ binding tool. I've been thinking about this, and I'd like some feedback on the ideas I've had. First - it seems natural to use template haskell to do the code generation. That way, the library could either write the generated code to a file using the pretty-printers, or just be spliced in directly. Now comes the question of how to map a C++ class hierarchy into haskell. It seems natural to try to map C++ classes into haskell typeclasses; however, there are a few issues involved with that. A separate datatype would have to be made for each C++ class to allow it to actually be instantiated, which isn't too bad. However, to allow haskell instances of the typeclass to call the old behavior it seems that there'd have to be duplicate functions of the ones in the typeclass, i.e. class A a where foo :: a -> IO () foo_cpp :: (A a) => a -> IO () That seems to be needed to allow haskell instances to call the old implementation in their definition, but it rubs me the wrong way. Can anyone suggest an alternate method, or suggest a different direction entirely? Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Announce: wxHaskell, a portable GUI library.
Given your impending vacation, this might not be the best time to mention it, but... I can't seem to download any files for wxHaskell from sourceforge; this is probably a misconfiguration on their part, but I thought it best to let you know as well. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
varying function by typeclass
I have a function that takes, among other things, a (wrapped) generic type, i.e. "forall a. a". My function can possible produce an error message; is there any way to set up the function so that if the type is an instance of Show include the value along with the error message? I can't think of any, and this is honestly the first time I've been directly frustrated by Haskell's typesystem, so it's bugging me more than it might otherwise. Any suggestions? Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
haskell bindings for cairo
I've hacked together a haskell binding for the cairo vector graphics library (http://www.cairographics.org). It's still got much that needs improvement, but it's at the usable stage. A tarball is available at http://ofb.net/~abe/hscairo-0.1.tar.bz2 ; documentation and build instructions are included. Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
hscairo 0.3
The haskell bindings for cairo have reached 0.3, which is enough of a milestone to warrant this post, I think. Main improvements include: * better (i.e. more Haskellish) wrappers for the Matrix functions * better status handling - status is now checked automatically, and errors reported properly. * Attributes are parameterized by object type as well as value type. What this means is that things other than the implicit Cairo object can have Attributes; for example, Matrix objects have an "affine" Attribute. * all current cairo functions wrapped. A few had been left out of the prior version due to implementation difficulty. * a better backend. Specifically, a running hscairo program no longer uses up all CPU time. The new version is available at http://ofb.net/~abe/hscairo-0.3.tar.bz2. Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: attribute 0.1
Attribute is a library for storing and retrieving named values from
haskell datatypes in arbitrary monads.
Many of the haskell GUI libraries have implemented something similar; in
one of my current projects, I discovered that such a thing would be
useful. However, I didn't want to tie it to my specific use, the result
of which is this library. The README included with the source is
hopefully enough documentation to get started, the text of which is
included at the end of this email.
A tarball is available at "http://abe.egnor.name/attribute-0.1.tar.bz2";.
Source can also be obtained via arch:
tla register-archive http://ofb.net/~abe/archive/2003
tla get [EMAIL PROTECTED]/attribute--main
=== README ===
This is attribute, monadic attributes for haskell datatypes. See COPYRIGHT
for copying information.
Building:
edit the Makefile for the install path
make
make install (as root)
The only dependency is a recent version of ghc (>=6).
Use:
Abstractly, an attribute represents a value that can be retrieved from or
stored into a specific type in a specific monad; an attribute can either
be readable, writable, or both, represented by the types Read, Write, and
ReadWrite.
A note on naming conventions: I've used general words (such as Read,
Write,
set, get, etc.) for most functions; this does not follow Haskell
convention,
but does follow the ideas at
"http://haskell.org/hawiki/UsingQualifiedNames";,
which makes far more sense to me. If you can't live without prefixes,
qualify the import.
Example: "ReadWrite Int String IO" represents a String that can be both
extracted from and stored into an Int in the IO monad (although such a
property is unlikely to be useful). A more useful attribute might be
something like:
contents :: Read FilePath String IO
which would represent the contents of a file, probably read in via
getContents or some such.
Attributes can be constructed directly from setter or getter functions:
data (Monad m) => Read o d m = Read (o -> m d)
data (Monad m) => Write o d m = Write (o -> d -> m ())
data (Monad m) => ReadWrite o d m = ReadWrite (o -> m d) (o -> d -> m ())
A few convenience functions are provided for constructing attributes:
attrMRef :: (MRef r m) => (a -> b -> b)
-> (b -> a)
-> ReadWrite (r b) a m
attrMRefT :: String -> ExpQ
attrMRef takes a pure mutator and extractor, and creates an attribute
that applies those functions to a monadic reference. Instances for MRef
are provided for both IORef and STRef.
attrMRefT simplifies a common case, where you have a pure datatype
defined with named records and you'd like to make attributes for some
of the records:
data Foo = Foo { fooBar :: Int, fooBaz :: String }
bar :: (MRef r m) => ReadWrite (r Foo) Int m
bar = $(attrMRefT "Main:fooBar")
baz :: (MRef r m) => ReadWrite (r Foo) String m
baz = $(attrMRefT "Main:fooBaz")
The String passed to attrMRefT is the name of one of the records;
the current implementation of template haskell requires that it be
prefixed with the name of the module in which it's defined.
attributes are bound to values by creating a Property; the constructors
for property are ":=", ":~", "::=", and "::~", which are pure set, pure
mutate, monadic set, and monadic mutate respectively. To reuse the Foo
example from above:
test :: IO (Int, String)
test = do ref <- newMRef $ Foo { fooBar = 3, fooBaz = "hello" }
set ref [ bar := 5, baz :~ (++" world") ]
bar' <- get ref bar
baz' <- get ref baz
return (bar', baz')
will return (5, "hello world"). Note that because attributes created
with
attrMRef or attrMRefT are qualified by monad type, this example could
be changed to use the ST monad simply by changing the type signature.
Two functions are provided for manipulating attributes: "set" and "get".
set :: (Monad m) => o -> [Property o m] -> m ()
get :: (Monad m, CanRead a) => o -> a o d m -> m d
The "CanRead" class constraint simply enforces the readability of the
particular attribute; both Read and ReadWrite are instances. There is a
similarly used "CanWrite" class:
class CanRead a where
aGet :: (Monad m) => (a o d m) -> (o -> m d)
class CanWrite a where
aSet :: (Monad m) => (a o d m) -> (o -> d -> m ())
While you are certainly free to define new instances of the classes, I
have
yet to find a use case where the simple Read/Write/ReadWrite types do not
suffice.
See the files in src/test/ for examples.
Have fun!
Abe Egnor ([EMAIL PROTECTED])
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
ANNOLUNCE: attribute 0.2
I apologize for the frequency, but based on initial feedback I made some interface-breaking changes and thought it wise to release. The major changes are: * use functions instead of a datatype for Property construction. From the user's point of view, this just means the colon goes at the end instead of the beginning, i.e. (=:) instead of (:=). * split non-haskell98 functions (MRef, attrMRef[T]) off into their own module - Data.Attribute.Util. Data.Attribute itself is now pure Haskell 98. * added an MRef instance for lazy STRefs. The new tarball is at "http://abe.egnor.name/attribute-0.2.tar.bz2";. Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Implementation of while loop
While "while" can be implemented in haskell, I would strongly suggest you look at using the many higher-order functions available (foldl/foldr, map, filter, etc.) - they're much more in line with the spirit of the language, and will lend themselves to much clearer expressions once you get the hang of them. What sort of thing do you want to do in your while loop? Is it a pure processing function, or an IO-related one? Abe [EMAIL PROTECTED] writes: >Hi,does any one knows how to implement while-do loop or nested while-do >loop? >I'm in a situation that I need to implement nested while do loop with >some if- >then-else condition in my code,but I have no idea about it.Thanks. > >Ray > > > > >This mail sent through www.mywaterloo.ca >___ >Haskell mailing list >[EMAIL PROTECTED] >http://www.haskell.org/mailman/listinfo/haskell > ___ 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
Re: lifting functions to tuples?
That only works for type constructors (or similar encapsulation functions), but not for any sort of a -> b functions, i.e. (+1). >How about this: > >liftTup :: (forall a. a -> f a) -> (x, y) -> (f x, f y) >liftTup f (x,y) = (f x, f y) > >Or ghc can infer the type if you write it like this: > >liftTup (f::forall a.a ->f a) (x::x,y::y) = (f x::f x, f y::f y) > >or simply: > >liftTup (f::forall a.a ->f a) (x,y) = (f x, f y) > > >It works too! (ghci -fglasgow-exts) > >> liftTup Just (1, 'c') >(Just 1,Just 'c') > >Duncan > >___ >Haskell mailing list >[EMAIL PROTECTED] >http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
pattern-matching extension?
I've occasionally wanted some sort of equivalent of an instanceOf function in haskell, i.e. one that would let me define a function that could dispatch on the type of its argument as well as the value. One option I've seen for this is "http://okmij.org/ftp/Haskell/class-based-dispatch.lhs";, but that unfortunately has the downside of requiring you to write both a constructor for PACK and an instance of Packable for each type you'd like to dispatch on. The thought occurred to me that it is (intuitively) natural to do this via extending the pattern-matching facility to include types as well as literal values, i.e. something like: f :: a -> String f (a :: Int) = "got an int, incremented: "++(show (a+1)) f (a :: Show q => q) = "got a showable: "++(show a) f _ = "got something else" This has a couple of nice features - it's a simple extension of the syntax, and acts as a sort of type-safe typecast. However, I have zero knowledge of how hard it would be to implement this, and there may be theoretical difficulties I haven't seen. Thoughts? Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] new "primitive" instances of Data?
I'm in the process of trying to write generic binary serialization code using the "Scrap Your Boilerplate" method. One bump I've run into is that there are no instances of Data provided for the extended set of numeric types (the stuff in Data.Word, etc.) and it seems to be impossible to hand-write an instance that behaves similarly to the instances for other primitive types. Any ideas for ways around this? ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] 3d or Nd geometry library?
I was somewhat surprised to see that there's only one geometry library on the haskell libraries page, and further dismayed to find that it for the most part only does 2d. It seems like haskell should be a natural fit for higher-order geometric libraries - has anyone heard of such? Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Per-type function namespaces (was: Data.Set whishes)
I think that this is a problem that can be solved with a simple convention change, rather than a language extension - instead of appending type names, I think it would be much better if modules simply used the short, convenient, common names and expected the user to import them qualified where overlap is a problem - in short, do exactly what DData does. It's slightly more verbose than OO-style: "Map.add map key value" instead of "map.add(key, value);" but I don't think that "what OO does" is a good language design target. Another random thought: what you describe sounds awfully similar to typeclasses, just with a single function in each typeclass. Abe [EMAIL PROTECTED] writes: >I've had an idea stewing in my head to do with per-type function >namespaces, that the current module namespace discussion reminded me >about. The problem is that there is a limited namespace for functions, >so that if you define a new data type, it is unwise to call functions >which work on that data type a very generic name such as 'add'. An >example of this is Data.FiniteMap and Data.Set: both data types define >a function to add things to their respective data types. > >addToFM :: Ord key => FiniteMap key elt -> key -> elt -> FiniteMap key >elt >addToSet :: Ord a => Set a -> a -> Set a > >So at the moment, many Haskellers will append the type name to the >function to indicate that it only works on that particular data type. >In this respect, Haskell is at a disadvantage vs most object-oriented >languages, because in them, you can write "x.add", and the type system >will perform "object-oriented polymorphism" for you and call the >correct add method, no matter if x is a FiniteMap or a Set. Writing >"addToFM fm ..." or "addToSet set ..." is surely a lot more >inconvenient than writing "fm.add" or "set.add", no? > >The idea that I've been throwing around is to be able to define a >separate namespace for each type; a function can either belong in a >"global" (default) namespace, or belong in a particular type's >namespace. So, in the above example, instead of writing "addToFM fm >...", we could instead associate an 'add' function with the FiniteMap >type, so we could write "fm.add ..." instead. Provided that fm's type >is monomorphic, it should be possible to call the 'correct' add >function; if we defined another 'add' function that's associated with >the Set type, that will only get called if the 'x' in "x.add" is of >type :: Set. So, like OO languages which inherently give separate >namespaces to their different objects, here we give separate namespaces >to different (monomorphic) types. In this case, if one simply writes >"add" instead of "x.add", the compiler throws an error, because there >is no 'add' function defined in the default namespace; add is only >defined when a programmer writes "x.add" where x :: FiniteMap or x :: >Set[1]. > >There are a number of means by which the x in x.add can be communicated >to the actual function: it's similar to the hidden 'self' or 'this' >variable that's present when you invoke a method on an object in OO. >Perhaps x is passed to the function as its first parameter, or maybe it >could be its last parameter, or even an arbitrary parameter (where the >parameter it's passed as could be defined in the type signature of the >function). Perhaps 'self' or 'this' could be an implicit parameter. >Any one of them will work just fine, I think. > >However, this scheme is only for functions which have such a 'primary' >data type to be associated with, such as FiniteMap or Set. For >functions which are truly polymorphic (such as ==), you still leave >them in the default namespace. Perhaps it's sensible to even make it a >requirement that functions in the default namespace must be >polymorphic: if they are monomorphic, they are associated with >operating on a specific data type, so they should belong in a >type-specific namespace. You then still guarantee that such >commonly-used polymorphic functions cannot be 'hijacked' to have stupid >type signatures; i.e. == is always guaranteed to be :: Eq a -> a -> >Bool. > >Anyhow, feedback is more than welcome; I would certainly welcome this >addition if it's feasible. It feels inferior to be typing in 'addToFM >foo' all the time when our OO brethren type the simpler and more >succinct 'foo.add', especially given that Haskell's type system is far >more powerful! > >1. I haven't thought hard enough about whether it would be possible to >have the same function name in both the 'default' namespace as well as >in per-type namespaces, but my gut feeling says it should be OK. > > >-- >% Andre Pang : trust.in.love.to.save >___ >Haskell mailing list >[EMAIL PROTECTED] >http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] concurrent haskell, higher-order types and parameterizing by typeclass
I have a system composed of threads communicating via channels; I'd like the communicated types to be instances of a particular typeclass (say Show for purposes of discussion), but not all the same type. Since Chan is paramterized by the communicated datatype, the best way I've found to do this is via a wrapper type: data Showable = forall a. Show a => Showable a writer :: Chan Showable -> IO () writer ch = mapM_ (writeChan ch) [Showable 42, Showable pi, Showable "hello", Showable 'c'] printer :: Chan Showable -> IO () printer ch = getChanContents ch >>= mapM_ (\(Showable a) -> print a) However, this solution requires a new wrapper datatype (or at least a new constructor) to be defined for every typeclass to be used in Chan-based communication; furthermore, all of the datatypes will be identical except for the name of the typeclass. It seems like I should be able to create a type that's parameterized by typeclass, i.e. something like: data Wrapper c = forall a. c a => Wrapper a writer :: Chan (Wrapper Show) -> IO () ... Alternatively, are there any ideas as to how I could communicate heterogeneous instances of a given typeclass in a typesafe manner (i.e. without escaping to Data.Dynamic)? Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Initialisation without unsafePerformIO
I don't see how this technique can be at all safe:
instance ReflectStorable s => Reflect (Stable s a) a where
reflect = unsafePerformIO $
do a <- deRefStablePtr p
freeStablePtr p
return (const a)
where p = reflectStorable (undefined :: s p)
reify :: a -> (forall s. Reflect s a => s -> w) -> w
reify (a :: a) k = unsafePerformIO $
do p <- newStablePtr a
reifyStorable p (\(_ :: s p) -> k' (undefined :: Stable s a))
where k' (s :: s) = (reflect :: s -> a) `seq` return (k s)
The above means that a StablePtr will be allocated once per reify and
destroyed once per reflect; I don't see how the code can guarantee
that there will be only one reflect per reify. In fact, it seems
quite likely that there will be far more reflects than reifys.
On Fri, 4 Jun 2004 03:35:25 -0700, John Meacham <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jun 04, 2004 at 12:35:14AM -0700, Ashley Yakeley wrote:
> > In article <[EMAIL PROTECTED]>,
> > John Meacham <[EMAIL PROTECTED]> wrote:
> >
> > > I am a fan of allowing top level declarations of the form:
> > >
> > > foo <- newIORef "foo"
> > >
> > > which would behave as an initializer, with the semantics being that it
> > > be evaluated at most once before foos first use. (so it could be
> > > implemented via unsafePerformIO or as an init section run before main).
> > >
> > > The
> > > {-# NOINLINE foo #-}
> > > foo = unsafePeformIO $ newIORef "foo"
> > >
> > > idiom is so common and useful, it should have some compiler support. It
> > > is 'clean' too, since all we are doing is extending the "world" with new
> > > state, but in a much cleaner/safer way then writing to a file or environment
> > > variable or other methods of storing state in the world.
> >
> > Clean it is not:
> >
> > foo :: a
> > foo <- newIORef undefined
> >
> > writeChar :: Int -> IO ()
> > writeChar x = writeIORef foo x
> >
> > readString :: IO String
> > readString = readIORef foo
> >
> > cast :: Char -> IO String
> > cast c = (writeChar c) >> readString
>
> Yeah, such an extension would need to ensure initializers are monomorphic. another
> advantage of a special syntax rather than unsafePerformIO.
>
>
> John
>
> --
> John Meacham - ârepetae.netâjohnâ
> ___
> Haskell mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/haskell
>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] generalised algebraic data types, existential types, and phantom types
I briefly skimmed the paper mentioned in a recent mailing on the ghc-users list that describes generalised algebraic data types (http://research.microsoft.com/Users/simonpj/papers/gadt/index.htm); my reaction can be summed up as "nifty!". I was curious to see if I could implement anything similar in current haskell, and ended up with the attached code. The main point of interest for me is the combination of phantom types and existential types; I'd never had the need to combine the two before. Is there any closer approximation possible? My code is close, but the type-safety isn't checked by the compiler (although it should be safe, if only the smart constructors are used), and it has that extra "Typeable" constraint. Abe data.hs Description: Binary data ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Why is getArgs in the IO monad?
It's not a constant; see, for example, System.Environment.withArgs (http://www.haskell.org/ghc/docs/latest/html/libraries/base/System.Environment.html#v%3AwithArgs). Abe On Mon, 17 Jan 2005 16:23:17 -0500, Jim Apple <[EMAIL PROTECTED]> wrote: > See subject. It seems that it would be constant through execution, and > so could be just [String]. > > Jim > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] type question revisited
Your first attempt didn't typecheck simply because > in return () means that the return value of the function is monadic, but you did not declare as such. In your second version, the type of shf is *not* a rank-2 type; it's exactly the same type as shw. This can be expressed (with ghc extensions) as > foo :: (a -> String) -> [a] -> [String] > foo (shw :: t) x = > let shf :: t > shf o = shw o > in map shf x or equivalently > foo :: (a -> String) -> [a] -> [String] > foo (shw :: t -> String) x = > let shf :: t -> String > shf o = shw o > in map shf x The essential aspect is that the 'a' from the type signature is *not* in scope for the let-bound type signature; you have to bring the appropriate variable 't' in by using an in-line type signature for 'shw'. Abe On 6/3/05, mv <[EMAIL PROTECTED]> wrote: > I answered my own question only to raise another - what I wanted to do is > this > > > > foo :: (a -> String) -> [a] -> [String] > > foo shw x = > > let > > shf :: ( forall a . a ) -> String > > shf o = shw o > > > > in map shf x > > the type of shf is a rank 2 type - but how do you map it ? as the above > gives > thise error in hugs: > > Use of shf requires at least 1 argument > > > > > > Virus checked by G DATA AntiVirusKit > Version: AVK 12.0.37 from 06.12.2002 > Virus news: www.antiviruslab.com > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
