unliftM
Is there a standard construct for something of this ilk: unliftM :: Monad m a -> a In this case, I need to construct a localised stateful computation comp :: Int -> Int comp n = unliftM (do x <- ... return x) -- Julian Assange|If you want to build a ship, don't drum up people |together to collect wood or assign them tasks and [EMAIL PROTECTED] |work, but rather teach them to long for the endless [EMAIL PROTECTED] |immensity of the sea. -- Antoine de Saint Exupery ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: A GUI toolkit looking for a friend
Simon Peyton-Jones wrote: > > I wrote: > > > > What's wrong with "ambitious" high-level systems. [snip] > > Nothing's wrong with ambitious systems! But there's an ambition/pragmatism > tradeoff. If there was a consensus about the Right Way to build an > ambitious (more declarative) system then we could all go for it. > But there isn't. So let the experiments flourish, but meanwhile it > would be of practical use to many people to have a stable, portable > (if less sexy) platform on which to build applications. OK, but is not FranTk a stable, portable, unsexy platform on which to build applications "meanwhile"? I heard some rumor that it was "dead", but it seems very much alive and kicking when I run the demo under Hugs. Moreover, Meurige Sage says that, > FranTk currently lives on top of Tcl-Tk. (...) However, it has been > designed to be as Tcl-Tk independent as possible. This means it can > be ported to other GUI systems. So we have this GUI interface that is declarative as well as, in your own words, "rather sophisticated". And it is not just platform independent but independent of GUI systems too. Why ditch it in favor of some in-the-middle library that will need plenty of work just to get going? I must be missing something here. If someone thinks FranTk is not The Right Way, then do tell me what is. -- Tore ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re:Inferring from context declarations
Marcin 'Qrczak' Kowalczyk wrote: [snip] > It would require to keep bodies of all polymorphic functions in > a form allowing instantiation in different modules. For example > ghc already requires too much memory (even a hundred MB for large > modules), and it leads to code bloat, so in the current state of > technology it's not advisable to always compile out polymorphism. [snip] I'll bet Marcin a pint (if he wants) that in 10 years time you will need 1GB of virtual memory just to run the latest version of Windows out of the box. How Microsoft will manage to use all that memory, I don't know (will we have irritating pop-up windows showing videos of wizards telling us how to save Explorer settings?), but then 10 years ago I would have found it difficult to conceive of a desktop computer needing 64MB. The current GHC separate compilation strategy probably is advisable at the current time, given available constraints, but I don't think we should make language decisions on that basis. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Inferring from context declarations
Lennart Augustsson wrote: > > Incidentally, this has nothing to do with allowing polymorphic recursion > on functions in Haskell. It could be done earlier too, but then it had > to be encoded using a class and instance declaration. I would argue that methods are in fact polymorphically recursive functions. Wasn't this one motivation to allow general polymorphic recursion in Haskell - that it is in the language anyway? - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] "Computer games don't affect kids. If Pac Man affected us as kids, we would all be running around in darkened rooms, munching pills, and listening to repetitive music." ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Inferring from context declarations
Thomas Johnsson wrote: > Lennart Augustsson writes: > > > Simon Peyton Jones' comments about dictionary passing are a red herring, > > > since they assume a particular form of compiler. Various (MLj, MLton) > > > ML compilers already inline out all polymorphism. > > ML is a language where you can do this. In Haskell it is not always > > possible to eliminate all polymorphism (due to polymorphic recursion). > > I'd like to see an example of this! Sure, here's one where you can't bound the number of dictionaries: main = interact $ show . f 'a' . read f :: (Eq a) => a -> Integer -> Bool f x 0 = x == x f x n = f [x] (n-1) If the input is 0 the comparison is of Char, if the input is 1 the comparison is of [Char], if the input is 2 the comparison is of [[Char]], etc. Incidentally, this has nothing to do with allowing polymorphic recursion on functions in Haskell. It could be done earlier too, but then it had to be encoded using a class and instance declaration. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: putStr vs. putStrLn
I just tried this example with putStrLn and putStr, and both worked fine. I am using the latest 4.08.2 GHC under Windows 2000. -Original Message- From: Andre W B Furtado [mailto:[EMAIL PROTECTED]] Sent: Monday, February 19, 2001 6:20 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: putStr vs. putStrLn Hello there. I used the code below to read and print the bitmap file attached (bitmap.bmp), which contains the character ASCII 26 (or 1A-hexa). This special character is used by MSDOS as an end of file marker. import IO import IOExts main :: IO () main = do bmFile <- openFileEx "bitmap.bmp" (BinaryMode ReadMode) charloop bmFile 0 charloop :: Handle -> Integer -> IO () charloop bmFile 70 = hClose bmFile charloop bmFile n = do hSeek bmFile AbsoluteSeek n a <- hGetChar bmFile putStrLn [a] charloop bmFile (n+1) This program did not stuck after reading the special character, but if you change putStrLn by putStr you will notice that a strange thing happens: after reading the special character, the program won't show any more characters. Why does it happen? ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: A GUI toolkit looking for a friend
Simon Peyton-Jones wrote: > Nothing's wrong with ambitious systems! But there's an > ambition/pragmatism tradeoff. If there was a consensus about the > Right Way to build an ambitious (more declarative) system then we > could all go for it. But there isn't. So let the experiments > flourish, but meanwhile it would be of practical use to many > people to have a stable, portable (if less sexy) platform on which > to build applications. > > Simon As a (sometimes quite nervous...) user of the Clean GUI, I assure all profans who never touched it that * It is quite ambitious. Oh yes, ambitious it is. * It is quite sexy, especially for those for whom everything is in a sense sexy. But it is inspiring, and has some metallic elegance. (For some people Robocop *IS* sexy). * It is powerful! === I began to scratch my head. Presumably all this business of local and global states is translatable to Haskell without much disturbances. But I am not sure whether I could monadise all unique-access objects (including Picture etc.) without serious troubles. Even in my short private essays, where I tried to "Haskellize" the Clean I/O, refraining from using this pseudo-imperative style: # object = doSomethingWith object # object = andMoreProcessingOf object ... and constructing monadic chains, I finally gave up, because my fingers generated too many bugs. But this is a personal observation, I am sure that more disciplined people can do it better. Jerzy Karczmarczuk Caen, France ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: A GUI toolkit looking for a friend
| What's wrong with "ambitious" high-level systems. Is something amiss | with their basic ideas or is it the nuts and bolts? Are they | too slow? | Too big? Too abstract? In short, why is there a need to | avoid the high | level and go for "in-the-middle" systems? I am still so new | to Haskell | that I have no opinion in the matter, and if Simon's comments reflect | some hard learned lessons about GUIs, I am curious to know what they | are. Nothing's wrong with ambitious systems! But there's an ambition/pragmatism tradeoff. If there was a consensus about the Right Way to build an ambitious (more declarative) system then we could all go for it. But there isn't. So let the experiments flourish, but meanwhile it would be of practical use to many people to have a stable, portable (if less sexy) platform on which to build applications. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: A GUI toolkit looking for a friend
Simon Peyton-Jones wrote: > > Gentle Haskellers > > This message is to invite offers to complete a promising > port of the Clean Object I/O library to Haskell. > > As you know, there are quite a few GUI toolkits for Haskell, but > none of them has become a de-facto standard. One confusing aspect > is that there are different "levels": > (see http://haskell.org/libraries/#guigs) I had hoped for a lively debate following this post, but so far there has not been a single response. So let me ask a few questions. > * Strangely, there are very few "in the middle" systems. One might hope > for an interface that was somewhat independent of the low-level library, > and somewhat more Haskell friendly, than the low-level veneers, but > not as ambitious as the high-level systems. ^^^ > ^^^ What's wrong with "ambitious" high-level systems. Is something amiss with their basic ideas or is it the nuts and bolts? Are they too slow? Too big? Too abstract? In short, why is there a need to avoid the high level and go for "in-the-middle" systems? I am still so new to Haskell that I have no opinion in the matter, and if Simon's comments reflect some hard learned lessons about GUIs, I am curious to know what they are. It might, after all, be simpler to continue developing (say) FranTk, than to start all over again with the Clean Object I/O Library, for which there may or may not emerge volunteers who will complete the port. -- Tore ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Inferring from context declarations
Wed, 21 Feb 2001 16:46:48 +0100, George Russell <[EMAIL PROTECTED]> pisze:
> Various (MLj, MLton)
> ML compilers already inline out all polymorphism. Some C++ compilers/linkers
> do it in a rather crude way as well, for templates. If you can do it,
> you can forget about dictionary passing.
It would require to keep bodies of all polymorphic functions in
a form allowing instantiation in different modules. For example
ghc already requires too much memory (even a hundred MB for large
modules), and it leads to code bloat, so in the current state of
technology it's not advisable to always compile out polymorphism.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: making a Set
Wed, 21 Feb 2001 18:11:22, G Murali <[EMAIL PROTECTED]> pisze:
> makeSet:: (a->Bool)->Set a
There are operations which can be performed on sets constructible in
that way, and there are operations which cannot.
For example you can check if an element belongs to a set, or compute
an intersection of two sets. But you can't check if a set is empty
or if two sets are equal.
> I understand that we need a new type Set like
> data Set a = Set (a->Bool)
In this case the definition of makeSet is very simple:
makeSet = Set
> what puzzles me is how to apply the funtion to all elements belonging
> to type a.
You can't find all elements of a given arbitrary type. (One reason
is that some types have infinitely many elements, and it's not the
only reason.)
You could restrict yourself to enumerable types, making an appropriate
class, or reuse existing classes:
allElements :: (Bounded a, Enum a) => [a]
allElements = [minBound .. maxBound]
allElements can be used to obtain a list of all values for types which
are instances of classes Bounded and Enum. Note that even for some
types which are instances of these classes, it's not very practical,
e.g. for Int (the list would have 4 billion elements).
Alternatively you could make a different representation of sets which
store all elements of a finite set in some data structure. You can't
construct such sets from arbitrary functions of type 'a -> Bool'.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
