- Haskell - Haskell.org

Movement in a frictionless environment
by R.Daniel 07 Jan '01

07 Jan '01

Hi, could anyone tell me where to find some info about generating movement on a frictionless environment? I need to put a ball running in a window, given an initial speed and then let it run along with the rules of phisics....can anyone give me a hint on where to find info, or on how to do that? I would be most greatefull. Thankx ----->R.Daniel ICQ 28959546

2 1

(no subject)
by kh0ndor＠aeiou.pt 07 Jan '01

07 Jan '01

which is the function in haskell that allows to generate us an amount of aleatory numbers I thank your help __________________________________________________________ Mensagem enviada pelo Xekmail: webmail grátis do AEIOU http://xekmail.aeiou.pt

2 1

Re: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
by Julian Assange 05 Jan '01

05 Jan '01

Peter Douglass <peterd(a)availant.com> writes: > Julian Assange wrote (Dec 28, 2000): > > > This is why all non S-exp like lanaguage are doomed to progressive > > syntactic cancer as the useful parts of operator name space and syntax > > space become progressively polluted and mutated by one fad after > > another. > > Could you expand on this? I would think that all languages have identifies > that, through common usage become standardized, and that this meaning > becomes a de-facto part of the language. Do you feel that this has not > happened in Lisp/Scheme? The identifier space in lisp/scheme has wide tree depth and is (essentially) lexically scoped. Infix operator identifiers in other languages are the antithesis of this. It could be argued, both fairly and unfairly, that the verbosity of S-exp bracketing leaves short identifiers less desirable than they otherwise would be, however tree-width arguments remain. Polution of syntax space is a more difficult problem. As new syntactic axioms are intruded, they should remain consistant with the existing syntax elements. This poses ever increasing restraint on the evolution of the language. New syntax elements appear less intuitive and more arbitary in an attempt to fit in with the morass of ever increasing restraints. If these restraints are not honnored, the language becomes inconsistant. Eventually the language is guarenteed to become either inconsistant or moribund as the number of interactions between language elements overwhelms a language designers attempts understand them. The same is even more true of language semantics. The trouble lays in finding initial axioms which can cleave large sections of future concept space between them. -- Julian Assange |If you want to build a ship, don't drum up people |together to collect wood or assign them tasks and proff(a)iq.org |work, but rather teach them to long for the endless proff(a)gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery

1 0

RE: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
by Peter Douglass 05 Jan '01

05 Jan '01

Julian Assange wrote (Dec 28, 2000): > This is why all non S-exp like lanaguage are doomed to progressive > syntactic cancer as the useful parts of operator name space and syntax > space become progressively polluted and mutated by one fad after > another. Could you expand on this? I would think that all languages have identifies that, through common usage become standardized, and that this meaning becomes a de-facto part of the language. Do you feel that this has not happened in Lisp/Scheme? --PeterD

1 0

Re: Learning Haskell and FP
by Benjamin L. Russell 04 Jan '01

04 Jan '01

On Wed, 3 Jan 2001 22:55:17 -0800 (PST) Fritz K Ruehr <fruehr(a)willamette.edu> wrote: > > [snip] > > An O'Reilly "nutshell" book is an even better suggestion > than > my "Design Patterns in Haskell" of a few days back, at > least > from the perspective of marketing and promotion. > > But it raises the issue of an appropriate animal mascot > for > the cover; I can only come up with the Uakari, an > exotic-looking > rainforest monkey, which sounds similar to "Curry". > > (look here for a picture:) > > <http://www.animalsoftherainforest.com/uakari.htm> Lalit Pant ( lalitp(a)acm.org ) (alternatively, lalit_pant(a)yahoo.com ) wrote an article in the May 2000 issue of _Java Report_ entitled "Developing Intelligent Systems With Java and Prolog" that described a Prolog implementation of the A-star search algorithm. Lalit stated that Prolog was useful for algorithm prototyping. Perhaps Lalit Pant and Simon Peyton Jones could collaborate together on an article, perhaps overseen by Paul Hudak, on prototyping search algorithms in Haskell, also for _The Java Report?_ If this article then had a high readership, maybe the article's success could then justify publication of an O'Reilly _Haskell in a Nutshell_ book? --Ben P. S. (Hi Doug Fields. I didn't know that you were reading this mailing list. I guess that I should also greet Professor Paul Hudak: Hello, Professor Hudak. Sorry about Collectively Speaking. How's jazz in general?) Benjamin L. Russell russell(a)brainlink.com benjamin.russell.es.94(a)aya.yale.edu "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho

1 0

RE: Problem with functional dependencies
by Simon Peyton-Jones 04 Jan '01

04 Jan '01

