June 2002 - Haskell - Haskell.org

Bilgisayar Egitiminde Bir Numara
by Sertifikam.Com 05 Jun '02

05 Jun '02

1 0

Type extensions
by Ronald Legere 04 Jun '02

04 Jun '02

Greetings. I have decided to try and understand the type system of haskell with extensions. As far as I can tell, the following set of extensions has been included, for example in ghc: multiparameter type classes constructor classes existential types explicit universal quantification scoped type signatures funtional dep?? Etc There is probably some overlap, and probably missed a few, as i do not understand what all these things do! ! My question: How do you get started learning all this? which of these is the most important? Is there a paper out there that explains most or all of these extensions and why you would want them and HOW the heck they work together? Ron Legere __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/

2 2

RE: readFloat
by Simon Peyton-Jones 04 Jun '02

04 Jun '02

| Especially converting rationals to a string and back should | always be the identity. It would be better to print rationals in the | form | numerator % denominator | | and read them in the same form. Oh yes, that is absolutely what Haskell does for Rationals. The 'read' and 'show' for Rational uses the % notation. No proposed change here. The point is instead this: if you specifically want to read a Rational from a string like "3.24", which is perfectly reasonable (324 % 100), then the same function (readFloat) should do it as read a Float from the string in that format. That's what type-class overloading is for. Simon

1 0

GreenCard: list marshalling
by Ferenc Wagner 03 Jun '02

03 Jun '02

Hi, I'd like to call LaPack routines from Haskell. Having read the GreenCard documentation it's still not obvious to me how I could marshall a list of numbers to C. Surely it's possible to create a ForeignObj, then fill it in element-by- element. But isn't there a more straightforward way? Even without monads? Cheers: Feri.

3 5

Haskell HBLAS Library
by Hal Daume III 03 Jun '02

03 Jun '02

Hi All, I've just finished porting the BLAS linear algebra library to Haskell and am about to begin porting the LAPACK lin alg extensions. Currently the "package" looks very flat: HBlas.Types -- basic type HBlas.Convert -- basic conversion routines HBlas.Level1 -- BLAS level1 routines HBlas.Level2 -- BLAS level2 routines HBlas.Level3 -- BLAS level3 routines since I intend to share types between the HBlas system and the HLapack system, I intend to (shortly) make it something like: LinAlg.Types -- basic types LinAlg.Convert -- conversion LinAlg.HBlas.Level1 .Level2 .Level3 LinAlg.HLapack.and-so-on Before I do this, since changing module names is nontrivial, I was looking for some input whether this would be sufficient, or if I should make it Math.LinAlg... or something else. or Contrib.LinAlg or whatever. I don't mean to start a huge discussion; if there's a correct thing to do, and someone would tell me that, that's sufficient. Also, I'm looking for someone to help me out packaging it all up; I know very little about making makefiles, etc. The whole package is fairly complicated, since it requries BLAS to be installed, greencard to be run, the haskell to be compiled, and haddock to generate the documentation. Hopefully someone will volunteer. Finally, I've been trying to make myself document the library; you can find a somewhat recent version of the haddock docs at: http://www.isi.edu/~hdaume/HBlas but this will probably move shortly. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

Re: arrows
by Ashley Yakeley 03 Jun '02

03 Jun '02

At 2002-05-25 01:32, Koen Claessen wrote: >Might I remind you that an arrow (as defined in category >theory) only requires identy and composition to be defined >and satisfying some laws? > >In particular, an arrow does not have to have the operations >"arr" and "first". Well either "arrow" is being used in two different senses or the "Arrow" class should be renamed. If you can't define "arr" and "first", it may be an arrow but it's not an Arrow. -- Ashley Yakeley, Seattle WA

2 1

Re: arrows
by Ashley Yakeley 03 Jun '02

03 Jun '02

At 2002-05-24 13:40, Wolfgang Jeltsch wrote: >Now, I have a type which would fit wonderfully into the Arrow concept if >arrows wouldn't be expected to have a first operator. ...then it's not an Arrow. It sounds like it might be one of these, however: class Compositor comp where { identity :: comp a a; compose :: comp b c -> comp a b -> comp a c; }; I'm not sure if 'Compositor' is a good name for it, or what. >Parser arrow. And there is also a meaningful definition for pure (arr). >pure f just has to be a parser which reads exactly one token, applies f >to it and outputs the resulting value. >The problem is that there seems to be no appropriate definition for >first. That's why, in my opinion, it would be very good to have only the Can't you have a parser that reads in one token tuple, and apply another parser to the first part of it only? Otherwise, perhaps you could have classes like this: class (Compositor arrow) => Semiarrow arrow where { arr :: (p -> q) -> arrow p q; }; class (Semiarrow arrow) => Arrow arrow where { arrFirst :: arrow p q -> arrow (p,r) (q,r); }; -- Ashley Yakeley, Seattle WA

5 4

