July 2001 - Haskell - Haskell.org

Need help
by Shirley Widyaningsih 14 Jul '01

14 Jul '01

--------------------------------------------- WANT A NEW JOB? THEN LET THE JOB FIND YOU Visit www.ecruit.com.au and register your profile. Then the headhunters can find you. --------------------------------------------- Get your own free email account at http://www.freemail.com.au/ now part of the Webuser.com.au independent portal. Visit at http://www.webuser.com.au ---------------------------------------------

1 0

Need help
by Shirley Widyaningsih 14 Jul '01

14 Jul '01

Hi, i've got some problem here. I'm a beginner in Haskell and i've already download haskell 98 <hugs98-feb2001>, but unfortunetly, i've bought books that used hugs 1.3 version. In the book, it's said "in front of a terminal screen, we'll see a displaying prompt sign "?", but in my terminal screen, there's no ? prompt sign execpt the PRELUDE> prompt sign. So could you all help me? do i have to set the hugs library or other after i downloading? my OS is windows 98. Thank you. Regards, Shirley --------------------------------------------- WANT A NEW JOB? THEN LET THE JOB FIND YOU Visit www.ecruit.com.au and register your profile. Then the headhunters can find you. --------------------------------------------- Get your own free email account at http://www.freemail.com.au/ now part of the Webuser.com.au independent portal. Visit at http://www.webuser.com.au ---------------------------------------------

1 0

Post-doc Positions Available at Stevens
by Adriana Compagnoni 13 Jul '01

13 Jul '01

We apologize if you have received multiple copies of this message. ---------------------------------------------------------------------- http://www.cs.stevens-tech.edu/Lab/SecureSystems_Lab/JoinUs.htm Post-Doctoral Positions Available Laboratory for Secure Systems Department of Computer Science Stevens Institute of Technology The Laboratory for Secure Systems at the Computer Science Department of Stevens Institute of Technology invites applications for Post-doctoral positions. The Lab has been recently created, and its mission is to pioneer new technologies for high-assurance and secure systems and prototype tools that can provide guarantees that a system will not exhibit unpredictable behavior in a hostile environment. Our objective is to consolidate and organize research already under way at Stevens. We are taking several approaches to language-based tools for high-assurance, secure systems. Language-based automated analysis can be used to check components during development and also at the point of deployment. Such analyses can complement trust-based approaches to security of mobile components and enhance performance by reducing overhead of run-time checking. Language-based tools fit the programming environments of professional practice, along side other tools like test-generators and performance profilers. Type-based analyses can prevent leakage of privileged data even with dynamic linking and replacement of libraries at run-time. New abstractions are being developed for fault-tolerant computation in wide area networks. Verification techniques can check correctness of implementations of security protocols. Much interest already exists in furthering the technologies, as demonstrated by collaborations of the faculty amongst themselves, with other academic institutions (e.g., with the Secure Internet Programming Laboratory at Princeton, with the FLINT project at Yale, with the University of Edinburgh), and with industrial partners (e.g., Lucent Technologies). Our work has current funding from industrial partners, through multiple grants from the National Science Foundation and the New Jersey Commission of Science and Technology. Successful applicants will be enthusiastic team players with a strong commitment to academic excellence. A PhD in Computer Science or Applied Mathematics or equivalent education is required. Preference will be given to applicants with experience in at least one of the following areas: *Type theory *Static program analysis *Formal verification *Semantics of programming languages *Higher-order programming languages *Implementation of programming languages Post-docs will participate in state of the art research in collaboration with other members of the Lab; they will produce technical reports to document their findings, and participate in building proof of concept software systems to experiment with research advances. The positions are initially for two years, renewable for a third year upon performance and availability of funds. Positions are expected to start with the new academic year in September 2001, but the starting date is flexible. Applicants should send a CV, a statement of research interests, and arrange for three letters of recommendation to be sent to: Adriana Compagnoni Department of Computer Science Stevens Institute of Technology Castle Point on Hudson Hoboken, NJ 07030 U. S. A. e-mail: abc(a)cs.stevens-tech.edu For more information contact Adriana Compagnoni (abc(a)cs.stevens-tech.edu) Dominic Duggan (dduggan(a)cs.stevens-tech.edu) or David Naumann (naumann(a)cs.stevens-tech.edu) Stevens Institute of Technology is an Equal Opportunity Employer. Laboratory for Secure Systems (http://www.cs.stevens-tech.edu/Lab/SecureSystems_Lab/) Computer Science Department (http://www.cs.stevens-tech.edu/) LocalWords: http www SecureSystems JoinUs htm docs initially CV dduggan LocalWords: Naumann

