You wouldn't be so confused if you had actually looked at Lato's implementation
and compared it to Oleg's most recent version.
Regards,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes
On Apr 21, 2011, at 6:27 PM, Jason Dagit wrote:
On Thu, Apr 21, 2011 at 8
This is a much cleaner definition of Iteratee and I'm happy to see it.
When are you going to move from your FTP site to Github, by the way? :)
Regards,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes
On Apr 21, 2011, at 12:32 AM, o...@okmij.org wrote:
Daniel
It's not OK and it's an artifact of the weak-typing and ill-defined semantics
that pervade iteratee libraries. It's possible to do a lot of bad stuff,
including binding with an iteratee yielding a remainder without consuming input.
Regards,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http
Now THATs what I'm talking about. Augment such a solution with interruptible
resumable data producers, and I'd have everything I need.
Regards,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes
On Mar 27, 2011, at 10:54 PM, wren ng thornton wrote:
In an ideal
This isn't quite what I'm after. I want to pull chunks on demand (i.e. have
control over both the input and the output). Enumeratees don't allow me to do
that.
Regards,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes
On Mar 27, 2011, at 7:58 PM, John Millikin
,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes
On Mar 26, 2011, at 3:12 PM, wren ng thornton wrote:
On 3/26/11 4:33 PM, John A. De Goes wrote:
4. Iteratees cannot incrementally produce output, it's all or nothing, which
makes them terrible for many real world
On Mar 26, 2011, at 4:24 PM, Mario Blažević wrote:
On 11-03-26 04:33 PM, John A. De Goes wrote:
Out of curiosity, have you looked at the monad-coroutine library? It's a
more generic and IMO much cleaner model, though I wouldn't recommend it as a
replacement because the enumerator
. They provide excellent
control of an input stream to the iteratee, but there is no structure
permitting equivalent control of the output stream.
Regards,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes
On Mar 27, 2011, at 3:22 PM, wren ng thornton wrote:
On 3/27/11 11:38 AM
experimenting with Mealy machines because I think they have more long-term
promise to solve the problems of iteratees.
Regards,
John A. De Goes
Twitter: @jdegoes
LinkedIn: http://linkedin.com/in/jdegoes
On Mar 26, 2011, at 1:03 PM, John Millikin wrote:
On Mar 26, 10:46 am, Michael Snoyman mich
Although you are joking, I've said it before and I'll say it again: server-side
web development is dead. Everything that can be pushed to the client will be.
Which leaves the server mainly for low-level persistence, data analysis, and
anything requiring security.
Static template-driven web
X-Saiga.
Regards,
John
On Dec 8, 2009, at 7:10 AM, Adam Cigánek wrote:
Hello there,
Is there some other parser library, with similar nice API than Parsec,
but which somehow handles left-recursive grammars? Ideally if it has
at least rudimentary documentation and/or tutorial :)
GTDNR is what I really want anyway... whether or not it's possible. :-)
At any given time, importing everything unqualified from every module used by a
typical hs leads only to a handful of ambiguities. While the general case might
be intractable, real-world cases might be trivial.
Regards,
/rails_rumble_92_web_apps_created_in_48_hours.php
[3] The difference in cost is strictly due to libraries. If you had
some killer Haskell libraries at your disposal, I have no doubt you
could do it for less than a Rails developer.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
(JavaScript,
CSS/HTML, Flash) or server-side developers (Java, PHP, Ruby, etc.).
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Oct 10, 2009, at 12:11 PM, John Melesky wrote:
On 2009-10-09, at 7:53 PM, John A. De Goes
transition two companies over to
Haskell, and likely more in the future.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http
a long way towards leveling the playing field.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Oct 7, 2009, at 5:41 PM, Curt Sampson wrote:
On 2009-10-02 09:03 -0600 (Fri), John A. De Goes wrote:
[Haskell] is missing
itself. Agile means more than getting
software out the door quickly, a fact many businesses have yet to learn.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Oct 7, 2009, at 5:49 PM, Curt Sampson wrote:
On 2009-10-02
Exactly, it's things like this that are so frustrating and which
reduce efficiency. In a mature library, you don't need to handle
details like this for yourself.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
the work you and your company have done for Haskell.
What has the Industrial Haskell group done so far? I haven't seen any
announcements. The work I'd be most interested in helping co-sponsor
is Haskell on JVM (biggest bang for the buck).
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution
of its methods.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Oct 8, 2009, at 1:00 PM, Gregory Crosswhite wrote:
Out of curiosity, why do you think that porting Haskell to the JVM
would make such a large difference
system,
network access, randomness, and so on. This could extend the safe
spot to cover much more computational real estate, and effectively
sandbox programs in various ways.
Good idea in theory, in practice I suspect it would lead to
unmanageable boilerplate.
Regards,
John A. De Goes
N-Brain
It's a complex area not a lot of people are working in. Similar
(actually worse than) dependent typing.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Oct 7, 2009, at 3:32 AM, Eugene Kirpichov wrote:
Or you can
This is the right approach to a GUI toolkit.
Note that personally, I believe the details of the presentation should
be separate from Haskell, stored in a separate file that is machine-
friendly, so designers can work in concert and in parallel with
developers.
Regards,
John A. De Goes
N
CSS is a good start by it's beset by all the problems of a 1st
generation presentation language, and is not particularly machine-
friendly.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Oct 6, 2009, at 10:44 AM
That's not gonna happen until when/if Haskell supports name/operator
overloading. There's a scarcity of good symbols/function names and
everyone wants to use them. So naturally, type class abuse follows.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n
With few exceptions, no such thing as a killer server-side app.
The Web 3.0 paradigm is simple: all work except sharing and
persistence of data is done on the client.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Oct 1, 2009, at 12:13 AM, Curt Sampson wrote:
And as far as something like dealing with a changing language and
libraries, the mainstream already has well-established and popular
techniques for doing just: agile development.
A project manager's worst nightmare:
Sorry boss, but we're just
that are of no interest whatsoever to commercial software
developers (new numerical hierarchies, category theory libraries,
etc.), and is missing many key libraries that would be of great
commercial value.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n
for doing just: agile development.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Oct 2, 2009, at 9:03 AM, minh thu wrote:
2009/10/2 John A. De Goes j...@n-brain.net:
On Oct 1, 2009, at 12:13 AM, Curt Sampson wrote
, a manager really likes the
ability to seamlessly move across platforms and architectures without
recompilation. 32 - 64? No problem. Linux - BSD? Sure, why not? Yes,
I'm sure even Amazon, Yahoo, and Google make these kinds of
considerations.
Regards,
John A. De Goes
N-Brain, Inc
for small applications that don't need specialized
libraries (and apparently, for small segments of the financial
industry). For other applications, it usually cannot compete
economically with other, vastly technically inferior languages like
Java.
Regards,
John A. De Goes
N-Brain, Inc
adoption and mass adoption).
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Sep 28, 2009, at 11:01 AM, Jason Dusek wrote:
2009/09/28 John A. De Goes j...@n-brain.net:
Libraries are _everything_...
Not exactly
open source libraries available for the Java platform.
But I do agree on this: the JVM does indeed need a Haskell-like
language.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Sep 27, 2009, at 8:10 PM, Curt Sampson
CAL is interesting, but unfortunately dead, and has no community.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Sep 27, 2009, at 3:38 PM, Peter Verswyvelen wrote:
That's not really true. Just use CAL from the Open
written tiny to small Haskell apps);
4. How many shops are capable of handling Haskell development
maintenance.
These are the kinds of information one needs to make an informed
decision about whether to introduce Haskell into the workplace.
Regards,
John A. De Goes
N-Brain, Inc
worth of
resources at your disposal.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Sep 28, 2009, at 7:49 AM, Curt Sampson wrote:
On 2009-09-28 07:01 -0600 (Mon), John A. De Goes wrote:
And I stand by my statement
, seamless,
and easy Java interop, then it would be a success. Having neither, I'm
not surprised it has no community and development has ceased.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Sep 28, 2009, at 9:59 AM
interop with Java. Haskell is not in this category. It's stuck in a
different world, wholly inaccessible to the masses.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Sep 27, 2009, at 10:16 AM, Curt Sampson wrote
Roundtrip is an important milestone for automated refactoring tools.
Nice work!
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Sep 3, 2009, at 2:57 PM, Niklas Broberg wrote:
Fellow Haskelleers,
I'm pleased
constraints, high-level constructs, and a powerful effect system.
Saying, I don't know exactly how it will look, is quite a bit
different from saying It can't be done. I claim the former.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724
,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Aug 16, 2009, at 2:46 AM, Marcin Kosiba wrote:
Hi,
IMHO, provided with a flexible effect system, the decision on how
to do
read/write operations on files is a matter of libraries
On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote:
On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes j...@n-brain.net
wrote:
You must think I'm arguing for some kind of low-level analog of C,
augmented with an effect system. I'm not. You can't do that.
No, I don't. I think you're arguing
In the presence of _uncontrolled concurrency_, you are correct, but
uncontrolled concurrency is a failed paradigm littered with defective
software.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Aug 16, 2009
. It's only an
illusion that such programs are safe, with or without transformation
of sequential read operations.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
___
Haskell
On Aug 14, 2009, at 9:34 PM, Sebastian Sylvan wrote:
On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes j...@n-brain.net
wrote:
If you don't like the file system, consider mutable memory. An
effect system will tell me I can safely update two pieces of non-
overlapping, contiguous memory
On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote:
2009/08/14 John A. De Goes j...@n-brain.net:
Hmmm, my point (perhaps I wasn't clear), is that different
effects have different commutability properties. In the case
of a file system, you can commute two sequential reads from
two different files
many almost-
impossible-to-debug crashes). I would not want functional languages
to adopt something that's proven to be insanity-inducingly difficult
to use.
Please don't ever bring up C again. You can't do anything interesting
in C.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution
and commute is quite complicated and needs to be baked
into the effect system, rather than being the responsibility of a
lowly developer.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Aug 13, 2009, at 12:24 PM, Sebastian
,
contiguous memory concurrently, even in different threads if the
complexity so justifies it. The IO monad is a poor man's solution to
the problem of effects.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
Thank goodness for a cleaner networking API. I almost chose Haskell's
socket API as an example of what _not_ to do in my series on Good API
Design (http://jdegoes.squarespace.com/journal/2009/5/11/good-api-design-part-3.html
).
Ended up going with Java though. :-)
Regards,
John A. De
with the file system or networking, etc.).
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Aug 13, 2009, at 2:42 AM, Sebastian Sylvan wrote:
On Thu, Aug 13, 2009 at 4:56 AM, John A. De Goes j...@n-brain.net
wrote
is interference from outside programs.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Aug 13, 2009, at 3:45 AM, Jason Dusek wrote:
2009/08/12 John A. De Goes j...@n-brain.net:
The next step is to distinguish between
experiment in that direction.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
the point is that a functional language with a built-
in effect system that captures the nature of effects is pretty damn
cool and eliminates a lot of boilerplate.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
So what, because effect systems might not eliminate *all* boilerplate,
you'd rather use boilerplate 100% of the time? :-)
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Aug 12, 2009, at 3:28 PM, Dan Doel wrote
. Something that dumb monads can't provide.
I haven't played with DDC, but I do believe some new FPL with a
powerful effect system is going to take off in the next 5 years.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
, memory, etc., then you'll be able to do some
extremely powerful parallelization optimization.
But for now providing course grained information on the class to which
an effect belongs is pretty interesting in its own right.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution
Tom is exactly right here. GPL is the kiss of death in the commercial
world. Haskell Platform exists in part to encourage industry use of
Haskell -- and to encourage braindead use of blessed libraries. GPL
libraries have no place in HP.
Regards,
John A. De Goes
N-Brain, Inc
I've spoken in favor of this many times before. But there are many who
think, Every function you write should have a unique name. Talk
about needless clutter.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Jul
JVM 7 has tail calls, and if you don't want to wait for that, goto
works perfectly well for self-recursive functions. Other techniques
can deal with mutual recursion, albeit at the cost of performance.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n
I don't have a source, but I know tail calls have been implemented (in
a patch) and tested, and at the JVM Summit everyone was saying this
was definitely going to be released in JVM 7.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net
That sounds sufficient -- basically, just tell the sponsored developer
where to look to get started, give him a rough idea of what needs to
be done, and let him sort out the rest.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376
I have strong interest in Haskell on the JVM. Not for Android, however.
Seems like every time this topic comes up, the consensus is that it's
not easy to support new targets with GHC, but that work is underway
to make such developments easier.
Regards,
John A. De Goes
N-Brain, Inc
?
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Jun 23, 2009, at 8:16 AM, Simon Peyton-Jones wrote:
Good news about the iPhone port!
There seems to be quite a bit more interest now in supporting
platforms other than
Una Merge does real-time merging and has per user undo. And it can do
lots of stuff that seems darcs-like, though I don't know enough about
darcs to say for sure (e.g. moving a user's own edits after other
edits).
http://www.n-brain.net/una_merge.html
Regards,
John A. De Goes
N
in
this area is clearly the best available). What I'd really like is
something like SMLtoJS (possibly without the reactive library), but
for Haskell. And that does not exist.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
infinite is not as easy, but it
might be sufficient to use lazy evaluation whenever there is a
possibility that a structure might be infinite. Any function exported
to JavaScript must return a finite list.
Annotations would be another way of handling this.
Regards,
John A. De Goes
N-BRAIN
4.3.5.
Haskell doesn't have anything close!
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Apr 25, 2009, at 11:53 AM, Jason Dusek wrote:
I'd like to be able to translate Haskell to JavaScript.
Many Haskell/JS bridges
.
Is there a simple way to download everything from Hackage?
One would need to write a script to do this.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
___
Haskell-Cafe mailing list
for Haskell 98. :-)
Do you think that's fair?
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Apr 23, 2009, at 3:18 AM, Jon Fairbairn wrote:
John A. De Goes j...@n-brain.net writes:
That's absurd. You have no way
if no one (that we know) uses them.
Moreover, the odds that everyone who is using n + k patterns are doing
so only in private is an untestable hypothesis (i.e. unscientific) and
extremely unlikely to be true.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n
Another reason for the 80 character limit: some developers have very
poor eyesight, which can be overcome with large monitors and large
fonts. This won't work if you have to scroll the code.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net
function
equality, you could use it to prove or disprove arbitrary theorems in
mathematics.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Apr 18, 2009, at 9:39 AM, Eugene Kirpichov wrote:
Could you then provide
possible to sell GPL code, only that
it's not commercially viable.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Mar 24, 2009, at 1:27 AM, Jules Bean wrote:
Rick R wrote:
The agreement doesn't specifically prohibit
companies selling the
labors of others. Joe Schmoe who contributed patch #2345235 to fix a
critical bug never sees a cent from RedHat. So your examples don't
support your case as much as you seem to think.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n
complicated enough and you know your way around it, then you can sell
support maintenance. However, those conditions doesn't apply to
consumer software, because consumers don't want complicated software.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net
A JIT compiler can easily know.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Mar 19, 2009, at 10:29 AM, Neil Mitchell wrote:
CSE is tricky and a potential space leak in general. I'd love it if
the compiler could
Workarounds for the lack of linguistic overloading. :-)
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Mar 3, 2009, at 12:52 AM, Lennart Augustsson wrote:
I often hide the Prelude and import my own Prelude which
understand your
question, Why have laziness in Haskell at all?
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Mar 2, 2009, at 6:03 PM, Henning Thielemann wrote:
On Mon, 2 Mar 2009, John Lato wrote:
Hello,
I am
,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 26, 2009, at 1:17 AM, Ketil Malde wrote:
Peter Hercek pher...@gmail.com writes:
Relinking against newer Gtk2Hs versions might not work.
You have the option of recompiling
On Feb 25, 2009, at 7:49 PM, Achim Schneider wrote:
John A. De Goes j...@n-brain.net wrote:
The problem is that PL research is probably not going to stop
evolving in our lifetimes. Yes, that research needs a venue, but why
should it be Haskell? Haskell is a good language and it's time to
start
into newer source code. Add
binary compatibility, and then the only real disadvantage in language
evolution becomes retraining and tools. Which are both significant
costs, to be sure, but not as significant as the former.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http
compatibility.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 26, 2009, at 1:08 PM, Achim Schneider wrote:
John A. De Goes j...@n-brain.net wrote:
What do you mean by progress? I noted before
No, I hate C and will never use it again in my entire life unless
forced to at the point of a gun.
You're point? :-P
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 26, 2009, at 1:17 PM, Jonathan Cast wrote
On Feb 26, 2009, at 1:36 PM, Jonathan Cast wrote:
On Thu, 2009-02-26 at 13:25 -0700, John A. De Goes wrote:
No, I hate C and will never use it again in my entire life unless
forced to at the point of a gun.
Why? Its libraries are far better, its editors are far better [1],
its
compilers
. The more people using Haskell, the more
libraries that will be written, the more bugs that will be fixed, the
more creativity that will be poured into development of libraries and
the language itself.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n
will
find or invent a new target to keep themselves occupied.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 25, 2009, at 5:52 PM, Jonathan Cast wrote:
On Wed, 2009-02-25 at 17:54 -0700, John A. De Goes wrote:
It's
.
Haskell is already behind state-of-the art in PL research and it seems
unlikely to catch up (witness the slow evolution of Haskell' and the
non-existent progress on Haskell2). Of course, I could be wrong.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n
, and if
successful, it would allow you to better focus on the really important
stuff.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 20, 2009, at 4:14 PM, John Meacham wrote:
On Fri, Feb 20, 2009 at 11:52:27PM +0100
can you provide if we get enough people
interested in this?
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 22, 2009, at 7:45 AM, John Meacham wrote:
On Sun, Feb 22, 2009 at 07:25:26AM -0700, John A. De Goes wrote
systems.
Not showing platform-specific packages by default *might* make package
writers more likely to develop cross-platform packages. We've heard
many times someone say, I don't know if it works on Windows, never
really thought of that.
Regards,
John A. De Goes
N-BRAIN, Inc
It's not practical at all. It's monstrously more complicated than C.
It would be much simpler to do it in C and use FFI.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 21, 2009, at 4:55 PM, Sebastian Sylvan
Maybe because one Haskeller generally tries to help another one.
That's what what it means to be a community, no?
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 21, 2009, at 6:47 PM, Jonathan Cast wrote
Unfortunately the proofs in dependently typed languages are
extremely long and tedious to write. Some kind of compiler proofing
tool could ease the pain, but I do not think it has low enough
complexity for a GSoC project.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution
in this area already.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 19, 2009, at 3:35 AM, Alberto G. Corona wrote:
2009/2/19 Wolfgang Jeltsch g9ks1...@acme.softbase.org
Am Donnerstag, 19. Februar 2009 02:22
and function of programs to suggest our intentions to
others.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http
On Feb 14, 2009, at 11:28 PM, wren ng thornton wrote:
John A. De Goes wrote:
On Feb 13, 2009, at 2:11 PM, Jonathan Cast wrote:
The compiler should fail when you tell it two mutually contradictory
things, and only when you tell it two mutually contradictory things.
By definition, it's
structure and associated properties.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 19, 2009, at 7:33 AM, Luke Palmer wrote:
On Thu, Feb 19, 2009 at 7:09 AM, John A. De Goes j...@n-brain.net
wrote:
On Feb 14
On Feb 13, 2009, at 6:31 PM, Krzysztof Skrzętnicki wrote:
On Fri, Feb 13, 2009 at 22:37, John A. De Goes j...@n-brain.net
wrote:
On Feb 13, 2009, at 2:11 PM, Jonathan Cast wrote:
The compiler should fail when you tell it two mutually contradictory
things, and only when you tell it two
to assist with typing.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 13, 2009, at 6:31 PM, Robert Greayer wrote:
-- John A. De Goes wrote:
Adding information cannot remove a contradiction from the
information
1 - 100 of 144 matches
Mail list logo
