On 17/01/2019 16:46, Mario Blažević wrote:
On 2019-01-16 3:26 p.m., Philippa Cowderoy wrote:
...
I'd like to thank you for your work - myself I'm infamously unable to
get things done (to the point of unemployability), and I've stayed
off the committee precisely because I can appreciate
On 18/12/2018 18:02, Henrik Nilsson wrote:
Moreover, while there is little risk of confusion when arrow
syntax is used, looking just at names, the fact is that the use of the
distinct "returnA" also sends a similar signal to the reader, and
consequently there is a certain consistency in distinct
On 18/12/2018 07:38, Herbert Valerio Riedel wrote:
Hello Mario et al.,
On Tue, Dec 18, 2018 at 4:17 AM Mario Blažević wrote:
While you're reviewing AMP, please take a bit of time to also comment on
the related new MonadPlus excise proposal at
https://github.com/haskell/rfcs/pull/23
The
of
producing the Haskell Report, I think about how H2010 went almost
nowhere because of how this kind of discussion makes it easy to not
decide on what any particular change to the Report might be, and sort
of wish that we had a Report which was current at all...
On Tue, 18 Dec 2018 at 10:07 Ph
ng this thought about exactly how general the code is, and making
it slightly harder to guess the types at a glance).
It's like while pure and return are equal whenever they would both
typecheck, they've come to have very different connotations about the
surrounding code.
On Tue, Dec 18,
On 18/12/2018 13:41, Henrik Nilsson wrote:
Hi,
Philippa wrote:
> It's a lot easier to estimate ecosystem impact given a switch that'll
> find all the resulting errors and give everyone a chance to fail any
> tests.
Yes, a good point.
But just to be clear, the impact of some changes go well
On 18/12/2018 12:23, Henrik Nilsson wrote:
Hi all,
Well, I am in favour of discussing AMP and MRP separately
Whoops, my bad, wasn't familiar enough to realise my suggestion was
effectively covered by MRP!
I think it might be a legitimate thing to tease do-uses-*> apart from
MRP-as-a-whole
I'm having a moment of fail trying to work out how to leave a comment.
Is there a reason (other than GHC not doing it yet) not to have do
notation use *> instead of >> in line with using the least restrictive
function? I have some otherwise-nice logic programming code that would
actively
with these concerns.
Richard
On Dec 6, 2018, at 4:59 PM, Philippa Cowderoy <mailto:fli...@flippac.org>> wrote:
I lack the energy to contribute to GHC directly, but these guidelines
are far too easy to abuse by someone acting in bad faith and we know
that bad faith actors have b
I lack the energy to contribute to GHC directly, but these guidelines
are far too easy to abuse by someone acting in bad faith and we know
that bad faith actors have been adjacent to our community and acted on
things that have taken place within it.
From where I'm sitting, guidelines like
Good to know!
It's important to keep morale up and do what we can. I imagine that'll
be small details in my case, but there's meaningful modernisation to be
done even if major type system features are still too difficult to
standardise just yet.
On 03/12/2018 21:23, Carter Schonwald wrote:
On 09/10/2018 00:58, Mario Blažević wrote:
On 2018-10-07 11:32 PM, Philippa Cowderoy wrote:
I'd be remiss if I didn't suggest a candidate with a specific
problem, a specific goal and a possible solution to its problem. So,
a modest proposal:
- Standardise OverloadedStrings
On 09/10/2018 00:58, Mario Blažević wrote:
On 2018-10-07 11:32 PM, Philippa Cowderoy wrote:
I'd be remiss if I didn't suggest a candidate with a specific
problem, a specific goal and a possible solution to its problem. So,
a modest proposal:
- Standardise OverloadedStrings
On 05/10/2018 18:05, Simon Peyton Jones via Haskell-prime wrote:
If we want to change that, the first thing is to build a case that greater
standardisation is not just an "abstract good" that we all subscribe to, but
something whose lack is holding us back.
To pick an example, I'm left
On 08/10/2018 02:51, Mario Blažević wrote:
Neither an abstract good nor a good abstraction are something Haskell
has ever shied away from. I don't know if you're actually asking for a
list of "concrete goods"? To start with, every GHC extension that's
added to a standard means:
- one less
You're implicitly arguing that no language should have support for
declaring informal intentions. That's rather more controversial than you
might think and it's worth separating out as a subject.
The fact you cheerfully talk about making return and bind inherently
related via superclass
Agreed - the appropriate means for specifying the type system is
something I'm not sure we have a truly good answer for at this point
alas. We're way past being able to rely on an informal "H-M +
constraints from typeclasses" style description if we want to describe
even extensions that have
In all honesty, Typing Haskell in Haskell is about as far as anyone
should push typechecking and type inference while claiming to still work
in a functional style. I don't think a good GADT pre-spec looks like
functional programming at all, it's a [constraint] logic programming
problem and
I stood up and suggested rebindable record syntax at Anglohaskell
earlier this year, but never got round to posting a proposal. Given the
TDNR discussion, it seems timely to link everyone to what I'd got round
to writing:
http://flippac.org/RebindableRecordSyntax.html
Apologies for the lack
On 03/07/2010 21:11, Stephen Tetley wrote:
For an applicative parser - many is the same combinator as Parsec's
many and some is many1.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 14/06/2010 23:17, Ivan Lazar Miljenovic wrote:
Emmanuel Castroemmanuel.cas...@laposte.net writes:
In practice, g is an optimised version of f when working on large
amount of elements.
It's a list, and map is lazy; not too sure you can get anything more
optimised than that for
Hi everyone. It's just over three months until the traditional time for
Anglohaskell, so I wanted to ask: is anyone willing to step up and run
it this year? We had a volunteer at last year's event, but I've
forgotten who. It was also suggested that emails about the organisation
and planning of
On 10/04/2010 13:57, Yves Parès wrote:
I answered my own question by reading this monad-prompt example:
http://paste.lisp.org/display/53766
But one issue remains: those examples show how to make play EITHER a human
or an AI. I don't see how to make a human player and an AI play SEQUENTIALLY
(to
On 27/03/2010 21:27, Günther Schmidt wrote:
Hi guys (and I mean it),
so, in short, no female haskellers ...
Bare one which sent me an email directly, but it looks like she's not
ready to come out of the closet yet.
And those of us already named for you. And there're a few others around
On 28/03/2010 21:38, Günther Schmidt wrote:
Hi guys,
judging by the responses so far it seems that the gay haskellers have
more balls than the female haskellers to come out of the closet.
Uhm.
So we can expect childish comments for not displaying ourselves on
demand now? Good to know.
On 28/03/2010 22:07, Günther Schmidt wrote:
Hi Fraser, hi all,
one thing I did notice is the total absence of a sense of humor on
this list. The only funny thing that on this list was Don't play with
your monads ...
Yes, us humourless feminists have clearly poisoned the list as a whole.
Luke Palmer wrote:
It's very hard to tell what is going on without more details. If you
*at least* give the ghci session, and possibly the whole code (while
it might be too much to read, it is not to much to load and try
ourselves).
This looks like a monomorphism restriction, which shouldn't
I have some mildly complicated parsing code, that uses parsec to return
a computation (in a state monad) that handles operator precedence - so I
can handle scoped precedence/fixities, much like in Haskell. I just
spent a while bolting on some new features. More time than I'd like, I'd
left it
I do a lot of work with parsers, and want to do more using Applicatives.
That said, I'm finding it a little tedious being forced to use pointless
style for a task that's well-suited to having a few names around. The
idea of an applicative do notation's been kicked around on #haskell a
few
Robert Atkey wrote:
On Fri, 2009-10-09 at 18:06 +0100, Philippa Cowderoy wrote:
This leads us to the bikeshed topic: what's the concrete syntax?
I implemented a simple Camlp4 syntax extension for Ocaml to do this. I
chose the syntax:
applicatively
let x = foo
let y = bar
Nicolas Pouillard wrote:
Excerpts from Edward Kmett's message of Fri Oct 09 20:04:08 +0200 2009:
I have idiom brackets in that toy library already, but the ado syntax is
fairly useful if you want to refer to several intermediate results by name.
To work with idiom brackets you need to
Wifi signups are Anglohaskell are now on the wiki - please add your
details by the 31st of July if you want a wifi account at MS Research
for the Friday. Alternatively, reply to this email with your full name,
institution, country of residence and email address.
The Anglohaskell wiki page can
heavy-weight. We want people to create a login (for the ML) and go
through the ML, just to get wiki access?
Who said anything about creating mailing list logins? Probably the
easiest-for-user thing us a form that sends the mail for them.
--
Philippa Cowderoy fli...@flippac.org
, and it provides OpenID. They may not be exploited for the
OpenID account yet, but I imagine they will be sooner rather than later
- OpenID is more useful to tie in people's existing identities.
--
Philippa Cowderoy fli...@flippac.org
___
Haskell-Cafe
email and let the requester pick who to
send the request to?
A mailing list, possibly attached to a ticketing/queue system, seems a
good idea? If it's just a list, admins should ack when they've added
someone to avoid duplicated effort.
--
Philippa Cowderoy fli...@flippac.org
has an account) have to make
edits on others' behalf, which is a serious inconvenience for both
myself and attendees, as well as something of a barrier to entry.
What's going on, and how can we speed things up?
--
Philippa Cowderoy fli...@flippac.org
.
--
Philippa Cowderoy fli...@flippac.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
!
If anyone wants to offer a talk, help with running the event,
accomodation for haskellers from out of town or some ideas, please feel
free to edit the wiki page appropriately and/or give us a yell in
#anglohaskell.
--
Philippa Cowderoy fli...@flippac.org
who're new or don't remember,
http://www.haskell.org/haskellwiki/AngloHaskell contains links to info
from previous years - the idea's a get-together with lots of talks from
hobbyist to academic, and plenty of chat.
--
Philippa Cowderoy fli...@flippac.org
already?), but IIRC they're part of how GHC handles boxing.
--
Philippa Cowderoy fli...@flippac.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Thu, 2009-03-12 at 14:56 -0700, Bryan O'Sullivan wrote:
However, it's also arguably the case that you shouldn't care about port
number ordering. That smells dodgy to me.
Port ranges aren't that uncommon.
--
Philippa Cowderoy fli...@flippac.org
implementation, possible type system extensions, library
design, all are good subjects.
Anyway, I shouldn't ramble on for too long here - #haskell-in-depth is
open for business and we look forward to seeing you there!
--
Philippa Cowderoy fli...@flippac.org
implementation, possible type system extensions, library
design, all are good subjects.
Anyway, I shouldn't ramble on for too long here - #haskell-in-depth is
open for business and we look forward to seeing you there!
--
Philippa Cowderoy fli...@flippac.org
On Thu, 15 Jan 2009, Lennart Augustsson wrote:
If I see Monoid I know what it is, if I didn't know I could just look
on Wikipedia.
And if you're a typical programmer who is now learning Haskell, this will
likely make you want to run screaming and definitely be hard to
understand. We at least
On Thu, 15 Jan 2009, Andrew Coppin wrote:
I don't know about you, but rather than knowing that joinFoo is associative,
I'd be *far* more interested in finding out what it actually _does_.
A good many descriptions won't tell you whether it's associative though,
and sometimes you need to know -
On Thu, 15 Jan 2009, Andrew Coppin wrote:
I was especially amused by the assertion that existential quantification is
a more precise term than type variable hiding. (The former doesn't even tell
you that the feature in question is related to the type system! Even the few
people in my poll who
On Thu, 15 Jan 2009, John Goerzen wrote:
Several people have suggested this, and I think it would go a long way
towards solving the problem. The problem is: this documentation can
really only be written by those that understand the concepts,
understand how they are used practically, and have
On Fri, 16 Jan 2009, Duncan Coutts wrote:
If you or anyone else has further concrete suggestions / improvements
then post them here now! :-)
Spell out what associativity means and what it means for that operation to
have an identity. List a few examples (stating that they're not all
, but this is not necessarily as neatly functional. If you
start with a deep embedding rather than a shallow one then this isn't
much of a problem even if you find your first attempt was fatally flawed
- the DSL code's just another piece of data.
--
Philippa Cowderoy fli...@flippac.org
On Wed, 12 Nov 2008, Andrew Coppin wrote:
I have a small question...
Given that interactivity is Really Hard to do in Haskell, and that mutable
state is to be strongly avoided, how come Frag exists? (I.e., how did they
successfully solve these problems?)
Because the givens are bull :-)
On Tue, 21 Oct 2008, Andrew Coppin wrote:
If I'm understanding this correctly, Template Haskell is a way to
auto-generate repetative Haskell source code.
Amongst other things, yes. It's also a way to perform repetitive
transformations on code, for example.
The thing that worries me is...
On Wed, 22 Oct 2008, Ariel J. Birnbaum wrote:
This is the part when the Lisp hackers in the audience chuckle, as one of
them
raises a hand and asks What happens when you grow tired of writing TH
boilerplate? Wait for another extension? And what after that?.
To be fair, the TH
On Sun, 19 Oct 2008, Bulat Ziganshin wrote:
Hello Bertram,
Sunday, October 19, 2008, 6:19:31 AM, you wrote:
That's 5 words per elements
... that, like everything else, should be multiplied by 2-3 to
account GC effect
Unless I'm much mistaken, that isn't the case when you're looking
On Sun, 19 Oct 2008, Bulat Ziganshin wrote:
Hello Philippa,
Sunday, October 19, 2008, 3:25:26 PM, you wrote:
... that, like everything else, should be multiplied by 2-3 to
account GC effect
Unless I'm much mistaken, that isn't the case when you're looking at the
minimum heap size
On Thu, 16 Oct 2008, Andrew Coppin wrote:
Actually, I added this to my real parser, and it actually seems to do exactly
what I want. Give it an invalid expression and it immediately pinpoints
exactly where the problem is, why it's a problem, and what you should be doing
instead. Neat!
Yep.
On Wed, 15 Oct 2008, Andrew Coppin wrote:
Suppose this is the top-level parser for my language.
snip
Does anybody know how to fix this irratiting quirk? I can see why it happens,
but not how to fix it.
One of:
expressions = many1 (try expression | myFail)
where myFail = {- eat your way
On Wed, 15 Oct 2008, Andrew Coppin wrote:
Suppose this is the top-level parser for my language. Now suppose the user
supplies an expression with a syntax error half way through it. What I *want*
to happen is for an error to be raised. What *actually* happens is that Parsec
just ignores all
On Wed, 15 Oct 2008, Andrew Coppin wrote:
Philippa Cowderoy wrote:
expressions = do es - many1 expression
eof
return es
Ah - so eof fails if it isn't the end of the input?
eof = notFollowedBy anyChar
(assuming I've got the identifiers right
On Wed, 1 Oct 2008, Don Stewart wrote:
malcolm.wallace:
Just a small nuance to what Don wrote:
so opinion seems to be that LGPL licensed *Haskell
libaries* are unsuitable for any projects you want to ship
commercially, without source code.
Unless you use a
On Sun, 21 Sep 2008, Andrew Coppin wrote:
Actually, none of these things were mentioned. The things people have
*actually* complained to me about are:
- Haskell expressions are difficult to parse.
This is partly an it's not braces, semicolons and function(application)
complaint, though not
introduce a new
complication
How should this be clarified?
For me, existentially-bound variables are rigid works well enough.
They're a somewhat non-obvious case of 'coming from an annotation'
though, and it does warrant mention.
--
Philippa Cowderoy [EMAIL PROTECTED
On Thu, 4 Sep 2008, John Van Enk wrote:
I'm looking for a document describing the differences between Parsec 3 and
Parsec 2. My google-foo must be off because I can't seem to find one. Does
any one know where to find that information?
Unfortunately there isn't currently a good one - in
On Thu, 2008-09-04 at 20:38 +, Duncan Coutts wrote:
On Thu, 2008-09-04 at 19:41 +0100, Philippa Cowderoy wrote:
On Thu, 4 Sep 2008, John Van Enk wrote:
I'm looking for a document describing the differences between Parsec 3 and
Parsec 2. My google-foo must be off because I can't
Oops, forgot to send to list.
On Mon, 2008-09-01 at 01:27 +0100, Philippa Cowderoy wrote:
On Mon, 2008-09-01 at 01:11 +0100, David House wrote:
2008/8/31 Ryan Ingram [EMAIL PROTECTED]:
My proposal is to allow ad-hoc overloading of names; if a name is
ambiguous in a scope, attempt to type
it, and if it's not fixed this
time it may never get fixed.
--
Philippa Cowderoy [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Wed, 20 Aug 2008, Claus Reinke wrote:
I seem to be unable to join the ghc chatroom at irc.freenode.net
at the moment (using Opera). Is that an issue with my irc client or a general
problem?
15:47 Joining chat room...
Disconnected from chat
It's probably on your end one way or
On Wed, 20 Aug 2008, Johannes Waldmann wrote:
On parsers: yes, LL/LR theory and table-based parsers have been
developed for a reason and it's no easy decision to throw them out.
Still, even Parsec kind of computes the FIRST sets?
No, it doesn't. That's not actually possible for monadic
Warning for Andrew: this post explains a new-to-you typed lambda calculus
and a significant part of the innards of Hindley-Milner typing in order to
answer your questions. Expect to bang your head a little!
On Tue, 27 May 2008, Andrew Coppin wrote:
- A function starts out with a polymorphic
On Fri, 16 May 2008, Achim Schneider wrote:
Andrew Coppin [EMAIL PROTECTED] wrote:
Wait... unexpected end of input; expecting [...] end of input [...]
That's just *wrong*...! ;-)
But don't despaire - show us your parser and what it's supposed to
parse, and I'm sure somebody
On Fri, 16 May 2008, Philippa Cowderoy wrote:
Confusing, isn't it? It's almost the right message, too. I'm pretty sure
the misbehaviour's because eof doesn't consume - see what happens if you
put an error message on all of whiteSpace?
It is indeed, and because the error merging code can't
On Fri, 16 May 2008, Achim Schneider wrote:
Philippa Cowderoy [EMAIL PROTECTED] wrote:
On Fri, 16 May 2008, Achim Schneider wrote:
Guess who ran into that with a separate token for
layout-inserted braces?
It can't be me, as I attempted to be as lazy as possible, not going
On Fri, 16 May 2008, Don Stewart wrote:
I don't understand what's ugly about:
go s l x | x m = s / fromIntegral l
| otherwise = go (s+x) (l+1) (x+1)
I suspect you've been looking at low-level code too long. How about the
total lack of domain concepts?
On Fri, 16 May 2008, Achim Schneider wrote:
My problem is that realTopLevel = expr, and that I get into an infinite
recursion, never closing enough parens, never hitting eof.
Have you run into the left-recursion trap, by any chance?
This doesn't work:
expr = do expr; ...
You can cover
On Fri, 16 May 2008, Andrew Coppin wrote:
Obviously most people would prefer to write declarative code and feel secure
that the compiler is going to produce something efficient.
Ultimately the only way to do this is to stick to Einstein's advice - make
things as simple as possible but no
On Sat, 17 May 2008, Achim Schneider wrote:
There's at least one token before any recursion, so I guess not. After
all, it terminates. It's my state that does not succeed in directing
the parser not to mess up, so I'm reimplementing the thing as a
two-pass but stateless parser now.
In most
On Wed, 23 Apr 2008, Johan Tibell wrote:
An interesting question. What is the goal of Haskell'? Is it to, like
Python 3000, fix warts in the language in an (somewhat) incompatible
way or is it to just standardize current practice? I think we need
both, I just don't know which of the two
On Mon, 25 Feb 2008, Ben wrote:
interactive:1:8:
Ambiguous type variable `t' in the constraints:
`Fractional t' arising from a use of `/' at interactive:1:8-10
`Integral t' arising from a use of `^' at interactive:1:7-15
Probable fix: add a type signature that fixes these
On Sun, 24 Feb 2008, Daniel Fischer wrote:
Agreed, and the page with the code may indeed be considered a valid
contribution. However, it certainly would be more valuable if it wasn't bare
code, but also included explanations of the mathematical or programmatical
ideas behind it.
The
On Sun, 24 Feb 2008, Daniel Fischer wrote:
b) posting C/C++ code there indicates that the reason for that is to be a
spoil-sport, not to further learning/thinking Haskell.
No, it doesn't. It provides code that people can port - an obvious step in
building a more complete wiki page.
--
On Sun, 24 Feb 2008, Daniel Fischer wrote:
Hi all,
I try not to be too rude, although I'm rather disgusted.
I know there are several sites out on the web where solutions to PE problems
are given. That is of course absolutely against the sporting spirit of
Project Euler, but hey, not all
On Mon, 18 Feb 2008, TOPE KAREM wrote:
Hello everyone,
I am just learning to program in Haskell, and I found recursion very
interesting.
However, I need to write a recursive function over two lists.
The function must check the elements in the two lists and return an
element that is
On Sun, 17 Feb 2008, Anton van Straaten wrote:
Is there a benefit to reusing a generic Either type for this sort of thing?
For code comprehensibility, wouldn't it be better to use more specific
names? If I want car and cdr, I know where to find it.
It's Haskell's standard sum type, with a
For a while I've been meaning to propose something along the lines of
this class:
class (MonadError m e, MonadError m' e') =
MonadErrorRelated m e m' e' | m - e, m' - e', m e' - m' where
catch' :: m a - (e - m' a) - m' a
rethrow :: m a - (e - e') - m' a
with an example instance
On Sat, 16 Feb 2008, Alan Carter wrote:
I'm a Haskell newbie, and this post began as a scream for help.
Extremely understandable - to be blunt, I don't really feel that Haskell
is ready as a general-purpose production environment unless users are
willing to invest considerably more than
On Thu, 7 Feb 2008, Albert Y. C. Lai wrote:
Is it good or bad to add:
instance (MonadIO m) = MonadIO (ParsecT s u m)
I don't see any reason not to add it - it's not as if we can prevent
people lifting to IO! Good catch.
--
[EMAIL PROTECTED]
A problem that's all in your head is still a
I'm having a little difficulty finding full properties for Parsec3's
Stream class, largely because I don't want to overspecify it with regard
to side-effects. Here's the class:
class Stream s m t | s - t where
uncons :: s - m (Maybe (t,s))
The idea is that:
* unfoldM uncons gives the
On Sun, 3 Feb 2008, Antoine Latter wrote:
Another picky nit:
The monad transformer type is defined as such:
data ParsecT s u m a
= ParsecT { runParsecT :: State s u - m (Consumed (m (Reply s u
a))) }
with the Consumed and reply types as:
data Consumed a = Consumed a
On Sat, 2 Feb 2008, Antoine Latter wrote:
I'm not a fan of parameterizing the Stream class over the monad
parameter `m':
snip
I looked through the sources and I didn't see anywhere where this
parameterization gained anything. As a proof of this I did a
mechanical re-write removing the
On Sat, 2 Feb 2008, Antoine Latter wrote:
To expand on this point, side-effect instances of Stream don't play
nice with the backtracking in Text.Parsec.Prim.try:
import Text.Parsec
import Text.Parsec.Prim
import System.IO
import Control.Monad
type Parser a = (Stream s m Char) =
On Sat, 22 Dec 2007, Cristian Baboi wrote:
On Sat, 22 Dec 2007 16:55:08 +0200, Miguel Mitrofanov
[EMAIL PROTECTED] wrote:
In Haskell I cannot pass a function to a function, only its
expansion.
What do you mean by expansion? Can you clarify this?
f1=\x-x+1
f2=\x-2*x
On Sat, 22 Dec 2007, Cristian Baboi wrote:
On Sat, 22 Dec 2007 17:13:55 +0200, Philippa Cowderoy [EMAIL PROTECTED]
wrote:
Here's a trivial example that does so:
(\x - x) (\x - x)
A lambda calculus classic that doesn't typecheck in Haskell:
(\x - x x) (\x - x x)
Feel free
On Wed, 5 Dec 2007, Simon Peyton-Jones wrote:
Nothing deep. Just that = means so many things that it seemed better
to use a different notation.
How about ==? Only one meaning so far, and that both on the term level and
equivalent to the constraint.
--
[EMAIL PROTECTED]
Ivanova is
On Thu, 18 Oct 2007, PR Stanley wrote:
Hi
Do you trust mathematical materials on Wikipedia?
Paul
To a first approximation - trust but verify.
--
[EMAIL PROTECTED]
I think you mean Philippa. I believe Phillipa is the one from an
alternate universe, who has a beard and programs in BASIC,
On Thu, 18 Oct 2007, [EMAIL PROTECTED] wrote:
Felipe Lessa writes:
On 10/17/07, Andrew Coppin [EMAIL PROTECTED] wrote:
... And it frustrates the hell out of me that 100% of the human
population consider Haskell to be an irrelevant joke language. ...
I feel this way as well,
On Tue, 16 Oct 2007, apfelmus wrote:
Robert Will wrote:
Could someone please summarize the current status and planned time
line for Haskell'?
John Launchbury wrote:
Up to now, the Haskell' effort has been mostly about exploring the
possibilities, to find out what could be in Haskell',
On Sun, 14 Oct 2007, David Stigant wrote:
However, most widely-used programs (ex: web browsers, word processors,
email programs, data bases, IDEs) tend to be 90% IO and 10% (or less)
computation.
No, they don't. They look it, but there's always a fair amount of
computation going on to
On Fri, 12 Oct 2007, Steve Schafer wrote:
On Fri, 12 Oct 2007 13:25:28 -0700, you wrote:
I'm not sure what sanity has to do with it. Presumably we all agree
that it's a good idea for the compiler to know, at compile-time, that
head is only applied to lists. Why not also have the compiler
On Fri, 12 Oct 2007, Steve Schafer wrote:
On Fri, 12 Oct 2007 21:51:46 +0100 (GMT Daylight Time), you wrote:
Which is nevertheless the kind of power you need in order to also be able
to prove precise properties.
We're not talking about POWER, we're talking about SYNTAX.
Which has no
On Wed, 10 Oct 2007, Yitzchak Gale wrote:
I wrote:
Perhaps Data.HashTable is what you are looking
for then?
Jerzy Karczmarczuk wrote:
extract from Data.Hash what you need...
why not try tries?
apfelmus wrote:
There's always Data.Map
Those are log n. I would personally use
On Wed, 10 Oct 2007, Andrew Coppin wrote:
(I'm less sold on whether you really need to learn a particular dialect
well enough to *program* in it...)
If you don't then you won't be able to see how complicated things actually
get done. It's also an important exercise in abstracting things
1 - 100 of 195 matches
Mail list logo