1 0

(no subject)
by Nelson 13 Jul '01

13 Jul '01

unsubscribe luti(a)linkexpress.com.br

1 0

RE: infelicity in module imports
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

Folks It seems that I forgot to send this message a couple of weeks ago. Assuming that silence meant assent, I implemented the proposal below in the report I put out yesterday. But in this case silence meant you hadn't been asked (an excellent way to reach consensus that I must remember for the future). So here's the message anyway. I don't think it's controversial, since it's the outcome the cognoscenti were seeking, and no one else will care. Well, so I hope! Simon | > In short, an import *always* brings the entire *qualified* | > set of names into scope. Hiding and revealing applies only | > to unqualified names. I must say that I thought GHC implemented | > this rule; if not I should fix it. | | That's not my reading of the report, and it's not what GHC implements. | | import A (f) | | brings only f and A.f into scope. How embarassing. Now I look at it (yet) again, the report is certainly ambiguous about whether import A(f) imports A.g as well. But SimonM is right to say that the implication is that it does *not* (contrary to my earlier message). But if it does not, then the treatment of hiding and explicit-listing is inconsistent, which is a Bug. There are two consistent positions 1. Every import of module A (no matter how constrained) imports all of A's exports with qualified names. Import of qualified names is unaffected by both hiding clauses and the explicit entity list 2. The explicit entity list, or hiding clause, for an import determines which entities are imported. The qualified names of all these entities are brought into scope; in addition, for an unqualified import the unqualified names are brought into scope too. Everyone who has spoken favours (2), and indeed GHC implements it. So I propose to change the report to say that much more explicitly. Any objections? Simon

5 5

RE: infelicity in module imports
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

| Even with option 2, there is scope for confusion. "Import" | without "qualified", imports both qualified and unqualified | names, but adding the word "qualified" doesn't make any | difference to the position of qualified names, but instead | silently fails to import unqualified names. True | There is still a | strange asymmetry, too. Whereas adding "qualified" to "import | Modname ( a, b, c)" doesn't change which entities are | imported, just the ability to refer to them by unqualified | names, adding qualified" to "import Modname hiding ( a, b, | c)" has the effect of importing everything that was previously hidden. Not so. I hope the Report now unambiguously states that import M hiding (a,b,c) import qualified M hiding(a,b,c) imports exactly the same entities (namely all that M exports except a,b,c), only in the latter case only the qualified names are brought into scope. Can you suggest a way I could state it more clearly in the Report? | Personally, I think the right solution is to import entire | modules (the exported parts) qualified, and optionally to | allow unqualified reference to some or all names, with a syntax like | import modid [as modid] [unqualifying ( [all except] | impspec] | all) | | but it's probably too late for this. Dead right! Simon

3 2

Another question wrt hiding imports
by Wolfgang Lux 12 Jul '01

12 Jul '01

After the recent discussion import hiding clauses in import declarations, I was wondering what the meaning of hiding clauses is in the case of algebraic data types (or classes). For instance if a have module A where data T = A | B which entities are imported when I include the declaration import A hiding(T) in a module? The report is not clear about this but I would expect that this imports data constructors A and B into the current module but not the type constructor T -- otherwise, what would be the meaning of import A hiding(T(B))? However, if this is true it is possible to export data constructors without their type via module B(module A) where import A hiding(T) which contradicts the statement in section 5.2 on p.64, that the form module m is equivalent to listing all entities imported from that module, because I cannot list a data constructor (without its type) in an export specification. Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux(a)uni-muenster.de

