- Haskell-Cafe - Haskell.org

Re: lexer puzzle
by Brandon Michael Moore 06 Oct '03

06 Oct '03

Note I've replied to haskell-cafe. This post is a bit chatty and low on solid answers. On Thu, 25 Sep 2003, Sean L. Palmer wrote: > > >>A... should be split into "A.." and "." > > >I found a compromise: let's make it a lexing error! :-) > > At least that agrees with what some Haskell compilers implement. No > > current Haskell compiler/interpreter agrees with what the report seems > > to say, that is that "A..." should be lexed as the two tokens "A.." and > > ".", and similarly, "A.where" should be lexed as "A.wher" followed by "e". > > Hi. I'm really new to Haskell, just learning it, and I must say I'm pretty > overwhelmed by the large variety of constructs. (=>, <-, \ to name a few) Would that be \ as in TREX row variable polymorphism? Just remember most operators are just library functions. It's only =, ->, =>, <-, :: that are really part of the language, and {,},; for grouping. Did I miss any? > > But I'm just writing this to let you guys know (surely you know this > already) that anyone from a C/C++/Java/Delphi background is going to > completely misunderstand the meaning of A.anything in Haskell... it's > completely nonintuitive to people with my background. I kinda like dot > notation because it ties together the symbols visually, for instance > "myrec.myfield" is more of a unit than "myrec myfield". It stays together > better when surrounded by other code, and would result in fewer parenthesis > necessary. A Python programmer would understand instantly: Python uses exactly the same syntax for module access, though Python modules are usually in lowercase. It also seems to be very much in the spirit of "access a member of this object" of an OO language. Or was that supposed to be composition of a constructor with a function, A . f? Function composition, and higher order functions in general are likely to confuse an imperative programmer, but I think there isn't much syntax can do there. Or are you talking about the field access syntax? Maybe the problem is that dot has two to five different meanings, function composition, naming module members, building hierarchial module names, being a decimal point, and making elipses, and is commonly used for yet another purpose in OO languages. > Haskell to me seems to be a great language with a syntax problem, and a bad > case of too many ways to do the same thing; thus every programmer does > things their own way and it's difficult to grasp the language by looking at > various programs, since they're all so very different. As a small example, > there's 'let' vs. 'where'. Maybe a bit of pruning would be in order. Do you mean the syntax is bad in places? Haskell is the cleanest language I know of, but I'm sure it has some grungy bits. I've had problems with unary minus (can't slice binary minus), and precedence of with irrefuatble patterns and type ascription. I would be happy for any confusing syntax to be improved. Any good ideas? Syntax change is a possibility: do notation is a relatively recent addition, and arrow syntax is in the works. I think you might instead mean the syntax cuts down our market share because it isn't like common (C derived) languages. I don't think Haskell could borrow any more syntax from C without actually making the language worse. It's a problem, but not with the syntax. If someone is so solidly into a C++/Java/OO mindset that the syntax would be a problem, the semantics would probably be even more of a problem. I would suggest Python if Haskell was too much of a jump for someone. It's still OO, but it encourages more flexible and interesting programs, and you don't have to live in a Java type system. Plus, it has more libraries, bindings, and PR, so it's easier to get permission to use it in a company. If someone is used to Python's layout rule and lack of type signatures, and gets their head around some of the fun you can have dynamically picking which members of an object to access, assigning to __dict__ and so on, then Haskell should be much less of a jump in syntax, and less imposing in semantics. > That said, I still think it looks more promising than any other language > I've looked at that actually is being actively used and maintained and has a > decent installed base and good cross platform support. So I will learn it. > I just wish the transition was easier and that it took less time to learn. > ;) > > Sean I learned Haskell from the "gentle introduction". It seemed gentle enough to me but others disagree, so I'm probably not the best for advice for the raw beginner. If you are interested in learning about monads though, Jeff Newbern's monad tutorial seems accessible and as complete as anything this side of Phil Wadler's paper. I hope learning Haskell goes well. Brandon

7 8

Re: Read and Write to Same File
by kuq32tr02＠sneakemail.com 06 Oct '03

06 Oct '03

> > main = do text <- readFile "test" > > let something = somefunc text > > writeFile "test" $! something > > There is no guarantee that $! will force evaluation of the entire > 'something', so you can start writing to file before you finished > reading from it. Hopefully it will cause an exception (like in GHC), > otherwise you could damage your data (like in Hugs). > > PS. How does it behave in NHC? This is the version I've been using for a while now. It runs perfectly fine in both GHC and Hugs. I've used it many, many times with no noticeable problems. Should I be seeing errors (like exceptions in GHC)? I don't have NHC installed, so I can't test it. Thanks!

1 0

Re: IO behaves oddly if used nested
by Derek Elkins 05 Oct '03

05 Oct '03

On Sat, 04 Oct 2003 13:13:59 +0200 "blaat blaat" <l4t3r(a)hotmail.com> 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 _ = "<<IO action>>" > 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.

2 1

Newbie qustion about monads
by Juanma Barranquero 05 Oct '03

05 Oct '03

