Re: framework for composing monads?
(Moving to haskell cafe...) On 18-Feb-2001 Manuel M. T. Chakravarty wrote: >> It is even acceptable for me to manage the state in C - >> independent of the API design - but then some time there >> will be the question: Why do I always say that that Haskell >> is the better programming language, when I'm >> really doing all the tricky stuff in C?... > > Sure - therefore, I proposed to use `IORef's rather than C > routines. Thanks for the hint! I took a look at them and now have some questions: a) It is clear that I need some C-link to access the cli/odbc lib. Up to now I planned to use Haskell Direct for this. Except of this, I want to stick to Haskell 98 and seek for maximal portability. Practically, this raises the question of wether nhc and hbc support hslibs or else I can provide a substitute for IORef's for these compilers. Can someone give me hint? b) What I finally need is "hidden state". My first attempt to get one using IORefs is: > import IOExts > > state :: IORef Int > state = unsafePerformIO $ newIORef 0 > > main = seq state $ do > writeIORef state 1 > currstate <- readIORef state > putStr (show currstate) Is this the right way? Cheers, Elke --- "If you have nothing to say, don't do it here..." Elke Kasimir Skalitzer Str. 79 10997 Berlin (Germany) fon: +49 (030) 612 852 16 mail: [EMAIL PROTECTED]> see: <http://www.catmint.de/elke> for pgp public key see: <http://www.catmint.de/elke/pgp_signature.html> ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Just for your fun and horror
Another good exam question (Hmm!): What does last (last (map return [1..])) lastly return given that last (return (not True))? I also would prefer "unit". "return" makes sense for me as syntactic sugar in the context of a "do"-expression (and then please like an unary prefix-operat or with low binding power...). An alternative sugary would be "compute": When a monad represents a computation, "init" returns a computation with a result, not just the result: foo x = if x > 0 then compute x*x else compute -x*x By the way, an alternative for "do" would be "seq" (as in occam) to indicate that operations are sequenced: getLine = seq c <- readChar if c == '\n' then compute "" else seq l <- getLine compute c:l But such a discussion has probably already been taken place some years ago. It would be interesting for me to know the arguments that led to the choice of "return" (and "do"). Elke. --- "If you have nothing to say, don't do it here..." Elke Kasimir Skalitzer Str. 79 10997 Berlin (Germany) fon: +49 (030) 612 852 16 mail: [EMAIL PROTECTED]> see: <http://www.catmint.de/elke> for pgp public key see: <http://www.catmint.de/elke/pgp_signature.html> ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Show, Eq not necessary for Num [Was: Revamping the numeric c
On 07-Feb-2001 Patrik Jansson wrote: (interesting stuff deleted) > As far as I remember from the earlier discussion, the only really visible > reason for Show, Eq to be superclasses of Num is that class contexts are > simpler when (as is often the case) numeric operations, equality and show > are used in some context. > > f :: Num a => a -> String -- currently > f a = show (a+a==2*a) > > If Show, Eq, Num were uncoupled this would be > > f :: (Show a, Eq a, Num a) => a -> String > > But I think I could live with that. (In fact, I rather like it.) Basically I'm too. However, what is missing for me is something like: type Comfortable a = (Show a, Eq a, Num a) => a or class (Show a, Read a, Eq a) => Comfortable a instance (Show a, Read a, Eq a) => Comfortable a I think here is a point where a general flaw of class hierachies as a mean of software design becomes obvious, which consists of forcing the programmer to arbitrarily prefer few generalizations to all others in a global, context-independent design decision. The oo community (being the source of all the evil...) usually relies on the rather problematic ontological assumption that, at least from a certain point of view (problem domain, design, implemention), the relevant concepts form in a natural way a kind a generalization hierarchy, and that this generalization provides a natural way to design the software (in our case, determine the type system in some a-priory fashion). Considering the fact that a concept, for which (given a certain point of view) n elementary predicates hold a-priory, n! possible generalizations exist a-priory, this assumption can be questioned. In contrary to the given assumption, I have made the experience that, when trying to classify concepts, even a light shift in the situation being under consideration can lead to a severe change in what appears to be the "natural" classification. Besides this, as is apparent in Show a => Num a, it is not always a priory generalizations that are really needed. Instead, the things must be fit into the current point of view with a bit force, thus changing concepts or even inventing new ones. (For example, in the oo community, which likes (or is forced?) to "ontologize" relationships into "objects", has invented "factories" for different things, ranging from GUI border frames to database connection handles. Behind such an at first glance totally arbitary conceptualization might stand a more rational concept, for example applying a certain library design principle called "factory" to different types of things. However one can't always wait until the rationale behind a certain solution is clearly recognized.) In my experience, both class membership and generalization relationships are often needed locally and post hoc, and they sometimes even express empirical (a-posteriory) relations between concepts instead of true analytical (a-priory) generalization relationships. As a consequence, for my opinion, programming languages should make it possible and easy to employ post-hoc and local class membership declarations and post-hoc and local class hierarchy declarations (or even re-organizations). There will of course be situations where a global a-priory declaration of generalization nevertheless still make completely sense. For Haskell, I could imagine (without having having much thought about) in addition to the things mentioned in the beginning, several things making supporting the "locally, fast and easy", including a mean to define classes with implied memberships, for example declarations saying that "Foo is the class of all types in scope for which somefoo :: ... is defined", or declarations saying that "class Num is locally restricted to all instances of global Num which also belong to Eq". Elke. --- Elke Kasimir Skalitzer Str. 79 10997 Berlin (Germany) fon: +49 (030) 612 852 16 mail: [EMAIL PROTECTED]> see: <http://www.catmint.de/elke> for pgp public key see: <http://www.catmint.de/elke/pgp_signature.html> ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: gui building in haskell
On 16-Jan-2001 Jan Kort wrote: (interesting stuff snipped...) > Ashley Yakeley wrote: >> Would some kind Haskell-to-Java bridge be a cost-effective way of >> providing a multi-platform GUI library, as well as network, SQL, RMI >> etc., etc.? >> >> It doesn't necessarily imply compiling to the JVM. Java could simply see >> the compiled Haskell code through the JNI. > > That sounds unlikely to me, how do you overide methods through JNI ? > The only way I can see this working is the way Mondrian does it: > make a more object oriented Haskell and compile to Java. I don't > think Mondrian is anywhere near an alpha release though. Aside: I often think that the Java-GUI, SQL and etc. stuff is also anywhere near an alpha release ... Best, Elke > > Jan > > ___ > Haskell-Cafe mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell-cafe --- "If you have nothing to say, don't do it here..." Elke Kasimir Skalitzer Str. 79 10997 Berlin (Germany) fon: +49 (030) 612 852 16 mail: [EMAIL PROTECTED]> see: <http://www.catmint.de/elke> for pgp public key see: <http://www.catmint.de/elke/pgp_signature.html> ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