RE: [Fwd: F#]
by Ashley Yakeley 03 Jun '02

03 Jun '02

At 2002-05-31 12:48, Don Syme wrote: >One point is that in the absence of extensive purity annotations to >imperative libraries you will need to use monads for operations that >shouldn't need them. But these cases are surely quite rare? In my experience, if it really is pure, chances are Haskell can do it by itself and you don't need a function in the library to do it. Perhaps there are exceptions for maths libraries. It seems to me the simplest thing for foreign libraries is to make all calls monadic. Certainly I do this in JVM-Bridge, all raw FFI calls are in the IO monad and I don't use "unsafe" anything anywhere. There are no particular "pure" Java library functions that are worth making an exception for. -- Ashley Yakeley, Seattle WA

1 0

CfP First International Conference on Security in Pervasive Computing (SPC2003)
by Dieter Hutter 03 Jun '02

03 Jun '02

-------------------------------------------- We are sorry if you receive multiple copies! -------------------------------------------- Call for Papers First International Conference on Security in Pervasive Computing (SPC-2003) March 12 - 14, 2003 in Boppard, Germany http://www.dfki.de/SPC2003 The ongoing compression of computing facilities into small and mobile devices like handhelds, portables or even wearable computers will enhance an ubiquitous information processing. The basic para- digm of such a pervasive computing is the combination of strongly decentralized and distributed computing with the help of diversified devices allowing for spontaneous connectivity via the internet. Computers will become invisible to the users awareness and exchange of information between devices will effectively defy users control. Assuming a broad usage of more powerful tools and more effective ways to use them the quality of every day life will be strongly influenced by the dependability of the new technology. Information stored, processed, and transmitted be the various devices is one of the most critical resources. Threats exploiting vulnerabilities of new kinds of user interfaces, displays, operating systems, networks, and wireless communications will cause new risks of loosing confidentiality, integrity, and availability. Can these risks be reduced by countermeasures to an acceptable level or do we have to redefine political and social demands as it is expressed by the Gartner Group from a privacy perspective: By 2010, driven by the improving capabilities of data analysis ... privacy will become a meaningless concept in Western societies. Topics of Interest: ------------------- The objective of this conference is to develop new security concepts for complex application scenarios based on systems like handhelds, phones, smartcards, and smart labels hand in hand with the emerg- ing technology of ubiquitous and pervasive computing. Particular subjects are methods and technology concerning the identification of risks, the definition of security policies, and the development of security measures that are related to the specific aspects of ubiquitous and pervasive computing like mobility, communication, and secure hardware/software platforms. Submissions: ------------ We welcome the submission of papers from the full spectrum of issues associated with security in pervasive computing. Submissions should describe completed work including descriptions of research, tools, and applications and should not exceed 15 pages in LNCS-style. Papers should be in postscript or pdf format, (lncs-style). Please submit papers by e-mail to spc2003(a)dfki.de Upon submission, name, address, and e-mail of the contact author should be included in the e-mail. Conference Schedule: -------------------- In consideration of the novel character of the conference theme it is planned to have three kinds of events: - invited talks that give an introduction into security related aspects of pervasive computing, - sessions for the presentation of technical papers, and - working groups that focus on particular problems areas. The results of the working groups will be presented and discussed in panel sessions. The final results will be published together with the technical papers in the Lecture Notes Series on Computer Science (LNCS). Location: --------- It will be held at an old former monastery in Boppard, Germany. Boppard is a nice small town located in the rhine valley about one hour away from Frankfurt airport. Organisation: ------------- The conference will be organised jointly by - German Information Security Agency (BSI) - German Research Center for Artificial Intelligence (DFKI) - Institute for Telematics, University of Freiburg. Program Committee ----------------- Michael Beigl (University of Karlsruhe) Joshua Guttman (MITRE) Dieter Hutter (DFKI) (co-organiser) Paul Karger (IBM Watson Research) Friedemann Mattern (ETH Zurich) Catherine Meadows (Naval Research Lab) Guenter Mueller (University of Freiburg) (co-organiser) Joachim Posegga (SAP) Kai Rannenberg (University of Frankfurt) Kurt Rothermel (University of Stuttgart) Ryoichi Sasaki (Tokyo Denki University) Frank Stajano (University of Cambridge) Werner Stephan (DFKI) (co-organiser) Moriyasu Takashi (Hitachi Ltd) Seiji Tomita (NTT Information Platform Laboratories) Markus Ullmann (BSI) (co-organiser) Important Dates: ---------------- - Submission of papers: October 31, 2002 - Notification of acceptance/rejection: December 31, 2002 - Camera ready final version of papers: January 31, 2003

1 0

RE: [Fwd: F#]
by Don Syme 03 Jun '02

03 Jun '02

Hi Manuel, One point is that in the absence of extensive purity annotations to imperative libraries you will need to use monads for operations that shouldn't need them. Having to add the annotations certainly counts as a complication in comparison to what many other languages have to do on .NET. As for monads, this is hardly the place to go into an argument about their relative merits re. all those slightly more widespread approaches to imperative programming. If you think driving imperative libraries using monads will be so great then a Haskell.NET would certainly be a perfect place to try out that theory. Don -----Original Message----- From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au] Sent: Fri 31.05.2002 03:27 To: Don Syme Cc: tweed(a)cs.bris.ac.uk; paul.hudak(a)yale.edu; haskell(a)haskell.org Subject: RE: [Fwd: F#] "Don Syme" <dsyme(a)microsoft.com> wrote, > And getting top-notch performance is obviously always a huge challenge > for Haskell, and you can't play some common implementation tricks when > compiling to IL. But the only truly serious complications added by .NET > itself are (a) the general problem of Haskell interop with imperative > libraries, requiring you to reach for monads quite often (or to wrap the > libraries yourself) [..] > IMHO problem (a) will always be the thing that stops Haskell becoming > very very big. But then being non-imperative it's also its main selling > point... So, you are saying that Haskell's problem with .NET is that it is not imperative, but at the same time you don't want to resort to Haskell's imperative sublanguage (the IO monad). I don't quite understand this. Personally, I find[1] Haskell to be very pleasant for imperative programming. In fact, I agree with SPJ, who wrote[2] (slightly provocatively), Haskell is the world's finest imperative programming language. Cheers, Manuel [1] After having written piles of low-level imperative code in Haskell. [2] In ``Tackling the Awkward Squad''

3 2