00:00:00 --- log: started haskell/02.01.11 01:20:09 --- quit: x99 (Read error: 113 (No route to host)) 02:12:30 --- quit: teek ("Coffee break") 02:52:45 --- quit: dmiles (Read error: 104 (Connection reset by peer)) 03:27:19 --- join: teek (teemu@k72.viikki.hoasnet.fi) joined #haskell 03:32:03 --- quit: teek ("Coffee break") 03:42:12 --- nick: clauZzzen -> clausen 03:54:23 --- join: shapr (~user@p-c2fbab4f.easy.inet.fi) joined #haskell 03:55:22 y0 04:11:12 good morning folks 04:13:31 --- nick: clausen -> clausen_banho 04:13:48 banho? 04:15:15 --- join: bsh (~MasterBot@dsp-202-72-158-119.manjimup.westnet.com.au) joined #haskell 04:15:26 shapr: bath in portuguese 04:15:34 oh, nifty 04:15:46 shapr: (I've been talking to ppl in pt, and sort of interrupt-and-go...) 04:16:22 --- part: bsh left #haskell 04:19:44 ok, I still don't understand this dropWhile and takeWhile stuff 04:19:44 but I got dropVowels working for me 04:19:44 here's what I used: 04:19:44 isVowel c = elem c "aeiou" 04:19:48 dropVowels string = filter (not . isVowel) string 04:20:51 does takeWhile have an advantage over filter? 04:20:53 oh 04:20:56 lemme guess 04:21:00 filter isn't lazy, and take is 04:21:36 they're both lazy 04:21:39 they do different things 04:21:54 filter (>0) [2,3,-1,4,-2] will give you [2,3,4] 04:22:04 takeWhile (>0) [2,3,-1,4,-2] will give you [2,3] 04:22:19 oho!! 04:22:39 so takeWhile *stops* when it hits the first non P ? 04:23:02 yep. 04:23:24 then this other code I wrote *did* work, I just didn't realize that was the right result 04:23:27 aha! 04:24:57 can I do nested where statements? 04:25:18 oh, I can! 04:25:20 nifty 04:25:25 this is funny: 04:25:33 dropVowels string = filter (not . isVowel) string where 04:25:33 isVowel c = elem c vowels where 04:25:33 vowels = "aeiou" 04:26:03 and I'd guess the difference is the 'scope' that these things are defined in... 04:26:18 so I can't reuse vowels in any scope other than isVowel, right? 04:26:24 * shapr tries it 04:34:59 --- nick: clausen_banho -> clausen 04:36:21 --- join: Peaker (peaker@bzq-193-224.red.bezeqint.net) joined #haskell 04:37:28 y0 y0 04:37:37 I wonder if this can get any simpler: 04:37:41 dropVowels string = filter (not . (\x -> elem x "aeiou")) string 04:37:57 I couldn't figure out a way to get rid of some parens 04:38:05 I'd bet I could get the not into the lambda somewhere though 04:38:59 hrm 04:39:13 dropVowels = filter (not . flip elem "aeiou") 04:39:23 what's flip? 04:39:30 * shapr hits the index 04:39:36 flip f x y = f y x 04:39:39 oh! 04:39:41 that's handy 04:39:56 that's elegant! 04:40:36 nice 04:40:38 thanks! 04:42:26 I'm kind of surprised that elem takes the set arg second 04:42:39 I'd expect Haskell functions would always put the most general arg first 04:42:42 * shapr thinks 04:42:57 shapr: yeah, it's obvious to curry it that way 04:43:03 wait, I bet that either arg could be more general, just depends on the situation 04:43:04 you'll always find situations where one way or the other is useful 04:43:07 yeah. 04:45:43 these are my observations: 04:45:52 in general, Haskell is more concise than other languages 04:46:09 it can even beat Perl sometimes, and that can get scary 04:46:20 just wait till you try to write a program that uses a lot of global state :-) 04:46:24 but its use of whitespace improves readability tremendously 04:46:33 I don't do that 04:46:36 :) 04:46:46 you can do it concisely, but you have to use some complicated features to get there 04:46:48 at least, I've always found a way around it so far 04:46:55 that's good, global state is in general bad 04:46:59 but it often can't be avoided 04:47:32 hm, I haven't run into many of those situations 04:50:05 --- join: mustard (~felix@159.180.250.254) joined #haskell 04:50:09 hi mustard 04:50:28 ello! 04:50:32 what's up? 04:51:41 got that friday feeling at work - lots of Java code to re-structure so I'm dreaming of greener programming pastures 04:51:46 heh, I understand that 04:54:41 I'd like to see some lint tools for various languages written in Haskell 04:58:19 --- join: teek (teemu@k72.viikki.hoasnet.fi) joined #haskell 04:58:39 hi teek 04:58:55 hi shapr 05:00:44 Peaker: ok, partial resolution doesn't quite work in Python 05:01:05 in Haskell, every function that takes two args and returns one, is actually two functions 05:01:13 partial resolution? 05:01:25 AutoCurrying T 05:01:26 yah, like (+1) 05:01:27 TM 05:01:28 shapr: But that's under the hood 05:01:47 what is the difference in the code that uses Python currying? 05:01:51 (from Haskell currying) 05:01:57 I thought currying was about changing f :: (a,b) -> c to f :: a -> b -> c ? 05:02:20 def curry(func, *args): return lambda *rest: func(*args, *rest) 05:02:40 that's effictively what haskell does 05:02:44 automagically 05:02:56 okay, and my question was what were the Haskell advantages? 05:03:00 yah, except that the hidden functions are actually executed 05:03:09 which doesn't happen in that Python code 05:03:13 the Haskell syntax is much more concise 05:03:20 shapr: they get executed 05:03:33 and it has a type system so it's harder to write incorrect code 05:03:33 I find that the strong type system catches lots of bugs 05:03:40 Heffalump: exactly! 05:03:42 hehe 05:03:56 Peaker: how so? 05:03:58 it's IMHO completely unrealistic to program anything with higher-order functions without a strong type system 05:04:03 isn't it called partial application ? 05:04:06 clausen: and more than trivial bugs? 05:04:12 Peaker: yes 05:04:20 (things you'd find about first time you unit-test your code anyways :) 05:04:31 Peaker: it often tells you that you are thinking about the problem in the wrong way, etc. 05:04:34 (I find) 05:04:35 I'm not convinced that static typing is an advantage over unit-testing myself 05:04:39 shapr: *a,*b is actually not allowed so that's invalid Python, let me show you real code: 05:04:43 you'd probably find the bugs if your unit-test did exercise the correct code path 05:04:47 >>> def curry(func, *args): return lambda *rest: func(*(args+rest)) 05:04:49 shapr: you find the bugs earlier 05:04:50 but compile-time is much better than test-time 05:04:58 >>> g=curry(f, 1, 2) 05:05:04 >>> g(3) 05:05:05 1 2 3 05:05:08 shapr: it isn't a substitute... but rather a time-saver 05:05:10 (f printing given a,b,c) 05:05:13 Heffalump, clausen: I'm not convinced, :) 05:05:15 (you don't pursue red herrings as much) 05:05:18 Heffalump: why? 05:05:24 well, I'm just saying my experience 05:05:28 ok, same here 05:05:34 Heffalump: why is compile-time better to find those things? 05:05:35 in C, I chase down lots of crappy bugs 05:05:38 peaker/shapr: well, you find them earlier 05:05:39 that I don't do in haskell 05:05:52 which saves you time 05:05:55 Heffalump: only to encourage you to 'it compiles! lets ship it' attitude? :) I mean, you must test it anyhow 05:06:04 not at all 05:06:09 it encourages you to get the design right 05:06:14 peaker: yes, of course. But you still save time because you find bugs earlier. 05:06:18 it's not just about the code "working" 05:06:28 the type system also forces you into a certain amount of cleanliness, IHO 05:06:29 IMHO 05:06:34 yeah 05:06:53 Heffalump: the time you spend compiling, fixing, compiling, ... is spent on hitting enter on exception lines and fixing it in runtime, which is just as quick from my experience, or sometimes even quicker 05:07:06 not in my experience 05:07:07 *shrug* 05:07:15 enter on exception lines? 05:07:22 I agree with Peaker, and I suspect none of us wil change our minds here :) 05:07:26 also, when you find problems during testing, how do you work out exactly where they are? 05:07:28 Heffalump: Just jumping to the faulty code 05:07:38 Heffalump: jumping to where the exception was raised 05:07:44 or to any of the callers of the function 05:07:52 umm, what if an exception wasn't raised, but you just got bad output? 05:07:53 so tell me: 05:08:00 why is C easier than assembler? 05:08:05 ahem 05:08:05 Heffalump: consider the time you spend typing the static typing information that is spent on writing more code in dynamic languages :) 05:08:17 I really want to settle this "can Python really do partial resolution" 05:08:22 hmmmm 05:08:28 probably a red herring... don't answer that 05:08:29 peaker: you don't have to type it in in Haskell, it can infer it 05:08:31 (my q) 05:08:39 clausen: because of its nested-expression syntax, abstraction of stack-framing, and many other abstractions 05:08:46 I only put static types in when they help me understand what a function does - it's kind of documentation 05:08:47 augh 05:08:51 * clausen agrees 05:09:01 also: 05:09:08 if you try to use a function in the wrong way, you hear about it 05:09:13 because EVERYTHING is a function 05:09:29 this type checking, in practice, digs up more dirt, so to speak 05:09:30 umm, that's not strictly true (that everything is a function) 05:09:33 Heffalump: ah. Okay, I believe in type inference to catch problems and optimize too, so I agree there. I just don't always like statically typing as it ends up killing polymoprhism and/or taking lots of valuable time 05:09:39 if you say "x = 5" then x isn't a function 05:09:46 yeah yeah :P 05:10:04 peaker: Haskell has a decent polymorphic type system, so static typing doesn't kill polymorphism 05:10:26 "taking lots of time" ? 05:10:39 (that's a slight simplification cos there are limitations to the polymorphism, but it's basically true) 05:10:43 the way I see it, Python is awesome and the best thing I've found yet, but it's also missing some pieces I'd like to have 05:10:46 Peaker: there are very rare cases, where Haskell's type system doesn't offer enough polymorphism. 05:10:47 * clausen thinks haskell has more polymorphis than, say, C++ in practise 05:10:49 Heffalump: doesn't writing 'string' in your dropVowel code deprive that code from working on lists of objects that can equal vowel characters? 05:10:53 so I'm willing to try Haskell to see if it works for me 05:11:12 peaker: yes. But it could be written to an interface that understood "isVowel" instead, if you wanted to 05:11:24 yah, type classes rock 05:11:30 with the advantage that if you did that, then if you accidentally tried to write it to an interface that didn't, you'd know about it 05:11:38 instead of getting some random result at runtime 05:11:38 Heffalump: but isVowel was written inside your dropVowel function, would that work? 05:11:57 no, you'd have to move it somewhere else if you wanted the interface to be "isVowel" 05:12:09 but if you wanted the interface to be "charOf", for example, then there'd be no problem 05:12:09 Peaker: he's saying, that you could define a type that has a method "isVowel" (effectively) 05:12:17 Heffalump: that seems like a lot more work 05:12:25 right 05:12:25 Peaker: actually it's really nice 05:12:30 peaker: two more lines 05:12:35 but, why would you want to do it? 05:12:38 or rather one more line and move the isVowel line somewhere else 05:12:39 you can add methods to any kind of type 05:12:42 (why would you want to make it polymorphic in this way?) 05:13:01 if you didn't have the type, what would happen if you tried to run dropVowels on a list of integers? 05:13:31 er, what would you call that type class anyway? 05:13:37 CharExts ? 05:13:40 dunno, Vowelable :-) 05:13:41 Heffalump: it'd drop all vowels, and leave the list as it is 05:13:53 class CharExts Char where -- ? 05:14:09 peaker: but it'd try to check if 5 == 'a', for example 05:14:21 Heffalump: which returns false 05:14:23 do you think that should always return false, rather than just being an error? 05:14:23 nope 05:14:28 it depends on the isVowel implementation 05:14:32 for each type 05:14:32 Heffalump: 5 and 'a' are both objects 05:14:45 class CharExts Char where 05:14:45 isVowel :: Char -> Char 05:14:45 isConsonant :: Char -> Char 05:14:46 peaker: there's a run-time penalty for that 05:14:48 Heffalump: ['a', 1, '2', 'b'] will return [1, '2', 'b'], [1,2,3] will return [1,2,3], it makes sense in a dynamic language 05:14:53 shapr: Char -> Bool 05:14:56 but you can set the default to "False" 05:15:02 Heffalump: there's a runtime penalty for pure functionality :) 05:15:03 Heffalump: oh, right, duh.. 05:15:12 (i.e. it's False for everything other than Chars immediately) 05:15:17 (unless they override) 05:15:28 clausen: but you still have to declare the interface 05:15:28 but you still have to say each type derives... 05:15:34 yep 05:16:08 anyway, I see this isVowel example as REALLY ugly 05:16:08 peaker: what do you mean? 05:16:27 (WTF do you want this kind of polymorphism. it's unnatural!) 05:16:33 s/./?!/ 05:16:36 :-) 05:16:56 clausen: look at the dynamic lists example 05:17:31 clausen: It might be useful if I have a list of varying-types 05:18:05 Peaker: why? 05:18:08 Peaker: Usually those varying types have some common property, which should be expressed as a type. Much safer that way 05:18:13 * clausen contends the opposite 05:18:14 Heffalump: pure functionality, as I understand it (which might be wrong :), disallows writing of some algorithms that depend on in-place mutability, and requires using alternative algorithms with far worse BigO time complexities 05:18:15 clausen: isVowel is a random example I came up with this morning from #loty 05:18:17 as a type class 05:18:37 * clausen thinks it's ugly, and never a good idea 05:18:57 peaker: yes, that's true. But the need to have only pure functions is a specific consequence of Haskell's laziness, rather than static typing. 05:19:04 teek: perhaps, but that costs you time and may be hard to 'formalize' without losing support of future changes 05:19:12 Peaker: the compiler can still implement it using an in-place algorithm 05:19:16 if we were talking about ML, for example, then you wouldn't have that penalty but you'd still have static typing 05:19:40 Heffalump: Okay, I meant to say that a performance hit is not always a factor in decisions, and always the last factor in Python decisions 05:19:41 clausen: but no compiler guarantees operational semantics to that extent, so you'd have no guarantees 05:19:49 right 05:19:53 clausen: converting algorithms like that would be solving the Halting Problem 05:20:00 Peaker: in the general case 05:20:07 Peaker: in practice, it's easier 05:20:14 hrm, what am I doing wrong here? 05:20:17 clausen: how would you implement a red-black-tree? 05:20:19 instance Char CharExts where 05:20:20 isVowel a = flip elem "aeiouAEIOU" 05:20:20 isConsonant = flip elem $ filter (not . isVowel ['A'..'Z'] ++ ['a'..'z'] ) 05:20:27 actually, in practice you use mutable stuff in the IO monad when you want the better time complexity :-) 05:20:31 Peaker: dunno... there's a book called "Purely Functional Data Structures" 05:20:38 Peaker: I'll read that first ;) 05:20:50 * clausen has bought it... it's waiting for me in .au 05:21:09 shapr: I suspect some brackets around the [ .. ] ++ [ .. ] would help 05:21:16 oh 05:21:17 clausen: Okasaki's book? 05:21:27 Heffalump: yep 05:21:28 Okasaki's Purely Functional Data Structures is a great reading ! I enjoyed that book a lot. 05:21:42 I need to get round to reading that 05:22:26 using Haskell does sometimes impose some form of algorithmic penalty, but as I've said that's because of its laziness, not the type system 05:22:35 However, it's true that there's many data structures and algorithms, which need destructive updates for simple implementation. Many graph algorithms for example. 05:22:37 clausen: I am not sure of what to make of a Haskell's programmer ability to implement a red black tree, where a procedural programmer can implement it based on algorithmic listings on the web... I mean, is Haskell a lot more difficult for low-level data structures? why wouldn't you want to combine procedural features into the language? 05:23:01 procedural (i.e. mutable values) features interact badly with laziness 05:23:03 rb tree should be quite easy to implement. and inplace and functional updates should have same complexity 05:23:04 However, in many cases, desctrutive updates can be hidden inside the algorithm. 05:23:12 Peaker: well, there are advantages to such "purity" 05:23:17 Peaker: it's easier to analyse 05:23:24 Peaker: easier for the compiler to optimize 05:23:25 Heffalump: don't guarantee laziness to work well when combined with side effects then 05:23:31 Peaker: it "feels" more elegant 05:23:34 (which is what motivates me) 05:23:41 clausen: the ease to optimize cancels out with the inability to do inplace changes 05:23:50 peaker: by "not work well" that means "no guarantee about what will actually happen" 05:23:56 Peaker: how do we know? 05:24:03 * clausen thinks more research... 05:24:05 peaker: and Haskell is fundamentally a lazy language, it's very hard *not* to use it. 05:24:07 rb trees can be implemented using pattern matching very elegantly 05:24:09 Peaker: anyway, like has been already said 05:24:12 Heffalump: Yes, like I'd guess Python laziness modules are implemented :) 05:24:18 Peaker: you can do RB trees, etc. easily in haskell 05:24:21 Peaker: just, you have to use monads 05:24:36 Peaker: (which is essentially a functional way of doing imperative programing) 05:24:41 monads are essentially the way that the semantics of updatable variables in a lazy language can be defined 05:24:54 clausen: okay, then why did you say you didn't know? And how would it work given that you need to make in-place changes? 05:25:32 didn't know what? 05:25:32 look at http://www.ai.univie.ac.at/~markus/ocaml_sources/pure_fun-1.0-2/chp3.ml for an implementation of a purely functional RedBlack set in Ocaml 05:25:52 Heffalump: you can implement lazy evaluation in Python, but I'm not quite sure I understand why you'd want it for any expression, and not only for things like map/filter/etc 05:26:07 teek: Ocaml supports inplace changes though.. 05:26:15 aha 05:26:20 instance CharExts Char where 05:26:20 isVowel a = elem a "aeiouAEIOU" 05:26:20 isConsonant a = elem a (filter (not . flip elem "aeiouAEIOU") ['A'..'Z'] ++ ['a'..'z']) 05:26:24 peaker: that module doesn't use it 05:26:33 clausen: didn't know how to implement a RB tree 05:26:42 peaker: well, you might want it for trees as well, for example 05:26:45 Peaker: in haskell... I did say I didn't know 05:26:51 Peaker: I said I should "read the book" 05:26:54 (remember?) 05:26:54 Peaker: yes, but that's a functional version 05:27:06 arghh 05:27:08 clausen: yeah, but then you said: you can do RB trees, etc. easily in haskell just, you have to use monads 05:27:10 Peaker: you can have pointers in haskell as well 05:27:13 clausen: which I find contraductory 05:27:21 Peaker: well, it's obvious you can use monads 05:27:30 Peaker: (which are really "non-functional" in a sense) 05:27:30 You have to hide them in a monad, or even use pointers that is in the IO-monad 05:27:34 dennisb: what are references useful for, when you might as well use a copy of the value? 05:27:40 Peaker: however, it turns out you don't need monads 05:27:47 anyway 05:27:49 Peaker: its about speed 05:27:50 what is a monad? 05:27:51 * clausen going back to hacking 05:28:01 gotta go 05:28:04 --- quit: teek ("Coffee break") 05:28:11 umm 05:28:11 a ds that might be harder to implement in functional languages is hashtable 05:28:14 dennisb: yes, but why would I want a pointer in the language level of a purely functional language 05:28:18 aha 05:28:19 got it 05:28:30 ok, here it is: 05:28:35 class CharExts a where 05:28:36 isVowel :: a -> Bool 05:28:36 isConsonant :: a -> Bool 05:28:37 a monad is an algebraic structure that amongst other things lets you encapsulate the use updatable values in a purely functional way 05:28:41 instance CharExts Char where 05:28:41 isVowel a = elem a "aeiouAEIOU" 05:28:42 isConsonant a = elem a (filter (not . flip elem "aeiouAEIOU") ['A'..'Z'] ++ ['a'..'z']) 05:28:45 smkl: or the simplest case of a hashtable, a mere array? 05:28:46 yay! and it even works! 05:28:47 s/use/use of/ 05:28:50 smkl: (mutable one) 05:28:55 shapr: cool :-) 05:29:07 sure 05:29:12 Peaker: for some problems you just need pointer, and there is a pure way to add them 05:29:19 shapr: why not reuse isVowel in isConsonant? 05:29:32 Heffalump: because I couldn't figure out how to do that :) 05:29:36 I'll try that, hang on 05:29:41 dennisb: I don't understand how it is possible you would need a pointer when the dereferenced object is always the same.. 05:29:58 one use of a pointer is for a quick equality test 05:30:03 dennisb: Couldn't you use a read-only-reference, or a copy of the object? 05:30:21 you can check two objects are the same by comparing them, but if they're very complicated that might take a while. Comparing the two pointers can save time. 05:30:23 Peaker: but then the algortihms might explode in size or something 05:30:25 I understand performance reasons but those sound easy to implement in the compiler-level 05:30:27 --- quit: mustard (Read error: 110 (Connection timed out)) 05:30:35 if they're the same the objects are the same, and if they're not, you compare the actual objects 05:30:40 dennisb: Okay, the compiler can simply never copy objects but only copy references 05:30:47 some graphalgorthims is a typical example where you really need pointers (references) 05:30:49 true 05:30:57 ok, got it 05:31:04 isConsonant a = elem a (filter (not . isVowel) ['A'..'Z'] ++ ['a'..'z']) 05:31:11 shapr: yep :-) 05:31:16 Heffalump: Okay, that is obvious, but I see that as a mere implementation detail 05:31:20 I'm so cool 05:31:25 * shapr does the nifty code dance 05:31:25 I don't see how "pointers" have to do with Haskell as a language 05:31:31 w00 05:31:39 they don't, much 05:31:56 --- join: mustard (~felix@159.180.250.254) joined #haskell 05:31:56 weren't you the one arguing earlier that having compilers do your implementation work is like solving the halting problem, btw? :-) 05:32:39 wheee 05:32:41 def isConsonant(l): import string ; return l in filter(lambda x: x.lower() not in "aeiou", string.letters) :) 05:32:54 Heffalump: converting copying-algorithms to inplace-changes is 05:33:01 you can use pointers, but you typically use them in a very small part of the program, like in a function for calculating something, and from the outside the function looks like any pure function 05:33:02 Heffalump: copying pointers rather than objects is trivial 05:33:39 dennisb: Again, why isn't it a hidden implementation detail of the compilation process, and appearant at the language level? 05:34:13 peaker: true 05:34:14 with monads, it is possible to emulate the sematics of other languages in haskell. with a state monad there is state, that is where pointers or references are useful 05:34:31 beacause no one have solved that problem. Best so far is letting the programmer handle this 05:35:08 10-15 years ago everyone tought you would never need to use pointers in a pure functional program, but state of the art changes. 05:35:12 dennisb: do you have a specific example of an algorithm that requires pointers as you describe? 05:35:16 smkl: and how are monads implemented? 05:35:28 Now I believe that most people think they really are needed 05:35:38 dennisb: Wouldn't such optimization only require the compiler to implement object copying as pointer copying? 05:35:39 Peaker: you should probably read stuff on www.haskell.org, and read some papers, etc. 05:35:39 peaker: often by the implementation of the language, so not in Haskell itself 05:35:44 but it depends on the monad 05:35:46 Heffalump: yes, you could use it to implement hashtables 05:36:06 yeah, point :-) 05:36:07 Heffalump: So Haskell is not a pure functional language and already more attractive :) 05:36:17 Peaker: it is purely functional 05:36:22 Peaker: how do you create a graph in memory? 05:36:22 clausen: not with monads.. 05:36:26 Peaker: monads are implemented in a purely functional way 05:36:34 peaker: any implementer of an external module has to guarantee that the *interface* to his module will be purely functional 05:36:52 you can't do IO without having an external library, for example 05:36:59 dennisb: An object containing copies of other objects within it will actually contain pointers to those objects in runtime, so its a graph.. 05:37:25 clausen: how is that possible? and in that case, why: peaker: often by the implementation of the language, so not in Haskell itself 05:37:28 boy am I glad this is being logged 05:37:50 Heffalump: yeah, I meant non-pure beyond I/O requirements 05:38:01 Peaker: go search google 05:38:03 the point is that the haskell main program returns a computation. this computation is contructed in a purely functional way. anyways, referential transparency remains 05:38:12 peaker: but as you yourself said, you can sometimes get better algorithmic performance with a non-pure implementation 05:38:13 well, then it needs to identify objects that should be the same, so it can change one of them to a pointer to the other 05:38:13 Peaker: I'm sure the original papers do a better job of explaining than me 05:38:19 but as I said, the *interface* must be pure. 05:39:27 to create the graph you really need references to distinct nodes so you can get hold of a special one and really point to that one 05:40:29 getChar and getChar are the same computation, but they might return different values depending on the context 05:40:29 smkl: that's why they are in the IO monad :-) 05:42:22 dennisb: if you guarantee objects are never copied but references are, you essentially have a graph 05:43:28 well, it can be hard to move pointers after you create it. 05:44:04 for creating I agree with you 05:44:18 there are for example algoritms where you reverse pointers in a graph 05:45:39 you really want to do that in place, and have a guarantee that it is fast, because the algorithm depends on that the pointer updating is O(1) 05:46:13 * Heffalump --> lunch and a meeting and stuff, bye 05:46:25 * shapr waves to Heffalump 05:47:48 --- quit: jewel (Read error: 110 (Connection timed out)) 05:54:34 Pointers are not dangerous, even functional programmers can use them. We just don't need them that often because we have polymorphi and higher order functions 05:59:59 And for the examples where you have a list with different kind of elements. Well, that doesn't happen to often, and if it does we would just have to put them in a tagged list. Even in a untyped language you need to know the type of the element anyway if you ever want to use it. But in an untyped language typically every value have a tag saying what type it is so it can generate runtime errors when something is wrong. 06:00:40 actually, in Python you don't necessarily have to know the type of what you're working on... 06:00:54 it has a very nifty thing that I'm not sure there's a name for.. 06:01:07 where you say "this function expects a X-like object" 06:01:14 like the classes in haskell, i guess 06:01:16 for example, a file-like object 06:01:19 yah, that kind of thing 06:01:48 in Haskell you'd write func :: File a => a -> b 06:01:58 and that's how almost everything in Python works 06:03:27 so func might be doing something like "func fileobjs = map read fileobjs" 06:04:05 yes 06:04:12 and those fileobjs could be actual file objects, strings acting as fileobjs (StringIO), arrays of whatever that just happen to have a read method, etc etc 06:04:58