Congratulation!!!
OY KEIKKAUS NETHERLANDS SWEEPSTAKES LOTTERY, n.l, BURDENSTRAAT 21B, 1000 DS AMSTERDAM, THE NETHERLANDS. TO THE MANAGER FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: OYL /2551256003/22 BATCH: 14/0017/IPD ATTENTION: SIRRE/ AWARD NOTIFICATION; FINAL NOTICE We are pleased to inform you of the announcement today,30th of Augst winners of the OYKEIKKAUS NETHERLANDS SWEEPSTAKE LOTTERY/ INTERNATIONAL PROGRAMS held on 24TH Sept. 2002. Your company,attached to ticket number 025-1146-1992-750, with serial number 2113-22 drew the lucky numbers 13-15-22-37-39-43, and consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum pay out of US$3.6m in cash credited to file REF NO. OYL/2551256003/22. This is from total prize of US$80,800,000.00 shared among the seventeen international winners in this category. All participants were selected through a computer ballot system drawn form 15 million names from Australia, New Zealand, America, Europe and North America and Africa as part of International Promotions Program, which is conducted annually. CONGRATULATIONS! Your fund is now deposited with a company insured in your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes US$1.3billion International Lottery. To begin your claim, please contact your claim agent; canond Gorge, [EMAIL PROTECTED],FOREIGN SERVICE MANAGER, GLOBAL CROSSING,AMSTERDAM, n.l , For due processing and remittance of your prize to a designated account of your choice. Remember, all prize money must be claimed not later than 16 th sept, 2003. After this date, all funds will abe returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every one of your correspondences with your agent. Furthermore, should there be any change of your address, do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions program. Sincerely, FRANK KLUVET THE PROMOTIONS MANAGER, OY KEIKKAUS NETHERLANDS SWEEPSTAKES LOTTERY, n.l. N.B. Any breach of confidentiality on the part of the winners will result to disqualification. SORRY FOR THE LATE INFORMATION THANKS OY KEIKKAUS. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Exhaustive Pattern-Matching
Dnia czw 28. sierpnia 2003 16:37, Frank Atanassow napisa: SML has the same limitations w.r.t. guards as Haskell; Haskell compilers can and do check exhaustiveness, but not redundancy because matches are tried sequentially. I believe SML matching is also sequential. If there is a difference between the two, it must have to do with laziness. SML doesn't have guards at all. Most Haskell matches are correctly flagged as non-exhaustive or redundant if you use otherwise instead of relying on some guards themselves being exhaustive (which the compiler can't check). -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Last call generalised
Dnia czw 28. sierpnia 2003 23:04, [EMAIL PROTECTED] napisa: copyList (x:xs) = x : copyList xs is surely not tail-recursive in the traditional sense, but I think that most Haskell programmers take it for granted that it runs in constant stack space. The problem lies in the fact that the execution of a Haskell function can be interleaved with the execution of the code which calls it. Counting total stack space ever consumed by parts consisting of a function is meaningless because between these parts the stack is usually unwound. If you implemented this in a strict language, you would probably attribute only building of the cons cell to the invocation of the function. The cell points to a thunk in its tail, so when the tail is evaluated, an anonymous function is called - the original function is long finished. I brought up the same issue some time back about . That is in func = f x func, we have the problem that is a function so func is not a last call. It's an easy problem: although func is not a tail call, is a tail call and itself in most monads enters its second argument in a tail position. I would name it an indirect tail call. In procedural programming, the idea of the last call is that there is an operator ; that is often thought of as separating statements. In Scheme not only sequencing generates tail calls; e.g. branches of 'if' are in a tail position wrt. the 'if' itself, the body of 'let' wrt. the whole 'let' etc. If these constructs were implemented as plain functions taking closures as parameters, you would derive whether they tail call some of their parameters from their implementation. A Scheme definition, which describes the semantics and not a concrete implementation, would probably specify which functions on which conditions are required to tail call which of their parameters. But Scheme prefers macros, so I think the language definition doesn't talk about tail call properties of standard functions - because there aren't any interesting functions to talk about. OTOH Haskell uses more functions instead of built-in syntactic constructs, because passing a parameterless closure is very easy - you just write the expression consisting of the body. This makes meaningful to ask which functions on which conditions enter some of their parameters in a tail position. For example does this with its second parameter if it's entered at all. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Type class problem
On 28 Aug 2003, Carl Witty wrote: On Thu, 2003-08-28 at 13:10, Brandon Michael Moore wrote: Unfortunately I don't have a useful syntatic condition on instance declarations that insures termination of typechecking. If types are restriced to products, sums, and explicit recursion, then termination is ensured if we restrict the assumtions of a declaration to instances for subexpressions of the type we are declaring an instance for (there are only a finite number of subexpressions times a finite number of classes, and one is added each time we apply a rule). I haven't made any progress if type operators are allowed, and I don't have any simple check whether a Haskell type expression can be represented without type operators. I was hoping to get normalization of type expressions from the simple kinding, but recursive operator definitions break that. Rather, regularity of the resulting types, or something like that. We can always evaluate a type expression to head normal form, but the complete expansion of a type can be irregular. I think some of David McAllester's papers from about 1990-1994 may be relevant here. He has several papers on deciding when sets of inference rules are terminating, or terminating in polynomial time. (He applies this in the context of automated theorem proving, but it should apply perfectly well to type class inference as well.) Thanks, this is interesting work. I've read New Results on Local Inference Relations, and skimmed a few other papers. Too bad I can't see how to use it. Determining locality seemed to require a global analysis, and superficial rules look too restrictive for instance declarations. Some of the ideas could probably be adapted to prove termination (and bounds) for sets of rules if the anteceedents of rules mention only subterms of the conclusion. It's pretty trivial to prove that regular terms have regular derivations if any, but I haven't looked for good bounds. It looked to me like most of the results assumed that terms were finite, but most of it should carry over to regular terms. I don't think it would be easy to extend to irregular terms, even if I had a good characterication of Haskell types. Does anyone know of any results in that direction? Simple kinds give you head normalization, but I don't know how to describe the sorts of terms that end up as constructor arguments as you evaluate type expressions. I want some reasonable characterization of the sort of trees you get when you evaluate type expressions completely. Does anyone know of papers or books on this? Thanks Brandon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell for non-Haskell's sake
Hi fellow Haskellers, I'm attempting to get a sense of the topology of the Haskell community. Based on the Haskell Communities Activities reports, it seems that the large majority of people use Haskell for Haskell's sake. If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. I don't need a long report, anything from a simple I do to a paragraph would be fine, and if you want to remain anonymous that's fine, too. Purposes which I consider Haskell for Haskell's sake include: - writing Haskell compilers/interpreters - developing libraries for Haskell - writing Haskell debuggers, tracers, profilers or other tools - more or less anything with matches /.*Haskell.*/, other than /in Haskell$/ :) Thanks, - Hal -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell for non-Haskell's sake
We are just a software company that builds multi platform (Unix - AIX Solaris HP-UX Linux, Windows) report generators for various formats, including Excel and PDF. Our product is not written in Haskell, but we do all our research by using Haskell as a prototype language for our ideas. In our minds, Haskell is the best language you can find now, and we thought to choose Haskell as a language for all our projects. But we decided not to do so because of couple things: 1. The language runtime that we have to include in every our projects 2. The language does still lack many useful libraries, like database access, which are essentials for any business development. Thanks, Andrey Dadakov [EMAIL PROTECTED] Aware Software, Inc http://www.awaresw.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hal Daume III Sent: Friday, August 29, 2003 5:39 PM To: Haskell Mailing List Subject: Haskell for non-Haskell's sake Hi fellow Haskellers, I'm attempting to get a sense of the topology of the Haskell community. Based on the Haskell Communities Activities reports, it seems that the large majority of people use Haskell for Haskell's sake. If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. I don't need a long report, anything from a simple I do to a paragraph would be fine, and if you want to remain anonymous that's fine, too. Purposes which I consider Haskell for Haskell's sake include: - writing Haskell compilers/interpreters - developing libraries for Haskell - writing Haskell debuggers, tracers, profilers or other tools - more or less anything with matches /.*Haskell.*/, other than /in Haskell$/ :) Thanks, - Hal -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
--- Hal Daume III [EMAIL PROTECTED] wrote: Hi fellow Haskellers, I'm attempting to get a sense of the topology of the Haskell community. Based on the Haskell Communities Activities reports, it seems that the large majority of people use Haskell for Haskell's sake. In our office we use Haskell for writing of tools but the main development is done in C++, C# and SQL. Probably we can use Haskell for large projects but there are still missing many features: - library for Graphical User Interface - Designer for dialogs and forms - Complete and comfortable IDE - Library and tools for Database access This is my motivation to start development of HToolkit. Krasimir __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
On 2003-08-29 at 17:39PDT Hal Daume III wrote: Hi fellow Haskellers, I'm attempting to get a sense of the topology of the Haskell community. Based on the Haskell Communities Activities reports, it seems that the large majority of people use Haskell for Haskell's sake. If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. In addition to the things you exclude, I've written (and sold!) a custom web-server log-analysis programme. I use Haskell for managing some personal data, and also use it a great deal for what prof. Wilkes calls nonce programming. Jón -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
Hi, Well, some time back I implemented PRE (Partial Redundancy Elimination) for C program in Haskell. The algorithm is fairly straightforward but involved some issues regarding how to represent the basic block information, graph etc. The haskell program itself can be improved though, but I'll take it up during december when my current term ends. Regards, Arun On Saturday 30 August 2003 06:09, Hal Daume III wrote: Hi fellow Haskellers, I'm attempting to get a sense of the topology of the Haskell community. Based on the Haskell Communities Activities reports, it seems that the large majority of people use Haskell for Haskell's sake. If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. I don't need a long report, anything from a simple I do to a paragraph would be fine, and if you want to remain anonymous that's fine, too. Purposes which I consider Haskell for Haskell's sake include: - writing Haskell compilers/interpreters - developing libraries for Haskell - writing Haskell debuggers, tracers, profilers or other tools - more or less anything with matches /.*Haskell.*/, other than /in Haskell$/ :) Thanks, - Hal -- Arun Kumar S Jadhav Masters Student, SIC-309, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk * Never negotiate out of fear Never fear to negotiate * --- -- Arun Kumar S Jadhav Masters Student, SIC-309, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk * Never negotiate out of fear Never fear to negotiate * ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
- Original Message - --- Hal Daume III [EMAIL PROTECTED] wrote: Hi fellow Haskellers, I'm attempting to get a sense of the topology of the Haskell community. Based on the Haskell Communities Activities reports, it seems that the large majority of people use Haskell for Haskell's sake. Simple. Haskell is the first language programming I ever learned, It is very easy to write because it does not have a gui or stuff that needs mouch knowledge, plus it is system free so I can compile it in any possible system (Windows, Unix, Linux...). Not to mention that I am not very good with programming which makes it easier for me (Funktionall Programming rules). Best Regards Alex ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. I don't need a long report, anything from a simple I do to a paragraph would be fine, and if you want to remain anonymous that's fine, too. I have used Haskell for: - Knit (http://www.cs.utah.edu/flux/knit/) A component language for C based on the Unit model used in MzScheme. (Roughly comparable to using ML functors for every module.) This was used to break the OSKit (a huge collection of OS kernel components extracted from Linux, Mach and *BSD) into finer grained components. A new version of Knit which allows import and export of types is almost ready. (The first version could only import/export functions, variables and opaque types.) [Knit is a language needing all the bits that Haskell is good for writing (lexing, parsing, static typechecking, desugaring, optimizing, generating 'code', etc.) Uses an external program written in C to rename symbols in ELF-format object files.] - CMI (due for release soon) A tunable cross-module inliner for C. Can be used to speed up your code. Can be used to reduce the stack consumption of embedded systems (http://www.cs.utah.edu/~regehr/stacktool/) Can be used to let you adopt a better programming style in C by letting you put aside some performance concerns. [Works by parsing C source code, merging multiple files into one, topologically sorting function definitions, pretty-printing, etc. All the things Haskell is good for!] - ADL An architecture description language which focusses on describing the hierarchies of schedulers and composition of software components found in embedded systems. (Background: http://www.cs.utah.edu/flux/papers/cee-flux-tn-02-02/) [Again, ADL is a language so it has all the usual bits Haskell is good for: lexer, parser, dynamic typechecking, dimension types, interpreter, etc. Also uses Haskell's ability to call external tools so it can use external analysis tools written in Haskell (like TSL, below), or written in C, perl, whatever.] - Task/Scheduler Logic (TSL) A language/ logic/ tool for reasoning about hierarchies of schedulers found in embedded systems. [Uses Haskell's strengths for implementing languages and for symbol manipulation (contains a small forward-chaining inference engine).] - FVision (Visual tracking) Given a bunch of simple image tracking primitives (written in C++ and assembly, part of the larger XVision system), build complex feedback loops, hierarchies, etc. to create more robust, flexible, sophisticated tracking systems. http://www.reid-consulting-uk.ltd.uk/alastair/publications/padl01/index.html Uses Haskell's ability to 'embed' domiain specific languages inside it. [One could argue that this project was just 'Haskell for Haskell's sake' but it's worth pointing out that it lead to a complete redesign of XVision along the lines I had developed in the Haskell version.] -- Alastair Reid ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell-report, chapter 3 - Expressions
Thank you. The '10' should be explained in the report as well. Ciao, Steffen ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
proving the monad laws
Hello, consider the following monad (which is a slight adaptation of the one used in Typing Haskell in Haskell) as given: data Error a = Error String | Ok a data TI a = TI (Subst - Int - Error (Subst, Int, a)) instance Monad TI where return x = TI (\s n - Ok (s,n,x)) TI f = g = TI (\s n - case f s n of Ok (s',m,x) - let TI gx = g x in gx s' m Error s-Error s) fail s = TI (\_ _-Error s) Now I would like to verify the monad laws. It is really easy to show that return is both a left- and a right-unit. But I got stuck with associativity: m@(TI mf) = (\a-f a = h) = = TI (\s n - case mf s n of Ok (s',m,x) - let TI gx = (\a-f a = h) x in gx s' m Error s-Error s) = ... = ((TI mf) = f) = h Is there someone outside who is willing to tell what fills the gap? A hint may be sufficient already. Or is there a tool, which finds such derivations? I have read the tutorial All about Monads, but there only is mentioned, that there is an obligation for the programmer to prove these laws. It would be helpful as well, to provide an example! I was wondering, if it is possible to simplify: let TI gx = f x =h in But the a may occur in h? Thank you. Steffen ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
Hi Hal (et al.) I am using it to write a compiler and interpretor for a quantum programming language, based on the semantics of the paper by Peter Selinger. (See http://quasar.mathstat.uottawa.ca/~selinger/papers.html#qpl for details on the semantics) On 29 Aug, Hal Daume III wrote: Hi fellow Haskellers, If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. I don't need a long report, anything from a simple I do to a paragraph would be fine, and if you want to remain anonymous that's fine, too. Purposes which I consider Haskell for Haskell's sake include: - writing Haskell compilers/interpreters - developing libraries for Haskell - writing Haskell debuggers, tracers, profilers or other tools - more or less anything with matches /.*Haskell.*/, other than /in Haskell$/ :) -- Brett G. Giles Grad Student, University of Calgary Formal Methods, Category Theory, Semantics of Programming http://www.cpsc.ucalgary.ca/~gilesb mailto:[EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
On Sat, 30 Aug 2003, Alastair Reid wrote: If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. I don't need a long report, anything from a simple I do to a paragraph would be fine, and if you want to remain anonymous that's fine, too. [snip] - FVision (Visual tracking) Given a bunch of simple image tracking primitives (written in C++ and assembly, part of the larger XVision system), build complex feedback loops, hierarchies, etc. to create more robust, flexible, sophisticated tracking systems. http://www.reid-consulting-uk.ltd.uk/alastair/publications/padl01/index.html Uses Haskell's ability to 'embed' domiain specific languages inside it. [One could argue that this project was just 'Haskell for Haskell's sake' but it's worth pointing out that it lead to a complete redesign of XVision along the lines I had developed in the Haskell version.] I do research in computer vision/image processing and I've also used Haskell quite a lot for doing prototyping of algorithms. I'm doing sort of the opposite thing to Alastair: he's taking established low-level image analysis techniques (written in C/C++) and combining them in more effective ways using Haskell as a language for doing higher level processing. (Apologies if this is an incorrect understanding.) I work on more effective low-level image processing algorithms with a higher-level stuff that's simple and stable enough that coding it in C++ doesn't cause a problem. I do extensive prototyping using simple Haskell implementations of ideas; once I'm reasonably happy that the idea has a chance of working I then convert it to C++. I have to convert to C++ for `real work' because (a) Haskell is too slow for most of the low-level stuff, particularly `semi real-time' image processing and (b) no-one else here knows Haskell so if I want to be able to share code on common projects I need either C or C++. I want eventually to be able to plug in Haskell code prototypes into the overall C++ structure to be able to do more testing before moving to C++, but that awaits me having enough free time to study the Haskell FFI, etc... I'm very impressed with the FVision stuff and I've contrasted what I do with the it just to show Haskell is being used for BOTH high and low-level areas. I also use Haskell for some `scripting-stuff level tasks' like autogenerating makefiles and processing log files. I write both Perl and Python code where they seems best, so I can reasonably say that in those cases where I use Haskell it's because I think it's easier for me than those languages. ___cheers,_dave_ www.cs.bris.ac.uk/~tweed/ | `It's no good going home to practise email:[EMAIL PROTECTED] | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
On Fri, 29 Aug 2003, Hal Daume III wrote: If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. I don't need a long report, anything from a simple I do to a paragraph would be fine, and if you want to remain anonymous that's fine, too. Purposes which I consider Haskell for Haskell's sake include: - writing Haskell compilers/interpreters - developing libraries for Haskell - writing Haskell debuggers, tracers, profilers or other tools - more or less anything with matches /.*Haskell.*/, other than /in Haskell$/ :) I'm writing a compiler in it for my dissertation project at uni - the source language is one of my own design. -- [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
I use haskell when I have to write a program myself and quickly. So I was very happy when I saw wxwindows bindings, because I wrote a frontend for mame with it, and it took three days to get something satisfying. We need some ordinary people use for haskell sometimes ;) V. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
Hello, 1 I wrote Haskell programs to compute matrix elements of operators (in physics). 2 I use Haskell for generating figures (Functional Metapost). 3 For generating HTML summaries out of some data. 4 For common text processing as an advanced sed. Actually, I do not use Haskell for Haskell at all... Sorry for that. :( Feri. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Subject: Re: unsafeInterleaveIO ordering
[resending this mail from a different address as it didn't seem to get through the first time. I apologise if you see multiple copies.] [snip] If you're using an eager haskell implementation which does some speculative evaluation of things that look cheap and that you might want to evaluate, the answer is probably no. (Because, having decided to do some speculative work in the absence of a demand, it might decide it has done enough work after the first action, and then later it would finish the job when the result is actually demanded.) Actually speculative/optimistic evaluation should be fine. Optimistic Evaluation refuses to speculate IO for exactly this reason. If a speculative computation attempts to call unsafePerformIO or evaluate the IO from an unsafeInterleaveIO then the speculation is immediately aborted. IO is never speculated. Anyone wanting to find out more about optimistic evaluation is encouraged to download the ICFP'03 paper from here: http://www.cl.cam.ac.uk/users/rje33/publications.html Threads are still an issue, but that can be dealt with using locking. -Rob ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
