-fallow-overlapping-instances Request
Currently -fallow-overlapping-instances only allows overlapping instances if one is a strict subset of the other. This is good (determinate), but sometimes you really need two instances that partially overlap. It would be nice if this could be disambiguated simply with another instance declaration. For instance: class C a b; instance C a (); instance C () a; instance C () (); As you can see, the first two instances partially overlap, but the third one disambiguates. I think it would be nice if GHC -fallow-overlapping-instances allowed this. This would take some of the pain out of overlapping instance resolution... -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -fallow-overlapping-instances Request
Currently -fallow-overlapping-instances only allows overlapping instances if one is a strict subset of the other. This is good (determinate), but sometimes you really need two instances that partially overlap. From a type-theoretic viewpoint, instance declarations are relations between (sets of) trees (= elements of the respective data types). So one needs representations of such relations with effective decidability of overlapping-ness, most-sepcific-ness and such. Unsurprisingly, there are representations with nice decidabilities, but they are not very expressive; and on the other hand there are representations with undecidable properties (see -fallow-undecidable-instances) This is an active area of research in the term rewriting/tree automata community, see for example the chapters on automata and n-ary relations (as well as tree set automata) in the TATA book. http://www.grappa.univ-lille3.fr/tata/ Well, at least my impression is that these topics *are* closely related, and *both* should certainly benefit from a closer investigation of their interrelations. (this is what I'll be attempting in one part of my thesis.) best regards, -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 -- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: efficiency of UArray
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 16 May 2002, Simon Peyton-Jones wrote: GHC doesn't remove intermediate lists down both branches of a zip, so yes, you'll get intermediate lists. Does deforestation not apply in this situation? - -- Russell O'Connor[EMAIL PROTECTED] http://www.math.berkeley.edu/~roconnor/ ``Later generations will regard set theory as a disease from which one has recovered.'' -- Poincare -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE85YbuuZUa0PWVyWQRAp5mAJ9r8rwosEr+1Z8CC/fjHa9gtuf7YACfcS+2 MIkhxrpDHjW/sqjl08Gkres= =/A1n -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Class Multiplicity
I have a curious Haskell design pattern. It's called one class per
function. It's strange, but I find that as I need more and more
generality, I end up with classes that look like this:
class (Monad m) = MonadGettableReference m r where
{
get :: forall a. r a - m a;
};
class (Monad m) = MonadSettableReference m r where
{
set :: forall a. r a - a - m ();
};
...and then I'll have a bunch of joining classes. Here's a joining
class:
class
(
MonadGettableReference m r,
MonadSettableReference m r
) = MonadFixedReference m r;
instance
(
MonadGettableReference m r,
MonadSettableReference m r
) = MonadFixedReference m r;
Sooner or later, for maximum generality they're all going to look like
this:
class Foo a where
{
foo :: a;
};
class Bar a where
{
bar :: a;
};
class
(
Monad m,
forall a. Foo (a - m a), -- pending appropriate extension
forall b. Bar (m b)
) = FooBar m;
instance
(
Monad m,
forall a. Foo (a - m a),
forall b. Bar (m b)
) = FooBar m;
I'm not sure if this is a good thing or a bad thing or what.
--
Ashley Yakeley, Seattle WA
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: What does FP do well? (was How to get ...)
Bjorn Lisper: ...sometimes the length of a list being returned from a function can be a simple function of the function arguments (or the sizes of the arguments), think of map for instance. In such cases, a static program analysis can sometimes find the length function. If we know thee functions for all list-producing functions in a closed program, then the lists could be represented by arrays rather than linked structures. I know Christoph Herrmann worked on such a program analysis some years ago. Also, I think Manuel Hermenegildo has done this for some logic language. Andrew Appel wrote something about pointer-less lists as well. What bothers me quite strongly is the algorithmic side of operations upon such objects. Typical iterations map- (or zip-) style: do something with the head, pass recursively to the tail, would demand intelligent arrays, with the indexing header detached from the bulk data itself. The consumed part could not be garbage collected. In a lazy language this might possibly produce a considerable amount of rubbish which otherwise would be destroyed quite fast. The concatenation of (parts of) such lists might also have very bad behaviour. Can you calm my anxiety? Jerzy Karczmarczuk ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ASSIST ME
On Friday 17 May 2002 02:10, John Peterson wrote: We could go to member-only posting if that's what people want but it means that students asking their homework questions will have a harder time :-). Surely that's a good thing! Maybe they will go to the people who are paid to help them, or maybe even try themselves, rather than posting their assigned questions verbatim to the list. On the other hand, maybe they will subscribe to the list and continue as before. Regards, Jim ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: What does FP do well? (was How to get ...)
Jerzy: Me: ...sometimes the length of a list being returned from a function can be a simple function of the function arguments (or the sizes of the arguments), think of map for instance. In such cases, a static program analysis can sometimes find the length function. If we know thee functions for all list-producing functions in a closed program, then the lists could be represented by arrays rather than linked structures. I know Christoph Herrmann worked on such a program analysis some years ago. Also, I think Manuel Hermenegildo has done this for some logic language. Andrew Appel wrote something about pointer-less lists as well. What bothers me quite strongly is the algorithmic side of operations upon such objects. Typical iterations map- (or zip-) style: do something with the head, pass recursively to the tail, would demand intelligent arrays, with the indexing header detached from the bulk data itself. The consumed part could not be garbage collected. In a lazy language this might possibly produce a considerable amount of rubbish which otherwise would be destroyed quite fast. The concatenation of (parts of) such lists might also have very bad behaviour. Can you calm my anxiety? No, since you're right. For instance, stream-type list computations, where list elements are used and then discarded, will not benefit from this kind of transformation. (They will be better optimized by deforestation.) List-to-array conversion will work best with computations where many different elements are used many times. Björn ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Positions Available
There are a number of people interested in FP at the University of Leicester, so maybe we can increase that number ... UNIVERSITY OF LEICESTER DEPARTMENT OF MATHEMATICS AND COMPUTER SCIENCE The Department of Mathematics and Computer Science invites applications for five positions in Computer Science. One position is at the professorial level and the others are lectureships, which are at a similar level to assistant professor positions in North America. The Department is divided into three groups: Computer Science, Pure Mathematics and Applied Mathematics. The current research interests of the Computer Science group are in Logic, Algorithms Complexity, Theory of Distributed Reactive Systems and Semantics. The appointments are intended to diversify and strengthen the Computer Science group with regards to both teaching and research. The successful applicants will be ambitious, able to develop their own research within a multi-faceted environment, and have a strong research record and potential. This is a superb opportunity for persons of energy, drive and ambition to assume rewarding roles and to establish themselves in a young, dynamic and rapidly developing department. Information about all aspects of the Department is available from its web pages [http://www.mcs.le.ac.uk]. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ CHAIR IN COMPUTER SCIENCE (Ref: P9044) We are looking for a person of drive and enthusiasm to create a leading research group. Candidates whose research interests are complementary to the existing research groups are particularly encouraged to apply. Nevertheless, applications are welcomed from individuals with an outstanding research record in any area of Computer Science. The appointment will commence on a date to be agreed. The salary will be within the professorial range. Further particulars are available from: Personnel Office (Professorial Appointments), University of Leicester, University Road, Leicester, LE1 7RH, U.K. Tel: (+44) (0)116 252 2422, Fax: (+44) (0)116 252 5140, email: [EMAIL PROTECTED], web: www.le.ac.uk/personnel/jobs. Candidates should submit one unbound copy of their application to the Personnel Office (Professorial Appointments). Closing date: 21st June 2002 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ LECTURERS A/B IN COMPUTER SCIENCE (Ref: A5485) 20,470 to 32,537 pounds pa (March 2002 pay scales) Available from 1st September 2002 LECTURER A IN COMPUTER SCIENCE (Ref: A5504) 20,470 to 24,435 pounds pa (March 2002 pay scales) Available for 2 years from 1st September 2002 Applications are invited for three lectureships (to start 1st September 2002 or as soon as possible thereafter) and a two-year lectureship in Computer Science (to start 1st September 2002). There is no restriction regarding the area of research and applicants with expertise in any area of Computer Science are welcomed. Application forms and further particulars are available (by quoting the reference) from Personnel Office, University of Leicester, University Road, Leicester, LE1 7RH, U.K. Tel: (+44) (0)116 252 5114, Fax: (+44) (0)116 252 5140, email: [EMAIL PROTECTED], web: www.le.ac.uk/personnel/jobs. Closing date: 10th June 2002 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Candidates who are interested in any of these positions are invited, if they so wish, to contact either of: Prof Rajeev Raman Professor Rick Thomas, Head of Computer Science Head of Department, telephone (+44) (0)116 252 3894telephone (+44) (0)116 252 3885 email [EMAIL PROTECTED]e-mail [EMAIL PROTECTED] who will be pleased to discuss the positions further. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Negative literals and the meaning of case -2 of -2 - True
To find out how Haskell implementations treat negated literals, I tested the following program: main = print (minusTwo,trueOrFalse) minusTwo = -2::N trueOrFalse = case minusTwo of -2 - True _ - False data N = Negate N | FromInteger Integer deriving (Eq,Show) instance Num N where negate = Negate fromInteger = FromInteger - The result is: * ghc 5.02.2: main outputs: (FromInteger (-2),True) GHC has two bugs in this area, one of which has been fixed recently. The current output is (Negate (FromInteger 2),False) (i.e. the same as hbc). We were being a little too eager to replace 'negate (fromInteger N)' by 'fromInteger (-N)'. There is also a bug in the pattern handling, however. Thanks for a nice test case... Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Call for papers for the SSGRR 2002s. Conference in L`Aquila near Rome,Italy (Jul 29 - Aug 4 2002.)
Dear Dr. Haskell, I have been appointed to serve as the General Chair of the Summer 2002 edition of the SSGRR series of international conferences. The SSGRR-2002S (Summer) conference on Infrastructure for e-Business, e-Education, e-Science, and e-Medicine takes place in SSGRR (Scuola Superiore G. Reiss Romoli), the delux congress and educational center of the Telecom Italia Group of companies. Programming-related papers (C,C++,JAVA,etc...) are of special interest for this conference, and your contributions are welcome! This is in L'Aquila near Rome, Italy, from July 29 (Monday) at 5pm (start of the Grand Opening) till August 4 (Sunday) at 10am (departure of busses to the Rome airport Fiumicino and the railway station Tiburtina). Most of the past participants beleive that this was one of the most interesting, most useful, and definitely THE most hospitable conference they ever attended. The SSGRR-2002S will be open by Jerome Friedman from MIT (laureate of the NOBEL PRIZE) and Travor Gruen-Kennedy of Citrix (listed by some sources as one of the world's TOP-25 contributors to the development of the Internet). For details, see the WWW site of the conference (www.ssgrr.it/en/ssgrr2002s/index.htm). Among other things, this WWW site also includes the full-blown version of the invitation letter-contract, with all relevant details (www.ssgrr.it/en/ssgrr2002s/invitation.htm). The soft deadline for you to decide if you are coming is May 25, 2002 (in the worst case you should respond before May 31th). By that date the place for you is unconditionally reserved. After that date, you will be accepted to the conference only if the existing 240 places are not filled. Before May 25, 2002, please send only the following: (a) TITLE, (b) AUTHORS, (c) AFFILIATION, (d) ABSTRACT, and (e) STATEMENT THAT YOU WILL COME 100% (answers like maybe will be treated as NO answer from you). The full paper is due on June 20, 2002. The early registration price for the 6-day stay at SSGRR is EURO1200 (if you represent an institution) or EURO1440 (if you come as an individual). Coming without a paper costs you extra EURO600 or EURO720, respectively. Deadline for the early registration is June 30, 2002. If you come with an accompanying person, the early registration extra cost is EURO300, for 6 days of bed and breakfast, in an external hotel (please note that the best external hotels are 4-star, and not nearly as comfortable as the accommodation in the SSGRR complex). The SSGRR complex includes only single-bed rooms, and therefore available only to those who come without an accompanying person. If you have any questions, please check the WWW site of the conference and especially the part entitled FAQ(Frequently Asked Questions). If you still have questions or there is something that we can do for you, please write to Organizing Committee at [EMAIL PROTECTED] (preferred) or if absolutely necessary, to myself directly ([EMAIL PROTECTED]). Sincerely yours, Professor V. M. Milutinovic, General Chair of the SSGRR-2002S (galeb.etf.bg.ac.yu/~vm/) P.S. No matter if you will attend the SSGRR-2002S conference or not, please let us know if you like to be invited to the Winter edition of the year 2003 (SSGRR-2003W) to be held in the same place from January 6, 2003 at 5pm till January 12, 2003 at 10am. Shall we reinvite you? Of course, if you wish not to receive again information about the SSGRR conferences, please let us know, and we will remove your name from our list. IMPORTANT DETAILS: 1. Your presentation is 25 minutes, plus 5 minutes for discussion and the change of speakers. 2. The author of the LAST paper in the session is the session chairman, so he/she is motivated to respect the timing. The slots of the non-show-up papers are to be used for extra discussions. Moving of presentation slots is NOT permitted. 3. Timing of the session is given on the WWW site of the conference. 4. Special sessions are dedicated to advanced programming, 5. More information on the SSGRR center is given on the WWW site of the conference. 6. Transportation related information, on July 29 from Tiburtina station in Rome to SSGRR in L'Aquila, and on August 4 from L'Aquila to Tiburtina station and Fiumicino airport is given in the conference WWW site (pay attention to FAQ). 7. Details of the food schedule, social program, and all other relevant details are also given on the WWW site of the conference. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Dependent Types
Robin,
Thanks very much for this. My problem turned out to be tripping over the
monomorphism restriction. When I looked at this it looked like a candidate
for dependent types but as you point out you can solve this just as well in
Haskell 98. You save a set of brackets with my approach!
Dominic.
Jon Fairbairn [EMAIL PROTECTED]@haskell.org on 16/05/2002
16:45:28
Sent by: [EMAIL PROTECTED]
To: Dominic Steinitz dominic.j.steinitz
cc: haskell
bcc:
Subject: Re: Dependent Types
Dominic Steinitz [EMAIL PROTECTED] wrote:
I've managed to crack something that always annoyed me when I used to do
network programming.
[. . .]
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.
I'm not sure I understand your problem. I don't see what's
wrong with the following approach, which is Haskell 98. The
type byte is coded as the type of the packet. Excuse the
perhaps ideosyncratic style ... (in particular, I'm
expecting people to use import qualified with this).
module ICMP where
data Type = Redirect RedirectData
| TimeExceeded TimeData
{- so you get an alternative for each of the packet types -}
instance Enum Type where
fromEnum (Redirect _) = 5
fromEnum (TimeExceeded _) = 11
{- we can't derive Enum for ICMP.Type, because it has non-nullary
constructors. That just makes it a bit more tedious
One could provide a class code with code:: t - Int
instead of fromEnum
-}
{- now we define individual record types for each of the different
ICMP types -}
data RedirectData = RedirectData {redirectCode:: RedirectCode,
ip_addr:: Int, -- whatever
redirectData:: [Int]} -- or whatever
data RedirectCode = RedirNet
| RedirHost
| RedirNetToS
| RedirHostToS
deriving Enum
data TimeData = TimeData {timeCode:: TimeExceededCode,
timeData:: [Int]} -- or whatever
data TimeExceededCode = ExcTTL
| ExcFragTime
deriving Enum
{- Since Haskell 98 doesn't have MPTCs, if we want to
encode packets as anything other than [Int] we'd have
to define more classes. Encode serves as an example. -}
class Encode t where
encode:: t - [Int]
instance Encode Type where
encode p@(Redirect d) = fromEnum p: encode d
encode p@(TimeExceeded d) = fromEnum p: encode d
instance Encode RedirectData where
encode d = fromEnum (redirectCode d): ip_addr d: redirectData d
instance Encode TimeData where
encode d = fromEnum (timeCode d): 0: timeData d
so one can go
encode (Redirect (RedirectData RedirNet 0 [0]))
and get [5,0,0,0], but
encode (TimeExceeded (TimeData RedirNet 0 [0]))
gives an error, as one would hope. What am I missing?
Cheers,
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
-
Save time by using an eTicket and our Self-Service Check-in Kiosks.
For more information go to http://www.britishairways.com/eservice1
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Class Multiplicity
On Thursday 16 May 2002 11:48 pm, Ashley Yakeley wrote: I have a curious Haskell design pattern. It's called one class per function. [...] I'm not sure if this is a good thing or a bad thing or what. You might want to take a look at the class system for the language Concurrent Clean. It encourages a one class per function setup similar to the one you mentioned, but without nearly as much syntax. The following is quoted from http://www.cs.kun.nl/~clean/About_Clean/tutorial/tutorial.html: In Clean a class is a family of functions with the same name As a very simple example consider the class of increment functions. class inc t :: t - t This says that the class inc has type variable t. There is only a single manipulation function in this class, which is also named inc. The type of this increment function is t - t. Instances of this class for integers and reals are defined by: instance inc Int where inc i = i+1 instance inc Real where inc r = r+1.0 ... - Brian Huffman ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
I need to know
Hi. Im a new haskell user, I know there are library about graphs, but i need to know all the info about, where I can download this library, and what can i do with it, and how can I use it. Thanks. __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: convering Fds to Handles
Sebastien Carlier [EMAIL PROTECTED] writes: Specifically, I'd like to use pipe from the Posix library to create a pipe and then pass one end of it to runProcess as its stdin. You may want to take a look at POpen (available from hslibs cvs, or http://www.01.246.ne.jp/~juhp/haskell/popenhs/). Process output works well, though it still has some problems with lazy process input. I have had problems with pipes and runProcess, now I am using forkProcess/executeFile/getProcessStatus and it works properly. Non-lazy IO presumably? Do you have an example you can show? Jens ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Ò»Ìõ¿í´ø¾Í×ã¹»ÁË£¡
ÄúºÃ£¬ÎÒÊDZ±¾©ÍòÀÊÍøÂç¿Æ¼¼ÓÐÏÞ¹«Ë¾Êг¡¿ª·¢²¿£¨Mario Yao),ºÜ¸ßÐËͨ¹ýÍøÂçÈÏʶÄãÃÇ£¬ÎÒÏ£ÍûÎÒÃÇÄܹ»Í¨¹ýÕâ´ÎÈÏʶ¿ªÊ¼ÎÒÃÇÓä¿ìµÄÉÌÒµºÏ×÷¡£ÎÒÃÇ´úÀíÃÀ¹úASANTE¹«Ë¾£¨Asante.com)¹«Ë¾µÄÀ¶É«Ð¡¾«ÁéϵÁпí´ø·ÓÉÉ豸¡£À¶É«Ð¡¾«ÁéȷʵÊÇÒ»¿î³öÉ«µÄ²úÆ·£¬Èç¹ûÄúÄܹ»ÐÖúÎÒÃǽøÐдúÀí»òÕß¾ÏúÕâ¿î²úÆ·£¬ÎÒÃǽ«·Ç³£¸ßÐË£¬²¢½«¸øÓèÄú×î´óµÄÖ§³Ö£¬ÇëÄú¶àÌᱦ¹óÒâ¼û¡£¿ÉÄÜÏÂÃæÎÒ˵µÄÄ㶼ÒѾÁ˽⣻ ÎÒÔÀ´Ò²ºÍ´ó¶àÊýÅóÓÑÒ»Ñù£¬ÔÚ¹«Ë¾ºÍÔÚ¼ÒÀﶼһֱ²ÉÓÃWindows9x/NT+Sygate»òÓÃWindows2000À´ÊµÏÖ¶à»ú¹²ÏíÉÏÍøµÄ£¬ËäÈ»ÕâÖÖ·½Ê½½Ï¾¼ÃÊ¡Ç®£¬µ«×ÜÊDz»Ì«Îȶ¨ºÍÀíÏ룬¸üÖØÒªµÄÊÇ£¬ÓÃÁËADSLÒÔºó³¤Ê±¼ä¹ÒÔÚÍøÉÏ£¬¾ÖÓòÍøϵͳºÜ²»°²È«£¬Í¬Ê±µ±ÒªÊµÏÖÈÃÍâÍø¼ÆËã»úÓû§À´·ÃÎÊ×Ô¼º¾ÖÓòÍøµÄWeb»òFTP·þÎñÆ÷¶¼ºÜÀ§ÄÑ£»¸ü²»·½±ãµÄÊÇÄÇ̨×÷Ϊ¹²Ïí²¦ºÅÁ¬½ÓµÄÈí·ÓÉÍø¹Ø¼ÆËã»ú±ØÐ볤ʱ¼ä¿ª×Å£¨¾ÍÏóÊÇÔÚ×ö³¤Ê±¼äµÄ¡°ÀÏ»¯¡±²âÊÔÓë¡°¿¼»ú¡±ÊÔÑéÒ»Ñù£¬ÓÐʱÏëÏëÒ²ÐÄÍ´£©£¬¶øÇÒÕą̂¼ÆËã»úµÄÓ²¼þÅäÖû¹ÒªÇóÂù¸ßµÄ²ÅÐУ¬·ñÔò¾Í¾õµÃ¡°ÍÏ¡±²»¶¯ÆäËü»úÆ÷¡£¿ÉÒªÊÇÄãÏë³ä·Ö·¢»ÓÕą̂½Ï¸ßÅäÖõġ°ºÃ»úÆ÷¡±µÄЧÄܶøÐèÒªÔÚËüÉÏÃæͬʱÔËÐÐһЩ´óÐÍÈí¼þÏóAutoCAD, PhotoshopºÍ×°ÁË´óÐÍÊý¾Ý¿âϵͳʱ£¬ËüÓÖ»áºÜÈÝÒ×µØÔì³É¡°ËÀ»ú¡±»ò²»Îȶ¨£¬Õâ·´¶ø³ÉÁ˾ÖÓòÍøÄÚÆäËûÓû§ÉÏÍøÊÜ×èµÄÆ¿¾±ÁË£¬ÕæΪ´ËûÉÙÉËÄԽ Ö±µ½ÎÒÃÇʹÓÃÁËÀ¶¾«ÁéϵÁÐϵÁпí´ø·ÓÉÆ÷£¬ÒÔÉÏÌáµ½µÄ¸÷ÖÖ·³ÄպͲ»±ãµÄʶ¼²»Óõ£ÐÄÁË£¬È«¶¼ÄܺÜÈÝÒ׵ؿìËٸ㶨¡£ À¶¾«ÁéϵÁпÉÒÔ×öÖÐСÆóÒµ¿í´ø·ÓÉÆ÷£¬Ö§³ÖxdslºÍCalbe¡£Ñù×ÓºÜÏÖ´ú£¬ÓдòÓ¡¿Ú¿ÉÇáËÉʵÏÖÍøÂç´òÓ¡£¬FR3002AL¿ÉÒÔ²åÉÏÎÞÏßÍø¿¨×öÎÞÏß¾ÖÓòÍø·ÓÉÆ÷£¬ÓÐÁËËü¾Í²»ÐèÒªÓÃһ̨˫Íø¿¨µÄµçÄÔ×÷Íø¹Ø»ò·þÎñÆ÷ÁË,¶øÇÒ¸ÃÉ豸¹ÜÀí·Ç³£ÈÝÒ×,ÓÃä¯ÀÀÆ÷¾Í¿ÉÒÔ·ÃÎʵ½Ëü£¬½ÚÊ¡Á˼¼ÊõÖ§³Ö¿ªÏú¡£ÁíÍâFR3004LCµÄÓÐÏßϵÁУ¬¿ÉÒÔÂú×ãÔÝʱ²»ÓÃÎÞÏßµÄÓû§¡£ÔÚ±±ÃÀ£¬¹«Ë¾Ôڰ칫ÊÒ´ó¶àÓÃËü×ö·þÎñÆ÷¡£×î´óµÄºÃ´¦ÊDz»µ«¿É½â·Å³öһ̨ÔÀ´×ö·ÓÉÍø¹ØµÄ¸ßÅäÖüÆËã»ú£¨·þÎñÆ÷£©£¬¶øÇÒËùÓоÖÓòÍøÓû§ÉÏÍøʱµÄÁ¬½ÓÏìÓ¦ËÙ¶ÈÃ÷ÏÔ±ÈÔÏÈ·½Ê½¿ì£¬¶øÇÒÎȶ¨£»ÒòΪÆäÌå»ýСÇÉ£¬µçÔ´¹¦ºÄÒ²ºÜС£¬ÊÊÒ˳¤Ê±¼ä¿ª»úÔÚÏß¹¤×÷£¬ÇÒ²»Õ¼µØ룬¿ÉÓëADSL»òCable Modem·ÅÔÚÒ»¸ö»ú¼Ü°åÉÏ£¬±ãÓÚÒ»Æð¹Û²ìºÍ¼à»¤ËüÃǵŤ×÷״̬¡£¸Ã·ÓÉÆ÷»¹´øÓÐ4¿Ú£¨Ò²Óдø8¿Ú£©µÄ½»»»Ê½10/100MB HUB£¬ËùÒÔ¶ÔÓÚÐèÒª¹²ÏíÁ¬Íø»úÆ÷½ÏÉÙµÄÓû§£¬»¹Ê¡È´Á˱¾À´ÐèÁíÍâ×Ô¹ºÒ»Ì¨½»»»Ê½/¹²ÏíʽHUBµÄ¿ªÏú¡£ ÁíÍ⣬ÓÉÓڸ÷ÓÉÆ÷¾ßÓзÀ»ðǽ¹¦ÄÜ£¬ËùÒÔ¿ÉÒÔ²»±ØÔÙµ£Ðij¤Ê±¼äÁ¬ÔÚ»¥Á¬ÍøÉÏ×Ô¼º¾ÖÓòÍø¼ÆËã»úµÄ°²È«ÎÊÌâ¡£¸Ã·ÓÉÆ÷»¹´øÓпÉÏÞÖÆÖ¸¶¨µÄÒòÌØÍøÍøÖ·£¨IP°ü¹ýÂË£©¹¦ÄÜ£¬¿É½ûÖ¹Ö¸¶¨PCÉÏÍøµÈµÈÐí¶àÆäËüʵÓúÍÌØÊâµÄ¹¦ÄÜ£¬ÕâЩÄÜÂú×ãÒ»²¿·ÖÓж෽ÃæÐèÇóµÄÓû§µÄÓ¦ÓÃÐèÒª¡£Å¶£¬¶ÔÁË£¬»¹ÓÐËüµÄ¼Û¸ñ±ÈÆðÔÀ´×÷Èí·ÓÉÍø¹ØµÄ·þÎñÆ÷(PC)À´Ö»ÓÐÆ伸·ÖÖ®Ò»¡£ ºÃÁË£¬ËµÁËÕâô¶à£¬Õ¼ÓÃÁËÄú±¦¹óµÄʱ¼ä×ÊÔ´£¬ÔÚ´ËÏòÄúµÀǸ£¬Èç¹ûÄú¶ÔAsante²úÆ·ÏëÁ˽â¸ü¶àÏêÇéµÄ»°£¬Äú¿ÉÒԵǽÎÒÃǵÄÍøÕ¾www.51wlan.com»òwww.asante.com.cn(AsanteÖÐÎÄÍøÕ¾£©£¬ÄúÒ²¿ÉÒÔ¸øÎÒдÐÅ£¬ÎÒÆÚ´ýÄúµÄÀ´ÐÅ£¡ ͬʱҲ»¶ÓÄúÏòÎÒ½éÉÜÄú¾õµÃÓмÛÖµµÄºÃ²úÆ· ÃÀ ¹ú Asante ¿í Ƶ · ÓÉ Ìá ¹© ÉÌ ±± ¾© Íò ÀÊ Íø Âç ¿Æ ¼¼ ÓÐ ÏÞ ¹« ˾ Wlan Networks Technologies, Inc. TEL:86(10) 82029760 82029761 82866008 82866015 13301073855 MAIL: 51wlan@51wlan http://www.51wlan.com http://www.asante.com(English Homepage) http://www.asante.com.cn (Chinese Homepage) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: convering Fds to Handles
Hi, I have had problems with pipes and runProcess, now I am using forkProcess/executeFile/getProcessStatus and it works properly. Non-lazy IO presumably? Do you have an example you can show? Sure: ---_%--- cut here ---_%--- module Main where import IO import Posix import System main = do (ri, wi) - createPipe (ro, wo) - createPipe rih - fdToHandle ri woh - fdToHandle wo runProcess /bin/cat [] Nothing Nothing (Just rih) (Just woh) Nothing wih - fdToHandle wi hPutStrLn wih (replicate 1 'a') roh - fdToHandle ro cs - hGetContents roh fdClose wi putStrLn (show $ length cs) ---_%--- cut here ---_%--- I am using GHC 5.03 from the HEAD (May 12 2002), on MacOS X. Older versions of GHC on Linux exhibit the same behavior. Output: localhost% ghc -o foo -package posix Main.hs localhost% ./foo /bin/cat: stdin: Resource temporarily unavailable 8192 localhost% It seems that the output is truncated to some buffer size, and I couldn't get rid of the error message. If you set up the file descriptors yourself (using dupTo, fdClose, forkProcess, and executeFile as appropriate), it seems to works better (no error message, and no limit on input/ouput size). Is runProcess broken? Or does the above example abuse its power? -- Sébastien ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: convering Fds to Handles
Sebastien Carlier [EMAIL PROTECTED] writes: I have had problems with pipes and runProcess, now I am using forkProcess/executeFile/getProcessStatus and it works properly. Non-lazy IO presumably? Do you have an example you can show? Sure: ---_%--- cut here ---_%--- snip ---_%--- cut here ---_%--- It seems that the output is truncated to some buffer size, and I couldn't get rid of the error message. If you set up the file descriptors yourself (using dupTo, fdClose, forkProcess, and executeFile as appropriate), it seems to works better (no error message, and no limit on input/ouput size). I meant do you have an example of your working code. Jens ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: convering Fds to Handles
I meant do you have an example of your working code. Sure. SubProcess.lhs Description: Binary data localhost% cat Main.hs module Main where import SubProcess main = do cs - subprocess /bin/cat [] (Just $ replicate 1 $ 'a') putStrLn $ show $ length cs localhost% ghc -package posix --make -o foo Main.hs ghc-5.03: chasing modules from: Main.hs Compiling SubProcess ( SubProcess.lhs, SubProcess.o ) Compiling Main ( Main.hs, ./Main.o ) ghc: linking ... localhost% ./foo 1 localhost% Note that is does leave zombie processes, since getProcessStatus is never called. I think, maybe appending something like the following to the ouput would work: output ++ (seq (unsafePerformIO childStatus) []) where childStatus = hClose roh ; getProcessStatus True False pid You would return childStatus along with the ouput. If the end of the string is reached, the zombie child will be reaped automatically. If you prematurely decide to stop reading the ouput, you have to call childStatus manually. I didn't bother to test it, because I didn't care about zombie processes. -- Sébastien
Re: convering Fds to Handles
* Sebastien Carlier [EMAIL PROTECTED] [020517 17:17]: I meant do you have an example of your working code. Sure. I'm sorry if this is a bit off-topic, but I got the following error when compiling Sebastien's code (with my ghc-5.02.3-2mdk): SubProcess.lhs:5: failed to load interface for `Posix': Could not find interface file for `Posix' while my Posix library files found in /usr/lib/ghc-5.02.3/imports/posix/ and also my /usr/lib/ghc-5.02.3/package.conf seems perfectly normal any hints pls? -- Regards, Jerry ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: convering Fds to Handles
On Friday, May 17, 2002, at 11:58 AM, Jerry, JiJie wrote: SubProcess.lhs:5: failed to load interface for `Posix': Could not find interface file for `Posix' while my Posix library files found in /usr/lib/ghc-5.02.3/imports/posix/ and also my /usr/lib/ghc-5.02.3/package.conf seems perfectly normal any hints pls? Make sure you added -package posix to you compilation command. -- Sébastien ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Simple Question Again
Hi, I'm sorry to bother everyone again with this simple append' stuff -- below is my revised append' function 1) append' :: [[a]] - a - [[a]] 2) append' [] y = [[y]] 3) append' (x:xs) y = 4) case xs of [] - foldr (:) [y] x 5)(z:zs) - (init (x:xs)) ++ [(last xs)++[y]] -- to achieve append' [] 1 = [[1]] append' [[1]] 2 = [[1, 2]] append' [[1], [2]] 3 = [[1], [2, 3]] -- and ghc gives the following compile error: p3a.hs:4: Cannot unify the type-signature variable `a' with the type `[a]' Expected type: [a] Inferred type: a In the list element: y In the second argument of `foldr', namely `([y])' make: *** [p3a] Error 1 -- now this is something I _really_ don't understand: -- x is of type [a], [y] is of type [a], and isn't foldr (:) [a] [a] -- perfectly valid?! Much thanx in advance -- Regards, Jerry ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Simple Question Again
On Fri, 17 May 2002, Jerry wrote: Hi, I'm sorry to bother everyone again with this simple append' stuff -- now this is something I _really_ don't understand: -- x is of type [a], [y] is of type [a], and isn't foldr (:) [a] [a] -- perfectly valid?! :type foldr forall a b. (a - b - b) - b - [a] - b now foldr is used with (:) which has type a - [a] -[a] so, to find the type of foldr (:) the type (a- b - b) must be unified with (:):: c-[c] - [c] therefore, (replacing a with c and b with [c]) foldr (:) :: [c] - [c] - [c] which is what you expected. however, you forgot. 1) append' :: [[a]] - a - [[a]] 2) append' [] y = [[y]] 3) append' (x:xs) y = 4) case xs of [] - foldr (:) [y] x 5)(z:zs) - (init (x:xs)) ++ [(last xs)++[y]] in case of [] - foldr (:) [y] x, foldr (:) [y] x :: [c], the same type as x. but append' works on lists of type [[c]] adds a element of type c and returns something of type [[c]], as you have declared in the type declaration of append'. so, what is the real problem? the type given by foldr (:) [y] x :: [c] doesn't match the resultant type of append', namely [[c]] Also, another good thing to check is that all branches of a case statement have the same type. If something x =case x of True - 3; False - lala could compile, what would be it's type?? (Hint, if you come from the dynamically typed world and do want to do something of the sort, there is the Either type. case x of True - Left 3; False - Right lala Jay Cox ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Q: Resolving ambiguous type variable
Hello, I am writing a function which returns an exception/error string should an unexpected parameter is passed in. Borrowing from the Maybe module I have the following: data Result a = Ex String | Value a deriving Show -- Testing the Result a type first_h :: [a] - Result a first_h [] = Ex No list first_h (x:xs) = Value x -- Trying out the first_h main :: IO() main = print (first_h []) Which the compiler complains: Ambiguous type variable(s) `a' in the constraint `Show a' arising from use of `print' at atype.hs:8 In the definition of `main': print (first_h []) This is understandable since it is unable to unify the empty list with a concrete list of type 'a' i.e. there are an infinite types which would match. My question is how can I indicate to the compiler that it does not matter which type the empty list is since the return result is of a concreate type. Thanks Tee ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Q: Resolving ambiguous type variable
In short, you cannot. What if your main were: main = getArgs = print . first_h The compiler doesn't know the difference and so it needs a type. Simple fix: main = print (first_h ([] :: [Char])) -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Fri, 17 May 2002 [EMAIL PROTECTED] wrote: Hello, I am writing a function which returns an exception/error string should an unexpected parameter is passed in. Borrowing from the Maybe module I have the following: data Result a = Ex String | Value a deriving Show -- Testing the Result a type first_h :: [a] - Result a first_h [] = Ex No list first_h (x:xs) = Value x -- Trying out the first_h main :: IO() main = print (first_h []) Which the compiler complains: Ambiguous type variable(s) `a' in the constraint `Show a' arising from use of `print' at atype.hs:8 In the definition of `main': print (first_h []) This is understandable since it is unable to unify the empty list with a concrete list of type 'a' i.e. there are an infinite types which would match. My question is how can I indicate to the compiler that it does not matter which type the empty list is since the return result is of a concreate type. Thanks Tee ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Q: Resolving ambiguous type variable
Erm, I think I said something stupid (or at least implied it). main = getArgs = print . first_h *will* work, because it knows that the result of a getArgs is a list of Strings. The problem you originally had was that when you say: first_h [] The [] could refer to a list of any type of element. Since not every element type is an instance of Show, it doesn't know that it can apply show to the list. By saying, for instance, (first_h ([] :: [Char])) you're saying okay, this is an empty list, but it's a list of Characters and you know that a character can be shown. If you backtrack what the type checker is doing, it says: print (first_h []) okay, the argument to print must be an instance of Show (print has type Show a = a - IO ()). therefore, first_h [] must be an instance of Show. well, what's the type of first_h []? Well, the type of first_h is [a] - Result a. is Result a an instance of show? well, let's see...you said data Result a = ... deriving (Show). this basically means you get an instance declaration: instance Show a = Show (Result a) where ...some stuf... so, we want to know if Result a is an instance of show. Well, it is whenever a is an instance of show. so, if the elements of your list are an instance of show, then (first_h []) is an instance of Show, as we require. however, since you just say [] it knows this is of type [a], but it *doesn't* know what a is. therefore, a could either be or not be an instance of show. however, if you explicitly specify what a is and that explicit type is an instance of show (like Char in my example), then everything is fine. -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Fri, 17 May 2002, Hal Daume III wrote: In short, you cannot. What if your main were: main = getArgs = print . first_h The compiler doesn't know the difference and so it needs a type. Simple fix: main = print (first_h ([] :: [Char])) -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Fri, 17 May 2002 [EMAIL PROTECTED] wrote: Hello, I am writing a function which returns an exception/error string should an unexpected parameter is passed in. Borrowing from the Maybe module I have the following: data Result a = Ex String | Value a deriving Show -- Testing the Result a type first_h :: [a] - Result a first_h [] = Ex No list first_h (x:xs) = Value x -- Trying out the first_h main :: IO() main = print (first_h []) Which the compiler complains: Ambiguous type variable(s) `a' in the constraint `Show a' arising from use of `print' at atype.hs:8 In the definition of `main': print (first_h []) This is understandable since it is unable to unify the empty list with a concrete list of type 'a' i.e. there are an infinite types which would match. My question is how can I indicate to the compiler that it does not matter which type the empty list is since the return result is of a concreate type. Thanks Tee ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Q: Resolving ambiguous type variable
The problem is that a is still ambiguous. For instance, look at the difference between: show ([] :: [Int])== [] show ([] :: [Char]) == because character lists are shown between quotes. so even though we know that this type variable a is an instance of show, we still don't know how to show it (i.e., we don't know which dictionary to use to lookup the show function for the datatype). -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Fri, 17 May 2002 [EMAIL PROTECTED] wrote: Would it be correct to conclude from your reasoning that the following would be properly typed by the compiler ? first_h :: (Show a) = [a] - Result a first_h [] = Ex No list first_h (x:xs) = Value x since we are explicitly stating first_h can only take a list containing elements deriving Show. My expectations would be that this would be unambiguous, unfortunately ghc-5.02.3 still complains with the reported error. Regards Tee Original Message From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Q: Resolving ambiguous type variable Date: Fri, 17 May 2002 10:24:29 -0700 (PDT) Erm, I think I said something stupid (or at least implied it). main = getArgs = print . first_h *will* work, because it knows that the result of a getArgs is a list of Strings. The problem you originally had was that when you say: first_h [] The [] could refer to a list of any type of element. Since not every element type is an instance of Show, it doesn't know that it can apply show to the list. By saying, for instance, (first_h ([] :: [Char])) you're saying okay, this is an empty list, but it's a list of Characters and you know that a character can be shown. If you backtrack what the type checker is doing, it says: print (first_h []) okay, the argument to print must be an instance of Show (print has type Show a = a - IO ()). therefore, first_h [] must be an instance of Show. well, what's the type of first_h []? Well, the type of first_h is [a] - Result a. is Result a an instance of show? well, let's see...you said data Result a = ... deriving (Show). this basically means you get an instance declaration: instance Show a = Show (Result a) where ...some stuf... so, we want to know if Result a is an instance of show. Well, it is whenever a is an instance of show. so, if the elements of your list are an instance of show, then (first_h []) is an instance of Show, as we require. however, since you just say [] it knows this is of type [a], but it *doesn't* know what a is. therefore, a could either be or not be an instance of show. however, if you explicitly specify what a is and that explicit type is an instance of show (like Char in my example), then everything is fine. -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Fri, 17 May 2002, Hal Daume III wrote: In short, you cannot. What if your main were: main = getArgs = print . first_h The compiler doesn't know the difference and so it needs a type. Simple fix: main = print (first_h ([] :: [Char])) -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Fri, 17 May 2002 [EMAIL PROTECTED] wrote: Hello, I am writing a function which returns an exception/error string should an unexpected parameter is passed in. Borrowing from the Maybe module I have the following: data Result a = Ex String | Value a deriving Show -- Testing the Result a type first_h :: [a] - Result a first_h [] = Ex No list first_h (x:xs) = Value x -- Trying out the first_h main :: IO() main = print (first_h []) Which the compiler complains: Ambiguous type variable(s) `a' in the constraint `Show a' arising from use of `print' at atype.hs:8 In the definition of `main': print (first_h []) This is understandable since it is unable to unify the empty list with a concrete list of type 'a' i.e. there are an infinite types which would match. My question is how can I indicate to the compiler that it does not matter which type the empty list is since the return result is of a concreate type. Thanks Tee ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