3 3

RE: Fixity declarations
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

Current wording is "A fixity declaration may appear anywhere that a type signature appears and, like a type signature, declares a property of a particular operator. Also like a type signature, a fixity declaration can only occur in the same declaration group as the declaration of the operator itself, and at most one fixity declaration may be given for any operator." Indeed, you can't give either a type signature or a fixity declaration for a pattern-bound variable. (By pattern-bound I include case expressions, function left hand sides etc.) Would it really help to say that you can't give a fixity for a pattern-bound variable? (After all, there are many other things you can't do.) If so, should we not say the same about type signatures? Are there other things that you can't do that should be identified? Simon | -----Original Message----- | From: Koen Claessen [mailto:koen@cs.chalmers.se] | Sent: 12 July 2001 17:00 | To: The Haskell Mailing List | Subject: Fixity declarations | | | Hi all, | | The topic is fixity declarations for operators. | | The report says: | | "Fixity is a property of a particular entity (constructor | or variable), just like its type; fixity is not a | property of that entity's name." | | It is possible to define fixities for locally declared | bindings: | | f x y z = x # y # z | where | infixr 4 # | a # b = a `div` b | | The use of (#) in the body of g is right associative. | | However, it is not possible to define the fixity of an | operator which is an argument to a function. If I define: | | foldr4 :: (a -> b -> b) -> b -> (a,a,a,a) -> b | foldr4 (#) z (a,b,c,d) = a # b # c # d # z | | I will have to put in parentheses explicitly, because it is | not possible to define the fixity of that entity (namely the | argument (#) to foldr4). | | In this case, (#) gets the default fixity, namely infixl 9. | | Apart from the fact if we want to allow this or not, I think | the report should be clear about that it is not possible to | define the fixities of locally bound operator names in this way. | | /Koen. | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

RE: Another question wrt hiding imports
by Simon Peyton-Jones 12 Jul '01

12 Jul '01

See Section 4.4.2, after the table. Does that answer the qestion? Simon | -----Original Message----- | From: S. Alexander Jacobson [mailto:alex@shop.com] | Sent: 12 July 2001 15:03 | To: wlux(a)uni-muenster.de | Cc: haskell(a)haskell.org | Subject: Re: Another question wrt hiding imports | | | I asked this a while ago and never got an answer. Asking | again in better context: | | How do you control importing operator precedence? | | Suppose that you have: | f x = 2 + 2 * x | | And an imported module increases the precedence of (+). | You end up getting mangled. | | My assumption is that the only way to protect yourself from | this is to import qualified so A.+ has a different precedence from +. | | But I don't think the report promises this. The report just | promises that A.+ has the same precedence as (+) inside module A. | | -Alex- | | ___________________________________________________________________ | S. Alexander Jacobson Shop.Com | 1-646-638-2300 voice The Easiest Way To Shop (sm) | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

Re: Another question wrt hiding imports
by Wolfgang Lux 12 Jul '01

12 Jul '01

"Simon Peyton-Jones" wrote > | For instance if a have > | > | module A where > | data T = A | B > | > | which entities are imported when I include the declaration > | > | import A hiding(T) > | > | in a module? The report is not clear about this but I would > | expect that > | this imports data constructors A and B into the current > | module but not > | the type constructor T > > Yes, that's right. Why is the report not clear? More precisely, how > could I improve it? I find it a little bit counterintuitive to be able to hide a type constructor but not its data constructors (in particular) because one cannot import a data constructor by simply giving its name in an import specification. Maybe a single sentence which explicates the fact that hiding(T) only hides the type constructor T but not any of the data constructors of T (except if T is also a data constructor in this or any another data type) is sufficient to make this clear. (But maybe I was particularly dumb in this case). Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux(a)uni-muenster.de

1 0