Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
Martin Vlk [EMAIL PROTECTED] writes: http://www-i2.informatik.rwth-aachen.de/Staff/Current/michaelw/sttt-ml-haskell.pdf Interesting to see others' experiences, even if they are slightly negative. It contains descriptions of lots of real-world problems and how They are only implementing TRUTH and CWB, no? Among other things it touches on the static typing pros and cons One critique against the paper is that they discuss language features at great length, but conclude that: |However, it turned out in our discussions that none of us were | enthusiastic about the idea of using a functional language for a | future verification tool because of their impoverished environments | compared with mainstream programming languages. I would like to see more discussion of what is impoverished about the environments, and what they consider mainstream programming languages. Certainly the authors could have discussed this in the main part of the paper? | Our impression was that SML and Haskell can play out their | advantages mainly in the prototyping stages of a project, an arena | where both would have to compete with dynamic languages like Lisp or | Smalltalk, or scripting languages like Python (which have faster | turn-aroundcycles due to absence of a compilation phase). I'm not sure the authors are even aware or the existence of interactive environments (e.g. Hugs and GHCi are not mentioned, only Haskell *compilers*). Disclaimer: I just browsed quickly through the paper. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
Hi folks, have you read this paper: http://www-i2.informatik.rwth-aachen.de/Staff/Current/michaelw/sttt-ml-haskell.pdf It contains descriptions of lots of real-world problems and how easily they are solved with Haskell (and ML, because the paper compares the two languages). Among other things it touches on the static typing pros and cons in a way that anyone who ever did serious programming will understand. vlcak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
My 2-pence worth on static typing.
Static typing to me seems to be a simplified form of design by contract.
There are some things about a program that can be proved true for all
time. Types are an example of such a thing. We can use type systems to
make assertions about properties that must be true for all time, and
then reject programs that break these rules.
One of the easyest things to prove about a program is that all values
and references are handled correctly - hence you will never see a
segmentation fault due to bad programming, it is just impossible (of
course the run-time-system which is written in C may cause one, but that
cannot be due to a bug in your program).
Taking one of your points in more detail:The single type property for
lists is not a problem due to the presence of algebraic datatypes, for
example want a list of strings and ints:
data StringOrInt = IsString String | IsInt Int
type ListOfStringOrInt = [StringOrInt]
You can also have lists of records... Think about it for a bit and you
will see there are very few cases where you need to have a list of
'general types'...
You can even use existential types to create lists of things with a
common interface, where you do not know in advance what types you may need:
data XWrap = XWrap (forall a . Show a = a)
type ListXWrap = [XWrap]
This creates a list where the items can be any type, provided they are a
member of the class Show. Also the only functions you can call on the
items in the list are the methods of the Show class... Of course you can
have multiple type constraints (forall a . (Show a,Num a) = a).
This is not the limit of how far we can go with static typing. We can
choose any provable property about a program... for example we could ask
that the compiler prove that the heap size of the program never exceeds
10M (not possible in any current language - but is an extension of the
concept).
Other things we can do ... with dependant types we can ask the compiler
to prove the correctness of sorting algorithms. If we define an ordered
list tgo be one where each element must be larger than the preceding one:
data OrderedIntList = Cons (a::Int) (l::OrderedList) | Nil {- where
a = head l -}
data IntList = [Int]
We can now define our sorting function:
quicksort :: IntList - OrderedIntList
By this we are asking the compiler to prove (by induction) that the
function provided can only result in
correctly ordered lists - irrespective of what arguments it is given (ie
proved true for any input)... This would have to be done symbolically
but is not beyond what can be achieved using logic programming.
To implement this, a Prolog program containing all the type constraints
of the function definition and
the proposed type would be evaluated... Prolog will say yes or no
to the function.
Regards,
Keean.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
On Tuesday 16 August 2005 21:56, Keean Schupke wrote: You can even use existential types to create lists of things with a common interface, where you do not know in advance what types you may need: data XWrap = XWrap (forall a . Show a = a) type ListXWrap = [XWrap] You probably meant to write data XWrap = forall a . Show a = XWrap a or, in GADT style (which I find a bit more intuitive here): data XWrap where XWrap :: Show a = a - XWrap Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
Keean Schupke wrote:
Other things we can do ... with dependant types we can ask the compiler
to prove the correctness of sorting algorithms. If we define an ordered
list tgo be one where each element must be larger than the preceding one:
data OrderedIntList = Cons (a::Int) (l::OrderedList) | Nil {- where a
= head l -}
data IntList = [Int]
We can now define our sorting function:
quicksort :: IntList - OrderedIntList
By this we are asking the compiler to prove (by induction) that the
function provided can only result in
correctly ordered lists - irrespective of what arguments it is given (ie
proved true for any input)... This would have to be done symbolically
but is not beyond what can be achieved using logic programming.
But the output being ordered is not enough. The output should also
be a permutation of the input. This can, of course, be expressed
in a similar way.
-- Lennart
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
Benjamin Franksen wrote: On Tuesday 16 August 2005 21:56, Keean Schupke wrote: You can even use existential types to create lists of things with a common interface, where you do not know in advance what types you may need: data XWrap = XWrap (forall a . Show a = a) type ListXWrap = [XWrap] You probably meant to write data XWrap = forall a . Show a = XWrap a or, in GADT style (which I find a bit more intuitive here): data XWrap where XWrap :: Show a = a - XWrap Yes I always get confused by the notation Haskell uses... I used explicit universal quantification by mistake. I tried to think logically about the encapsulation existential types represent - and got the wrong form. I for one would like to see the use of 'exists' as a keyword for existential types, after all different symbols are used in modal logic (upside-down-A for forall, and backwards-E for exists). Regards, Keean. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
On Tuesday 16 August 2005 22:29, Keean Schupke wrote: Benjamin Franksen wrote: On Tuesday 16 August 2005 21:56, Keean Schupke wrote: You can even use existential types to create lists of things with a common interface, where you do not know in advance what types you may need: data XWrap = XWrap (forall a . Show a = a) type ListXWrap = [XWrap] You probably meant to write data XWrap = forall a . Show a = XWrap a or, in GADT style (which I find a bit more intuitive here): data XWrap where XWrap :: Show a = a - XWrap Yes I always get confused by the notation Haskell uses... Same here. I used explicit universal quantification by mistake. I tried to think logically about the encapsulation existential types represent - and got the wrong form. I for one would like to see the use of 'exists' as a keyword for existential types, after all different symbols are used in modal logic (upside-down-A for forall, and backwards-E for exists). I once read a paper about type classes and existentials (can't remember exact title or author, was it Läufer?) where the proposal was to make existential quantification implicit (just as the universal one is in Haskell98). That is, any type variable that appears on the rhs of a data type, but not on the lhs, is implicitly existentially quantified, as in data XWrap = Show a = XWrap a I always thought this was a pretty nice idea. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
Lennart Augustsson wrote:
Keean Schupke wrote:
quicksort :: IntList - OrderedIntList
By this we are asking the compiler to prove (by induction) that the
function provided can only result in
correctly ordered lists - irrespective of what arguments it is given
(ie proved true for any input)... This would have to be done
symbolically but is not beyond what can be achieved using logic
programming.
But the output being ordered is not enough. The output should also
be a permutation of the input. This can, of course, be expressed
in a similar way.
Yes, the easiest way would be to constrain the output list to be a subset of
the input list, and vice-versa... something like:
quicksort :: (x::IntList) - (y::OrderedIntList) {- where x : y
x : y -}
of course you would have to use the correct definition of subset - you
really want to
treat the list as a multi-set.
Keean.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
Benjamin Franksen wrote: as in data XWrap = Show a = XWrap a I always thought this was a pretty nice idea. Wow, I hadn't thought of that... of course you still need to explicitly give the universal quantification if you need it. I guess the best option is to make it optional, as I still like the look of: data XWrap = exists a . Show a = XWrap a It kind of say this is existential quantification in large freindly letters... (A bit like a book I once read - except that said Don't Panic) Keean. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell] pros and cons of static typing and side effects ?
Perhaps this discussion could move to Haskell-café? We try to keep the bandwidth on Haskell@haskell.org fairly low. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Meacham | Sent: 12 August 2005 00:47 | To: haskell@haskell.org | Subject: Re: [Haskell] pros and cons of static typing and side effects ? | | On Thu, Aug 11, 2005 at 03:40:25PM -0400, Hamilton Richards wrote: | At 10:40 PM +0200 2005/8/10, mt wrote: | ... Languages with | static typing would be more suitable if programs were something you thought | of in advance, and then merely translated into code. But that's not how | programs get written. | | Well, that is actually how lots of programs do get written. | | For software that is experimental and exploratory, whose code | undergoes continual change and whose only users are the code's | authors, static typing is arguably a dispensable nuisance. A type | error that pops up during execution is probably no more inconvenient | than one that's caught by static type checking. That's why Lisp is | popular for AI work. | | I find pretty much completly the opposite is true. for random hacking | and evolving code, static typing is essential. There is only so much | room in one's brain to keep track of how everything works. if you were | meerly translating from a previous design, this isn't so much an issue. | but when writing code that is evolving and changing and perhaps you | don't quite know how it will turn out, your ability to recall and | understand how everything works together is a major limiting factor on | the scope of what you can acomplish. Static typing offloads a _ton_ of | responsibility away from the programmer. you no longer need to worry or | even think about what types are held in variables because you know any | mistakes will be caught by the compiler. and with haskell's advanced | type system, you can encode much more advanced constraints and | invarients in the type system offloading even more work from your brain. | Haskell's strong type system made me writing jhc alone possible, not | because of the better reliability (that is great though!), but because | it let me 'forget' about so many inconsequential details that they type | system enforced so I only needed to use brain-space for high level | constructs and my overall evolving, changing, plan. I tend to only use | perl or other dynamically typed languages when writing something that I | know exactly what it will do and how to do it beforehand, because I find | it to be quite an inflexible language when it comes to changing code | after the fact, not because of any syntatic difficulty, but because you | basically have to constantly redervive everything the program does and | all the unspoken invarients to understand it and how to change it. which | is something that gets super-linearly harder as code size grows. | | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | ___ | 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
[Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
[Moved to the Haskell cafe] It's Friday afternoon here so I thought I'd join in the fun. On Thu, 2005-08-11 at 23:01 -0400, [EMAIL PROTECTED] wrote: While you can't be certain that once your code typechecks, it's bug-free (though that does often happen), you can be almost guaranteed that if your code typechecks after a refactoring, the refactoring didn't introduce any bugs. (I tend to agree with ajb's sentiment, but I'll play the devil's advocate anyway). Perhaps we can reach a fixed point of violent agreement? I'm a bit concerned with can't be certain on the one hand, and _almost_ guaranteed, on the other. I guess there are nuances to be explored here, and it is all about degree of confidence. Sometimes I have high confidence in my refactoring, like introducing a state monad. Other times I have much less confidence, like swapping the order of arguments in numerical calculations. However, if it weren't for static type checking then I would be much less game to even _try_ introducing a state monad in my code in the first place. (Maybe that's just me). Another colleague of mine gave the opinion that one of the reasons higher-order code is less common in Prolog than Haskell is that in Prolog does not have static type checking (it's just one factor out of many). It seems to me like static type checking has the capacity to make some refactorings much less heroic than they would be in the non-static setting. That's my log on the fire for today. Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] pros and cons of static typing and side effects ?
mt [EMAIL PROTECTED] writes: http://paulgraham.com/lispfaq1.html [Most hackers I know have been disappointed by the ML family. Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written. I disagree. Static typing in essence gives you a lot of small unit tests for free. When refactoring code, these tests are often sufficient to ensure that the refactored code works. (Other types of errors are usually weeded out in the unfactored code, and not introduced by refactoring) Static typing also gives you the flexibility to juggle compositions of higher order functions; I almost always commit type errors when constructing a largish expression, but when the type errors are weeded out, more often than not the expression works as expected. All IME, of course. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] pros and cons of static typing and side effects ?
Hello mt, Thursday, August 11, 2005, 12:40:39 AM, you wrote: m [thnk 4 the previous answers !] m Good [morning, afternoon, night], m I try to better understand some things... maybe you can help me. m Id' like to know what are the pros and cons of (not) having static typing. m Same question for (direct support of) side effects. m To help you to find answers, here I quote this page : m http://paulgraham.com/lispfaq1.html m [Most hackers I know have been disappointed by the ML family. Languages with m static typing would be more suitable if programs were something you thought m of in advance, and then merely translated into code. But that's not how m programs get written. m The inability to have lists of mixed types is a particularly crippling m restriction. It gets in the way of exploratory programming (it's convenient m early on to represent everything as lists), and it means you can't have real m macros.] i can quote someone from this list: if haskell compiler allow my program to be compiled then i know that there is no more errors in it. static typing is just an instrument which catches much more programmers' errors. static typing don't allow more programs tobe compiled - conversely, it prohibits a part of programs/techniques. but if you want to WORK, not hack - that is a right way m Same question for (direct support of) side effects. it's just because Haskell is a lazy language. this rises expresivness and strongly divides program to two parts - without side effects and with side effects -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] pros and cons of static typing and side effects ?
Bulat Ziganshin [EMAIL PROTECTED] writes: I can quote someone from this list: if haskell compiler allow my program to be compiled then I know that there is no more errors in it. I wish quotes like this weren't bandied about without mentioning that they almost entirely, but not quite, true. Of course many programs that compile have bugs in them! A more accurate statement is that static typing catches a lot of trivial errors, and can be leveraged to make more complex errors less likely to occur and faster to track down. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] pros and cons of static typing and side effects ?
i can quote someone from this list: if haskell compiler allow my program to be compiled then i know that there is no more errors in it. static typing is just an instrument which catches much more programmers' errors. static typing don't allow more programs tobe compiled - conversely, it prohibits a part of programs/techniques. but if you want to WORK, not hack - that is a right way yes, that's the kind of answer i expected... that's the kind of thing you always see when reading something about haskell. but i guess there's arguments against... i'd like to make my opinion without just reading a post saying it catches many errors. maybe this mailing list is not the right place to ask this question ;-) maybe i should ask on a lisp mailing list :) m Same question for (direct support of) side effects. it's just because Haskell is a lazy language. this rises expresivness and strongly divides program to two parts - without side effects and with side effects the way it's divided is to remain purely functional. would it be bad if the side effects part was designed without keeping a pure functional language ? i see sometimes this kind of arg : it's easier to reason with a pure functional semantic. is this hold when you have to program a fair amount of imperative code in haskell? in fact my first question was not haskell centric but more general, like if i wanted to design a new language, not like if i wondered which language to choose. regards, mt ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] pros and cons of static typing and side effects ?
From: mt [mailto:[EMAIL PROTECTED] yes, that's the kind of answer i expected... that's the kind of thing you always see when reading something about haskell. but i guess there's arguments against... i'd like to make my opinion without just reading a post saying it catches many errors. maybe this mailing list is not the right place to ask this question ;-) maybe i should ask on a lisp mailing list :) For far more reading than anyone could possibly tolerate, see various dicussions at http://lambda-the-ultimate.org. Go to the home page, enter static typing in the search box, and then report back two days later :-) e.g. Why type systems are interesting http://lambda-the-ultimate.org/node/view/100 (continued (!) in part II http://lambda-the-ultimate.org/node/view/175 ) Alistair. - * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] pros and cons of static typing and side effects ?
At 10:40 PM +0200 2005/8/10, mt wrote: ... Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written. Well, that is actually how lots of programs do get written. For software that is experimental and exploratory, whose code undergoes continual change and whose only users are the code's authors, static typing is arguably a dispensable nuisance. A type error that pops up during execution is probably no more inconvenient than one that's caught by static type checking. That's why Lisp is popular for AI work. On the other hand, for code that is intended for wide distribution, static typing is extremely useful. When a user swipes his card in an ATM, you don't want the machine's response to be Sorry, type error. A successful static type check amounts to a partial correctness proof, i.e., a guarantee that a large class of possible errors will not occur during execution. That guarantee is worth some inconvenience-- or would be, if static typing were in fact inconvenient. I'd argue, however, that for software that's being written for a specified purpose, and which therefore has a well defined specification, static type checking is a definite convenience-- it automates some of the reasoning that responsible programmers are obliged to undertake in any case. Of course I have to concede that much software that's sold to customers is not actually thought of in advance, but is developed haphazardly, with inordinate effort expended on debugging. This regrettable practice no doubt bears much of the blame for the deplorable state of the software industry, which is the only one I know of whose products are routinely sold with a disclaimer of all responsibility for their quality. Regards, --Ham -- -- Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer (retired)The University of Texas at Austin [EMAIL PROTECTED][EMAIL PROTECTED] http://www.cs.utexas.edu/users/ham/richards -- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] pros and cons of static typing and side effects ?
On Thu, Aug 11, 2005 at 03:40:25PM -0400, Hamilton Richards wrote: At 10:40 PM +0200 2005/8/10, mt wrote: ... Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written. Well, that is actually how lots of programs do get written. For software that is experimental and exploratory, whose code undergoes continual change and whose only users are the code's authors, static typing is arguably a dispensable nuisance. A type error that pops up during execution is probably no more inconvenient than one that's caught by static type checking. That's why Lisp is popular for AI work. I find pretty much completly the opposite is true. for random hacking and evolving code, static typing is essential. There is only so much room in one's brain to keep track of how everything works. if you were meerly translating from a previous design, this isn't so much an issue. but when writing code that is evolving and changing and perhaps you don't quite know how it will turn out, your ability to recall and understand how everything works together is a major limiting factor on the scope of what you can acomplish. Static typing offloads a _ton_ of responsibility away from the programmer. you no longer need to worry or even think about what types are held in variables because you know any mistakes will be caught by the compiler. and with haskell's advanced type system, you can encode much more advanced constraints and invarients in the type system offloading even more work from your brain. Haskell's strong type system made me writing jhc alone possible, not because of the better reliability (that is great though!), but because it let me 'forget' about so many inconsequential details that they type system enforced so I only needed to use brain-space for high level constructs and my overall evolving, changing, plan. I tend to only use perl or other dynamically typed languages when writing something that I know exactly what it will do and how to do it beforehand, because I find it to be quite an inflexible language when it comes to changing code after the fact, not because of any syntatic difficulty, but because you basically have to constantly redervive everything the program does and all the unspoken invarients to understand it and how to change it. which is something that gets super-linearly harder as code size grows. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] pros and cons of static typing and side effects ?
G'day all. Quoting John Meacham [EMAIL PROTECTED]: I find pretty much completly the opposite is true. for random hacking and evolving code, static typing is essential. I agree with that. While you can't be certain that once your code typechecks, it's bug-free (though that does often happen), you can be almost guaranteed that if your code typechecks after a refactoring, the refactoring didn't introduce any bugs. This is a crucial property of sufficiently typed languages which I rely on all the time when evolving code. In addition, coming up with typed data structures tends to focus my thinking early. I think it was Dijkstra who commented that he could understand your code much better if you show him your algorithms AND your data structures, rather than showing him your algorithms alone. When programming in a less statically-typed language, I often find myself having to document the structure of the data during the random hacking phase anyway, even if I'm only using diagrams on paper. So why not document it in a form that the computer can also understand? One thing I do sympathise with is that programming in a statically typed language is no fun if the type system isn't flexible enough to support serious hacking. You really can feel like you're fighting the type system. Older ML variants (I have particularly bad memories of SML), and older Turner-esque languages for that matter, are no match for Haskell 98 plus Glasgow extensions or O'Caml in this respect. Cheers, Andrew Bromage ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: [Haskell] pros and cons of static typing and side effects ?
The previous comments make sense to me. The lots-of-unit-tests aspect of static typing I find really useful, far exceeding any BDSM cost. If I'm engaging in exploratory programming, the type inference combined with the ability to write 'error armadillo' in stubs for values I can't be bothered to generate right now really works conveniently for me. Although I agree that lots-of-lists is very handy in early prototyping, I don't feel at all constrained by using homogeneous lists, although very occasionally I may use existential types, and the way I write programmes is exactly to think in advance and then write the code: to do otherwise just wastes my time because then the code doesn't work in some confusing way and I have to do that thinking I postponed to figure out why - or, if it does work, I have to think about it to satisfy myself that appearances aren't deceiving. I'm not quite sure what macros would look like in Haskell, but I've not missed those either. In Lisp I would tend to use them for things that involved changing the values of variables, but that's not really a Haskellish thing to be doing anyway. Mind you, I learned Lisp after learning ML, so to some extent I was thinking in ML when writing in Lisp. Alas, dead-tree versions of On Lisp are hard to come by affordably, but I am now trying to learn more about what I might have missed about Lisp. I find monads useful because I find it a helpful debugging aid for functions to be quite clear about what side effects they may want to have. I posted this to Haskell-Cafe instead of the main Haskell list, because I'm rambling a bit. Puzzled Haskell-Cafe readers may like to check http://www.mail-archive.com/haskell@haskell.org/msg17009.html -- Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
