- Haskell - Haskell.org

Your message to Hugs-Users awaits moderator approval
by hugs-users-admin＠haskell.org 17 May '02

17 May '02

Your mail to 'Hugs-Users' with the subject Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 133787 bytes but there's a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

ASSIST ME
by vincent yerima 16 May '02

16 May '02

CONFIDENTIAL BUSINESS PROPOSAL You may be suprise to receive this letter from me since you dont know me personally. The purpose of my introduction is that I am VINCENT YERIMA, the first son of DAVID YERIMA, the most popular farmer in Zimbabwe who was recently murdered in the land dispute in my country. I got your contact through network online hence decide to write you. Before the death of my father, he had taken me to Johannesburg to deposit the sum of US$7,000,000.00(seven million united states of America dollars)in one security company as he forsaw the coming danger in Zimbabwe. This money wasdeposited in a box as gemstones in to avoid much demurage from the security company.This amount was meart for the purchase of new machines and chemicals for the new farm and establishment in Swziland. This land problems came when Zimbawean president ROBERT MUGABE introduced a new land act reform wholly affected the rich white farmers and some few black farmers. And this resulted to the killing and mob action by Zimbabwe war returns and some lunatics in the society.It is agaist this background that I and my family fled Zimbabwe for fear of our lives and currently staying in The Netherlands where we seek political asylum and mooreso have decided to transfer my father' money to more reliable foreign account sinces the law of The netherland prohibits a refugee to open any bank account or to be involveed in any financial transaction throughout the territorial zone of Netherland . as the eldest son of my father , I am saddled to with the respobility of seeking a genuine foreign account where this money could be transfered without the the knowledge of my government who are bert on taking everything we have got.The South Africa government seems to be playing along with them. I am faced with the delima of moving this amount of money out of South Africa for fear of going through the same experience in futre, both countries have similar political history. I am seeking for a partner who I have to entrust my future and family in his hand , I must let you know that this transaction is risk free. If you accept to assist me andmy family , all I want you to do for me , is to arrange with the security company to clear the consignment (funds) from their afiliate office here in the Netherlands as I have already given directives for the consignment to be brought to The Netherlands from South Africa. But before then all modalities will have to be put in place e.g change of ownershipto the consignment and this money intend I intend to use for investment . I have two options for you , firstly you can choose to have certain percentage of the money or you can go into partnership with me for the proper profitable investment of the money in your country . Which ever the option you want , feel free to notify me. I have aslo mapped out 5% of the money for all kinds of expense incured in the process of this transaction. If you do not prefer a partnership I a willing to give you 15% of the money while the remaining 80% will be for my investment inin your country. Contact me with the above email address while i imlore you to maintain the absolute secrecy required in this transaction. Thanks God bless you Vincent Yerima _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

1 0

Re: infix type constructors
by Andrew J Bromage 16 May '02

16 May '02

G'day all. On Thu, May 16, 2002 at 07:24:10AM -0700, Simon Peyton-Jones wrote: > I'm slowly getting around to this. Design questions: > > (A) I think it would be a good compromise to declare that operators > like "+" are type *constructors* not type *variables*. So > S+T > would be a type. That's slightly inconsistent with value variables, > but it's jolly useful. So only alphabetic things would be type > variables. While we're at it, could we have infix notation for type classes too? class (a * b) c | a b -> c where (*) :: a -> b -> c Cheers, Andrew Bromage

1 0

Subject: Scheme Workshop 2002 -- submission deadline extended
by shivers＠cc.gatech.edu 16 May '02

16 May '02

