Re: check for exhaustive patterns is broken
On Mon, Feb 11, 2002 at 05:37:32PM +0100, Feliks Kluzniak wrote: I would replace the last guard with 'otherwise'. Strangely enough, this particular solution never occurred to me. Not as pretty as the original, but thanks! A somewhat prettier solution would maybe be to use Ord.compare: case (compare k k') of LT - ... ; GT - ... ; EQ - ... This might even be faster if comparison is expensive. Lauri Alanko [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC 5.02: --make and -i
It seems to me that the -i command line argument is ignored when used together with --make. GHC reports that the modules can't be found. Is there any way to use a library (lib*.a + *.hi files) that is not compiled as a package with ghc --make? Not at the moment, no. If you have a library (without source), it must be a package. However, making a package spec is fairly easy, and you can use a local package.conf file rather than installing the package globally. We may revisit this at some point - at the time we didn't anticipate it being a problem, but you're not the first person to run into this. It should be possible to convince GHC internally that all pre-compiled code belongs to one pseudo-package. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: check for exhaustive patterns is broken
A somewhat prettier solution would maybe be to use Ord.compare: case (compare k k') of LT - ... ; GT - ... ; EQ - ... Thanks, I did consider this one, but it did not seem too pretty to me. All in the eye of the beholder, of course. This might even be faster if comparison is expensive. Hm, you might have a point. I tend to more or less forget about lower-level speed issues when programming in Haskell, which is quite a relief (!) and still leads to good result. -- F. K. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Stack Overflow Panic
Wolfgang Thaller wrote: [...] There is no problem with ghc-5.02.2 on Intel. I cannot try it out on ghc-5.03/intel due to lack of disk space. Any Ideas? The GHC from HEAD (Feb 28) crashes, too, even without -O. :-( No idea why, but -v tells me that it is the first simplifier pass... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Stack Overflow Panic
Just a small note: Changing PP from a datatype renaming (newtype) to an algebraic datatype (data) or inlining ppThen helps... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Raw Sockets
How do I use raw sockets? According to the documentation I can use AF_RAW. It also refers the user to the implementation in fptools/hslibs/net/SocketPrim.lhs. Do I really need to do this and if so how do I get it? The SocketPrim library (aka Network.Socket) really only supports AF_INET and AF_UNIX. Many of the other AF_ things are quite system-dependent; eg. Linux doesn't have AF_RAW. The documentation is a bit slack, although it does mention at the top of the Family(..) definition that your mileage may vary depending on the OS you use. Do you really want a raw socket, or will a datagram (UDP) socket do? If so, you can just pass Datagram as the SocketType argument to SocketPrim.socket. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Cross compilers
Simon Marlow [EMAIL PROTECTED] writes: Cross compilation in GHC is usually done by taking .hc files generated on a machine with a working GHC and compiling them on the target machine using only gcc. This is how we bootstrap GHC on new machines. So then it reduces to getting a GCC cross compiler? (Which shouldn't be insurmountable) Yes, you could do it this way. It may be less hassle to just take the .hc files to the target machine and compile them there, however. Setting up a real cross-compiling environment can be tricky - eg. making sure you're getting the right include files and so on. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC on MacOS X
I've spent a day compiling ghc (5.03, checked out from CVS a few days ago) on MacOS X 10.1. The results: another unregistered build, a PowerPC implementation of createAdjustor (foreign export dynamic now works!). Great stuff! You should coordinate with Sigbjorn Finne [EMAIL PROTECTED] who is also working on a MacOS X port, I believe. I needed to modify a total of six files: File: Adjustor.c Status: Locally Modified File: ClosureFlags.c Status: Locally Modified File: Main.c Status: Locally Modified File: Storage.h Status: Locally Modified File: Posix.hsStatus: Locally Modified File: Socket.hsc Status: Locally Modified If you post the patches to [EMAIL PROTECTED], we'll take a look. Socket.hsc refused to compile because on MacOS X, sigaddset() is a macro that chokes if its parameter is a void*. I added a wrapper function in a small C header file, but that's really ugly. What's the proper way? The right way is to add a wrapper, as you've done. With proper use of 'inline' you can eliminate any performance reduction too (it's probably not that big a deal, though). I also got a compiler panic on one of my own modules I tried to compile. I'll post that to ghc-bugs, as I somehow don't think it has to do with the PPC port. There are/were some problems due to rottage in the unregisterised code generation path, but I think Sigbjorn has mostly cleaned these up now. Try updating your CVS tree to get the fixes. What I really need, of course, is a registered compiler... I'm even prepared to learn some Perl to do that, but for now I don't really have a clue what to do - I don't know enough about Intel/Sparc assembly language and runtime conventions to find out from the code without a few hints - can anyone give me a few pointers what the mangler is supposed to do _exactly_? Ok, the mangler really just does two things. It removes the C function prologues/epilogues to support tail-calls, and it brings info tables and entry code next to each other. You'll get most of the way there by just setting up a PPC machine-specific section at the start of mangler/ghc-asm.lprl (there's already a powerpc version for rs6000, I'm not sure how relevant this is, though). The other things you need to look at are: - rts/StgCRun.c, which is the tiny layer between C land and registerised Haskell land, which just saves a few registers and makes some space on the C stack. - includes/TailCalls.c (probably the defaults for FB_ FE_ and JMP_() will do). - includes/MachRegs.h, which defines the register mapping. There's one for PPC already, which again may or may not be relevant. Be sure to talk to Sigbjorn before diving in though, so as to avoid duplicating any effort. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Raw Sockets
Simon, Thanks for the reply. I wanted to send ICMP packets. Linux does support AF_RAW. This compiles and runs on my linux system. /* * Create the socket. */ if ( (proto = getprotobyname(icmp)) == NULL) err_quit(unknown protocol: icmp); if ( (sockfd = socket(AF_INET, SOCK_RAW, proto-p_proto)) 0) err_sys(can't create raw socket); Dominic. Simon Marlow [EMAIL PROTECTED]@haskell.org on 04/03/2002 12:00:33 Sent by: [EMAIL PROTECTED] To: Dominic Steinitz dominic.j.steinitz glasgow-haskell-users cc: bcc: Subject: RE: Raw Sockets How do I use raw sockets? According to the documentation I can use AF_RAW. It also refers the user to the implementation in fptools/hslibs/net/SocketPrim.lhs. Do I really need to do this and if so how do I get it? The SocketPrim library (aka Network.Socket) really only supports AF_INET and AF_UNIX. Many of the other AF_ things are quite system-dependent; eg. Linux doesn't have AF_RAW. The documentation is a bit slack, although it does mention at the top of the Family(..) definition that your mileage may vary depending on the OS you use. Do you really want a raw socket, or will a datagram (UDP) socket do? If so, you can just pass Datagram as the SocketType argument to SocketPrim.socket. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users - Save time by using an eTicket and our Self-Service Check-in Kiosks. For more information go to http://www.britishairways.com/eservice1 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Raw Sockets
It looks like you want SOCK_RAW, not AF_RAW. GHC does support this, with the 'Raw' socket type, something like this: proto - getProtocolByName icmp s - socket AF_INT Raw proto should be: s - socket AF_INET Raw (protoNumber proto) and of course you have to be root to send raw packets to the network. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
2nd CFP: Unification in non-classical logics
=== We apologize if you receive this more than once === Second call for papers Unification in Non-Classical Logics --co-located with ICALP 2002-- July, 12-13, 2002, Málaga, Spain http://www.satd.uma.es/aciego/icalp-ws.html === The workshop on Unification in Non-Classical Logics will be held in Málaga, as a workshop of the 29-th International Colloquium on Automata, Languages, and Programming (ICALP 2002), which is a very convenient forum for an open discussion of the subject of non-canonical unification, roughly depicted below. Aims and scope -- Unification in non-classical logics, with various approaches to handling generalised terms, has drawn more and more attention in recent years. It turns out to be among the most promising areas of research on non-classical logics and its applications. So far, most popular lines of research include fuzzy unification of (conventional) databases and the use of fuzzy concepts in information retrieval. Some international events based on these topics have been held so far, for instance, the 2nd Intl Workshop on Logic Programming and Soft Computing (LPSC'98), or the special session on Advances in Possibilistic Logic and Related Issues at the IFSA Congress in Vancouver, Canada (2001), have non-classical unification among their topics. This workshop at ICALP is conceived as a forum for the exchange of ideas relevant for the concept of unification in non-classical logics, including, but not limited to, the following topics (practical implementations and experiences as well as theoretical advances): * Unification in multiple-valued and fuzzy logic programming. * Unification based on similarities and fuzzy equivalence relations. * Categorical unification. * Practical use of non-classical unification, e.g. in expert systems and information retrieval. We expect potential participants from the following areas: multiple-valued logic, fuzzy logic, uncertainty in logic programming, categorical applications to computer science. The workshop will have a limited number of presentations and the organizers will apply a refereeing procedure accordingly. The format will be as a set of presentations followed by a round table discussion. As the number of participants is estimated not to be very large, time enough will be allocated for each presentation (between 30 and 40 minutes), thus helping to have a relaxed workshop atmosphere in which discussions are encouraged. Submission -- Authors are invited to submit an extended abstract of their papers, presenting original contributions to the workshop themes. The workshop proceedings will be published as an issue in the ENTCS series (Electronic Notes on Theoretical Computer Science). Submissions should be written in English and not exceed 15 pages using the ENTCS style, and sent to the organizers in either PS or PDF form, together with a text-only message containig: title, abstract and keywords, the author's full names, and address and e-mail for correspondence. Simultaneous submission to other meetings with published proceedings is not allowed. Important dates --- * 20.03.2002 Workshop paper submission deadline * 21.04.2002 Workshop paper acceptance notification * 10.05.2002 Workshop paper camera-ready deadline Organizing Committee Patrik Eklund Manuel Ojeda-Aciego Dept. Computing Science Dept. Matematica Aplicada Umea University Universidad de Malaga mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED] -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Flocasa: 1st Call for Paper
[ Our apologies for multiple copies. ] == 1st International Workshop on Foundations of Coordination Languages and Software Architectures (Foclasa 2002) August 24, 2002, Brno, Czech Republic Workshop affiliated to CONCUR'2002, 20 - 23 August 2002. http://www.fi.muni.cz/concur2002/Foclasa == SCOPE AND TOPICS Modern information systems rely more and more on combining concurrent, distributed, mobile and heterogenous components. This move from old systems, typically conceived in isolation, induces the need for new languages and software architectures. In particular, coordination languages have been proposed to cleanly separate computational aspects and communication. On the other hand, software architects face the problem of specifying and reasoning on non-functional requirements. All these issues are widely perceived as fundamental to improve software productivity, enhance maintainability, advocate modularity, promote reusability, and lead to systems more tractable and more amenable to verification and global analysis. The aim of the workshop is to bring together researchers working on the foundations of component-based computing, coordination, and software architectures. Topics of interest include (but are not limited to): o Theoretical models for coordination (component composition, concurrency, dynamic aspects of coordination, semantics, expressiveness); o Specification, refinement, and analysis of software archi- tectures (patterns and styles, verification of functional and non-functional properties); o Coordination, architectural, and interface definition languages (implementation, interoperability, heterogeneity); o Agent-oriented languages (formal models for interacting agents); o Dynamic software architectures (mobile agents, configuration, reconfiguration); o Modeling of information systems (groupware, internet and the web, workflow management, CSCW and multimedia applications) o Coordination patterns (mobile computing, internet computing); o Tools and environments for the development of coordinated applications SUBMISSION GUIDELINES Papers describing original work are solicited as contributions to Foclasa. Submitted papers should be limited to 6 000 words, preferrably formatted according to the Fundamenta Informaticae style (available at http://fi.mimuw.edu.pl/submissions.html). They should be emailed as PostScript (PS) or Portable Document Format (PDF) files to [EMAIL PROTECTED] PROCEEDINGS The proceedings will be published as a technical report of the Institute of Informatics at the University of Namur, and will be available at the workshop. Selected papers will be published in a special issue of the Funda- menta Informaticae journal, with February 2003 as expected publi- cation time. IMPORTANT DATES: o May 25, 2002:Submission deadline. o June 30, 2002: Notification of acceptance. o August 1, 2002: Final version. o August 24, 2002: Meeting Date. LOCATION The workshop will be held in Brno in August 2002. It is a satellite workshop of CONCUR 2002. For venue and registration see the CONCUR web page at http://www.fi.muni.cz/concur2002/ WORKSHOP ORGANIZERS o Antonio Brogi (University of Pisa, Italy) o Jean-Marie Jacquet (University of Namur, Belgium) PROGRAMME COMITTEE: o Antonio Brogi (University of Pisa, Italy) - Co-chair o Rocco De Nicola (University of Firenze, Italy) o Jos Luiz Fiadeiro (University of Lisbon, Portugal) o Roberto Gorrieri (Univerity of Bologna, Italy) o Paola Inverardi (Univerity L'Aquila, Italy) o Jean-Marie Jacquet (University of Namur, Belgium) - Co-chair o Joost Kok (University of Leiden, The Netherlands) o Antonio Porto (New University of Lisbon, Portugal) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Flocasa: 1st Call for Paper
[ Our apologies for multiple copies. ] == 1st International Workshop on Foundations of Coordination Languages and Software Architectures (Foclasa 2002) August 24, 2002, Brno, Czech Republic Workshop affiliated to CONCUR'2002, 20 - 23 August 2002. http://www.fi.muni.cz/concur2002/Foclasa == SCOPE AND TOPICS Modern information systems rely more and more on combining concurrent, distributed, mobile and heterogenous components. This move from old systems, typically conceived in isolation, induces the need for new languages and software architectures. In particular, coordination languages have been proposed to cleanly separate computational aspects and communication. On the other hand, software architects face the problem of specifying and reasoning on non-functional requirements. All these issues are widely perceived as fundamental to improve software productivity, enhance maintainability, advocate modularity, promote reusability, and lead to systems more tractable and more amenable to verification and global analysis. The aim of the workshop is to bring together researchers working on the foundations of component-based computing, coordination, and software architectures. Topics of interest include (but are not limited to): o Theoretical models for coordination (component composition, concurrency, dynamic aspects of coordination, semantics, expressiveness); o Specification, refinement, and analysis of software archi- tectures (patterns and styles, verification of functional and non-functional properties); o Coordination, architectural, and interface definition languages (implementation, interoperability, heterogeneity); o Agent-oriented languages (formal models for interacting agents); o Dynamic software architectures (mobile agents, configuration, reconfiguration); o Modeling of information systems (groupware, internet and the web, workflow management, CSCW and multimedia applications) o Coordination patterns (mobile computing, internet computing); o Tools and environments for the development of coordinated applications SUBMISSION GUIDELINES Papers describing original work are solicited as contributions to Foclasa. Submitted papers should be limited to 6 000 words, preferrably formatted according to the Fundamenta Informaticae style (available at http://fi.mimuw.edu.pl/submissions.html). They should be emailed as PostScript (PS) or Portable Document Format (PDF) files to [EMAIL PROTECTED] PROCEEDINGS The proceedings will be published as a technical report of the Institute of Informatics at the University of Namur, and will be available at the workshop. Selected papers will be published in a special issue of the Funda- menta Informaticae journal, with February 2003 as expected publi- cation time. IMPORTANT DATES: o May 25, 2002:Submission deadline. o June 30, 2002: Notification of acceptance. o August 1, 2002: Final version. o August 24, 2002: Meeting Date. LOCATION The workshop will be held in Brno in August 2002. It is a satellite workshop of CONCUR 2002. For venue and registration see the CONCUR web page at http://www.fi.muni.cz/concur2002/ WORKSHOP ORGANIZERS o Antonio Brogi (University of Pisa, Italy) o Jean-Marie Jacquet (University of Namur, Belgium) PROGRAMME COMITTEE: o Antonio Brogi (University of Pisa, Italy) - Co-chair o Rocco De Nicola (University of Firenze, Italy) o Jos Luiz Fiadeiro (University of Lisbon, Portugal) o Roberto Gorrieri (Univerity of Bologna, Italy) o Paola Inverardi (Univerity L'Aquila, Italy) o Jean-Marie Jacquet (University of Namur, Belgium) - Co-chair o Joost Kok (University of Leiden, The Netherlands) o Antonio Porto (New University of Lisbon, Portugal) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: GCJNI, a Java Native Interface forHaskell
I am pleased to announce release 1.1 of GCJNI. GCJNI is a library that allows Haskell to invoke Java code via the Java Native Interface (JNI). The implementation uses GreenCard to make the JNI (a C language interface) available to Haskell. GCJNI includes a few convenient features, such as: - Integration of the Haskell and Java garbage collectors, so that Java objects are garbage collected when they are no longer accessible from Haskell. - Type class based overloading, which makes it easy to pass common types (like Int, Float and String) to or from Java code. - A tool (GenBindings) which uses Java reflection on a set of compiled Java classes to generate a Haskell module with a simple, high-level, type-safe interface to the underlying Java code. GCJNI has been succesfully tested using both hugs98 and ghc under both Linux and Windows. The distribution includes a unified Makefile system and detailed release notes that makes it very easy to configure, compile and install for any supported combination of Haskell implementation and platform. More information (including pointers to the relevant distributions) is available from the GCJNI web page at: http://www.haskell.org/gcjni Bug reports and feedback should be sent to [EMAIL PROTECTED] Enjoy! News: Release 1.1 (03-March-2002): * Substantial improvements to configuration and build process. Unified Makefile structure for Linux and Windows using Cygwin and GNU make. -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: Haven - A Functional Vector Graphics Library
I am pleased to announce an experimental release of Haven, a library for scalable vector graphics in Haskell. Haven provides a wealth of features, including: - Data types for common geometric shapes such as rectangles, ellipses and Bezier curves. - Composition of arbitrary shapes from sequences of straight and curved segments. - Intersection tests and bounds calculations on shapes. - Cropping of any image by any shape. - Affine transformations on images and paths. - Calculation of precise rectangular bounds of shapes and images. - High quality, anti-aliased rendering. - Scalable outline fonts. - Smooth blending of colors (gradients) - Alpha blending (transparency). - Fine-grained control of stroke width, join rules and end caps. - Constructive Area Geometry (CAG) for composing shapes using simple set-theoretic operations. Haven presents a purely functional API, but is implemented using the Java2D renderer. For more information on Haven, including examples and download instructions, please visit the haven web page at: http://www.haskell.org/haven Please send suggestions and bug reports to: [EMAIL PROTECTED] Enjoy! News: Release 1.1 (03-March-2002): * Substantial improvements to configuration and build process. Unified Makefile structure for Linux and Windows using Cygwin and GNU make. -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Why is this function type-correct
Hello, Recently, I wrote a function similar to x :: a x = x 42 which is type-correct (Hugs, Ghc, THIH). Still, from the expression it is clear that the type shoud have a function type. The definition x :: a - b x = x 42 is equally well accepted, though I can't see why this type would be correct. (I'd expect it to be too general.) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Why is this function type-correct
Hello, Recently, I wrote a function similar to x :: a x = x 42 which is type-correct (Hugs, Ghc, THIH). Still, from the expression it is clear that the type shoud have a function type. The definition x :: a - b x = x 42 is equally well accepted, though I can't see why this type would be correct. (I'd expect it to be too general.) For what reasons are these types considered correct? Thanks, Rijk-Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Convite Especial
CONVITE ESPECIAL. http://www.repositorio.com.br Convidamos você a visitar o maior e mais completo site de Informática atualmente na Internet Brasileira. São milhares de configurações, scripts, strings de modem, Linux, Windows, Mac, Imac e outros ACESSO TOTALMENTE GRATUITO. São mais de 150 categorias de busca com acesso a múltiplas bases de conhecimento. Temos mais de 100Mb de perguntas e respostas em nosso banco de dados. Faça como quase 2.000.000 de internautas, visite-nos. NÃO DEIXE DE NOS VISITAR. Lembre-se, o acesso é gratuito. http://www.repositorio.com.br Atenciosamente Webmaster De acordo com as diretivas aprovadas no 105o Congresso de Base Normativas Internacionais sobre SPAM, Seção 301, Parágrafo (a) (2) (c) Decreto S. 1618, Título Terceiro, um E-mail não poderá ser considerado SPAM, enquanto inclua uma forma de ser removido. Por isso se deseja ser excluído da nossa lista responda esta mensagem para [EMAIL PROTECTED] com o título Remova. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Why is this function type-correct
Recently, I wrote a function similar to x :: a x = x 42 which is type-correct (Hugs, Ghc, THIH). Still, from the expression it is clear that the type shoud have a function type. The definition x :: a - b x = x 42 is equally well accepted, though I can't see why this type would be correct. (I'd expect it to be too general.) In two words: polymorphic recursion. You'll find that the compiler won't be able to derive a type for 'x' in either of the two examples you gave, but x has several types the most general of which is 'forall a. a' (ie. your first example). The fact that x has type 'forall a. a' is also a useful hint as to its behaviour - the only value that has such a type is bottom. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Why is this function type-correct
Rijk J. C. van Haaften [EMAIL PROTECTED] wrote: Recently, I wrote a function similar to x :: a x = x 42 which is type-correct (Hugs, Ghc, THIH). Still, from the expression it is clear that the type shoud have a function type. The definition x :: a - b x = x 42 is equally well accepted, though I can't see why this type would be correct. (I'd expect it to be too general.) For what reasons are these types considered correct? When you say x :: a you are asking that the compiler check that everything you say about x is consistent with x being acceptable where /any/ type is required. In the application x 42, it requires that x be a function, which is fine, because x has any type, and this includes functions. When you say x = x 42, this requires that the type returned from x 42 is the same as the type of x, again fine because if x::a, then x:: Integer - a also, so x 42:: a. It works out in practise because x = x 42 gives x the value bottom, and bottom::a for all a. Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Why is this function type-correct
mån 2002-03-04 klockan 15.11 skrev Rijk J. C. van Haaften: Hello, Recently, I wrote a function similar to x :: a x = x 42 which is type-correct (Hugs, Ghc, THIH). Still, from the expression it is clear that the type shoud have a function type. It might interest you to know that this function is also type correct: x :: x x = x x x x x x I would like to see a compiler derive that type though... Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: GCJNI, a Java Native Interface forHaskell
Antony, at the given URI it says JDK 1.4 is required, do you know that there will be problems with 1.3 or is it expected to work with 1.3 also and just not tested? Thanks for your help Marko ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Standard Library report: List union
The current library report defines unionBy like this: unionBy eq xs ys = xs ++ deleteFirstsBy eq (nubBy eq ys) xs why does it take the nub of ys, but not xs? I'd have expected unionBy eq xs ys = (nubBy eq xs) ++ deleteFirstsBy eq (nubBy eq ys) xs Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Standard Library report: List union
On Mon, 4 Mar 2002, Jon Fairbairn wrote: The current library report defines unionBy like this: unionBy eq xs ys = xs ++ deleteFirstsBy eq (nubBy eq ys) xs why does it take the nub of ys, but not xs? I'd have expected unionBy eq xs ys = (nubBy eq xs) ++ deleteFirstsBy eq (nubBy eq ys) xs Jón Pure guess, but... (no really!) For the sake of argument, lets define a ulist as a list where for all elements x in list l, there is no element n with index not equal to that of x (index being position of the element in the list) such that eq n x == True. In other words every element in a ulist appears only once. Suppose you (unionBy eq x y) to get a result. Suppose also that x is a ulist A. x is a ulist by argument. B. the result of (nubBy eq ys), lets call it z, is a ulist. C. the result of (deleteFirstsBye eq z xs) is a list which has no elements in common with xs). because (deleteFirstsBy eq) deletes elements and doesnt add,the result is a ulist. D. Adding new, unique, elements (elements not equal to a element in the ulist in question) to a ulist results in a ulist. E. Therefore (unionBy eq x y) is a ulist. Why should this be important? what if you wanted to fold the function (unionBy eq) over a list of lists to get a ulist? Assuming you start with an initial ulist, by your suggestion you'd be applying (nubBy eq) to a ulist (generated by the the repeated application (unionByeq), which would be the same as applying the identity function to a ulist. (meaning you have essentially one big nasty no-op)! However, in taking a look at unionBy, one might wonder why it isnt defined like so (assuming xs would be the accumulated ulist in the fold. unionBy eq xs ys = (deleteFirstsBy eq (nubBy eq ys) xs) ++ xs or maybe better (to mirror (++)) unionBy' eq ys xs = (deleteFirstsBy eq (nubBy eq ys) xs) ++ xs in using this definition, the number of conses with (:) should be linear (or less) with with the number of elements to be added to the first_ulist in the following folds. foldl (unionBy eq) first_ulist list_of_lists foldr (unionBy' eq) first_ulist list_of_lists So, is there aother reason I cannot think of? I'm sure I haven't covered all bases here. Thanks, Jay Cox ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy Evaluation
On Mon, 4 Mar 2002, Tom Pledger wrote: Nguyen Phan Dung writes: : | mylist :: [Integer] | mylist = [1..10] | | In Hugs, I type mylist to print out all the elements inside. However, | after printing about 22000 elements, the system crashs outputs: | Garbage collection fails to reclaim sufficient memory The declaration of mylist is a pattern binding, not a function binding - see section 4.4.3 of the Haskell 98 report. What that means in this particular case is that the system saves the result in case you want to use it again, rather than freeing the part of the list it's already printed. Try typing [1..10] at the Hugs prompt instead. So would wrapping such possibly fiendish entities as [1..] with the const function and replacing all references to the toplevel binding with (binding ()) make sure that the first part of the list could be thrown away and re-computed if needed? Or does one need to NOINLINE it as well? Example to make myself clear: mylist = const [1..10] main = print (mylist ()) It seems like we had a discussion about something very similar to this a few months ago on some haskell.org list. Thanks, Jay Cox ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
CFP: 2002 Haskell Workshop
[My apologies if you receive multiple copies of this message] --- C A L L F O R P A P E R S --- ACM SIGPLAN 2002 Haskell Workshop Pittsburgh, PA, USA 3rd October 2002 (as part of PLI'02) === The purpose of the Haskell Workshop is to discuss experience with Haskell, and possible future development of the language. The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), Montreal (2000), and Firenze (2001). For detailed information please consult http://www.cse.unsw.edu.au/~chak/hw2002/ Submission deadline: *** 24th May 2002 *** ** P L E A S E N O T E ** * If there is sufficient demand, we will try to organise facilities for system demonstrations. If you are generally interested in demonstrating an application or tool written in Haskell, please contact the PC chair [EMAIL PROTECTED] at your earliest convenience, so that we can judge demand. * Submission and publication information changed with respect to the provisional CFP published earlier. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
