[Haskell-cafe] mistake in Gentle Introduction
On this page: http://www.haskell.org/tutorial/modules.html it refers to the process of hiding imported names from a module and gives the example: import Prelude hiding length whereas the correct syntax is import Prelude hiding (length) I spent nearly an hour beating my head against this. Can someone fix this in the documentation? Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Wed, Sep 21, 2005 at 12:12:16PM +0100, Immanuel Litzroth wrote: > "Tomasz Zielonka" <[EMAIL PROTECTED]> writes: > > > On Wed, Sep 21, 2005 at 08:53:47AM +0100, Immanuel Litzroth wrote: > >> "David F. Place" <[EMAIL PROTECTED]> writes: > >> > >> >I was hoping that the examples I requested would be examples of > >> >particular control constructs or extensions to the language's syntax > >> >and semantics. Though I admit that such things are possible in lisp, > >> >I suspect that their utility is minimal. > >> > >> Ever heard of the loop macro? > >> Immanuel Litzroth > > > > I would be nice if you could give some examples for use of LOOP macro > > that you think would be cumbersome to translate to Haskell. > > > That was not the original question and I think that would lead to > pointless discussion about the meaning of "cumbersome". You are right, sorry. I agree that the ability to create your own control structures is a win. I only argue that when it's possible, it's better to avoid using macros for this. > Another example is UFFI, basically a bunch of macros to do platform > independent foreign function interfaces. Good example - laziness, HOFs and closures don't help much here. > I a currently writing a macro to generate the functions and > datastructures to read an ipod database. This allows me to > declaratively say > (defheader (header-name inherits-from) >(field-name length &optional reader)...). > I doubt this would be easy in Haskell (maybe with TH it could be done) I am doing similar things with Haskell. The amount of TH code needed is minimal, I prefer to put most of the machinery in the type system. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] killing a running thread interactively
More particularly, is there a getAllThreadIds function somewhere? -Ale- On Wed, 21 Sep 2005, S. Alexander Jacobson wrote: Is the general pattern to write all threadIds to a file, and then have a separate function that takes the file and kills them? Or is there something more clever? -Alex- On Wed, 21 Sep 2005, Simon Marlow wrote: On 16 September 2005 20:42, S. Alexander Jacobson wrote: If I am running a server interactively. (using ghci). Is there any way to kill its running threads without terminating the interpreter? If you can get ThreadIds for the threads, yes. GHCi doesn't (currently) create a new thread for each expression evaluation, so attempting to kill that thread might kill your GHCi session (it shouldn't but that's another story). Cheers, Simon ** CRM114 Whitelisted by: [EMAIL PROTECTED] ** __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] killing a running thread interactively
Is the general pattern to write all threadIds to a file, and then have a separate function that takes the file and kills them? Or is there something more clever? -Alex- On Wed, 21 Sep 2005, Simon Marlow wrote: On 16 September 2005 20:42, S. Alexander Jacobson wrote: If I am running a server interactively. (using ghci). Is there any way to kill its running threads without terminating the interpreter? If you can get ThreadIds for the threads, yes. GHCi doesn't (currently) create a new thread for each expression evaluation, so attempting to kill that thread might kill your GHCi session (it shouldn't but that's another story). Cheers, Simon ** CRM114 Whitelisted by: [EMAIL PROTECTED] ** __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Sep 21, 2005, at 10:58 AM, Immanuel Litzroth wrote: I personally find loop usually the most concise way to express my iteration requirements. Perhaps, but with tail recursion equivalent to iteration you no longer have any real "requirement" to iterate. It's a lifestyle choice. :-) David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Network parsing and parsec
On Wednesday 21 September 2005 20:17, John Meacham wrote: > On Wed, Sep 21, 2005 at 12:32:56AM +0200, Benjamin Franksen wrote: > > On Tuesday 20 September 2005 16:50, John Goerzen wrote: > > > On the flip side, Parsec is really nice. I wonder how easy it > > > would be to make it parse [Word8] instead of String? > > > > Isn't Parsec parameterized over the token type? > > > > > Or even a > > > FastPackedString? (And how easy it would be to get that instead > > > of a String from hGetContents)? > > > > From the FPS haddock: > > > > hGetContents :: Handle -> IO FastString > > > > Read entire handle contents into a FastString. > > > > This may or may not do what you want...it's probably not a lazy > > read. > > If it can be implemented via 'mmap' then it is effectivly a lazy > read. and _very_ efficient to boot. True, I forgot mmap. Taking a look at the implementation reveals that it indeed uses mmap (if available on the platform). Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Really confused
On Wed, 21 Sep 2005, Mark Carter wrote: I get the idea that data SM a = SM (S -> (a,S)) maps a state to a result, and a new state. OTOH, looking at instance Monad SM where -- defines state propagation SM c1 >>= fc2 = SM (\s0 -> let (r,s1) = c1 s0 SM c2 = fc2 r in c2 s1) return k = SM (\s -> (k,s)) just confuses me no end. It really broke my brain for a while too - I had to graph the thing out on a piece of paper before I could follow what it was doing. The return should be easy enough, no? In the >>= code, c is "unboxed computation", fc is "function yielding computation", r is "result" and s is "state" - the first line of the let gets the result of the first computation and the state after it, the second line applies fc2 to the result to get the second computation and then the final line applies the computation to the intermediate state. There's a little boxing and unboxing going on, but that's pretty much it. Any pointers, like am I taking completely the wrong approach anyway? I'm also puzzled as to how the initial state would be set. You set the initial state with a "run" function, like so: runSM (SM f) initialState = f initialState The result will be a tuple: (result, finalState) -- [EMAIL PROTECTED] The task of the academic is not to scale great intellectual mountains, but to flatten them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Network parsing and parsec
On Wed, Sep 21, 2005 at 12:32:56AM +0200, Benjamin Franksen wrote: > On Tuesday 20 September 2005 16:50, John Goerzen wrote: > > On the flip side, Parsec is really nice. I wonder how easy it would > > be to make it parse [Word8] instead of String? > > Isn't Parsec parameterized over the token type? > > > Or even a > > FastPackedString? (And how easy it would be to get that instead of a > > String from hGetContents)? > > From the FPS haddock: > > hGetContents :: Handle -> IO FastString > > Read entire handle contents into a FastString. > > This may or may not do what you want...it's probably not a lazy read. If it can be implemented via 'mmap' then it is effectivly a lazy read. and _very_ efficient to boot. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Really confused
I'm trying to define a type called Stream. For now, assume that that the type has 3 fields: uid, x, y. X and y represent a point in space that a stream occupies, and uid is a unique identifier for the stream. The uid should be "auto-generated". It's important that streams have an identity so that they can be referred to and manipulated. Streams will be put together into a list, and they'll eventually need to be able to point to one another. It would be nice to be able to print the uid, just to show that it works. Now it occured to me that what one might want to generate the uids is a monad, let's call it UID. It'll have a function get, which returns another identifier. I assumed that the best solution for the problem would be in terms of monads, because successive calls to get return different results; i.e. there's a bit of state going on inside. The values returned can start from 1, and increment by 1 each time. I had a look at some documentation at: http://www.haskell.org/tutorial/monads.html and I'm afraid my brain just froze. I get the idea that data SM a = SM (S -> (a,S)) maps a state to a result, and a new state. OTOH, looking at instance Monad SM where -- defines state propagation SM c1 >>= fc2 = SM (\s0 -> let (r,s1) = c1 s0 SM c2 = fc2 r in c2 s1) return k = SM (\s -> (k,s)) just confuses me no end. Any pointers, like am I taking completely the wrong approach anyway? I'm also puzzled as to how the initial state would be set. ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Network parsing and parsec
On Wednesday 21 September 2005 19:36, Jan-Willem Maessen wrote: > On Sep 20, 2005, at 6:32 PM, Benjamin Franksen wrote: > > On Tuesday 20 September 2005 16:50, John Goerzen wrote: > >> On the flip side, Parsec is really nice. I wonder how easy it > >> would be to make it parse [Word8] instead of String? > > > > Isn't Parsec parameterized over the token type? > > > >> Or even a > >> FastPackedString? (And how easy it would be to get that instead of > >> a String from hGetContents)? > > > > From the FPS haddock: > > > > hGetContents :: Handle -> IO FastString > > > > Read entire handle contents into a FastString. > > > > This may or may not do what you want...it's probably not a lazy > > read. > > It seems like there might need to be something like: > > hGetContentsLazily :: Handle -> IO [FastString] > > which returns file contents in chunks based on our ability to buffer > the handle. If we can mmap the handle, we may get a singleton list > with a giant FastString; if we are using a Socket or a terminal, each > succeeding string might be the next chunk of available data from the > handle. From the FPS haddock: data LazyFile Constructors LazyString String MMappedFastString FastString LazyFastStrings [FastString] Instances Eq LazyFile readFileLazily :: FilePath -> IO LazyFile That comes pretty near. Unfortunately it works on a file name, not a handle. Thus it cannot be used for a socket or such things. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Network parsing and parsec
On Sep 20, 2005, at 6:32 PM, Benjamin Franksen wrote: On Tuesday 20 September 2005 16:50, John Goerzen wrote: On the flip side, Parsec is really nice. I wonder how easy it would be to make it parse [Word8] instead of String? Isn't Parsec parameterized over the token type? Or even a FastPackedString? (And how easy it would be to get that instead of a String from hGetContents)? From the FPS haddock: hGetContents :: Handle -> IO FastString Read entire handle contents into a FastString. This may or may not do what you want...it's probably not a lazy read. It seems like there might need to be something like: hGetContentsLazily :: Handle -> IO [FastString] which returns file contents in chunks based on our ability to buffer the handle. If we can mmap the handle, we may get a singleton list with a giant FastString; if we are using a Socket or a terminal, each succeeding string might be the next chunk of available data from the handle. I had the impression the internals of getContents from the prelude worked a bit like this (in GHC, anyway). -Jan-Willem Maessen Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
"David F. Place" <[EMAIL PROTECTED]> writes: > On Sep 21, 2005, at 3:53 AM, Immanuel Litzroth wrote: > >> Ever heard of the loop macro? > > Yes, the loop macro is a good example for the argument against lisp. > Lisp has features to support iteration that date back to the time > before it was understood that tail recursion is equivalent to > iteration. > In fact, even in the early '90s most common lisp compilers > didn't implement tail-merging. I doubt there is any program > implemented using the loop macro that couldn't be more elegantly > implemented recursively. > In fact, when writing in lisp or scheme, I > always write recursively now that I can depend on compilers to tail- > merge. I personally find loop usually the most concise way to express my iteration requirements. Immanuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] killing a running thread interactively
On 16 September 2005 20:42, S. Alexander Jacobson wrote: > If I am running a server interactively. (using ghci). > Is there any way to kill its running threads without terminating the > interpreter? If you can get ThreadIds for the threads, yes. GHCi doesn't (currently) create a new thread for each expression evaluation, so attempting to kill that thread might kill your GHCi session (it shouldn't but that's another story). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-style proof tools?
Robin Green schrieb: > Does anyone know of a prover / proof assistant / proof verifier which uses a > vaguely Haskell-like syntax? That is to say, it allows you to express > theorems in Haskell-style syntax, print proof steps in Haskell-style syntax, > etc. Hi Robin, As part of a seminar, I'm currently working with Isabelle/HOL http://isabelle.in.tum.de/ to prove correctness of a function originally written in Haskell. Isabelle/HOL supports a functional programming style very close to Haskell (NB Isabelle itself is written in ML). I'm not done yet, but I hope to make this work into a little "A real-life example of program verification with Isabelle/HOL" paper. As I said, it's not finished yet (by far), but I've got the termination proof along with a couple of lemmas. I'll put the current state on the web so you can have a look: http://scannedinavian.org/~pesco/code/transpose/Transpose.thy This is the theory file containing the Isabelle definitions and proofs. http://scannedinavian.org/~pesco/code/transpose/transpose.lhs This is the original literal Haskell module. It contains the Haskell function and a quick informal proof. HTH, Sven Moritz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Sep 21, 2005, at 3:53 AM, Immanuel Litzroth wrote: Ever heard of the loop macro? Yes, the loop macro is a good example for the argument against lisp. Lisp has features to support iteration that date back to the time before it was understood that tail recursion is equivalent to iteration. In fact, even in the early '90s most common lisp compilers didn't implement tail-merging. I doubt there is any program implemented using the loop macro that couldn't be more elegantly implemented recursively. In fact, when writing in lisp or scheme, I always write recursively now that I can depend on compilers to tail- merge. David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
David F. Place wrote: > I don't deny that all of the things you mentioned are wonderful > indeed. I just wonder if they really could only be done in lisp or > even most conveniently. Obviously, if you can do it in Lisp, you can do it in any Turing-complete language; in the worst case, you just write a Lisp interpreter. As for convenience: syntax matters. The equivalence of code and data in Lisp lets you write your own syntactic sugar. You're still bound by the lexical (token-level) grammar, although reader macros mean that isn't much of a restriction. -- Glynn Clements <[EMAIL PROTECTED]> ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
"Tomasz Zielonka" <[EMAIL PROTECTED]> writes: > On Wed, Sep 21, 2005 at 08:53:47AM +0100, Immanuel Litzroth wrote: >> "David F. Place" <[EMAIL PROTECTED]> writes: >> >> >I was hoping that the examples I requested would be examples of >> >particular control constructs or extensions to the language's syntax >> >and semantics. Though I admit that such things are possible in lisp, >> >I suspect that their utility is minimal. >> >> Ever heard of the loop macro? >> Immanuel Litzroth > > I would be nice if you could give some examples for use of LOOP macro > that you think would be cumbersome to translate to Haskell. > That was not the original question and I think that would lead to pointless discussion about the meaning of "cumbersome". Loop is an example of a control construct that can be implemented by a macro. One can can discuss it's utility, but it was deemed important enough to be standardized (by lisp people). It was only one of the macros developed at that time to do things sequencelike things (series, generators/gatherers were others) . Another example is UFFI, basically a bunch of macros to do platform independent foreign function interfaces. I a currently writing a macro to generate the functions and datastructures to read an ipod database. This allows me to declaratively say (defheader (header-name inherits-from) (field-name length &optional reader)...). I doubt this would be easy in Haskell (maybe with TH it could be done) since I build a list of (header-name . (field-names ...)) at compile time which is then used to generate code that locally binds these to the result of reading them so that readers can refer to fields already read e.g. (let* ((field-name (reader stream))) ((field-name2 (reader field-name1 stream)) Immanuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Basic type classing question.
Karl Grapone <[EMAIL PROTECTED]> writes: > I've just started learning Haskell, and I must admit I'm finding it a > bit hard to get my head around the typing system... Okay. > What I want to be able to do is add and remove fields while the system > is running, While I'm sure you'll get some advanced replies to this, IMHO there is a contradiction between static (ie. compile time) type safety, and run-time modification of the types. If you are happy with dynamic typing, I would encode the data fields as lists of (keyword,value) pairs, and insert the necessary checks where appropriate. I.e. something like: type Keyword = String -- alternative: data Keyword = Name | Address |.. type Value = String-- or: data KeyVal = Name String | Number Int |.. data Employee = E [(Keyword,Value)] data Department = D [(Keyword,Value)] You can easily look up and update the field lists by using standard Prelude funcitions. -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
Re: [Haskell-cafe] Trapped by the Monads
Bill Wood <[EMAIL PROTECTED]> writes: >> The variable mem is a so-called hybrid variable; it crunches >> together 2 different concepts: a boolean value (could I allocate >> memory?) and an address value (what is the address where I can find >> my allocated memory). IMO, Maybe is exactly the oppsite, it extends a data type with a NULL value (to use DB terminology), and leaves no opportunity for confusing the extended type with the original. > I mostly agree with the "tightening-up", but there are times when I > really miss the nil hacks :-) In Haskell as well? I alwasy felt the cost of inserting a "null" predicate (when I want to test for an empty list) to be low. -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
Re: [Haskell-cafe] Basic type classing question.
maybe, i completely missunderstand you. please, could you program your example
in another language than haskell, one you know better?
i'm not sure -- did you try to define variables instead of types?
data Employee = Emp
data Department = Dept
translated to c++ this means sth like
typedef void Employee;
typedef void Department;
did you want sth like ...?
data Employee = Emp [(String,Either String Int)]
emp1 :: Employee
emp1=Emp [("Name",Left "Karl Ranseier"),("Identifier",Right 7),("Address",Left
"Graveyard 13")]
-marc
Karl Grapone wrote:
> Hi,
>
> I've just started learning Haskell, and I must admit I'm finding it a
> bit hard to get my head around the typing system...
>
> If I wanted to represent Employees and Departments in a Haskell
> program I could use data declarations like so:
> data Employee = Emp ...
> data Department = Dept ...
>
> This seems limited in (at least) two ways:
> I can't dynamically add fields to an employee or department, and
> once I pull a field out of an instance I lose type information.
>
>
> What I want to be able to do is add and remove fields while the system
> is running, I suppose via hs-plugins, and I should be prevented from,
> for example, accidentally taking an employees first name and using it
> as a departments address.
>
> My first attempt was the following, which isn't even valid and doesn't
> appear to buy me much anyway.
>
> class DataContainer c
>
> class DataContainer c => DataField f c a where
> extract :: f -> a
> apply :: (a -> a -> a) -> f -> f -> f
>
> data DataContainer c => Field c a = Fld c a
> instance DataField Field c a where
> extract (Fld _ a) = a
> apply f (Fld c a1) (Fld _ a2) = Fld c (f a1 a2)
>
>
> data Employee = Emp
> instance DataContainer Employee
>
> data Department = Dept
> instance DataContainer Department
>
> type EmployeeName = Field Employee String
> type EmployeeAddress = Field Employee String
> type EmployeeIdentifier = Field Employee Integer
> type DepartmentAddress = Field Department String
> type DepartmentIdentifier = Field Department Integer
> ...
>
>
> The 'DataField instance Field' declaration gives kind errors regarding
> how many type arguments Field is applied to. I don't claim to
> understand kinds at this point.
> Even if it did work, apply doesn't appear to force the arguments to be
> of the same type, and the declared type synonyms aren't enough to
> prevent me getting employee names and addresses confused.
>
> Is there a correct way to express what I'm trying to do? Or is it a
> bad idea to start with?
>
> Thanks
> Karl
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-style proof tools?
On 9/21/05, Robin Green <[EMAIL PROTECTED]> wrote: > Does anyone know of a prover / proof assistant / proof verifier which uses a > vaguely Haskell-like syntax? That is to say, it allows you to express > theorems in Haskell-style syntax, print proof steps in Haskell-style syntax, > etc. Skimming through the Haskell report reveals links that seem promising: http://www.cs.chalmers.se/~catarina/agda/ http://www.haskell.org/yarrow/ And maybe: http://www.ittc.ku.edu/~wardj/prufrock/ -- regards, radu http://rgrig.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
On Wed, Sep 21, 2005 at 08:53:47AM +0100, Immanuel Litzroth wrote: > "David F. Place" <[EMAIL PROTECTED]> writes: > > >I was hoping that the examples I requested would be examples of > >particular control constructs or extensions to the language's syntax > >and semantics. Though I admit that such things are possible in lisp, > >I suspect that their utility is minimal. > > Ever heard of the loop macro? > Immanuel Litzroth I would be nice if you could give some examples for use of LOOP macro that you think would be cumbersome to translate to Haskell. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell-style proof tools?
Does anyone know of a prover / proof assistant / proof verifier which uses a vaguely Haskell-like syntax? That is to say, it allows you to express theorems in Haskell-style syntax, print proof steps in Haskell-style syntax, etc. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
"David F. Place" <[EMAIL PROTECTED]> writes: >I was hoping that the examples I requested would be examples of >particular control constructs or extensions to the language's syntax >and semantics. Though I admit that such things are possible in lisp, >I suspect that their utility is minimal. Ever heard of the loop macro? Immanuel Litzroth ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
