- Haskell - Haskell.org

haskell-mode and xemacs
by Christian Maeder 03 Jul '03

03 Jul '03

Hi, whenenver I open a haskell file (*.hs) with my xemacs I get an annoying warning in a splitted window: (1) (error/warning) Error in `post-command-hook' (setting hook to nil): (void-variable imenu--index-alist) The modes (Haskell Font Ind Doc) seem to work, though. My xemacs has [version 21.4; April 2001]. I use this xemacs as it was installed without any customizations under Suse Linux 2.4.19-4GB on i686. I've found write-protected /usr/share/xemacs/xemacs-packages/lisp/haskell-*.elc files. The haskell-mode.elc does not seem to be the latest version: (defconst haskell-version "1.43" (#$ . 632)) I don't know how to include the *.el files of the latest haskell mode in xemacs. (I've no problems with GNU emacs.) The problem occurs on several laptops. Does someone has an advice? Thanks Christian

2 2

Template Haskell - read function
by Thomas L. Bevan 02 Jul '03

02 Jul '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm struggling to write the following function in Template Haskell. I have a phantom type, >data HTMLPage a = HTMLPage FilePath This type points to an HTML file, where 'a' refers to the return type of the posted form. So, mostly, I would expect types like HTMLPage (String, String, Date, Int) Where this represented a form the returned someone's first name, last name, dob and age. So, I want a function that will take the returned name/value pairs and cast them into the matching type. eg. >readForm :: Read a => [(String,String)] -> HTMLPage a -> a Can anyone give me any pointers or am I better off just abandoning this approach? Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/AsiKYha8TWXIQwoRAvzuAKDPHD4oztAPLFShEWsLuclT7BaImwCfSB8e 9c2aTbTCSpVwabXVsht62DM= =orX3 -----END PGP SIGNATURE-----

1 1

Suffix Tree
by Markus.Schnell＠infineon.com 02 Jul '03

02 Jul '03

Does anybody know of a suffix tree implementation for Haskell? Are there algorithms for a (lazy) functional setting? My reference is Dan Gusfield: "Algorithms on Strings, Trees, and Sequences: Computer Science and Computational Biology". Thanks, Markus -- Markus Schnell Infineon Technologies AG, CPR ET Tel +49 (89) 234-20875

2 1

Re: Ledit (was Re: [Caml-list] how to use a module) (fwd)
by Hal Daume III 01 Jul '03

01 Jul '03

There was some discussion about something like this a while ago...would this solve our problems? -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume ---------- Forwarded message ---------- Date: Tue, 1 Jul 2003 14:49:22 -0400 From: Neel Krishnaswami <neelk(a)alum.mit.edu> To: Matt Gushee <mgushee(a)havenrock.com> Cc: caml-list(a)pauillac.inria.fr Subject: Re: Ledit (was Re: [Caml-list] how to use a module) Matt Gushee writes: > > Okay, then, I have some questions about ledit: > > How do you use it? I have actually tried ledit 2 or 3 times, but if > I invoke the 'ledit' executable that is created, e.g. > > $ ./ledit > > I get ... something ... some sort of shell-like environment, I > guess. But all it does is echo whatever I type. And when I read your > post, I downloaded it again to be sure, but the same thing happened > again. I also tried making a custom toplevel with ledit, but the > result seems to be identical to the plain ledit executable. Do this $ ledit ocaml in order to get line editing in the ocaml toplevel. The really cool thing about ledit is that it adds line editing to *any* program. -- Neel Krishnaswami neelk(a)alum.mit.edu ------------------- To unsubscribe, mail caml-list-request(a)inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

1 0

foldr in terms of map
by Hal Daume 01 Jul '03

01 Jul '03

Kind of a random question for today :). We all know that we can write map in terms of foldr: > map f = foldr ((:) . f) [] as I understand it, this is essentially because foldr encapsulates all primitive recursive functions and since map is primitive recursive, we can implement it in terms of a fold. one thing that is interesting to note is that if we are also given references, a function to sequence monadic actions ('sequence_') and reverse, we can write foldr in terms of map (I do this in the IO monad, but as long as you have refs, it doesn't really matter -- if you used a "better" monad, you could replace the unsafePerformIO with something which doesn't sound so bad, but in this case, the operation is safe): > foldr f z l = unsafePerformIO $ do > v <- newIORef z > sequence_ $ map (modifyIORef v . f) (reverse l) > readIORef v Of course, we can postulate instead of sequence_, rsequence_, defined as: > rsequence_ :: Monad m => [m a] -> m () > rsequence_ [] = return () > rsequence_ (x:xs) = do rsequence_ xs; x; return () it's probably also possible to do it by storing in the reference a function which we compose, but that's not interesting here. now, when we're in the IO monad, the difference between the real foldr and the simulated one is that the simulated one cannot deal with infinite inputs. for instance: > head $ foldr (:) [] [1..] should return 1, which it does for the real version. the simulated one hangs. one might like to attribute this to the fact that IO is a strict monad, but that doesn't seem to be all -- we would also need to be able to read and write references lazily in order to get this to work completely. Q1: is this correct? is there a way to "fix" the above definition or to use a different monad to get laziness? i think not, but can't prove it. now, if we just limit ourselves to finite inputs, things look a lot better. however, this brings up really the main question i have. foldr (in its original form) is in some sense quintessentially(sp?) PR on lists, whereas map is not. however, it seems that the combination map+rsequence_+references is enough to give you full PR power. what more can we say about this? clearly references play the largest role here, but it also seems impossible to remove this dependence on the sequencing operation. clearly there is some class of algorithms weaker that primitive recursive into which both map and rsequence_ fall. these two functions are in some sence counterparts to eachother: map retains list structure and only modifies elements, which rsequence_ destroys list structure and doesn't modify (just "runs") elements. is there some sor tof theory that talks about this relationship? and why is it that when put together, these things are strong enough (plus refs) to subsume primitive recursiveness? - Hal p.s., responses delayed until after ICFP are equally welcome :) -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

2 1

RE: Language extension proposal
by Simon Peyton-Jones 30 Jun '03

30 Jun '03

If you have a class like this class FloatTraits a where mantissa :: Int then the type of mantissa is mantissa :: forall a. FloatTraits a => Int There's nothing wrong with this in principle; the difficulty is that when you say mantissa + 4 you aren't saying which float type to get the mantissa of. Earlier messages have outlined workarounds, but in some ways the "real" solution is to provide a syntax for type application. A polymorphic function should be applied to a type argument; these type arguments are always implicit in Haskell, but are explicit in System F. They are also explicit in O-O languages that support polymorphism. For example, in C++ one might say mantissa<Double> + 4 And in fact that's just what we *want* to say here. (The workarounds in earlier emails all amount to passing a *value* argument as a proxy for a type argument.) If we could only figure out a good syntax for (optional) type application, it would deal rather nicely with many of these cases. Trouble is, '<..>' gets confused with comparisons. And when there are multiple foralls, it's not obvious what order to supply the type parameters. It'd be useful in other situations too. For example, one could have lambdas at the type level, if one was willing to instantiate them explicitly. sequence :: forall (m:*->*) (a:*). [m a] -> m [a] data STB a s = s -> (a,s) -- Oops: got the parameters backwards ....sequence<\b. ST b MyState, Int>... Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Ashley Yakeley | Sent: 28 June 2003 00:25 | To: haskell(a)haskell.org | Subject: Re: Language extension proposal | | In article <20030625041751.GA29774(a)smtp.alicorna.com>, | Andrew J Bromage <ajb(a)spamcop.net> wrote: | | > Another example is floating point format information, like the | > information in C's <float.h>. One might implement this as: | > | > class (Bounded a) => FloatTraits a where | > epsilon :: a -- OK | > mantissaDigits :: Int -- Not OK! | | Oh I do this all the time in HBase. I simply do this: | | data Type a = MkType | | getType :: a -> Type a | getType _ = MkType | | class (Bounded a) => FloatTraits a where | epsilon :: a | mantissaDigits :: Type a -> Int | | The only annoyance is that you frequently have to write (MkType :: Type | MyFloat). Syntactic sugar for _that_ would be useful. | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

3 2

Re: Language extension proposal
by Ashley Yakeley 30 Jun '03

30 Jun '03

At 2003-06-30 01:55, Ralf Hinze wrote: >What about > mantissa (| Double |) + 4 ? This would work perfectly with my method if (| Double |) were syntactic sugar for (mkType :: Type Double) or similar. I really think it's the most straightforward way of doing it and I hazard the easiest to implement. -- Ashley Yakeley, Seattle WA Almost empty page: <http://semantic.org/>

1 0

Re: Language extension proposal
by Ashley Yakeley 28 Jun '03

28 Jun '03

At 2003-06-28 02:51, Ralf Laemmel wrote: >Suffering from persecution mania, >I prefer to know for sure that nobody never ever will >pattern match on those a's. So I prefer to write: I don't understand. Did you mean pattern-match on MkType? I could stop that by hiding it but exposing mkType = MkType. -- Ashley Yakeley, Seattle WA

2 1

Language extension proposal
by Andrew J Bromage 28 Jun '03

28 Jun '03

G'day all. I've been toying with an idea for a small language extension, and I was curious what you all think of this. As a motivating example, consider the following standard typeclass: class Bounded a where min :: a max :: a This is an example of what I refer to as a "traits typeclass" (by analogy to traits classes, well-known to C++ programmers). The idea is that you want to specify certain properties/operations which depend on a _type_, rather than any particular value of that type. Another example is floating point format information, like the information in C's <float.h>. One might implement this as: class (Bounded a) => FloatTraits a where epsilon :: a -- OK mantissaDigits :: Int -- Not OK! For obvious reasons, the declaration of mantissaDigits is not valid Haskell. Instead, you might do something like this: class FloatTraits a where mantissaDigits :: a -> Int instance FloatTraits Float where mantissaDigits _ = 24 instance FloatTraits Double where mantissaDigits _ = 53 and invoke it as, say: mantissaDigits (undefined :: Float) A decent strictness analyser can tell if an argument to some function is always unused (in GHC core terminology, this means its demand is "absent") and thus avoid passing the argument at all. However, it is currently impossible to tell if this is true all instances of a typeclass. What I would like is some annotation that I can use to tell my compiler that this argument of this method is always unused, no matter what instance it resolves to. My proposal is to grab a new punctuation symbol (I will use '~' as an example) to sit alongside the GHC extension use of '!'. Where '!' means that an argument may be evaluated before calling a function, '~' means than an argument may be ignored by the callee. So in the above example, I can write: class FloatTraits a where mantissaDigits :: ~a -> Int Now this marker is not as simple to implement as '!'. The strict marker is advisory; if you stripped all '!'s from your program, it would still have the same static semantics. Not so with '~', which must be statically checked. However, the static analysis is pretty trivial, except for the problem of inference. Basically, if a variable has absent demand, it a) can't be pattern matched on (unless the pattern is a variable, of course), and b) can't be passed as an argument to a function (including a data constructor) which doesn't also treat that argument as having absent demand. I therefore propose that the marker not be inferred for top-level definitions, or at least for exported definitions. If you declare it, it's checked, but otherwise it's not. In addition, any calls that you pass a variable with absent demand to must themselves have the marker declared explicitly in their type signatures. There may also be an argument for extending '~' to data constructors, in the same way that H98 uses '!'. This would allow parameters with absent demand to be stored in data structures. I can't think of a use for this right now, but it shouldn't be too much harder to add. What do you all think? Useful? Not worth the effort? Cheers, Andrew Bromage

6 5

sockets and handles in ghc
by Jurriaan Hage 27 Jun '03

27 Jun '03

Hello, I've been using sockets and handles with ghc-5.04.3. The strange thing is now that when I make a handle out of a socket and ask whether the handle is readable or writable, it returns True for the former and False for the latter, although sockets are bidirectional. And yes, I am able to read from and write the handle notwithstanding. I also got an exception once when working with these things and the debug information I got then, showed that both should have returned True instead. Can anyone enlighten me? thanks, Jur -- http://www.cs.uu.nl/people/jur/progrock.html -- jur(a)cs.uu.nl If e-mail does not work try jurriaanhage(a)hotmail.com

2 1