Re: The Haskell 98 Report
"Claus Reinke" <[EMAIL PROTECTED]> writes: > So, as a small token, I've revised my original plan and will now buy one > of the printed versions (I shall also place higher priority on submitting > to JFP in the future;-). Let's support forward-looking publishers! > > Thanks, Simon, and thanks, Conrad Guettler & CUP! I agree totally (I wasn't going to buy a copy, but now I will). Please let us know when the book becomes available through online bookstores... Thanks, Simon and Conrad! Carl Witty ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Design patterns in Haskell
I shamelessly copy from the abstract of [1]:
We contend that design patterns can be an effective means of
consolidating and communicating program construction expertise for
functional programming just as they have proven to be in
object-oriented programming. One might suppose that the powerful
abstraction mechanisms of functional programming obviate the need for
design patterns, since many pieces of program construction knowledge
can be captured by reusable functions. This confusion of design
patterns with reusable components misses the point: patterns start
where components end, in the sense that the former describe how the
latter can be constructed and used. Thus, additional abstraction
\emph{creates} the need for new design patterns.
[1] Design Patterns for Functional Strategic Programming
http://www.cs.vu.nl/Strafunski/dp-sf/
Ralf
P.S.: Should we move to haskell-cafe@... ?
--
Ralf Laemmel
VU & CWI, Amsterdam, The Netherlands
http://www.cs.vu.nl/~ralf/
http://www.cwi.nl/~ralf/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: AW: slide: useful function?
G'day all. Just to clarify... On Tue, Dec 03, 2002 at 12:42:21PM -0500, David Bergman wrote: > But, design patterns are clearly overestimated as a tool for (indirect) > code production, you are right in that. Absolutely agreed. Design patterns are little more than: - A common language for engineers to talk to each other. - Good documentation. - A useful way to get engineering experience across to a mentoree. Yes, patterns are over-hyped. Nevertheless, there's a baby somewhere in all that bathwater. Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Mathematics and Software Engineering (was slide: useful function? )
[EMAIL PROTECTED] wrote (on 03-12-02 18:18 +0100): > Perhaps I should rephrase: > > There's too much mathematics in it, I'm not a mathematician ..and later... > > lot of mathematics. One of the things I like about FP is that it > > demands more mathematical sophistication of its practitioners, which, > > contrary to some opinions, I think is a Good Thing. > > I'm fully with you there, but - as someone already pointed out - I don't > want to need a math major to read a paper regarding programming. How many times has this phrase been uttered, I wonder...! The truth is: You DON'T need a math degree to understand such papers. This may come as a shock, but the reason for this is that they are not written by or for an audience of mathematicians, but rather for an audience of CS researchers who actually possess---wait for it---CS degrees! :) Now, admittedly, there is a lot funny notation, jargon and special concepts in PLT papers. That's why a few people have undertaken the task of writing textbooks, surveys and tutorials for people who did not come into this world with the Library of Congress preloaded in their brains. Two good books which come to mind are: John C. Mitchell. Foundations for Programming Languages. MIT Press, 1996. Benjamin C. Pierce. Types and Programming Languages. MIT Press, 2002. I've also collected some freely available ones here: PLT Online http://www.cs.uu.nl/~franka/ref That was CS and PLT. Now let's talk about mathematics and algebra. It doesn't take a degree in mathematics to do or understand mathematics. The people who get degrees in mathematics get them, not in order to do mathematics, but rather in order to create/discover (do you favor Plato or Brouwer?) _new_ mathematics. People nowadays use the word "mathematics" as if it were some exotic beast you can only find in the hinterlands of darkest Africa! Every field, even something as mundane as accounting, has its wildly esoteric corners. No one expects programmers to be experts in twistor theory or inaccessible cardinals. Hell, no one expects CS researchers to be experts in those bits either. Elementary algebra is not one of those esoteric bits. As mathematical topics go, it's simple, fundamental, ubiquitous and closely connected to FP. It won't gobble up your grandmother or demand your first-born child. At a guess, I think most FP programmers could easily get up to speed on the basics of constructive universal algebra in the context of FP---signatures, initial algebras, catamorphisms, free constructions, monads, etc.---in the space of a workshop-length course. It's common practice for programmers in industry to take training courses on things like Java beans, ActiveX controls and UML; why not algebra, or proof theory or operational semantics? At least those things are sure to survive longer than the latest buzzword technology... -- Frank ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Design patterns in Haskell
> size. while there's really no substitute for experience, i really > believe we could benefit from some patterns. There was a list of design patterns for Haskell on the Wiki (back in the days when it worked): http://haskell.org/wiki/wiki?CommonHaskellIdioms --KW 8-) -- Keith Wansbrough <[EMAIL PROTECTED]> http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Design patterns in Haskell
[Frank Atanassow <[EMAIL PROTECTED]>]
>
> Furthermore, design patterns come with a set of informal hints about when and
> where to apply the pattern. The notion of HOF is, of course, completely
> neutral about this, except insofar as the type system forces you to provide a
> HOF where a function is expected. OTOH, the advice that "you should use HOFs
> to model widget actions" or "you should use HOFs to allow customization of
> applications via hooks" (as in Emacs LISP) could reasonably be construed as a
> design pattern. So maybe a design pattern can be regarded as a correspondence
> between formal concepts and domain-specific ones.
>
i think this (especially the last sentence) is a crucial observation.
all too often, the fp community (communities) seems to write design
patterns off on the grounds that "our languages do that stuff for us".
this is based on far too unsophisticated an understanding of design
patterns. certainly the patterns that are useful in c++ will not all
be useful in haskell, and many of them will even appear trivial. but
this does not mean that the appropriate correspondence(s) "between
formal concepts and domain-specific ones" will always be obvious. in
fact, this is exactly the kind of information that programmers new to
haskell need more of.
one of the purposes of design patterns is to capture the idiom of a
particular language, often using fairly specific domain examples. "to
solve this kind of problem in this language, these are the usual
techniques. here are guidelines for choosing between them..." these
guidelines often include, for example, which techniques work well (or
poorly) with which others, some counter-indications for using a
particular technique, which techniques excel in particular
circmstances ("pattern A is a better choice when you expect to
register callbacks only once and use them many times, while B is a
better choice when you expect callbacks to change quite frequently"),
etc.
i hope it's obvious that this is significantly more information, and
significantly more useful, than: "when you need something like
callbacks, use hofs." i know i'm not the only programmer who
understands most of the syntax and semantics of haskell, but still
feels far less than confident engineering a program of any decent
size. while there's really no substitute for experience, i really
believe we could benefit from some patterns.
m
--
matt hellige [EMAIL PROTECTED]
http://matt.immute.net
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: AW: slide: useful function?
Hi, Bill. I agree 90% with you in your questioning the adequateness of trying to incorporate design patterns in Haskell, and the actual productive use of them in other languages as well. But, I must defend design patterns, and Haskell, a bit... William Lee Irwin III wrote: > On Mon, Dec 02, 2002 at 10:37:09AM +1100, Andrew J Bromage wrote: > > In the interest of fairness, the declarative programming community > > occasionally appears to have an aversion to actual engineering. If > > you mention a term like "design patterns", people look down their > > virtual noses at you like you're trying to infect their pure > > theoretical world with something unsanitary. My point is > that nobody > > is immune from this kind of thinking, it just takes different forms. > > I've got some issues here: > > (1) Various things I'm doing as a practitioner lack theoretical > background (and/or content) for various problems in them. > e.g. how does one measure per-cpu time spent waiting on > io on SMP? > e.g. page replacement mixes kinds of memory, creating > list searches What has this to do with design patterns? There is, as you know, certainly no need for theoretical substance in order to either define or apply design patterns. They are often quite vague and pragmatic. Oh, I see, you switch between critizising design patterns and declarative languages... Ok, I will try to follow. > (2) In theory and in practice I've seen "design patterns" and a couple > other "popular" programming movements add up to nothing. Design > patterns in particular produced precisely zero useful code or > code design during its entire lifetime as designs on > the level on > which its principles operate are not ever getting > freshly redone. I have used design patterns mainly as (1) a common language in communication with development teams and (2) as a library of thought patterns (adornments, visitors, wrapper etc.) for less experienced developers (i.e., developers not having built up these patterns "implicitly"). So, the use of design patterns is *not* mainly to create code directly, but rather a common terminology within teams and communities. But, design patterns are clearly overestimated as a tool for (indirect) code production, you are right in that. > (3) Various tidbits of theoretically motivated languages > assume so much > infrastructure as to be unsuitable for various (kernel) > environments. There's a circular dependency between what some > things implement and the infrastructure assumed, which is where > the problem lies. What infrastructure are you referring to? > (4) There is no excuse for willful ignorance. Linear searches in > interrupt context and other gross inefficiencies have brought > systems down because the events triggering the poor algorithms > occurred in realtime and are generated by hardware. They > consistently livelocked boxen with sufficient cpu counts. Yes, linear search is certainly bad, not only in that particular context, but in all... We can all agree on that one. > At any rate, the gist of all this is that even though I don't > use much in the way of theory now, I would like to use more > of it, and there are various things I wouldn't mind having > that aren't universally available. > > A much lower-level language (i.e. one requiring far less > infrastructure) with a decent type system and some modularity > would be nice for systems programming, which is the majority > of my work, but it really just doesn't make a difference > because the work is generally concentrated on a given > preexisting system, which isn't going to get converted > between languages. There is one such language: C (if you can call the type system decent...) > And last, but not least, programming is a mathematical > discipline. Even the most dreary programming tasks are > phraseable as such. > > (1) hardware does not obey spec, but driver is needed > -- augment the driver's state machine to handle new error cases > (2) ridiculous code/patch merging constraints are enforced > -- analyze program structure to devise incremental > merge strategy > (3) make process interaction and/or scheduling decision > -- scheduling has lots of mathematical stuff behind it It is also fruitful to separate "formal" and "mathematical" a bit, since most people tend to diverge into differential geometries, categories, Gilbert spaces etc. when "mathematics" is mentioned, but stay still when "formal" arguments are presented. I.e., your example scenarios above would probably be best classified as formal. Yes, I know that everything formal is mathematical when scrutinized... > None of this is to say that I haven't made extensive and > highly beneficial use of Haskell in userspace, which I have. > It is a full- blooded substitute for perl, python, and > several other "scripting" languages that supposedly ride on Al
Mathematics and Software Engineering (was slide: useful function? )
> > There's too much mathematics in it, I'm only an engineer... ;-) Perhaps I should rephrase: > There's too much mathematics in it, I'm not a mathematician > reminds of what I think is one of the biggest problems with > conventional > software development: the lack of appreciable mathematics in the > specification, design, coding, or implementation of programs. In this While this is surely true, I think, there is also a lack of communication between software engineers. Civil, Mechanical or Electrical Engineers have well-established plans, while software engineers have not (see http://fmc.hpi.uni-potsdam.de/). One should not forget, that many practical problems are not solvable by a rigorous mathematical approach. German reading people may have a look at http://fmc.hpi.uni-potsdam.de/research/literature/wendt_1998-kommunikationsp roblem_der_informatiker.pdf, where some problems are pointed out (with an edge to it). > sense there is a huge contrast between conventional software > development > practice and other engineering disciplines. Definitely. But software development is probably not old enough... It's like the difference between somebody bying some Radio Shack stuff and putting it together until it works, and an engineer making informed decisions for layout and choice of elements for a circuit. This informedness relies partly on mathematics, but at least as much on experience and pragmatics. Most software people are still bying Radio Shack stuff... (and isn't it easy?) > I was once an electrical > engineer, and I used lots of mathematics (not just in school, but in > industry), and I know that most other engineering disciplines > also use a So you know that to use diracs and fourier you don't necessarily need to understand what functionals are about. Likewise, it's not necessary to understand category theory to use monads and the like. > lot of mathematics. One of the things I like about FP is that it > demands more mathematical sophistication of its practitioners, which, > contrary to some opinions, I think is a Good Thing. I'm fully with you there, but - as someone already pointed out - I don't want to need a math major to read a paper regarding programming. This doesn't mean there is something wrong with these papers, it's just that I wished there would be more accessible versions. Hope to got my point across, Markus -- Markus Schnell, Infineon Technologies AG ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Design patterns in Haskell
Andrew J Bromage wrote (on 03-12-02 09:52 +1100): > On Mon, Dec 02, 2002 at 08:26:06AM +0100, Johannes Waldmann wrote: > > > well I love design patterns, it's just that in Haskell-land > > they are called higher-order functions, or polymorphic functions, etc. > > Can I safely translate that as "We use design patterns but we don't > like the name?" > > In a different language, you use different design patterns. Just as > iterator-based patterns are next to useless in Haskell (where we have > lazy streams), patterns based on CPS are next to useless in a > language with state and non-local return constructions. I think there is a world of difference between GoF-style design patterns and things like HOFs, polymorphism and whatnot in Haskell. If you are programming GUI applications in C and use callbacks for the widget actions, then you are basically using the design pattern which gets formalized as HOFs in an ML-like language. But C will not guarantee for you that you callback function is well-typed, hold onto the data in the closure, do the necessary garbage collection, etc. Those things may seem like details, but they are what make HOFs robust and practical to use ubiquitously; the callback design pattern, since it is basically puts the burden on the programmer, can never hope to achieve that degree of robustness. Furthermore, design patterns come with a set of informal hints about when and where to apply the pattern. The notion of HOF is, of course, completely neutral about this, except insofar as the type system forces you to provide a HOF where a function is expected. OTOH, the advice that "you should use HOFs to model widget actions" or "you should use HOFs to allow customization of applications via hooks" (as in Emacs LISP) could reasonably be construed as a design pattern. So maybe a design pattern can be regarded as a correspondence between formal concepts and domain-specific ones. -- Frank ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Calling ghc dll's with MSVC++ code
Hey! I need to call haskell DLL's from a c++ program, and this C++ is written in Microsoft's Visual C++ 6.0 I created the DLL sing the directives given at ghc user's guide (11.3 and 11.4) and created the dll. To create a .lib import file, I linked with the option -optdll--output-lib -optdllMyDll.lib I can compile and link my C++ problem, but when I run it, it crashes. I tried even to create a DLL from a C source I'm sure it works (as I created the DLL before with MSVC++ environment, and I could make it work out), and even this DLL crashes whe its functions are accessed. I'm using GHC 5.0.4.1 Is there some special command lines that must be used to create DLLs to be used with windows? Or is there some known difficulty doing it? Someone that succeded can please tell me exactly how was it done? If more info is needed, I can send the sources and command lines I used to compile. ps: I'm not using cygwin (i don't have it installed in my computer actually), but as far as I understood, it shouldn't be a problem ´Thanks for help! Mauricio