I have an extremely-newbie question about monads and how to interpret the monadic laws; I asked that same question yesterday on IRC and the answers were interesting but non-conclusive (to me anyway). I'm trying to learn monads by reading "All About Monads", version 1.0.2. I though of defining a monad like that: data Counted a = Ct Int a instance Monad (Counted) where return x = Ct 1 x Ct n x >>= f = let (Ct n' x') = f x in Ct (n+n') x' -- fail as default The intent is that Counted objects "count" the number of times an operation is applied to them. (For the purpose of the question, that's irrelevant anyway: the problem would be the same if I assigned a random number to the Int on each calling of >>=.) According to "All About Monads", the first monadic law says: (return x) >>= f == f x In my case, let's suppose I define: reverseCounted :: [a] -> Counted [a] reverseCounted x = return (reverse x) so I do: c1 = return "xxx" >>= reverseCounted -- c1 == Ct 2 "xxx" c2 = reverseCounted "xxx" -- c2 == Ct 1 "xxx" Now comes the question: In what sense should I interpret the "==" in the monadic law? Obviously, c1 and c2 are not structurally equal. If I can accept that two Counted things are "equal" even if they are not identical, is enough for me to define: instance Eq a => Eq (Counted a) where Ct _ x == Ct _ y = x == y to satisfy the first law? Yesterday I was said that it'd work if c1 and c2 are mutually substitutable. They are, for the purposes of equality, though evidently not for every purpose. A simple: count (Ct n _) = n allows me to distinguish between them. Juanma

5 13

Why does this work - haskell mysteries?!
by ,,, 05 Oct '03

05 Oct '03

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)

1 0

Haskellsupport in KDevelop
by Peter Robinson 05 Oct '03

05 Oct '03

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

3 3

RE: "interact" behaves oddly if used interactively
by Simon Marlow 04 Oct '03

04 Oct '03

> Yes, the presence of lazy IO makes optimistic evaluation more > complicated, but I do not see that it compromises the purity of the > language in anyway (whatever purity is ;-). So, we're agreed that the presence of lazy evaluation makes implementing optimistic evaluation (and other evaluation strategies) more complicated. Personally, I find it disturbing that the presence of this family of library functions affects something as low-level as the evaluation strategy of the language. Or, to put it another way, it enforces a particular evaluation strategy on a part of the language, when the rest of Haskell makes no such restrictions. I would expect, in a pure language, that I could reduce any expression in a program to HNF (or _|_) without affecting the meaning of the program. In Haskell, I can only do this so long as the expression doesn't involve any lazy I/O. The real problem is that lazy I/O injects side effects into the pure world of expressions. Haskell has a perfectly good system for encapsulating side effects - the IO monad. So why put these sneaky side effects into pure values? Cheers, Simon

5 4

RE: "interact" behaves oddly if used interactively
by Simon Marlow 03 Oct '03

03 Oct '03

> > The real problem is that lazy I/O injects side effects into the pure > > world of expressions. Haskell has a perfectly good system for > > encapsulating side effects - the IO monad. So why put > these sneaky side > > effects into pure values? > > I fear one problem is that the word "side effect" is not properly > defined. > > Actually both getContents and interact are in the IO monad. Since the > action "interact" is not terminated until the input stream ends, I do > not see any problem there. Yes, it is probably true that you cannot observe any non-referential-transparency using only interact. The side effects are only visible in the IO monad, and since as you say interact doesn't let you back into the IO monad until it has finished, it is probably safe. The unsafety is only visible using the other lazy I/O operations, principally hGetContents. > Evaluation never leaves the IO monad until > termination. getContents is more strange. However, you can just define > its semantics to yield a random string. When you are not > careful you may certainly get something nearly random ;-) So... you agree that getContents in its current form should really be called unsafeGetContents? Unless perhaps we redefine its semantics to either (a) yield a random string or (b) eagerly slurp the entire stream contents? Cheers, Simon

4 3

RE: "interact" behaves oddly if used interactively
by Simon Marlow 03 Oct '03

03 Oct '03

[ taking this one to haskell-café... ] > I still do not quite agree with Simon that 'interact' exposes anything > but non-strictness. Non-strictness means that > > map toUpper _|_ = _|_ > map toUpper ('a':_|_) = ('A':_|_) > map toUpper ('a':'b':_|_) = ('A':'B':_|_) > > and 'interact (map toUpper)' is a great way to experience > this property. > > However, you can also experience the property without 'interact', > evaluating expressions like > > take 2 (map toUpper ('a':'b':undefined)) Certainly you can observe non-strictness, that's not the point. The point is that you can also observe more than just non-strictness using interact, and I don't think that is desirable. For example: interact (\xs -> let z = length xs in "Hello World\n") Now, Haskell is a pure language, so it shouldn't matter whether the implementation evaluates z or not, as long as it is careful not to violate the non-strict semantics by turning a terminating program into a non-terminating one. A parallel Haskell implementation might happily spawn off another thread to evaluate z for example. An optimistic implementation might evaluate z for a fixed amount of time before continuing with the main thread of evaluation. BUT in the presence of lazy I/O this simply isn't true any more. Why? Because z is not pure; evaluating it has a side-effect. And yet it has type Int. Am I the only one who thinks this is wrong? Cheers, Simon

8 11

Question about Type Checking
by Clement 03 Oct '03

03 Oct '03

Hi i am doing a type checker. and how can i check if the Expn that i have is a Prim Function = ("f",[([Arg "x"],Simple (Int 2))]) type Function = (Name, [Equation]) type Equation = ([Expn], Body) {- (the body of) either a simple equation: f a1 .. an = e or a conditional equation: f a1 .. an | b1 = e1 ... | bm = em data Body = Simple Expn | Conditional [(Expn, Expn)] deriving (Show, Read) data Expn = Int Int | Char Char | Bool Bool | Arg Name | Prim Name | Func Name | Appn Expn Expn | Tuple [Expn] and how can i group the Expn together for Appn? __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

1 0