Bryan O'Sullivan wrote:
On Thu, Dec 10, 2009 at 5:01 AM, Johann Höchtl
mailto:johann.hoec...@gmail.com>> wrote:
> Yes. I'm working on a patch at the moment.
Is there something planed to happen in 2010?
Retooling the I/O manager isn't a huge job, but it requires the
equivalent of se
> This is a matter that I genuinely at the present time do not grasp and
> I am hoping that some of you who are more familiar with the Haskell
> language may be able to help enlighten me. I feel the question to be
> an important one. What material benefit does Haskell derive from being
> a "pure" f
On Thu, Dec 10, 2009 at 6:34 PM, David Leimbach wrote:
>>
>> >> 2b. You can define brand new flow control constructs *inside* the
>> >> language
>> >> itself. (E.g., in Java, a "for" loop is a built-in language construct.
>> >> In
>> >> Haskell, "for" is a function in Control.Monad. Just a plain o
On Dec 11, 2009, at 3:50 AM, John D. Earle wrote:
David, think of the machine as being the earth and laziness is in
the clouds.
It reads so much better as "laziness is in the heavens".
Strict evaluation is closer to the machine.
It doesn't have to be. Graph reduction hardware has been b
>
>
> >> 2b. You can define brand new flow control constructs *inside* the
> language
> >> itself. (E.g., in Java, a "for" loop is a built-in language construct.
> In
> >> Haskell, "for" is a function in Control.Monad. Just a plain ordinary
> >> function that anybody could write.)
> >>
> >
> > Psst
On Dec 9, 2009, at 4:00 AM, Robin Green wrote:
At Thu, 10 Dec 2009 12:07:32 +,
Magnus Therning wrote:
As I understand it it all started with laziness. I don't know if
laziness is impossible without purity
More or less.
The S programming language, used for statistics,
- is not pure
- D
On Dec 11, 2009, at 3:05 AM, Miguel Mitrofanov wrote:
Not to mention that in Emacs with glasses-mode enabled camelCase can
be made even more readable (my personal favorite is highlighting
internal capital letters with bold).
And there is some reason why letters following underscores could
On Dec 11, 2009, at 3:00 AM, Daniel Fischer wrote:
Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe:
Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that
went into Haskell forNoApparentReasonThatIHaveEverHeardOf,
mb_t's_bcs the ndrscr_stl is considered far uglier a
On Dec 11, 2009, at 1:01 AM, John D. Earle wrote:
This is a matter that I genuinely at the present time do not grasp
and I am hoping that some of you who are more familiar with the
Haskell language may be able to help enlighten me. I feel the
question to be an important one. What material
On Thu, Dec 10, 2009 at 2:42 PM, Stephen Tetley
wrote:
> C'mon Andrew - how about some facts, references?
Filling in :-)
> 2009/12/10 Andrew Coppin :
>
>
>> 1. Code optimisation becomes radically easier. The compiler can make very
>> drastic alterations to your program, and not chance its meanin
On Thu, Dec 10, 2009 at 1:46 PM, Andrew Coppin
wrote:
> o...@okmij.org wrote:
>>
>> Andrew Coppin wrote:
>>
>>>
>>> What we're really trying to do here is attach additional information to a
>>> value - information which exists only in the type checker's head, but has
>>> no
>>> effect on runtime b
The attached document works for me.
HTH,
Andres
--
Andres Loeh, Universiteit Utrecht
mailto:and...@cs.uu.nl mailto:m...@andres-loeh.de
http://www.andres-loeh.de
\documentclass{article}
%include polycode.fmt
%options ghci
\begin{document}
\section{Test}
> test = putStrLn "\\section{Re
Hi all,
I was looking through some of the Hackage packages to find examples of
how developers are extending UserHooks in their Setup files, but it
wasn't easy, since the great majority of Cabal Setup files in Hackage
simply require only the standard line of 'main = defaultMain' or
'defaultMa
C'mon Andrew - how about some facts, references?
2009/12/10 Andrew Coppin :
> 1. Code optimisation becomes radically easier. The compiler can make very
> drastic alterations to your program, and not chance its meaning. (For that
> matter, the programmer can more easily chop the code around too..
John D. Earle wrote:
What material benefit does Haskell derive from being a "pure"
functional language as opposed to an impure one?
1. Code optimisation becomes radically easier. The compiler can make
very drastic alterations to your program, and not chance its meaning.
(For that matter, the
o...@okmij.org wrote:
Andrew Coppin wrote:
What we're really trying to do here is attach additional information to a
value - information which exists only in the type checker's head, but has no
effect on runtime behaviour.
Haskell has had the ability to attach arbitrary many pieces of
2009/12/10 Richard O'Keefe :
> On Dec 10, 2009, at 2:58 AM, Roel van Dijk wrote:
>> I tried to be conservative with the choice of unicode symbols. I have
>> defined the division sign (÷) to be (/). But it could just as well be
>> defined as 'div'.
>
> No it couldn't. One expects 3÷2 to be 1½, not
I have not read all/most of the replies.
>What material benefit does Haskell derive from being a "pure" functional
>language as opposed to an impure one? Please provide examples as I require
>instruction.
A pure functional lanugage allows lazy evaluation, which adds another
tool to your modulari
Dear all,
I want to call a function "f :: Scenario -> Doc", using lhs2tex, that returns a Doc of the HughesPJ pretty print library. The returning Doc is embedded with Latex syntax. I mean, calling (show f s) returns some thing like:
"\\subsubsection*{Scenario sc01}\n\\begin{itemize}\n\\item "
P
2009/12/10 David Leimbach :
> While it's fair to mention that unsafePerformIO is not in the report ...
Colin Paul Adams called me out off list and its in the FFI appendum
and in Haskell 2010 - "I've still got 21 days!".
Best wishes
Stephen
___
Haskell
Hi Stephen,
While it's fair to mention that unsafePerformIO is not in the report for the
reasons you give, it is present in some libraries. The practical reality of
the situation is you can not in general trust that because a function's
signature is pure, that the implementation of that function
Sebastian Sylvan writes:
> I think laziness requires purity to make sense. Laziness implies that the
> order of evaluation is highly unpredictable and depends strongly on the
> implementation details of libraries and such
Laziness is like single-threaded concurrency.
> So it's fickle. Someone a
On Thu, Dec 10, 2009 at 11:16 AM, John D. Earle wrote:
> Dear Gregg,
>
> You wrote, "Just think about how one reads a mathematical text - you need
> not actually compute subformulae or even analyze them logically in order to
> work with them." I hate to have to say this, but do you realize that
I'm going to try to respond to your letters later on when I have more time.
This break may also be useful in that it may help the conversation from
becoming overheated. I stopped in the middle of a letter and put it in the
draft folder so that I could give it greater attention. I was writing it
I'll try to paraphrase you, to see if I understand you correctly.
The composition splice . quote can have one 'hard' error source.
Grammatically incorrect quote. I think that will be caught by the type
checker. Of a bigger concern are logical errors, introduced by buggy
macros. But it is template
On Thu, Dec 10, 2009 at 5:01 AM, Johann Höchtl wrote:
>
> > Yes. I'm working on a patch at the moment.
>
> Is there something planed to happen in 2010?
>
Retooling the I/O manager isn't a huge job, but it requires the equivalent
of several weeks of work. I tossed out my initial attempt at a patch
Hello David
Apropos the (unfortunately) frosty exchanges that greeted the first
release of UHC a couple of months ago, which argued that UHC wasn't
Haskell because it didn't implement n+k patterns, one could argue (at
least for rhetorical effect) that Haskell plus unsafePerformIO isn't
Haskell, I
In fairness to John, his trying really hard to avoid causing offense might
having something to do with the fact that he just had a couple dozen or so
e-mails attacking him personally the last time he tried asking questions about
Haskell and comparing it to O'Caml.
I have to confess that I mysel
Dear Gregg,
You wrote, "Just think about how one reads a mathematical text - you need not
actually compute subformulae or even analyze them logically in order to work
with them." I hate to have to say this, but do you realize that algebra is
concerned with functions among other things and it is
2009/12/10 Sebastian Sylvan :
> I think laziness requires purity to make sense. Laziness implies that the
> order of evaluation is highly unpredictable and depends strongly on the
> implementation details of libraries and such (which you may not have access
> to). So it's fickle. Someone adds an if
>
> I won't mention the name so as not to offend anyone.
Oh I'm sure we can handle it ;)
Though I'm curious as to how a language could be effect free in a practical
sense, but not a strict one? could you give an example?
To answer your original question, there are many benefits haskell gains fr
My understanding of functional programming is that nearly everything is a
function, and that evaluation of those functions is how programs are
written. Functional programming languages treat functions as first class
values, allowing them to be passed to other functions and returned from
functions.
On Thu, Dec 10, 2009 at 11:56 AM, Sebastian Sylvan
wrote:
>
>
> On Thu, Dec 10, 2009 at 3:30 PM, John D. Earle wrote:
>>
>> My intuition says that laziness and purity are distinct whereas yours says
>> that purity is a necessary condition. This is what needs to be reconciled.
>
> I think laziness
Vladimir, I do not mind becoming more familiar with the internals, but as
you pointed out that Template Haskell may provided much of the needed
functionality. I tend to doubt that it will provide all the needed
functionality, however. The new syntax created by the syntax macros will
either rein
On Thu, Dec 10, 2009 at 3:30 PM, John D. Earle wrote:
> My intuition says that laziness and purity are distinct whereas yours says
> that purity is a necessary condition. This is what needs to be reconciled.
>
I think laziness requires purity to make sense. Laziness implies that the
order of eva
On Thu, Dec 10, 2009 at 4:15 PM, John D. Earle wrote:
> To elaborate there is another language that is also a functional
> language. I won't mention the name so as not to offend anyone. It too is
> effect free, that is what makes it functional and it is a functional
> language in the true sense
On Thu, Dec 10, 2009 at 9:13 AM, John D. Earle wrote:
> Most of the discussion centers on the benefits of functional programming
> and laziness. Haskell is not merely a lazy functional language. It is a pure
> lazy functional language. I may need to explain what laziness is. Laziness
> is where y
What I think might be confusing the situation partially is that there is a
difference between the language and its implementation. Any side effect would
have been accounted for even though there is a means to side step it and its
inclusion may have been perceived as a undesirable and perhaps unn
So my question is, Did the leap from effect free for all practical purposes to
effect free in a strict sense yield any material benefits?___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
To elaborate there is another language that is also a functional language. I
won't mention the name so as not to offend anyone. It too is effect free, that
is what makes it functional and it is a functional language in the true sense
of the term, but it is not effect free in the sense that Haske
If anything, I'd flip those two...
On the backend, things are anything but pure but it helps us reason about
the program on the front end.
Laziness also isn't nearly as prevalent on the backend as it is on the front
end.
Even though we can reason about things using purity and laziness on the
fro
Laziness is on the logic front end and purity is on the execution back end.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
You're right. I mean referential transparency.
2009/12/10 John D. Earle :
> Eugene, by purity do you mean effect free? There is a subtle difference. The
> lack of effects makes a language functional, but this does not imply that
> the language is pure.
>
> -
Eugene, by purity do you mean effect free? There is a subtle difference. The
lack of effects makes a language functional, but this does not imply that
the language is pure.
--
From: "Eugene Kirpichov"
Sent: 10 Thursday December 2009 0838
To: "Joh
Yes I remember when watching Erik Meijer's videos on Channel9 he said
a similar thing: "laziness in the presence of side effects makes your
head explode"...
I guess the recent Microsoft Rx framework for .NET (that permits
impure push-based functional reactive programming with LINQ) will soon
show
Non-strictness is not necessary for purity, but it sure gives you some nice
properties... Take for example
const x y = x
It would be really nice for this function to have the property "always
results in x no matter what you give it as it's second argument". But for a
language which is strict, al
> If one were to think of this as a project, the initial project goal might be
> a proof of concept, that such an undertaking though non-trivial may be worth
> while.
for me it is currently quite tough, since I don't know the internals at all
> It would be desirable to act on the abstract syntax
2009/12/10 John D. Earle :
> My intuition says that laziness and purity are distinct whereas yours says
> that purity is a necessary condition. This is what needs to be reconciled.
>
Mixing impurity and laziness makes code whose behavior is too hard to
understand. So, there is no theoretical reaso
Laziness is on the logic front end and purity is on the execution back end.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
My intuition says that laziness and purity are distinct whereas yours says
that purity is a necessary condition. This is what needs to be reconciled.
I believe that everyone is thinking that lazy evaluation and strict
evaluation are similar activities whereas they are profoundly different.
_
On Thu, Dec 10, 2009 at 9:50 AM, John D. Earle wrote:
> in progress. The Haskell creed appears to be, This is the way so stick to
> it! The idea appears to be that by sticking to the program the problems will
> be overcome in time and we will be left with all the glorious goodness. At
I think thi
I understand that this is very much a work-in-progress. But we have to also
come to the realization that there's people forming "industrial groups" and
such around Haskell, and trying very earnestly to show that it's worth
looking into for serious practical applications.
I do believe that it's im
Most of the discussion centers on the benefits of functional programming and
laziness. Haskell is not merely a lazy functional language. It is a pure
lazy functional language. I may need to explain what laziness is. Laziness
is where you work through the logic in its entirely before acting on th
On 2009-12-10 01:11, John D. Earle wrote:
Is Parsec capable of parsing a mildly context sensitive language?
I expect that one can parse any decidable language using Parsec. Whether
it is convenient to do so is another question.
--
/NAD
___
Haskell-Ca
If one were to think of this as a project, the initial project goal might be
a proof of concept, that such an undertaking though non-trivial may be worth
while.
It would be desirable to act on the abstract syntax trees that result from
the compiler parsing the source code and not the source co
On Thu, Dec 10, 2009 at 6:31 AM, Alberto G. Corona wrote:
> My understanding is that a pointer to the lazy expression tree for the
> calcualtion of the parameter is put it the corresponding location of the
> function expression tree. But at any time you can force the evauation before
> the call.
David, think of the machine as being the earth and laziness is in the
clouds. Strict evaluation is closer to the machine. The relationship between
a lazy algorithm and the earth is abstract; hence, it will make creating
algorithms especially efficient ones difficult. All of this is still a work
> An important question will be, Will syntax macros work out better than an
> existing tool such as Happy?
They work in scheme, and typed scheme
http://www.ccs.neu.edu/scheme/pubs/popl08-thf.pdf
and a different hygienic mscheme is used in dylan
http://people.csail.mit.edu/jrb/Projects/dexprs.pdf
B
At Thu, 10 Dec 2009 12:07:32 +,
Magnus Therning wrote:
> As I understand it it all started with laziness. I don't know if
> laziness is impossible without purity
More or less.
Haskell is a language where anything can be evaluated lazily by
default. Unlike say Scheme, where if you want someth
My understanding is that a pointer to the lazy expression tree for the
calcualtion of the parameter is put it the corresponding location of the
function expression tree. But at any time you can force the evauation before
the call. or the compiler itself. Optimization is possible depending on the
k
John D. Earle wrote:
This is a matter that I genuinely at the present time do not grasp and I am hoping that
some of you who are more familiar with the Haskell language may be able to help enlighten
me. I feel the question to be an important one. What material benefit does Haskell derive
from
And that would be true if everything were strict and not partially evaluated
sometimes :-)
My understanding is the following... (and I could be way off)
Remember that a function of arity N is really N functions of arity 1 with
their arguments bound one at a time to create a new function along the
Not to mention that in Emacs with glasses-mode enabled camelCase can be made
even more readable (my personal favorite is highlighting internal capital
letters with bold).
Daniel Fischer wrote:
Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe:
Given the amazinglyUglyAndUnreadably
2009/12/10 Sebastian Sylvan :
>
>
> The killer app for that, IMO, is parallelism these days.
Parallelism has been a killer app for quite a long time:
Darlington's ALICE running Hope:
http://www.chilton-computing.org.uk/acd/dcs/projects/p011.htm
Clean was originally targeted to parallel machines:
Am Mittwoch 09 Dezember 2009 23:54:22 schrieb Richard O'Keefe:
> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that
> went into Haskell forNoApparentReasonThatIHaveEverHeardOf,
mb_t's_bcs the ndrscr_stl is considered far uglier and less readable by others
(granted,
underscore-sty
One more advantage that is not frequently cited
Purity permits to pass every parameter of a procedure by reference (giving
the pointer) rather that by value giving a copy, and still be sure that the
data has not been modified. Besides the safety. this is great language
optimization itself.
20
On Thu, Dec 10, 2009 at 1:38 PM, Bulat Ziganshin
wrote:
> Hello Sebastian,
>
> Thursday, December 10, 2009, 4:27:49 PM, you wrote:
> > The killer app for that, IMO, is parallelism these days
>
> btw, are you seen Google App Engine? it's python/java ATM, but i think
> that haskell will be ideal fit
What material benefit does Haskell derive from being a "pure" functional
language as opposed to an impure one?
Here is my list of benefits of purity (some of them are enhanced by other
features like the type system).
Purity means referential transparency. that means that the programmer has
no
Hello Sebastian,
Thursday, December 10, 2009, 4:27:49 PM, you wrote:
> The killer app for that, IMO, is parallelism these days
btw, are you seen Google App Engine? it's python/java ATM, but i think
that haskell will be ideal fit there. it's all about
computations-in-cloud, or more precisely hosti
On Thu, Dec 10, 2009 at 12:01 PM, John D. Earle wrote:
> This is a matter that I genuinely at the present time do not grasp and I
> am hoping that some of you who are more familiar with the Haskell language
> may be able to help enlighten me. I feel the question to be an important
> one. What ma
On 2009-12-10 07:16, o...@okmij.org wrote:
There are at least two parser combinator libraries that can deal with
*any* left-recursive grammars.
Parser combinators are often used to describe infinite grammars (with a
finite number of parametrised non-terminals). The library described by
Frost et
While going through the Haskell literature I uncovered a passage that said
that, I'm paraphrasing: Complexity was at a premium. The task was very complex
and what was needed to get Haskell to achieve its goals was extraordinary.
This might explain how laziness kept Haskell pure. Everything was
Andrey Popp wrote:
GHC uses select() call in its I/O manager thread. There is ticket
#635(http://hackage.haskell.org/trac/ghc/ticket/635) about replacing
select() to more effective I/O multiplexer.
Thank you, I found this ticket right back 10 minutes ago!
On Thu, Dec 10, 2009 at 3:10 PM, Jo
GHC uses select() call in its I/O manager thread. There is ticket
#635(http://hackage.haskell.org/trac/ghc/ticket/635) about replacing
select() to more effective I/O multiplexer.
On Thu, Dec 10, 2009 at 3:10 PM, Johann Höchtl wrote:
> Hello,
>
> How does Haskell handle sockets? Is it using select
-- Forwarded message --
From: "Bryan O'Sullivan"
Date: Jan 2, 5:32 am
Subject: Will GHC finally support epoll in 2009?
To: Haskell-cafe
On Wed, Dec 31, 2008 at 11:42 AM, Levi Greenspan
wrote:
>> Hence my question - is it likely that GHC will supportepollin 2009?
> Yes. I'm
Hello All
Paul Hudak's 'Conception, evolution, and application of functional
programming languages' gives an account of the motivations, as its
only available to ACM members, here are some lengthy quotes:
"At least a dozen purely functional languages exist along with their
implementations. The ma
Earlier in this thread I wrote "... but like so what." In this letter I hope to
address what I wrote more fully.
The command line option that was found that allows for Haskell source code to
be preprocessed accepts a Haskell source code file as an argument. This file
defines a preprocessor. It
Magnus, thank you. It at least gives me a lead. I can focus on the
significance of laziness and what role it may have on purity. That the
language is lazy gives me no anxiety as I see laziness as natural. I see
Haskell as having proven that laziness is viable; a language can be lazy and
fast an
Hello,
How does Haskell handle sockets? Is it using select or epoll? I ask
especially in regard to
http://groups.google.com/group/erlang-programming/browse_frm/thread/a73efebabf352d19#
Regards,
Johann
___
Haskell-Cafe mailing list
Haskell-Cafe@haske
On Thu, Dec 10, 2009 at 12:01 PM, John D. Earle wrote:
> This is a matter that I genuinely at the present time do not grasp and I am
> hoping that some of you who are more familiar with the Haskell language may
> be able to help enlighten me. I feel the question to be an important one.
> What mate
This is a matter that I genuinely at the present time do not grasp and I am
hoping that some of you who are more familiar with the Haskell language may be
able to help enlighten me. I feel the question to be an important one. What
material benefit does Haskell derive from being a "pure" function
To Underscore or Not to Underscore
Richard O'Keefe and I were privately discussing the relative merits of his
and my approach. We have come to an agreement. It concerns whether or not
hyphens should be replaced with underscores. The following is my response to
his most recent letter:
I do no
"Richard O'Keefe" writes:
>> You mean to parse a - b differently then a-b? You don't have the
>> problem in LISP as AFAIR you use (- a b) but in Haskell it would be a
>> problem.
> Haskell already has this problem with ".", where we generally need
(As somebody pointed out, this is usually unam
83 matches
Mail list logo