The Scheme Workshop submission deadline has been extended two weeks. The new submission deadline is May 31 (2200 UTC). The 2002 Scheme Workshop will be in Pittsburgh in October, the day before ICFP. We will be planning not only presentation of papers but also some interesting group discussions. Going by the previous workshops, it should be a useful and fun day for just about anyone with an interest in Scheme or functional programming languages. I hope to see you there, and I especially encourage people to submit papers to the program committee. Please take a moment to read the "call for papers" I've appended below, and see if you have a topic or result you would like to submit to the program committee. See you in Pittsburgh. -Olin Shivers workshop chairman ACM SIGPLAN 2002 Scheme Workshop Thursday, October 3, 2002 Pittsburgh, Pennsylvania The workshop forms part of PLI 2002, which consists of the ICFP and PPDP conferences and other workshops. Full details on the workshop can be found at URL <http://scheme2002.ccs.neu.edu/>. ------------------------------------------------------------------------------- * Scope ------- The purpose of the workshop is to discuss experience with and future developments of the Scheme programming language, as well as general aspects of computer science loosely centered on the general theme of Scheme. Papers are invited concerning all aspects of the design, semantics, theory, application, implementation, and teaching of Scheme. Some example areas include (but are not limited to): - Theory Formal semantics, correctness of analyses and transformations, lambda calculus. - Design critiques Limitations of the language, future directions. - Linguistic extensions Scheme's simple syntactic framework and minimal static semantics has historically made the language an attractive "lab bench" for the development and experimentation of novel language features and mechanisms. Topics in this area include modules systems, exceptions, control mechanisms, distributed programming, concurrency and synchronisation, macro systems, and objects. - Type systems Static analyses for dynamic type systems, type systems that bridge the gap between static and dynamic types, static systems with "type dynamic" extensions, weak typing. - Implementation Compilers, optimisation, virtual machines, resource management, interpreters, foreign-function interfaces, partial evaluation, and generally implementations with novel or noteworthy features. - Program-development environments The Lisp and Scheme family of programming languages have traditionally been the source of innovative program-development environments. Authors working on these issues are encouraged to submit papers describing their technologies. - Education Scheme has achieved widespread use as a tool for teaching computer science. Papers on the theory and practice of teaching with Scheme are invited. - Applications and experience Interesting applications which illuminate aspects of Scheme; experience with Scheme in commercial or real-world contexts; use of Scheme as an extension or scripting language. - Scheme pearls Elegant, instructive examples of functional programming. A "Scheme pearl" submission is a special category, and should be a short paper presenting an algorithm, idea or programming device using Scheme in a way that is particularly elegant. ------------------------------------------------------------------------------- * Proceedings ------------- The proceedings of the conference will be published as a Georgia Tech College of Computing technical report. A special issue of the journal Higher-Order and Symbolic Computation about Scheme <http://www.kluweronline.com/issn/1388-3690> is planned afterwards. ------------------------------------------------------------------------------- * Important dates ----------------- - Submission deadline: 2200 UTC, 31 May, 2002 - Notification of acceptance or rejection: 26 July, 2002 - Final paper due: 31 August, 2002 - Workshop: 3 October, 2002 ------------------------------------------------------------------------------- * Submission guidelines ----------------------- Authors should submit a 100-200 word abstract and a full paper by 22:00 Universal Coordinated Time on Thursday, 31 May, 2002. (Note that 2200 UTC is 1800 EDT, or 1500 PDT.) Submissions will be carried out electronically via the Web, at <http://scheme2002.ccs.neu.edu/>. Papers must be submitted in PDF format, or as PostScript documents that are interpretable by Ghostscript, and they must be printable on US Letter sized paper. Individuals for which this requirement is a hardship should contact the program chair at least one week before the deadline. There are two classes of submissions: reular papers and short papers: - Regular papers Submissions should be no more than 12 pages (including bibliography and appendices) in standard ACM conference format: two columns, nine point font on ten point baseline, page 20pc (3.33in) wide and 54pc (9in) tall with a column gutter of 2pc (0.33in). Authors wishing to supply additional material to the reviewers beyond the 12 page limit can do so in clearly marked appendices, on the understanding that reviewers are not required to read the appendices. Submissions that do not meet these guidelines will not be considered. Suitable style files for Latex, Word, and Word Perfect can be found on the submission Web site. Submitted papers must have content that has not previously been published in other conferences or refereed venues, and simultaneous submission to other conferences or refereed venues is unacceptable. Each paper should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, saying why it is significant, and comparing it with previous work. Authors should strive to make the technical content of their papers understandable to a broad audience. - Short papers Short papers need not present novel research; it is sufficient that they present material of interest or utility to the Scheme or functional-programming community. "Scheme pearls" submissions should be presented as short papers. Short papers should be formatted with the same guidelines as regular papers, but are expected to be typically around six pages in length. ------------------------------------------------------------------------------- * Organisers ------------ Workshop chair: Olin Shivers College of Computing Georgia Tech Atlanta, Ga 30332-0280 +1 404 385.00.91 shivers(a)cc.gatech.edu Steering committee: William D Clinger (Northeastern University) Marc Feeley (University of Montreal) Matthias Felleisen (Northeastern University) Matthew Flatt (University of Utah) Dan Friedman (Indiana University) Christian Queinnec (University Paris 6) Manuel Serrano (INRIA) Mitchell Wand (Northeastern University) Program committee: Alan Bawden (Brandeis) Olivier Danvy (University of Aarhus) Richard Kelsey (Ember, Corp.) Brad Lucier (Purdue University) Paul Steckler (Northeastern University) Andrew Wright (Aleris) Publicity: Shriram Krishnamurthi (Brown University)

1 0

Functional design patterns (was: How to get functional software engineering experience?)
by Ralf.Laemmel＠cwi.nl 16 May '02

16 May '02