I think you can simplify the example. Given class HasFoo a b | a -> b where foo :: a -> b instance HasFoo Int Bool where ... Is this legal? f :: HasFoo Int b => Int -> b f x = foo x You might think so, since HasFoo Int b => Int -> b is a substitution instance of HasFoo a b => a -> b but if we infer the type (HasFoo Int b => Int -> b) for f's RHS, we can then "improve" it using the instance decl to (HasFoo Int Bool => Int -> Bool), and now the signature isn't a substitution insance of the type of the RHS. Indeed, this is just what will happen if you try with GHC, because GHC takes advantage of type signatures when typechecking a function defn, rather than first typechecking the defn and only then comparing with the signature. I don't know what the answers are here, but there's more to this functional dependency stuff than meets the eye. Even whether one type is more general than another has changed! Simon | -----Original Message----- | From: qrczak(a)knm.org.pl [mailto:qrczak@knm.org.pl] | Sent: 17 December 2000 19:30 | To: haskell(a)haskell.org | Subject: Problem with functional dependencies | | | The following module is rejected by both | ghc -fglasgow-exts -fallow-undecidable-instances | and | hugs -98 | | -------------------------------------------------------------- | ---------- | class HasFoo a foo | a -> foo where | foo :: a -> foo | | data A = A Int | data B = B A | | instance HasFoo A Int where | foo (A x) = x | | instance HasFoo A foo => HasFoo B foo where | foo (B a) = foo a | -------------------------------------------------------------- | ---------- | | The error messsage says that the type inferred for foo in B's instance | is not general enough: the rhs has type "HasFoo B Int => B -> | Int", but | "HasFoo B foo => B -> foo" was expected.

6 8

ANNOUNCE: GHood -- a Graphical Hood (pre-release)
by C.Reinke 04 Jan '01

04 Jan '01

Ever wanted to see what your Haskell program is doing? Andy Gill's Hood library (http://www.haskell.org/hood/) represents a big improvement over previous uses of trace & co. It doesn't affect strictness properties, and instead of displaying debug information in the nearly incomprehensible order in which it is generated, it collects, post-processes and pretty-prints the information and displays the results after program evaluation, in a more readable form. However, as Andy already noted in the Hood documentation, there is a lot of useful information to be gathered from the order in which (parts of) data structures are observed. Now that Hood associates individual observation events with the data structures to which they belong, thus facilitating comprehension of observations, it would be nice to find a way to visualise the observation order as well. Andy's plan was to incorporate such a feature into a textual browser add-on for Hood (in CVS, not released yet?). But for tasks for which structural context and relationships between parts dominate over details, my personal preference would be a graphical form of visualisation. GHood is my current attempt to add a such a graphical viewer to Hood. It hasn't yet reached its final form, but it is quite useful and usable already. We have played with it locally, and I can't spent too much time on this, but I would like to get some external feedback before I finalise the development. Hence this pre-release. Currently, GHood comes in two files: a drop-in replacement for the Hugs98 variant of Hood (only minimal changes, same interface) and a Java class file archive for the graphical viewer itself. To find the two files, please visit my Haskell corner at: http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/ Enjoy (and let me know what you think about it), Claus -- Claus Reinke, http://www.cs.ukc.ac.uk/people/staff/cr3/ Computing Lab, University of Kent at Canterbury

1 0

Happy InstallShield update
by Reuben Thomas 04 Jan '01

04 Jan '01

I just noticed that the Happy 1.9 InstallShield contained a dynamically linked executable for Happy. This was a Bad Idea, so I've replaced it with a statically linked executable. This should work for more people. -- http://sc3d.org/rrt/ | maxim, n. wisdom for fools

1 0

Learning Haskell and FP
by Doug Ransom 04 Jan '01

04 Jan '01

I have read "The Craft of Functional Programming" by Simon Thompson and a few paper on the web. "The Craft" is a good book, but it is an introduction to FP. It seems to me it there are a lot of books on OO design I can pick up at the bookstore, but in the FP world, one must worm their way through all sorts of papers. I have seen papers on Catamorphisms, Monads, Programming with Barbed Wire, folds, etc. I think these papers are hard to understand if you don't have the acadademic/mathematical background -- being papers and not textbooks these papers assume a fair bit of base knowledge. I know I can design a fold function to use in place of primitive recursion for most data structures -- I just don't know if I should. It is pretty easy to get through "The Craft of Functional Programming" without understanding what Category Theory , a Catamorphism , or a Kleisli Composition is. I can see lots of real Software Engineering oppurtunities for these various techniques if I could just put them together. Is there a good textbook on Functional Programming which starts from a base point similar to "The craft of Functional Programming" but more advanced in terms of introducing necessary topics like Category theory, catamorphisms, monads, etc? I would find such a book very useful, especially if it concentrated on lazy functional programming. Doug Ransom Systems Engineer Power Measurement Ltd. http://www.pml.com 250-652-7100 office 250-652-0411 fax mailto:doug_ransom@pml.com

15 21

RE: Learning Haskell and FP
by Simon Peyton-Jones 04 Jan '01

04 Jan '01

| > 1. How the #$!? do I read some data from a file. Good, I've | > got the data, now I can work on it. Nope, now I have an "IO | > thingie" whatever that is, but all of the standard functions want | > a regular "thingie" now what? Perhaps this would be a good moment to advertise the revised version of Tackling the Tackling the Awkward Squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell http://research.microsoft.com/~simonpj/#marktoberdorf (Concerning the thread I'm responding to, it gives an introduction to monadic input/output.) I've revised and extended this tutorial quite a bit since I announced it last year, with a lot of help from people on the Haskell mailing list: thank you! Further suggestions are most welcome. Simon Abstract Functional programming may be beautiful, but to write real applications we must grapple with awkward real-world issues: input/output, robustness, concurrency, and interfacing to programs written in other languages. These lecture notes give an overview of the techniques that have been developed by the Haskell community to address these problems. I introduce various proposed extensions to Haskell along the way, and I offer an operational semantics that explains what these extensions mean.

2 1