Re: [Haskell-cafe] [Off topic] Proving an impossibility
On 9/3/07,Vimal[EMAIL PROTECTED] wrote:
while E do
S
if F then
break
end
T
end
He then asked us to *prove* that the above programming fragment cannot
be implemented just using if and while statement, even if S and T can
be duplicated a finite number of times
But it IS possible. Just add a boolean flag:
Possibly, you are not allowed to change the sequence of machine operations at
all. See, if you change while(A){B} to if(A){B};while(A){B}, the sequence
is exactly the same; but it's not possible in this case.
It reminds me of a paper by Knuth, where he states that goto statement is
necessary; don't remember the title, however.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: FFI and DLLs
Lewis-Sandy, Darrell wrote: An early proposal for the FFI supported importing functions directly from dynamic link libraries: www.*haskell*.org/hdirect/ffi-a4.ps.gz http://www.haskell.org/hdirect/ffi-a4.ps.gz This looks like it was dropped from the final version of the addendum in favor of C header files as the sole form of import entities. Not being a C programmer, how would one go about importing a foreign function (e.g. void Foo(void) ) from a dynamic link library (e.g. foo.dll)?? Would someone be willing to provide an explicit example? You don't have to do anything special to import a function from a DLL. e.g. here's one from the Win32 library: foreign import stdcall unsafe windows.h CloseHandle c_CloseHandle :: HANDLE - IO Bool The windows.h header file isn't essential unless you're compiling via C with GHC, when compiling direct to native code with -fasm the header file is ignored. Note that by convention most functions in DLLs are called using the stdcall convention, so you have to specify this on the foreign import. To link against the DLL, the easiest way is to name the DLL directly on the command line. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serial Communications in Haskell
Hi! You can check how I did this in my Lego Mindstorms NXT interface, pre-beta version: http://www.forzanka.si/files/NXT.tgz That's really cool! I hope you can upload this to hackage soon. I do not think it is ready yet. It is working but it is missing extensive testing (making some bigger programs in practice, to see how it behaves and to see if the API is sane) and of course documentation (how to use it, examples, tutorials ...). I will continue with this project in a few months. (The main reason is that I do not have any experience with Hackage and Cabal nor I have time now for this. But if anybody wants to help ...) I am using it in my AI robot research project where I am using Lego Mindstorms NXT unit and communicating with it over Bluetooth. And the AI is made in Haskell. :-) Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Off topic] Proving an impossibility
On Sep 4, 2007, at 5:02 , Miguel Mitrofanov wrote: It depends on arbitrary restrictions on what constitutes an (boolean) expression, something that is anathema to functional programmers :-) Spot the language: while if E then S; F else False fi do T od It reminds me of a paper by Knuth, where he states that goto statement is necessary; don't remember the title, however. I don't remember needing a goto in Haskell... Well, for imperative languages, of course. We're talking goto-the-concept, since break counts as goto; thus, so does MonadCont, and so does pattern match failure in a monad. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation of GLUT package
On 9/4/07, Sven Panne [EMAIL PROTECTED] wrote: But coming to the main point: I can't see a reason why the GLUT package needs to be rebuilt, it gets the freeglut-specific API entries dynamically (at least, that was the plan ;-). Replacing the original GLUT DLL with the freeglut DLL should work. because freeglut *is* a drop-in replacement for the old GLUT (modulo support for some obscure input devices). A more detailed description of what goes wrong with that simple approach would be helpful... The detection of freeglut or glut is at compile time by checking if some function exists. Otherwise it's not able to link. So you'll have to re-compile the Haskell GLUT package. Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Off topic] Proving an impossibility
Brandon S. Allbery KF8NH [EMAIL PROTECTED] writes: On Sep 4, 2007, at 5:02 , Miguel Mitrofanov wrote: It depends on arbitrary restrictions on what constitutes an (boolean) expression, something that is anathema to functional programmers :-) Spot the language: while if E then S; F else False fi do T od It reminds me of a paper by Knuth, where he states that goto statement is necessary; don't remember the title, however. I don't remember needing a goto in Haskell... Well, for imperative languages, of course. We're talking goto-the-concept, since break counts as goto; I hadn't interpreted the reminding of Knuth that way. I wouldn't count break as a goto -- what makes goto especially nasty is that the destination isn't indicated by the structure of the source; it could be just anywhere. Break is slightly more structured. thus, so does MonadCont, and so does pattern match failure in a monad. I've never been entirely happy with those... -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending the idea of a general Num to other types?
Henning Thielemann wrote:
If you are happy with writing do {1;2;3;4} you are certainly also happy
with cv [1,2,3,4], where cv means 'convert' and is a method of a class
for converting between lists and another sequence type.
class ListCompatible lc where
cv :: [a] - lc a
rt :: lc a - [a] {- restore :-) -}
Better don't adapt the names, but the idea would work, wouldn't it?
Oh but I will not write do {1;2;3;4}, this was just an idea :-) Yep,
your approach certainly works, but I just found it was a bit of a
discrepancy in Haskell (numbers getting better lifting support than lists).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Off topic] Proving an impossibility
I hadn't interpreted the reminding of Knuth that way. I
wouldn't count break as a goto -- what makes goto especially
nasty is that the destination isn't indicated by the
structure of the source; it could be just anywhere. Break is
slightly more structured.
Maybe you might need to take a look at this :-)
http://kerneltrap.org/node/553/2131
Linus does get a little serious about Pascal.
But I feel that gotos, like pointers is a tool that makes programming easy
(in some context, like modeling a simple FSA). So, its better that we
take them in a
Use them with Caution attitude!
Okay, pointers may not be a nice thing to discuss here :-)
I have been a little sluggish in my replies to mails that came here. I forgot
to click Reply All. These are smoe of the missed replies ...
But it IS possible. Just add a boolean flag:
done = False
while E and not(done) do...
I'll let you work out the rest. Unless I am missing something here... are
you not allowed to introduce extra variables? It's a strange thing for your
professor to ask, since under reasonable assumptions, anything that is
computable can be done only using if and while. goto (which is essentially
what break is) is never necessary.
Ah, yes, it is possible in this case, but you have used an extra variable.
It is okay, but our professor doesnt want to put emphasis on
Computability here (or maybe I dont realize it), but the point is: Are
such programming constructs really necessary in a programming
language? i.e. Is Breakl, goto, falling through switch/case
statements, necessary in a language?
This also brings another point. What if there are N loops like this,
and there is no break statement available in your language? You would
have to use N conditional variables, and would make mainting the code
a horrible thing to do.
Possibly, you are not allowed to change the sequence of machine operations at
all. See, if you change while(A){B} to if(A){B};while(A){B}, the sequence
is exactly the same; but it's not possible in this case.
Changing the sequence is fine as long as the execution of one doesnt
affect another.
So, he is trying to bring the idea of functional programming here, to
avoid side-effects.
It reminds me of a paper by Knuth, where he states that goto statement is
necessary; don't remember the title, however.
Thanks for the info! I willl check it out soon!
~Vimal
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Off topic] Proving an impossibility
Vimal wrote: Ah, yes, it is possible in this case, but you have used an extra variable. It is okay, but our professor doesnt want to put emphasis on Computability here (or maybe I dont realize it), but the point is: Are such programming constructs really necessary in a programming language? i.e. Is Breakl, goto, falling through switch/case statements, necessary in a language? If your (or your professor's) question is not about computabily, but about expressivenes, what's the point of asking for a proof? In a turing-complete language, everything should be expressible :) Sensible questions may include: how easy is it to express a language feature using only other language features? (local or global transformation needed, code blowup, mechanical transformation or rewrite-from-scratch?) This also brings another point. What if there are N loops like this, and there is no break statement available in your language? You would have to use N conditional variables, and would make mainting the code a horrible thing to do. I disagree. You would have to introduce a temporary variable for every breakable loop, an assignment to the approbiate variable for every break and a lot of tests of temporary variables to skip parts of the loop body. Since breaks can only occur withing the loop body, and each break only breaks the innermost loop, all of these temporary variables can share the same name and shadow each other in the case of nested loops. by reserving a approbiate name (like done) for this variable by convention. Reading such code, you can just just resugar the code by reading if not done then, done := true and let var done = false in while ... as primitives. This is a local transformation, the code blowup is linear and it is possible to do it mechanically. I therefore consider the break statement as easily emulated by temporary variables. On the other hand, the obvious next step would be to provide actual names for these three uses of the done-variable, either by using whatever abstraction means provided by the language, or by adding syntactic sugar. In Haskell, we would simply define an approbiate monad to hide the if not done then-parts in the bind operation and reuse the existing syntactic sugar for monadic expressions. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending the idea of a general Num to other types?
On Tue, 2007-09-04 at 16:06 +0200, Peter Verswyvelen wrote:
Henning Thielemann wrote:
If you are happy with writing do {1;2;3;4} you are certainly also happy
with cv [1,2,3,4], where cv means 'convert' and is a method of a class
for converting between lists and another sequence type.
class ListCompatible lc where
cv :: [a] - lc a
rt :: lc a - [a] {- restore :-) -}
Better don't adapt the names, but the idea would work, wouldn't it?
Oh but I will not write do {1;2;3;4}, this was just an idea :-) Yep,
your approach certainly works, but I just found it was a bit of a
discrepancy in Haskell (numbers getting better lifting support than lists).
I don't think this has been mentioned explicitly yet, but the
discrepancy is purely for pedagogical purposes.
In Gofer, list comprehensions (and list syntax, IIRC) /was/ generalized
(to an arbitrary instance of MonadPlus). But that means that any
mistake in your syntax likely brings up a type error mentioning
MonadPlus. This confuses CS freshmen (who are easily confused anyway);
thus, Haskell restricts list syntax to lists so the type errors are
simpler.
By contrast, most CS freshman have already used languages with multiple
number types, so all you have to do is explain that type errors
involving Num are Haskell's way of dealing with them. So the syntax can
be generalized to the type class in that case without confusing freshmen
as much.
jcc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Code from Why Functional Programming Matters
Andrew Wagner [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] current position (or, even more ideally, the so-called principal variation, which is the best series of moves from the current position). Is there a good way to collect this, without mapping some sort of function over the tree that puts a list of moves on every node too? Hughes seems to completely ignore this, and I wonder if it's because it gets ugly to implement. While Hughes code looks nice, the more efficient you make your search the uglier it is going to be (at least with my Haskell skills) In reality you will at least want iterative deepening and principle variation search. I posted code for PVS (ugly code) http://www.haskell.org/haskellwiki/Principal_variation_search I thought I had some code doing iterative deepening based on this, but it looks like I lost it somewhere. If you want to use hash tables, history, killer moves, etc. Then I think you are going to have to monadize everything. It is a pity that Hughes doesn't demonstrate adding some of these things. Maybe it is possible using arrows? (without making everything look like C, which would be my solution). Rene. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation of GLUT package
On Tuesday 04 September 2007 15:37, Paul L wrote: The detection of freeglut or glut is at compile time by checking if some function exists. Otherwise it's not able to link. So you'll have to re-compile the Haskell GLUT package. Show me the code where the alleged tests are made, please... :-) The only things which are determined at build time are the linker options for linking OpenGL/GLUT applications and the calling convention on the platform in question. If you change your GLUT DLL to a freeglut DLL, everything should work, including freeglut extensions. If not, I consider this as a bug and I'll try to fix it. But to see what's going on, some logs, commandlines, etc. are needed to reproduce what other people have done. For a more detailed discussion, perhaps the hopengl list might be more appropriate. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Request for code review - Knuth Morris Pratt for Data.Sequence
Using the code developed for ByteStrings by myself, Christ Kuklewicz and Daniel Fischer, I've implemented Knuth-Morris-Pratt substring searching on Data.Sequence Seq values. Attached you'll find the library in kmp.zip.safe. The algorithm is implemented in the module Data.Sequence.KMP. At the root, SpeedTest.hs can be compiled on Windows with the prof_compile.bat file included (you'll need to install the regex-dfa and regex-base packages from Hackage to build). SpeedTest searches for a known value in the 7 MB file endo.dna (which can be downloaded from http://www.icfpcontest.org/endo.zip) using several different algorithms and methods: strict and lazy bytestrings, regular expressions, and the KMP algorithm for Seq values. SpeedTest is pretty fast but I worry about its space usage. It may just be the nature of Seq values, but I cannot get it to run in constant space when I think it should be. I'm especially interested in help here. All comments and feedback are welcome. Since the zip file includes a darcs context file, feel free to send patches. Justin kmp.zip.safe Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation of GLUT package
hs_GLUT_getProcAddress in cbits/HsGLUT.c apparently requires FREEGLUT or GLUT_API_VERSION = 5 or OPENGLUT to be defined at compile time in order to work, as the standard GLUT 3.7 doesn't even have the glutGetProcAddress(..) function. Regards, Paul Liu On 9/4/07, Sven Panne [EMAIL PROTECTED] wrote: On Tuesday 04 September 2007 15:37, Paul L wrote: The detection of freeglut or glut is at compile time by checking if some function exists. Otherwise it's not able to link. So you'll have to re-compile the Haskell GLUT package. Show me the code where the alleged tests are made, please... :-) The only things which are determined at build time are the linker options for linking OpenGL/GLUT applications and the calling convention on the platform in question. If you change your GLUT DLL to a freeglut DLL, everything should work, including freeglut extensions. If not, I consider this as a bug and I'll try to fix it. But to see what's going on, some logs, commandlines, etc. are needed to reproduce what other people have done. For a more detailed discussion, perhaps the hopengl list might be more appropriate. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Off topic] Proving an impossibility
On 9/3/07, Vimal [EMAIL PROTECTED] wrote:
Hi
In my Paradigms of Programming course, my professor presents this piece of
code:
while E do
S
if F then
break
end
T
end
This is seriously offtopic but kinda fun anyway...
There's a nice formalism for investigating this kind of problem called
Kleene Algebra with Tests (KAT). Google to find out more - I
hesistate to give a link as every link I can find points to a file in
a proprietary format or requires a password, but there are lots of
documents out there.
The idea is that it gives a way to describe the path of execution of
imperative programs using notation remarkably like regular
expressions. The above loop could be written as X where X =
E'+ES(F+F'TX). E and F are 'tests' while S and T are more like
'actions'. For a test X, X' means not X and these symbols behave
just like regular expressions except that X+X'=1. A normal while loop
with no breaks, while (A) { B }, is given by Y where Y = ABY+A', so Y
= (AB)*A'. Anyway, the task is now an algebraic one: show that you
can't construct a solution to X = E'+ES(F+F'TX) using composition of
E, F, S, T and the Y = ABY+A' while-construction. Note that the
process of converting the imperative code to algebraic notation is
remarkably similar to that of porting imperative code to recursive
Hakell code, and that tests look a lot like guards in a
non-determinstic monad. (That was my obligatory mention of Haskell to
make things seem vaguely on topic.)
Also check out the folk theorem here:
http://citeseer.ist.psu.edu/harel80folk.html which can be solved much
more easily using KAT.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending the idea of a general Num to other types?
Jonathan Cast wrote: I don't think this has been mentioned explicitly yet, but the discrepancy is purely for pedagogical purposes. In Gofer, list comprehensions (and list syntax, IIRC) /was/ generalized (to an arbitrary instance of MonadPlus). But that means that any mistake in your syntax likely brings up a type error mentioning MonadPlus. This confuses CS freshmen (who are easily confused anyway); thus, Haskell restricts list syntax to lists so the type errors are simpler. By contrast, most CS freshman have already used languages with multiple number types, so all you have to do is explain that type errors involving Num are Haskell's way of dealing with them. So the syntax can be generalized to the type class in that case without confusing freshmen as much. jcc Well, that is a very good reason, but for newbies (or should I say, for me ;-) ), most error messages are very confusing anyway! An since Haskell is really an advanced language, why not go all the way? It feels to me that for learning FP to newbies, a small subset of Haskell would be more suitable to get started, so really easy error messages can be given (Helium does that already?) Otherwise you would need a very clever compiler/editor machine learning system, that looks at how a class of users fixes a certain error, so the compiler can adapt its error message the next time a similar pattern occurs (which is science fiction right now I think...) Now, these complex error messages are not just for Haskell; when I did complicated C++ template programming, the error message sometimes became as long as a full page when printed, and it took me more time to decipher the error than to fix the code ;-) PS: Gofer, is that an existing language? As far as some googling can tell me, it's dead? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending the idea of a general Num to other types?
On Tue, 2007-09-04 at 23:03 +0200, Peter Verswyvelen wrote: Jonathan Cast wrote: I don't think this has been mentioned explicitly yet, but the discrepancy is purely for pedagogical purposes. In Gofer, list comprehensions (and list syntax, IIRC) /was/ generalized (to an arbitrary instance of MonadPlus). But that means that any mistake in your syntax likely brings up a type error mentioning MonadPlus. This confuses CS freshmen (who are easily confused anyway); thus, Haskell restricts list syntax to lists so the type errors are simpler. By contrast, most CS freshman have already used languages with multiple number types, so all you have to do is explain that type errors involving Num are Haskell's way of dealing with them. So the syntax can be generalized to the type class in that case without confusing freshmen as much. jcc Well, that is a very good reason, but for newbies (or should I say, for me ;-) ), most error messages are very confusing anyway! An since Haskell is really an advanced language, why not go all the way? It feels to me that for learning FP to newbies, a small subset of Haskell would be more suitable to get started, so really easy error messages can be given (Helium does that already?) Exactly. But the Haskell 98 standard pre-dates Helium. I think Haskell' could be made more complicated now that Helium exists, but don't know whether that's in the cards. Otherwise you would need a very clever compiler/editor machine learning system, that looks at how a class of users fixes a certain error, so the compiler can adapt its error message the next time a similar pattern occurs (which is science fiction right now I think...) GHC I think tries to mediate this through the minds of its developers. Now, these complex error messages are not just for Haskell; when I did complicated C++ template programming, the error message sometimes became as long as a full page when printed, and it took me more time to decipher the error than to fix the code ;-) PS: Gofer, is that an existing language? As far as some googling can tell me, it's dead? Right. Gofer died the quick death of most research languages, although it influence Hugs. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Elevator pitch for Haskell.
This page (http://www.npdbd.umn.edu/deliver/elevator.html) has a template for an elevator pitch. This is what you say to someone when you have 30 seconds to explain your big idea, for instance if you find yourself in an elevator with them. I thought I'd try instantiating it for Haskell. For software developers who need to produce highly reliable software at minimum cost, Haskell is a pure functional programming language that reduces line count by 75% through reusable higher order functions and detects latent defects with its powerful static type system. Unlike Ada and Java, Haskell allows reusable functions to be combined without the overhead of class definitions and inheritance, and its type system prevents the hidden side effects that cause many bugs in programs written in conventional languages. Comments? Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elevator pitch for Haskell.
It's very nice, but I would say that anyone who needs an elevator pitch shouldn't be using or working with Haskell. Haskell is for people who already get it. I've had job offers from people just because they knew I _liked_ Haskell, even though they weren't asking me to use it for the job. OTOH, something like this might be useful for pitching Haskell to students, which is where the real growth opportunities are (minds not yet closed). Mike Paul Johnson wrote: This page (http://www.npdbd.umn.edu/deliver/elevator.html) has a template for an elevator pitch. This is what you say to someone when you have 30 seconds to explain your big idea, for instance if you find yourself in an elevator with them. I thought I'd try instantiating it for Haskell. For software developers who need to produce highly reliable software at minimum cost, Haskell is a pure functional programming language that reduces line count by 75% through reusable higher order functions and detects latent defects with its powerful static type system. Unlike Ada and Java, Haskell allows reusable functions to be combined without the overhead of class definitions and inheritance, and its type system prevents the hidden side effects that cause many bugs in programs written in conventional languages. Comments? Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elevator pitch for Haskell.
Paul, It's a good start, but it's a little too feature oriented rather than benefits oriented. Features: makes programmers more productive, allows projects to grow larger, allows maintenance teams to pick up the code with less skills xfer, faster time to market and faster and more reliable changes to existing systems. All features boil down to improving bottom line (saving money), improving top line (creating more revenue), or customer satisfaction. My 2 cents (aka 1.2 euro pennies) Thanks, David On 9/4/07, Paul Johnson [EMAIL PROTECTED] wrote: This page (http://www.npdbd.umn.edu/deliver/elevator.html) has a template for an elevator pitch. This is what you say to someone when you have 30 seconds to explain your big idea, for instance if you find yourself in an elevator with them. I thought I'd try instantiating it for Haskell. For software developers who need to produce highly reliable software at minimum cost, Haskell is a pure functional programming language that reduces line count by 75% through reusable higher order functions and detects latent defects with its powerful static type system. Unlike Ada and Java, Haskell allows reusable functions to be combined without the overhead of class definitions and inheritance, and its type system prevents the hidden side effects that cause many bugs in programs written in conventional languages. Comments? Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- lift, the fast, powerful, easy web framework http://liftweb.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elevator pitch for Haskell.
Paul, This page (http://www.npdbd.umn.edu/deliver/elevator.html) has a template for an elevator pitch. I thought I'd try instantiating it for Haskell. For software developers who need to produce highly reliable software at minimum cost... Looks like a good pitch for developers. Here's my attempt for management: For software project leaders looking to decrease the risk of software construction in large componentized systems. Haskell is a programming language where software components can be built safely and predictably from existing components without increasing the system's overall complexity. Unlike Java or C, Haskell functions are called 'safe' because each function either explicitly states its side effects or is guaranteed to have none. Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elevator pitch for Haskell.
And here's my guide for public health officials... WARNING: Learning Haskell is dangerous to your health! Disguised as a fully-functional programming language, Haskell is actually a front for a working math-lab, supported by a cult of volunteers seeking to ensnare weak-headed but normal programmers susceptible to the dogma that laziness is a virtue. Though cut with syntactic sugar to be more palatable to newbies, each Haskell construct is in fact a contagious mix of higher-order functions, lambda expressions, and partial applications, a highly addictive gateway drug to category theory, initial algebras, and greco-morphisms. Some users have gotten trapped inside an IO monad unable to get out safely, and even gone mad trying to decipher commutative diagrams or perfect their own monad tutorial. Signs of addiction include prefixing co- to random words or needlessly replacing recursive functions with combinators and pointfree notation. The least fixed point of this unnatural transformation is the inability to find joy in the use of imperative programming languages. In some cases, hackage is irreversible and can lead to uncontrolled blogging. Further study is needed to understand the strong correlation between intelligence and Haskell addiction. Meanwhile, those at risk should be made to program in teams to suppress their creative drive. Dan Weston Paul Johnson wrote: This page (http://www.npdbd.umn.edu/deliver/elevator.html) has a template for an elevator pitch. This is what you say to someone when you have 30 seconds to explain your big idea, for instance if you find yourself in an elevator with them. I thought I'd try instantiating it for Haskell. For software developers who need to produce highly reliable software at minimum cost, Haskell is a pure functional programming language that reduces line count by 75% through reusable higher order functions and detects latent defects with its powerful static type system. Unlike Ada and Java, Haskell allows reusable functions to be combined without the overhead of class definitions and inheritance, and its type system prevents the hidden side effects that cause many bugs in programs written in conventional languages. Comments? Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elevator pitch for Haskell.
Awesome! I'm reminded of the IRC post that said that Haskell is bad, it makes you hate other languages. Mike Dan Weston wrote: And here's my guide for public health officials... WARNING: Learning Haskell is dangerous to your health! Disguised as a fully-functional programming language, Haskell is actually a front for a working math-lab, supported by a cult of volunteers seeking to ensnare weak-headed but normal programmers susceptible to the dogma that laziness is a virtue. Though cut with syntactic sugar to be more palatable to newbies, each Haskell construct is in fact a contagious mix of higher-order functions, lambda expressions, and partial applications, a highly addictive gateway drug to category theory, initial algebras, and greco-morphisms. Some users have gotten trapped inside an IO monad unable to get out safely, and even gone mad trying to decipher commutative diagrams or perfect their own monad tutorial. Signs of addiction include prefixing co- to random words or needlessly replacing recursive functions with combinators and pointfree notation. The least fixed point of this unnatural transformation is the inability to find joy in the use of imperative programming languages. In some cases, hackage is irreversible and can lead to uncontrolled blogging. Further study is needed to understand the strong correlation between intelligence and Haskell addiction. Meanwhile, those at risk should be made to program in teams to suppress their creative drive. Dan Weston Paul Johnson wrote: This page (http://www.npdbd.umn.edu/deliver/elevator.html) has a template for an elevator pitch. This is what you say to someone when you have 30 seconds to explain your big idea, for instance if you find yourself in an elevator with them. I thought I'd try instantiating it for Haskell. For software developers who need to produce highly reliable software at minimum cost, Haskell is a pure functional programming language that reduces line count by 75% through reusable higher order functions and detects latent defects with its powerful static type system. Unlike Ada and Java, Haskell allows reusable functions to be combined without the overhead of class definitions and inheritance, and its type system prevents the hidden side effects that cause many bugs in programs written in conventional languages. Comments? Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: xmonad 0.3
The xmonad dev team is pleased to announce the 0.3 release of xmonad. xmonad: a tiling window manager http://xmonad.org About: xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use. All features of the window manager are accessible from the keyboard: a mouse is strictly optional. xmonad is written and extensible in Haskell. Custom layout algorithms, and other extensions, may be written by the user in config files. Layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled on several screens. Features: * Very stable, fast, small and simple. * Automatic window tiling and management * First class keyboard support: a mouse is unnecessary * Full support for tiling windows on multi-head displays * Full support for floating windows * XRandR support to rotate, add or remove monitors * Per-workspace layout algorithms * Per-screens custom status bars * Easy, powerful customisation and reconfiguration * Large extension library * Extensive documentation and support for hacking Since xmonad 0.2, the following notable features and bug fixes have appeared: New features: * floating layer support: transients windows are not tiled by default, and windows may be dragged to and from a traditional floating layer (which allows mouse-resizing, and overlapping windows). * improved Xinerama support: workspace switching reuses multiple displays more effectively. * huge new extension library. Over 50 extensions to xmonad have been contributed by users, and are available all in a standard library, with documentation. More information, screenshots, documentation and community resources are available from: http://xmonad.org Xmonad is available from hackage, and via darcs. Happy hacking! The Xmonad Team: Spencer Janssen Don Stewart Jason Creighton Xmonad has also received contributions from at least: Alec Berryman Andrea Rossato Chris Mears Daniel Wagner David Glasser David Lazar David Roundy Hans Philipp Annen Joachim Fasting Joe Thornber Kai Grossjohann Karsten Schoelzel Michael Sloan Miikka Koskinen Neil Mitchell Nelson Elhage Nick Burlett Peter De Wachter Robert Marlow Sam Hughes Shachaf Ben-Kiki Shae Erisson Simon Peyton Jones Stefan O'Rear as well as many others on the IRC channel and mailing list. Thanks to everyone! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Learn Prolog...
On 9/2/07, Andrew Coppin [EMAIL PROTECTED] wrote: One of standard exercices in Prolog is the construction of the meta-interpreter of Prolog in Prolog. While this is cheating, I recommend it to you. It opens eyes. Ever tried implementing Haskell in Haskell? ;-) In many respects, Haskell is a much higher-level language than Prolog. Before you all gasp and go plonk!, consider the following argument. In Prolog, you need to pay close attention to the exact order in which things are executed. In preditcate logic you may write (using haskellish term notation) a(xs,ys,zs) = (xs = [] /\ ys = zs) \/ (xs = (x:ws) /\ zs = x:vs /\ a(ws, ys, vs)) but to interpret this as a *program* you have to consider how it will be executed. In particular, using SLD resolution, conjunction (/\, or ',' in Prolog notation) is not commutative as it is in predicate logic. This is good in some respects - in this respect it is easier to write efficient Prolog than Haskell, but at the same time, compilers can't rewrite programs (i.e. optimize) nearly so effectively. And that's not even taking into account that Prolog is impure, so the compiler has to watch out for side effects. Also, still considering append, as a high level specification of the relationship between lists and their concatenation, it is ill-typed: append([], Ys, Ys). append([X|Xs], Ys, [X|Zs]) :- append(Xs, Ys, Zs). (Ye Gods! My Prolog *has* rusted quickly!) From the clauses, it is clear that the first argument must satisfy list([]). list([X|Xs]) :- list(Xs). but the same is not true of the second and third arguments. ?- append([1,2,3], 4, Zs). Zs = [1|[2|[3|4]]] ?- Lee Naish has written in detail on this subject. Another argument in favour of Haskell being high-level is John Hughes' glue argument. If you don't know what I mean, go and read Why Functional Programming Matters. Hey, that was fun. I have barely written *any* Prolog since I finished my thesis. :-) cheers, T. -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] About mplus
I've been thinking about making a data type an instance of MonadPlus. From the Haddock documentation at haskell.org, I see that any such instance should satisfy mzero `mplus` x = x x `mplus` mzero = x mzero = f = mzero v mzero = mzero but is that all there is to it? Are there no other requirements for MonadPlus to make sense? I also wondered why, once MonadPlus was added to the language, the definition of ++ wasn't changed to (++) = MonadPlus (with the MonadPlus instance for [] defined directly). Aside from getting msum and guard, is there any point in bothering to make something an instance of MonadPlus? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Learn Prolog...
On Wed, 2007-09-05 at 13:21 +1000, Thomas Conway wrote: On 9/2/07, Andrew Coppin [EMAIL PROTECTED] wrote: One of standard exercices in Prolog is the construction of the meta-interpreter of Prolog in Prolog. While this is cheating, I recommend it to you. It opens eyes. Ever tried implementing Haskell in Haskell? ;-) In many respects, Haskell is a much higher-level language than Prolog. Before you all gasp and go plonk!, consider the following argument. In Prolog, you need to pay close attention to the exact order in which things are executed. That's because Prolog is -ugly-. The only reason I recommend it is because it's archetypical and there aren't any other logic languages with anywhere near the mindshare/significance. For a thing of sheer beauty, see, e.g. LolliMon. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Learn Prolog...
On Wed, Sep 05, 2007 at 01:21:52PM +1000, Thomas Conway wrote: but to interpret this as a *program* you have to consider how it will be executed. In particular, using SLD resolution, conjunction (/\, or ',' in Prolog notation) is not commutative as it is in predicate logic. I've always wondered why Prolog uses DFS, instead of some complete method like DFID or Eppstein's hybrid BFS... having to worry about clause order seems so out of place. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] About mplus
On Wed, Sep 05, 2007 at 03:35:03PM +1200, ok wrote:
I've been thinking about making a data type an instance of MonadPlus.
From the Haddock documentation at haskell.org, I see that any such
instance should satisfy
mzero `mplus` x = x
x `mplus` mzero = x
mzero = f = mzero
v mzero = mzero
but is that all there is to it? Are there no other requirements for
MonadPlus to make sense?
I also wondered why, once MonadPlus was added to the language, the
definition of ++ wasn't changed to
(++) = MonadPlus
(with the MonadPlus instance for [] defined directly).
It was. They changed it back in Haskell 98, as part of a grand program
of dumbing down the langauge... Cale Gibbard says {{{I get the impression
there were a lot of people on the Haskell 98 committee who really really
hated polymorphism.}}}.
Stefan
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Off topic] Proving an impossibility
You get the logic and code blowup problems that require either local variables, breaks, gotos, or continuations because you're working with tests that generate side-effects. Mixing side-effects and tests is going to generate a goto, sure, but if the code was rewritten in a functional style the problems would go away, even in an imperative context. Or even: myFunc E' = if E' do S if not F then do T myFunc E main = do myFunc E of course you could rewrite this in a while loop too although you'd have to use an assignment, but at least still not one with a silly done variable. E' = E while(E') S if not F T E' = E endwhile I've actually used this sort of construct plenty of times in imperative languages (putting fenceposts in a list generated by an enumerator, etc.) because its clearer and simpler than break. Break isn't as bad as goto, but it can also lead to difficulty reasoning about large functions along the same lines. in Java I often find myself initializing a return value upfront and then setting it according to the logic of the program rather than calling return at arbitrary points for the same reason again -- it lets you avoid duplicate cleanup code and reason clearly about the flow of control in your program. Of course, this is what a finally block is for, except finally blocks are ugly, while unwindProtect in, say, lisp, is somewhat neater except it breaks with full continuations, which is why, as i understand it with my still limited Haskell-fu, a monadic context that you can enter and exit is the cleanest way to enforce this stuff, and it works precisely because the pure functionality is enforced. Okay, now I'm rambling. Except that I do note, now, that assignment, and I suppose procedures are disallowed as well because the original question was apparently only with regards to using just the if and while statement (which I assume would also disallow the logical operators used in the initial post as well). All of which maybe, is just therefore the professor's way to push students to realize that if and while *alone* are insufficiently expressive to generate all possible flow control combinations (i.e. one can't construct an if/while calculus the same way one can construct an S K one). --S while E do S if F then break end T end On Sep 4, 2007, at 11:39 AM, Tillmann Rendel wrote: Vimal wrote: Ah, yes, it is possible in this case, but you have used an extra variable. It is okay, but our professor doesnt want to put emphasis on Computability here (or maybe I dont realize it), but the point is: Are such programming constructs really necessary in a programming language? i.e. Is Breakl, goto, falling through switch/case statements, necessary in a language? If your (or your professor's) question is not about computabily, but about expressivenes, what's the point of asking for a proof? In a turing-complete language, everything should be expressible :) Sensible questions may include: how easy is it to express a language feature using only other language features? (local or global transformation needed, code blowup, mechanical transformation or rewrite-from-scratch?) This also brings another point. What if there are N loops like this, and there is no break statement available in your language? You would have to use N conditional variables, and would make mainting the code a horrible thing to do. I disagree. You would have to introduce a temporary variable for every breakable loop, an assignment to the approbiate variable for every break and a lot of tests of temporary variables to skip parts of the loop body. Since breaks can only occur withing the loop body, and each break only breaks the innermost loop, all of these temporary variables can share the same name and shadow each other in the case of nested loops. by reserving a approbiate name (like done) for this variable by convention. Reading such code, you can just just resugar the code by reading if not done then, done := true and let var done = false in while ... as primitives. This is a local transformation, the code blowup is linear and it is possible to do it mechanically. I therefore consider the break statement as easily emulated by temporary variables. On the other hand, the obvious next step would be to provide actual names for these three uses of the done-variable, either by using whatever abstraction means provided by the language, or by adding syntactic sugar. In Haskell, we would simply define an approbiate monad to hide the if not done then-parts in the bind operation and reuse the existing syntactic sugar for monadic expressions. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending the idea of a general Num to other types?
On Sep 4, 2007, at 5:03 PM, Peter Verswyvelen wrote: Otherwise you would need a very clever compiler/editor machine learning system, that looks at how a class of users fixes a certain error, so the compiler can adapt its error message the next time a similar pattern occurs (which is science fiction right now I think...) On that note, I've been finding GHC's type suggestions often worse than useless, and wish it wouldn't even bother to try -- even more confusing for new users to have the compiler suggest pointless things like declaring an instance of Num String or whatever. I'd prefer it if it could just tell me what *specific* part of an expression, which symbol even, the expected and inferred values differed. On the other hand, when trying to guess at operator precedence rules, the applied to too many and applied to too few errors are actually pretty handy. --S ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Learn Prolog...
On 9/5/07, Derek Elkins [EMAIL PROTECTED] wrote: That's because Prolog is -ugly-. The only reason I recommend it is because it's archetypical and there aren't any other logic languages with anywhere near the mindshare/significance. For a thing of sheer beauty, see, e.g. LolliMon. Oh, look, I quite like Prolog in some respects. Especially Nu-Prolog which has safe negation. I also highly recommend learning it. It will enrich the way you think about problems, especially if you get to know it well enough to understand how logic variables are implemented, etc. T. ps I feel obliged to put in a good word for Mercury which I worked on, along with a few other denizens in this forum. See www.mercury.cs.mu.oz.au. -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Learn Prolog...
On 9/5/07, Stefan O'Rear [EMAIL PROTECTED] wrote: I've always wondered why Prolog uses DFS, instead of some complete method like DFID or Eppstein's hybrid BFS... having to worry about clause order seems so out of place. Well, a couple of reasons are pretty well agreed in the Prolog community: 1. Order of side-effects. 2. Efficiency of implementation. and arguably 3. Hysterical Raisins. -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] About mplus
On 9/4/07, ok [EMAIL PROTECTED] wrote: I've been thinking about making a data type an instance of MonadPlus. From the Haddock documentation at haskell.org, I see that any such instance should satisfy mzero `mplus` x = x x `mplus` mzero = x mzero = f = mzero v mzero = mzero but is that all there is to it? Are there no other requirements for MonadPlus to make sense? Also, mplus has to be associative. I.e. (a `mplus` b) `mplus` c == a `mplus` (b `mplus` c) I also wondered why, once MonadPlus was added to the language, the definition of ++ wasn't changed to (++) = MonadPlus (with the MonadPlus instance for [] defined directly). You mean (++) = mplus. I've wondered that too. Similarly, one should define map = fmap. And a lot of standard list functions can be generalized to MonadPlus, for example you can define filter :: (MonadPlus m) = (a - Bool) - m a - m a (This is not the same as filterM.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Finance-Quote-Yahoo 0.3
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Quote-Yahoo-0.3 i know minor point releases do not merit a list announcement but yahoo discontinued a url i was using to download data, so users of this package must upgrade. sorry for the hassle. thanks brad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