Andrew J Bromage wrote: > On the other hand, it's an exciting time to do engineering in > declarative languages, because we can invent the design patterns and > discover what the good habits are as we go along. BTW, FP is older than OOP. So why are we so late :-) ? Joost Visser and I, we worked out a few maybe not so obvious functional programming patterns such as Success By Failure, Role Play, Rewrite Step, Keyhole Operation just to mention a few. By not so obvious I mean that they deal with generic programming rather than functional programming in general. http://www.cs.vu.nl/Strafunski/dp-sf/ We use a certain FORMAT for design patterns, and there is some modest analysis why this format is appropriate. Also, there is some discussion why design patterns would do good for functional programming. This might be interesting in the further process of accumulating design patterns for functional programming. I am in complete agreement with Jeffrey Palmer who wrote: > From the research I've done to date, functional programming provides > enough of a paradigm shift that there are significant new patterns/idioms I have the feeling that the FP community has a hard time getting started with design patterns. Part of the problem is that design patterns are inherently "vague" and this is maybe something the authors in our field do not like to consider. That is, if something is being written that is meant to document design experience for functional programming, it ends up being complex (say, "Stop programming this or that; you will definitely fall in love with Haskell if you can parse this article."). Another more technical part of the problem is that it is not obvious what format would be appropriate, especially because the driving ingredient of an OO design pattern is the class hierarchy or an object structure, and this does not make sense in a functional setting. Yet another problem is that design patterns are all about design and less about coding. Many challenges in functional programming are about coding, and just about coding. We might need a different understanding of what design patterns are because we would like to cover the rich set of programming idioms in functional programming. I feel tempted to say there aren't that many in OOP. I guess there are more reasons why there is no GoF book out yet for FP. But at least Jeffrey, Joost, and I, we are working on that :-) Jeffrey Palmer wrote, too: > To avoid any pattern debates: I personally believe that patterns are > especially useful for getting novices up to speed on concepts that > might not be readily apparent at first glance. Rather than treating > patterns as anything "special" in their own right, for me they're simply > a really convenient way of teaching people new and interesting concepts. Why do you say this if you want to AVOID a debate ;-) ? Design patterns are maybe convenient for teaching ... But they are ESSENTIAL to gather design experience, and to regulate the terminology in a field. They are also CRUCIAL for the interaction of design and programming in the implementation phase, AND for the idea of refactoring. Also, the idea of a design pattern catalogue is just a kind of SELF-CHECKING notion to address all concerns a programmer could possibly have. By self-checking I mean that the firm adherence to a well-designed format for a catalogue is the key. Ralf -- Dr.-Ing. Ralf Laemmel CWI & VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/

6 5

Your message to Hugs-Users awaits moderator approval
by hugs-users-admin＠haskell.org 16 May '02

16 May '02

Your mail to 'Hugs-Users' with the subject Meeting notice Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 126883 bytes but there's a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

Re: State monads don't respect the monad laws in Haskell
by Jan-Willem Maessen 16 May '02

16 May '02

Dylan Thurston <dpt(a)lotus.bostoncoop.net> writes: > I don't think this is necessarily wise to drop this from the report > altogether. To me, it seems comparable to associativity of addition > for instances of Num; many instances don't satisfy it (e.g., Float), > but it's a useful guideline to keep in mind. > > I've often been bothered by the inconsistent treatment of laws in the > report; why are there laws for functors, monads, and quot/rem and > div/mod, and not much else? I'm pleased to see that the laws that are > given actually do have exceptions. Chalk me up as someone in favor of laws without exceptions. Allow me for a moment to make a reductio argument: We should just make Haskell into a strict language. Our equational laws still hold 95% of the time---after all, we don't really write non-terminating computations that often, and that's where the laws break down. And gosh darn, we sure get an efficient implementation. Of course, this argument doesn't really work out for the Haskell constructs we know and love (monadic computations spring to mind given the present conversation, along with certain uses of parsing combinators, but I bet you can think of your own examples). Having spent several years working with versions of Haskell with weakened equational semantics, I have become a bit of a reactionary on this point. Sort-of equational semantics just aren't powerful enough for many applications---we spend our time mired in the corner cases (such as non-termination), which is exactly what we were trying to avoid by using Haskell in the first place. I can't stress that enough. Freedom from crazy corner cases is Haskell's big selling point. None of this "except for infinite computations" stuff. None of this "as long as f has no side effects". If I have to worry about corner cases, I'm probably better off adding type classes and beautiful syntax to OCaml. That said, "seq" is a big wart on Haskell to begin with. I might be willing to allow "nice" rules like the monad laws to apply *as long as the results are not passed (directly or indirectly) to seq*. But I'm not willing to go from "the IO monad disobeys the laws in the presence of seq, and that might be OK" to "my monad disobeys the laws in code that never uses seq, and that's OK because even IO breaks the monad laws". And I'd really much rather we cleaned up the semantics of seq---or better yet, fixed the problems with lazy evaluation which make seq necessary in the first place. [Let me be clear: I believe hybrid eager/lazy evaluation, the subject of my dissertation, does eliminate the need for seq in most cases---so I'm a bit biased here.] -Jan-Willem Maessen

