[Haskell-cafe] Monad.Reader #20 - DEADLINE EXTENSION
Call for Copy: The Monad.Reader - Issue 20 - DEADLINE EXTENSION --- Whether you're an established academic or have only just started learning Haskell, if you have something to say, please consider writing an article for The Monad.Reader! The updated submission deadline for Issue 20 is now: **Wednesday, March 21** The Monad.Reader The Monad.Reader is a electronic magazine about all things Haskell. It is less formal than journal, but somehow more enduring than a wiki- page. There have been a wide variety of articles: exciting code fragments, intriguing puzzles, book reviews, tutorials, and even half-baked research ideas. Submission Details ~~ Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue to me by e-mail (ezy...@mit.edu). Articles should be written according to the guidelines available from http://themonadreader.wordpress.com/contributing/ Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll work something out. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On Mon, Dec 19, 2011 at 7:10 PM, Alexander Solla wrote: > * Documentation that discourages thinking about bottom as a 'value'. It's > not a value, and that is what defines it. The fact that bottom is a value in Haskell is the fundamental thing that differentiates Haskell from other languages and the source of its power. The fact that f _|_ /= _|_ potentially _is_ what it means to be a lazy language. It is what allows us to implement loops and conditionals as normal functions rather than requiring special and limited language contexts. But more importantly, it is required to think about _|_ as a value in order to prove the correctness of many algorithms, it is the base case of your inductive reasoning. A Haskell programmer who cannot think of _|_ in that way will plateau as very useful idioms such as tying the knot, infinite data structures, etc.. are just complicated to think about in operational semantics when they get more interesting than an infinite list. Not treating _|_ as a value would be a huge disservice to anyone learning the language. Sure, it may seem a little strange coming from the imperative world to think of it as a value, but it is by far the oddest concept in Haskell, after all, _functions_ are values in Haskell and people seem to eventually figure that out. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
On Wed, Mar 7, 2012 at 11:47 AM, Alejandro Serrano Mena wrote: > I agree with you that maybe this proposal is vague for a GSoC, but I don't > think that websockets is a good option either, because not all browsers > support them. We already have a websockets library, but like you say it is not very useful by itself because it may not be supported in all browsers. The GSoC proposal is to create a library that will use appropriate fallbacks on all browsers, which is how websockets are normally used. > > > 2012/3/7 Greg Weber >> >> This is obviously a great concept. However, it may not be appropriate >> for a GSoC. The design space is far too open, and it is not clear if >> anything in that space will end up beating plain old javascript. >> >> I think my proposal for an awesome websockets library [1] shows that >> this is putting the cart before the horse. For some of the potential >> javascript solutions, websockets is a dependency anyways. Without >> being able to hold open a connection to the server, required server >> interaction will be too slow. >> Yesod has been successful by explicitly avoiding any new radical >> paradigms, but by instead just trying to get the basics of web >> development established correctly. Without websockets, we don't have >> the basics down for fluid client-side interaction. >> The groundwork for this ticket has been laid: it should be easy to >> accomplish with time left over. >> So we are guaranteed a clear win for the community. With the time left >> over, a solution to the javascript problem can be attempted. But there >> is no burden for it to be solved within the summer. Next year the >> landscape will be more mature and we can try to come up with a solid >> proposal for the javscript problem if the community hasn't already >> created a solution. >> >> [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
I agree with you that maybe this proposal is vague for a GSoC, but I don't think that websockets is a good option either, because not all browsers support them. Indeed, web development has gone a long way without contant communication with the server and I think Haskell should support this way of working too. My idea would rather go on the direction of using stablished Haskell concepts to web development. Some ideas are: - use an applicative interface like the one of Yesod for forms validation and sending - see the DOM via a Zipper interface, so widgets will "anchor" themselves in some point of the tree and change things around them - use FRP for Canvas interaction - ... Actually, thinking which Haskell concepts could behave well with client-side development is an interesting discussion by its own :) 2012/3/7 Greg Weber > This is obviously a great concept. However, it may not be appropriate > for a GSoC. The design space is far too open, and it is not clear if > anything in that space will end up beating plain old javascript. > > I think my proposal for an awesome websockets library [1] shows that > this is putting the cart before the horse. For some of the potential > javascript solutions, websockets is a dependency anyways. Without > being able to hold open a connection to the server, required server > interaction will be too slow. > Yesod has been successful by explicitly avoiding any new radical > paradigms, but by instead just trying to get the basics of web > development established correctly. Without websockets, we don't have > the basics down for fluid client-side interaction. > The groundwork for this ticket has been laid: it should be easy to > accomplish with time left over. > So we are guaranteed a clear win for the community. With the time left > over, a solution to the javascript problem can be attempted. But there > is no burden for it to be solved within the summer. Next year the > landscape will be more mature and we can try to come up with a solid > proposal for the javscript problem if the community hasn't already > created a solution. > > [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
This is obviously a great concept. However, it may not be appropriate for a GSoC. The design space is far too open, and it is not clear if anything in that space will end up beating plain old javascript. I think my proposal for an awesome websockets library [1] shows that this is putting the cart before the horse. For some of the potential javascript solutions, websockets is a dependency anyways. Without being able to hold open a connection to the server, required server interaction will be too slow. Yesod has been successful by explicitly avoiding any new radical paradigms, but by instead just trying to get the basics of web development established correctly. Without websockets, we don't have the basics down for fluid client-side interaction. The groundwork for this ticket has been laid: it should be easy to accomplish with time left over. So we are guaranteed a clear win for the community. With the time left over, a solution to the javascript problem can be attempted. But there is no burden for it to be solved within the summer. Next year the landscape will be more mature and we can try to come up with a solid proposal for the javscript problem if the community hasn't already created a solution. [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1607 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHCi fails to load C++ object files (missing symbol)
Sorry for the double post, but I forgot to mention I'm using GHC 7.4 and
gcc/libstdc++ 4.5.2.
(Running Ubuntu 11.04 Natty Narwhal).
2012/3/7 Yves Parès
> Hi, I'm trying to have GHCi load a haskell file that depends on a C++
> object file, which causes GHCi to fail because of an unknown symbol (*and
> I did link with **libstdc++*), whereas the link into an executable with
> ghc works and runs perfectly.
>
> I've reduced my code to the smallest one that produces the problem:
> The C++ part defines a mere class and C externals that enable
> communication with Haskell:
>
> // Header Stuff.hpp
> class Base {
> public:
> Base();
> ~Base();
> }
>
> extern "C" {
> Base* mkthing();
> void delthing(Base*);
> }
>
> ---
>
> // Source Stuff.cpp
> #include
> #include "Stuff.hpp"
> using namespace std;
>
> Base::Base()
> {
> cout << "Base created" << endl;
> }
>
> Base::~Base()
> {
> cout << "Base deleted" << endl;
> }
>
> extern "C" {
> Base* mkthing()
> {
> return new Base();
> }
>
> void delthing(Base* b)
> {
> delete b;
> }
> }
>
> Haskell code (just for reference, but I'm not sure it's relevant), Main.hs:
>
> {-# LANGUAGE ForeignFunctionInterface #-}
> import Foreign
> import Foreign.C
>
> foreign import ccall unsafe "mkthing"
> mkthing :: IO (Ptr ())
>
> foreign import ccall unsafe "delthing"
> delthing :: Ptr () -> IO ()
>
> main = do
> p <- mkthing
> delthing p
>
>
> I then compile it with:
> g++ -c Stuff.cpp
> ghci Main.hs Stuff.o -lstdc++
>
> And then the error is:
> Loading object (static) Stuff.o ... done
> Loading object (dynamic)
> /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/libstdc++.so ... done
> final link ... ghc: Stuff.o: unknown symbol `__dso_handle'
> linking extra libraries/objects failed
>
> Whereas 'ghc Main.hs Stuff.o -lstdc++' works just fine.
> Does GHCi lacks a link directive that regular GHC has?
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHCi fails to load C++ object files (missing symbol)
Hi, I'm trying to have GHCi load a haskell file that depends on a C++
object file, which causes GHCi to fail because of an unknown symbol (*and I
did link with **libstdc++*), whereas the link into an executable with ghc
works and runs perfectly.
I've reduced my code to the smallest one that produces the problem:
The C++ part defines a mere class and C externals that enable communication
with Haskell:
// Header Stuff.hpp
class Base {
public:
Base();
~Base();
}
extern "C" {
Base* mkthing();
void delthing(Base*);
}
---
// Source Stuff.cpp
#include
#include "Stuff.hpp"
using namespace std;
Base::Base()
{
cout << "Base created" << endl;
}
Base::~Base()
{
cout << "Base deleted" << endl;
}
extern "C" {
Base* mkthing()
{
return new Base();
}
void delthing(Base* b)
{
delete b;
}
}
Haskell code (just for reference, but I'm not sure it's relevant), Main.hs:
{-# LANGUAGE ForeignFunctionInterface #-}
import Foreign
import Foreign.C
foreign import ccall unsafe "mkthing"
mkthing :: IO (Ptr ())
foreign import ccall unsafe "delthing"
delthing :: Ptr () -> IO ()
main = do
p <- mkthing
delthing p
I then compile it with:
g++ -c Stuff.cpp
ghci Main.hs Stuff.o -lstdc++
And then the error is:
Loading object (static) Stuff.o ... done
Loading object (dynamic)
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/libstdc++.so ... done
final link ... ghc: Stuff.o: unknown symbol `__dso_handle'
linking extra libraries/objects failed
Whereas 'ghc Main.hs Stuff.o -lstdc++' works just fine.
Does GHCi lacks a link directive that regular GHC has?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
Doesn't sound overused to me. FWIW, one of the ideas floating around in my head is exactly what you're describing. On Wed, Mar 7, 2012 at 2:41 PM, JP Moresmau wrote: > Maybe I'll sound like an overused meme, but what about JQuery? JQuery > already takes a combinator-like approach to Javascript and DOM > manipulations, so maybe we could have a combinator library that would > mimic the JQuery library. We'd obviously need some extra combinators > for the required parts of Javascript and HTML generation that are not > done via JQuery. > > JP > > On Tue, Mar 6, 2012 at 11:10 PM, Alejandro Serrano Mena > wrote: >> My idea would be reusing some of the already-available tools for compiling >> Haskell to JS (for example, UHC), and develop with any of them a complete >> library for client-side scripting; rather that redevelop a way to compile >> Haskell to JS. >> >> I think it's really a pity not being able to use things like what Yesod >> provides in a client-side context. And both sides would benefit: they can >> share common code for datatypes (as it's done in Google Web Toolkit), and >> autogenerate some code for sending or receiving AJAX requests, for example. >> >> >> 2012/3/6 Michael Snoyman >>> >>> On Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena >>> wrote: >>> > Hi, >>> > I'm really looking forward to helping in the Summer of Code, if Haskell >>> > goes >>> > into it this year (something I take for granted :). I would like to >>> > propose >>> > an idea for a project, and I'm looking for suggestions about whether >>> > it's >>> > good, should be improved or it's just unfeasible. >>> > >>> > My idea is to make a client-side Haskell Web Toolkit, in the spirit of >>> > Google Web Toolkit, which would allow to program in Haskell the client >>> > part >>> > of a web application, and would complement the web frameworks already >>> > existing for Haskell (such as Yesod and Snap). The point is coming about >>> > with a Haskell-ish way to program applications, to reuse all the >>> > existing >>> > knowledge for our beloved language. >>> > >>> > I've added more details in a pre-proposal in Google Docs, available >>> > >>> > in https://docs.google.com/document/d/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit >>> > Tell me if you prefer to see it in other format, but I didn't want to >>> > generate a bigger e-mail. >>> > >>> > Thanks in advance. >>> >>> I definitely think the idea has merit. In general I'm wary of >>> solutions which try to compile down to Javascript[1], and I'm not sure >>> if actually providing a full Haskell-to-JS approach is a good idea. >>> Another possibility might be a DSL/combinator library for generating >>> JS. Though at this point, I wouldn't rule out either approach. >>> >>> Yesod is currently wrapping up its 1.0 release (almost certainly >>> out-the-door by the end of April), and after that our main focus is >>> intended to be client-side integration, so we would certainly be happy >>> to discuss design ideas and collaborate in general. >>> >>> Michael >>> >>> [1] I say "compile down to" to mean nontrivial changes, as opposed to >>> something like Coffeescript, which is a fairly simple conversion. >> >> >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
Maybe I'll sound like an overused meme, but what about JQuery? JQuery already takes a combinator-like approach to Javascript and DOM manipulations, so maybe we could have a combinator library that would mimic the JQuery library. We'd obviously need some extra combinators for the required parts of Javascript and HTML generation that are not done via JQuery. JP On Tue, Mar 6, 2012 at 11:10 PM, Alejandro Serrano Mena wrote: > My idea would be reusing some of the already-available tools for compiling > Haskell to JS (for example, UHC), and develop with any of them a complete > library for client-side scripting; rather that redevelop a way to compile > Haskell to JS. > > I think it's really a pity not being able to use things like what Yesod > provides in a client-side context. And both sides would benefit: they can > share common code for datatypes (as it's done in Google Web Toolkit), and > autogenerate some code for sending or receiving AJAX requests, for example. > > > 2012/3/6 Michael Snoyman >> >> On Tue, Mar 6, 2012 at 11:40 PM, Alejandro Serrano Mena >> wrote: >> > Hi, >> > I'm really looking forward to helping in the Summer of Code, if Haskell >> > goes >> > into it this year (something I take for granted :). I would like to >> > propose >> > an idea for a project, and I'm looking for suggestions about whether >> > it's >> > good, should be improved or it's just unfeasible. >> > >> > My idea is to make a client-side Haskell Web Toolkit, in the spirit of >> > Google Web Toolkit, which would allow to program in Haskell the client >> > part >> > of a web application, and would complement the web frameworks already >> > existing for Haskell (such as Yesod and Snap). The point is coming about >> > with a Haskell-ish way to program applications, to reuse all the >> > existing >> > knowledge for our beloved language. >> > >> > I've added more details in a pre-proposal in Google Docs, available >> > >> > in https://docs.google.com/document/d/1FnTNO9uTobDHRTDXWurKns7vGTjeauw0nRhbtt6vavs/edit >> > Tell me if you prefer to see it in other format, but I didn't want to >> > generate a bigger e-mail. >> > >> > Thanks in advance. >> >> I definitely think the idea has merit. In general I'm wary of >> solutions which try to compile down to Javascript[1], and I'm not sure >> if actually providing a full Haskell-to-JS approach is a good idea. >> Another possibility might be a DSL/combinator library for generating >> JS. Though at this point, I wouldn't rule out either approach. >> >> Yesod is currently wrapping up its 1.0 release (almost certainly >> out-the-door by the end of April), and after that our main focus is >> intended to be client-side integration, so we would certainly be happy >> to discuss design ideas and collaborate in general. >> >> Michael >> >> [1] I say "compile down to" to mean nontrivial changes, as opposed to >> something like Coffeescript, which is a fairly simple conversion. > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Associative prefix operators in Parsec
Consider a simple language of logical expressions:
> import Control.Applicative
> import Text.Parsec hiding ((<|>), many)
> import Text.Parsec.String
> import Text.Parsec.Expr
>
> data Expr = Truth
> | Falsity
> | And Expr Expr
> | Or Expr Expr
> | Not Expr
> deriving (Show, Eq)
I define a simple expression parser using Parsec:
> expr :: Parser Expr
> expr= buildExpressionParser table (lexeme term)
> "expression"
>
> term :: Parser Expr
> term= between (lexeme (char '(')) (lexeme (char ')')) expr
> <|> bool
> "simple expression"
>
> bool :: Parser Expr
> bool = lexeme (string "true" *> pure Truth)
><|> lexeme (string "false" *> pure Falsity)
>
> lexeme :: Parser a -> Parser a
> lexeme p = p <* spaces
>
> table = [ [prefix "!" Not ]
> , [binary "&" And AssocLeft ]
> , [binary "|" Or AssocLeft ]
> ]
>
> binary name fun assoc = Infix (do{ lexeme (string name); return fun }) assoc
> prefix name fun = Prefix (do{ lexeme (string name); return fun })
Now this doesn't work:
> test1 = parseTest expr "!!true"
But this does:
> test2 = parseTest expr "!(!true)"
I have studied the code for buildExpressionParser, and I know why this
happens (prefix operators are treated as nonassociative), but it seems
like one would often want right-associative prefix operators (so test1
would work). Is there a common workaround or solution for this problem?
I assume the nonassociativity in Parsec is by design and not a bug.
--
\ Troels
/\ Henriksen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
Hi, Alejandro Serrano Mena wrote: > My idea is to make a client-side Haskell Web Toolkit, in the spirit of > Google Web Toolkit, which would allow to program in Haskell the client part > of a web application, and would complement the web frameworks already > existing for Haskell (such as Yesod and Snap). http://www.haskell.org/haskellwiki/Haskell_web_toolkit - In memoriam ;) Feel free to use these ideas. It would be nice if you could pick it up and complete - I never did... -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
