Read and Write to Same File
I am writing a program that reads and writes to the same file. I was having some problems with it writing to the file before it read it. I solved it in the following two ways: 1. main = do text <- readFile "test" let something = somefunc text writeFile "test2" something renameFile "test2" "test" 2. main = do text <- readFile "test" let something = somefunc text writeFile "test" $! something Are both of these correct (guaranteed to give the behavior I want)? Which is better (and why)? Thanks! ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: IO behaves oddly if used nested
it might be more clear if IO had a show instance like instance (Typeable b) => Show (IO b) where show (x:: IO a) = "<< IO action producing a " ++ (show $ typeOf (undefined :: a)) ++ " >>" then print $ getChar prints << IO action producing a Char >> of course this may not be feasable for all implemenations if they don't autoderive Typeable... John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Newbie qustion about monads
On Thu, 02 Oct 2003 14:57:22 +0200, Juanma Barranquero <[EMAIL PROTECTED]> wrote:
> data Accum s a = Ac [s] a
>
> instance Monad (Accum s) where
>return x = Ac [] x
>Ac s1 x >>= f = let Ac s2 y = f x in Ac (s1++s2) y
>
> output :: a -> Accum a ()
> output x = Ac [x] ()
After trying this one, and also
output :: a -> Accum a a
output x = Ac [x] x
I though of doing:
data Accum a = Ac [a] a
because I was going to accumulate a's into the list.
That didn't work; defining >>= gave an error about the inferred type
being less polymorphic than expected ('a' and 'b' unified, etc.).
After thinking a while, I sort of understood that >>= is really more
polymorphic, i.e., even if it is constraining [s] to be a list (because
it is using ++), it really is saying nothing about the contents of the
list. It is "output" who's doing the constraint, but, with the very same
monad, I could do:
output :: [a] -> Accum Int [a]
output x = Ac [length x] x
or
output :: a -> Accum [a] a
output x = Ac [[x]] x
or whatever.
But then I wondered, is there any way to really define
data Accum a = Ac [a] a
i.e., constraining it to use a for both values, and make a monad from it?
Curious,
Juanma
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: IO behaves oddly if used nested
On Sat, 04 Oct 2003 13:13:59 +0200 "blaat blaat" <[EMAIL PROTECTED]> wrote: [moved to Haskell-Cafe] > > Neither example is odd behavior, unless > >you consider Hugs providing a perfectly reasonable instance of Show > >for IO a odd. > > True, every program behaves exactly as according to the definition of > the run-time behavior of Haskell programs. (Hugs deviates a bit from > ghc but ah well) The odd is not in the run-time behavior. > > The odd is in the conceptual explanation. If I give a description of > some f x = y function in Haskell I expect that some program f x is > reduced to y and the result is given back (possibly printed). A good > story to sell to students. Then use an impure language like Scheme. This is exactly what the IO monad avoids. > This is almost everywhere the case except for the IO monad. This is never the case. You can -only- print things via the IO monad. > In the former example, the inner putStr is _not_ evaluated but a > message is shown (hinting that a IO has some structure we can observe > before evaluation). The message shown doesn't expose any structure, let alone suggest that you can observe it. The message is independent of the actual IO action it only uses the type. You could write the Show instance yourself. instance Show (IO a) where show _ = "<>" > In the latter example, it is shown that we are not > interested in a result of a IO program, but only in its (lazily > generated) side-effects. The effects aren't lazily generated. Monads are independent of evalution order. They would work just as well in a strict language. This is what makes them pure. (See Amr Sabry's "What is a Purely Functional Language?") > The monad behaves oddly with respect to the f > x = y behavior. Not really. If f x were, f x = \_ -> unsafePerformIO (putStr "Hello") would you be surprised that f 5 doesn't print "Hello"? > I think I observe the following reactions when I explain IO: Perhaps because you don't explain it properly? > * Why is an IO a evaluated if I am not interested in it's result? > (opposite to the f x = y lazy behavior) It isn't. If you are interested in it's result, then the result is an action which will do whatever -when run-, -not- the side-effects. If you aren't interested in it's result it will never be evaluated in Haskell, but even if it were (by adding a seq or using a strict language) the result would -still- be an action that will do something -when run-, and since you aren't interested in it it will be discarded without ever executing; a good thing as this maintains purity. > * Why is in the putStr "hello world" example Hello World not shown? > (opposite to expected f x = y eval-first-then-show behavior) Because it is never run. > * Why is in the IO (IO ()) example the inner IO () not evaluated? Because it is never run. > (somewhat opposite to expected f (f x) behavior - I personally wonder > if it is even sound in a category theoretical setting) As for the Category Theoretic behavior, it's perfectly sound. The RTS just discards the result, given that in a sense it's type is IO a -> something where 'a' is not free in something, all it -can- do is discard the result by parametricity. It doesn't matter if it 'a' is Int, (), IO FooBar, Char-> Int or anything else, any more than it matters in what type or value the first argument is in f _ = () or the "return" type of the monad action m in do_ <- m;return() (or written another way, m >>= \_ -> return ()). If you think of IO actions as state transformers (which has it's faults but works for this), then the observed behavior makes perfect sense. None of the IO actions -can- execute because they don't have the state of the world to process. It's just like with the State monad, execState (do x <- get;put (x+5);return (put 10)) 0 returns 5 not 10, the state (0 then 5) is never passed to put 10. This can be seen by unfolding this into the standard state-passing definition. If we take out the execState, -nothing- happens and we just get functions that will transform a state once it's provided; they won't and -can't- do anything until that state is provided. So putStr "foo" is IO () is World -> ((),World), it is not surprising that f _ = 10, f (putStr "foo") does not print "foo", anymore than it is surprising that f (\x -> undefined) does not cause an error, or f (put 10) does not change some state somewhere. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Haskellsupport in KDevelop
On Sat, Oct 04, 2003 at 07:15:32PM +0200, Peter Robinson wrote: > What's really missing is a (primitive) background parser written that reports > syntax errors. It can be written in yacc, antlr, etc., anything that produces > C/C++ code. The only parsers for Haskell I could find are written themselves > in Haskell. > Does anyone know about one or must I write it from scratch? There's a yacc parser in Hugs. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Why does this work - haskell mysteries?
Thanks, the Scheme-version made it even clearer! Cheers, Petter On Saturday 04 October 2003 13:53, you wrote: > On Sun, 5 Oct 2003 11:02:37 + > > Petter Egesund <[EMAIL PROTECTED]> wrote: > > Hi & thanks for answering. > > > > I think I got it - the chaning of the functions lies in the last part > > of > > > > (\w -> if v==w then n else sto w) > > > > I am used to higher ordered functions from Scheme, but it was the > > delayed evaluation which played me the trick here. This function is > > built when updating, and not executed before asking value 'x'?! > > If by delayed evaluation you mean lazy evaluation then that has nothing > to do with it. Obviously the function isn't executed before asking the > value of 'x' because no function can run without it's argument(s). The > same representation will behave exactly the same in Scheme. > > (define init-store (lambda (key) 0)) > (define (lookup-store store key) (store key)) > (define (update-store store key value) >(lambda (lookup-key) > (if (equal? key lookup-key) > value > (lookup-store store lookup-key > > Obviously, this will make the function taking lookup-key when > update-store is called (just like Haskell) and (just like Haskell) it > will only be executed when applied to a key to lookup. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Haskellsupport in KDevelop
On Saturday 04 October 2003 20:20, Wolfgang Jeltsch wrote: > Great! I will probably use it since I like Haskell and KDE very much. > > By the way, wasn't KDevelop only for developing in C and C++? The current stable Release 2.1.* is a C/C++ only IDE but the upcoming 3.0 will probably support: Ada, Bash, C/C++, Fortran, Java, Pascal, Perl, PHP, Python, Ruby, Haskell, SQL > Did they move > to a plugin-based approach which allows support for other programming > languages? Yes, no other code has to be changed. Language support is plugin/kparts based. :-) Peter > > ___ > Haskell-Cafe mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Haskellsupport in KDevelop
Am Samstag, 4. Oktober 2003, 19:15 schrieb Peter Robinson: > Hello, > > I've begun to write a plugin that provides basic support for Haskell in > KDevelop 3.0 alpha. (http://www.kdevelop.org). Great! I will probably use it since I like Haskell and KDE very much. By the way, wasn't KDevelop only for developing in C and C++? Did they move to a plugin-based approach which allows support for other programming languages? > [...] > Regards, > Peter Wolfgang ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Haskellsupport in KDevelop
Hello, I've begun to write a plugin that provides basic support for Haskell in KDevelop 3.0 alpha. (http://www.kdevelop.org). It is already included in the CVS and the latest alpha7 release. Screenshots: http://www.thaldyron.com/snap1.png http://www.thaldyron.com/snap2.png http://www.thaldyron.com/snap3.png At the moment it's only possible to create a new project and to build/run it with GHC. What's really missing is a (primitive) background parser written that reports syntax errors. It can be written in yacc, antlr, etc., anything that produces C/C++ code. The only parsers for Haskell I could find are written themselves in Haskell. Does anyone know about one or must I write it from scratch? Regards, Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Why does this work - haskell mysteries?
On Sun, 5 Oct 2003 11:02:37 + Petter Egesund <[EMAIL PROTECTED]> wrote: > Hi & thanks for answering. > > I think I got it - the chaning of the functions lies in the last part > of > > (\w -> if v==w then n else sto w) > > I am used to higher ordered functions from Scheme, but it was the > delayed evaluation which played me the trick here. This function is > built when updating, and not executed before asking value 'x'?! If by delayed evaluation you mean lazy evaluation then that has nothing to do with it. Obviously the function isn't executed before asking the value of 'x' because no function can run without it's argument(s). The same representation will behave exactly the same in Scheme. (define init-store (lambda (key) 0)) (define (lookup-store store key) (store key)) (define (update-store store key value) (lambda (lookup-key) (if (equal? key lookup-key) value (lookup-store store lookup-key Obviously, this will make the function taking lookup-key when update-store is called (just like Haskell) and (just like Haskell) it will only be executed when applied to a key to lookup. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Why does this work - haskell mysteries?
Hi & thanks for answering. I think I got it - the chaning of the functions lies in the last part of (\w -> if v==w then n else sto w) I am used to higher ordered functions from Scheme, but it was the delayed evaluation which played me the trick here. This function is built when updating, and not executed before asking value 'x'?! So then I go on to the next chap. in the tutorial :-) Cheers, PE On Friday 03 October 2003 23:31, you wrote: > This seems to me like one of those frustrating problems... if you are > comfortable with the language then why it works is "obvious", but it's > difficult to explain why it's obvious. (My mathematical analysis lecturer > often used to say "if it's obvious then either it's an assumption or it can > be proven in 3 lines".) > > Suppose you have a function -- any function, and I don't care how it's > implemented -- that maps a Char to an Int, and let's call it InitStore. > > So, maybe we have > >initStore 'a' == 4 >initStore 'b' == 5 > > Now, consider what happens if I define: > >myStore :: Char -> Int >myStore 'a' = 3 >myStore x = initStore x > > then: > >myStore 'a' == 3 >myStore 'b' == 5 > > Now suppose that 'initStore' is implemented in a fashion similar to > 'myStore' ... and I think you start to get an idea about why it works. > > I suspect that any difficulty with this is not being entirely used to the > idea that a function is a datum pretty much like any other datum. So > functions that return results based on some other function value value may > be less familiar than functions that return a value based on a given list? > > Another comment: trying to figure how it all works in memory is probably > not helping. Returning to the 'myStore' example above: is there any doubt > that it works as claimed? Maybe it's only when you try to figure out how > it works operationally that you get confused ... but to understand that I > think one needs an appreciation of how functional languages are actually > *implemented*. When programming in a conventional language like C, one is > quite prepared to accept the operational behaviour as described, but if you > try to understand how that works when mapped onto a modern > performance-optimized hardware architecture, I think it's easily as > difficult to follow as functional language implementation. > > I've no idea if anything here is remotely helpful. > > #g > -- > > At 23:48 04/10/03 +, Petter Egesund wrote: > >Hi; > > > >the proof of the pudding does lies in the eating... but I still wonder why > >this code is working (it is taken from the book "The Craft of functional > >programming"). > > > >The program connects a variable-name to value. The fun initial gives the > >initial state, update sets a variable & value reads a value). > > > >I evaluate > > > > value my_store 'b' to 5 > >and value my_store 'a' to 3 > > > >as expected from the text in the book. > > > >But I can't see what is happening here. The book has a parallel example > > where the data is held in a list, and this version is easy to follow, but > > this trick with storing a lambda-function inside a newtype beats me. > > > >The problem is that I do not understand where the accumulated data is > > stored (not in a list - it seems like something like a chain of functions > > which can be pattern-matched, but I am not sure). > > > >And why does not the lambda-function (\w -> if v==w then n else sto w) > >start a > >endless loop? > > > >(This is not homework - I am a programmer who is curious about Haskell!) > > > >Any clues, anyone? > > > > > >Cheers, > > > >Petter > > > > > >-- Var is the type of variables. > > > >type Var = Char > > > >newtype Store = Sto (Var -> Int) > >-- > >initial :: Store > > > >initial = Sto (\v -> 0) > > > >value :: Store -> Var -> Int > > > >value (Sto sto) v = sto v > > > >update :: Store -> Var -> Int -> Store > > > >update (Sto sto) v n > > = Sto (\w -> if v==w then n else sto w) > > > >-- testit -- > > > >my_store = update (update (update initial 'a' 4) 'b' 5) 'a' 3) > > > > > > > >___ > >Haskell-Cafe mailing list > >[EMAIL PROTECTED] > >http://www.haskell.org/mailman/listinfo/haskell-cafe > > > Graham Klyne > [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Type tree traversals [Re: Modeling multiple inheritance]
This message illustrates how to get the typechecker to traverse
non-flat, non-linear trees of types in search of a specific type. We
have thus implemented a depth-first tree lookup at the typechecking
time, in the language of classes and instances.
The following test is the best illustration:
> instance HasBarMethod ClassA Bool Bool
> -- Specification of the derivation tree by adjacency lists
> instance SubClass (Object,()) ClassA
> instance SubClass (Object,()) ClassB
> instance SubClass (ClassA,(ClassB,())) ClassCAB
> instance SubClass (ClassB,(ClassA,())) ClassCBA
> instance SubClass (Object,(ClassCBA,(ClassCAB,(Object,() ClassD
> instance SubClass (Object,(ClassB,(ClassD,(Object,() ClassE
>
> test6::Bool = bar ClassE True
It typechecks. ClassE is not explicitly in the class HasBarMethod. But
the compiler has managed to infer that fact, because ClassE inherits
from ClassD, among other classes, ClassD inherits from ClassCBA, among
others, and ClassCBA has somewhere among its parents ClassA. The
typechecker had to traverse a notable chunk of the derivation tree to
find that ClassA.
Derivation failures are also clearly reported:
> test2::Bool = bar ClassB True
> No instance for (HasBarMethodS () ClassA)
> arising from use of `bar' at /tmp/m1.hs:46
> In the definition of `test2': bar ClassB True
Brandon Michael Moore wrote:
> Your code doesn't quite work. The instances you gave only allow you to
> inherit from the rightmost parent. GHC's inference algorithm seems to pick
> one rule for a goal and try just that. To find instances in the first
> parent and in other parents it needs to try both.
The code below fixes that problem. It does the full traversal. Sorry
for a delay in responding -- it picked a lot of fights with the
typechecker.
BTW, the GHC User Manual states:
>However the rules are over-conservative. Two instance declarations can
> overlap, but it can still be clear in particular situations which to use.
> For example:
>
> instance C (Int,a) where ...
> instance C (a,Bool) where ...
>
> These are rejected by GHC's rules, but it is clear what to do when trying
> to solve the constraint C (Int,Int) because the second instance cannot
> apply. Yell if this restriction bites you.
I would like to quietly mention that the restriction has bitten me
many times during the development of this code. I did survive though.
The code follows. Not surprisingly it looks like a logical program.
Actually it does look like a Prolog code -- modulo the case of the
variables and constants. Also
head :- ant, ant2, ant3
in Prolog is written
instance (ant1, ant2, ant3) => head
in Haskell.
{-# OPTIONS -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances
#-}
data Object = Object
data ClassA = ClassA
data ClassB = ClassB
data ClassCAB = ClassCAB
data ClassCBA = ClassCBA
data ClassD = ClassD
data ClassE = ClassE
class SubClass super sub | sub -> super where
upCast:: sub -> super
instance SubClass (Object,()) ClassA
instance SubClass (Object,()) ClassB
instance SubClass (ClassA,(ClassB,())) ClassCAB
instance SubClass (ClassB,(ClassA,())) ClassCBA
instance SubClass (Object,(ClassCBA,(ClassCAB,(Object,() ClassD
-- A quite bushy tree
instance SubClass (Object,(ClassB,(ClassD,(Object,() ClassE
class HasBarMethod cls args result where
bar :: cls -> args -> result
instance (SubClass supers sub,
HasBarMethodS supers ClassA)
=> HasBarMethod sub args result where
bar obj args = undefined -- let the JVM bridge handle the upcast
class HasBarMethodS cls c
instance HasBarMethodS (t,x) t
instance (HasBarMethodS cls t) => HasBarMethodS (Object,cls) t
instance (HasBarMethodS cls t) => HasBarMethodS ((),cls) t
instance (SubClass supers c, HasBarMethodS (supers,cls) t) =>
HasBarMethodS (c,cls) t
instance (HasBarMethodS (a,(b,cls)) t) => HasBarMethodS ((a,b),cls) t
instance HasBarMethod ClassA Bool Bool where
bar _ x = x
test1::Bool = bar ClassA True
--test2::Bool = bar ClassB True
test3::Bool = bar ClassCAB True
test4::Bool = bar ClassCBA True
test5::Bool = bar ClassD True
test6::Bool = bar ClassE True
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