10 11

Dependent Types
by Dominic Steinitz 16 May '02

16 May '02

I've managed to crack something that always annoyed me when I used to do network programming. However, Hugs and GHC behave differently. I'd be interested in views on this approach and also which implementation behaves correctly. Suppose I want to send an ICMP packet. The first byte is the type and the second byte is the code. Furthermore, the code depends on the type. Now you know at compile time that you can't use codes for one type with a different type. However, in Pascal (which is what I used to use) you only seemed to be able to carry out run time checks. Here's a way I came up with for checking at compile time in Haskell. module Main(main) where -- ICMP has many more values for the type byte but we only need two for the example. data Redirect = Redirect data TimeExceeded = TimeExceeded data ICMPType = MkRedirect Redirect | MkTimeExceeded TimeExceeded -- 5 and 11 are the values that get sent. instance Enum ICMPType where fromEnum (MkRedirect Redirect) = 5 fromEnum (MkTimeExceeded TimeExceeded) = 11 data ICMPCodeRedirect = RedirNet | RedirHost | RedirNetToS | RedirHostToS deriving Enum data ICMPCodeTimeExceeded = ExcTTL | ExcFragTime deriving Enum class Encode a b | a -> b where encode :: a -> b instance Encode ICMPType String where encode = show . fromEnum instance Encode Redirect (ICMPCodeRedirect -> String) where encode a y = encode (MkRedirect a) ++ (show (fromEnum y)) instance Encode TimeExceeded (ICMPCodeTimeExceeded -> String) where encode b z = encode (MkTimeExceeded b) ++ (show (fromEnum z)) Now I can say things like encode Redirect Redir and get the value "50". But if I say encode Redirect ExcTTL then I get a type error. GHC gives Couldn't match `ICMPCodeRedirect' against `ICMPCodeTimeExceeded' Expected type: ICMPCodeRedirect -> String Inferred type: ICMPCodeTimeExceeded -> t and Hugs gives ERROR: Constraints are not consistent with functional dependency *** Constraint : Encode Redirect (ICMPCodeTimeExceeded -> [Char]) *** And constraint : Encode Redirect (ICMPCodeRedirect -> String) *** For class : Encode a b *** Break dependency : a -> b This is just what you want as it picks up errors at compile time not at run time. However, if I now comment out the functional dependency class Encode a b {- | a -> b -} where encode :: a -> b and include the expressions x = encode TimeExceeded ExcTTL main = putStrLn x then Hugs complains ERROR "codes.hs" (line 37): Unresolved top-level overloading *** Binding : x *** Outstanding context : Encode TimeExceeded (ICMPCodeTimeExceeded -> b) whereas GHC doesn't complain. Which is right? Dominic.

2 1

RE: Dependent Types
by Simon Peyton-Jones 16 May '02

16 May '02

| Here's a bit of background I managed to dig up: | http://www.mail-archive.com/haskell@haskell.org/msg05160.html | It appears that a change to the monomorphism | restriction to match Hugs's behaviour was considered for | Haskell 98, but it looks like it never made it into the report | (for what reason I'm not sure - the arguments in favour of the | change look fairly compelling). There was a bit of to and fro, but I ended up deciding not to do anything: http://www.mail-archive.com/haskell@haskell.org/msg03293.html Simon

1 0

Re: preprocessing printf/regex strings (like ocaml)
by David Feuer 16 May '02

16 May '02

On Sun, May 12, 2002, Oliver George wrote: > perl like things... > > msg' = replace "s/love/lust/" msg > > or, nice regex stuff... > > main = case match "^(\d+)" of > Nothing -> 0 > Just (i) -> i > Ick! regexes can be handled much better than that. Imagine something like: q = case x of /"^$" -> "Empty Line." /"^(foo@\d+)" -> foo ++ "hello!" /"confusion (foo@?) (bar@*)" -> "foo is" ++ foo ++ "And bar is" ++bar /"(a@*)" -> error "Sorry: I don't know what to do with "++a I don't know if this sort of syntax could work, but something similar would seem sensible. If it's not clear: the regex is used as a pattern. If it matches the string, that path is taken in the case statement. Also, wherever there are parenthesis with a "variable @", that variable is bound to the relevent string portion. > the python string notation (str % tuple) would fit really well too... > > putStrLn "hello %s, you got %d right" % ("oliver", 5) Might be nice. > > > Am I the only one who sees this as being a really valuable extension to > haskell? or does it exist and i've just never noticed? > > > cheers, Oliver. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Night. An owl flies o'er rooftops. The moon sheds its soft light upon the trees. David Feuer

10 18