Re: [Haskell-cafe] pros and cons of static typing and side effects ?
On pondělí 29 srpna 2005 8:57, Ketil Malde wrote: It contains descriptions of lots of real-world problems and how They are only implementing TRUTH and CWB, no? Yes, and lots of real-world situations that they faced during the development. That's what I meant. 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? Please read section 5 in the paper. 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*). I am very sure they are aware of them. Interactive interpreters are simply not enough of a tool for commercial development - more sophisticated tools are necessary. In Haskell we don't even have basic things like code structure visualisation, efficient browsing and fully language-aware editor with typing support etc. This is one of the ways of distinguishing the mainstream languages. Mainstream means that enough people use them for someone to put in the effort to build the tools. vlcak ___ 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
[Haskell-cafe] Transactional in-memory model
Hi folks, I am new to Haskell, coming from an object-oriented realm. As an exercise I am trying to develop an API for accessing/changing services configuration in a SysV-like init environment. Being object-oriented I have defined a model of runlevels/services and a parser that creates instances of these structures from the underlying files. That way my program is able to interrogate the current state of the services configuration. Now I would like to ask how to go about designing the part that will make changes to the config in respect to the following requirement. I want the API to allow making changes only to the model and then applying them back to the filesystem at once. This is to support UI where the user will make various changes and then hit Apply or Cancel. I am imagining this as a sort of simple transactional behaviour of the in-memory model. At the moment I am thinking of passing the whole model around through the various API functions, that will make the changes, but there are many questions to be answered. I need to keep the original model state and a stack of the changes made so that at commit-time I can figure out what has been changed. Also some changes might affect each other (add service followed by remove service, etc.). Anyway the main question is how should such a scenario be approached. Can anyone throw in some ideas to get me started? It might well be that this whole idea of a model with changing state is wrong in respect to FP. If so, what would the right way be? Cheers vlcak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
