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 Ev
ers 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
informat
On Feb 13, 2009, at 6:31 PM, Krzysztof Skrzętnicki wrote:
On Fri, Feb 13, 2009 at 22:37, 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
either expression without more information?
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-cafe
able to use name overloading and
make some programs a lot more readable.
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
In your own subjective opinion, which is not shared by many other
Haskellers, myself included.
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 1:08 PM, Jonathan Cast wrote:
On Fri, 2009-02-13 at
suppose you could see how
warmFuzzyThingFirstOperation is used and if it can be typed in exactly
one way.
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
`map' type-checks, with those imports, why on earth should this one
fail? You don't want to remove a wart from the language, you want to
introduce one!
Umm, no, that would still give an error. See definition of "one and
exactly one".
Regards,
John A. De Goes
N-BRAIN, I
definition that allows an expression to type, then
name overloading in the same scope is permitted.
Aside from exponential performance in pathological (but unlikely)
cases, what issue do you have with such a proposal?
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
ht
Name overloading and type inference are not incompatible -- the issue
has been discussed here before, though I'm too lazy to dig up the
conversation.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-
cern to an
implementor, not to an end-user of Haskell like myself.
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 10:16 AM, Neil Mitchell wrote:
Hi
Chances are the program you're using to write y
The signal-to-noise ratio with fully qualified names/operators goes
way down -- that's the need.
Go take one of your programs and fully qualify every name and every
operator. Doesn't look so pretty then, does it? And it wouldn't be
easy to read, either.
Regards,
Jo
rloading can certainly be abused, but in my opinion, the lack
of it results in more problems than it eliminates.
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 3:43 AM, Neil Mitchell wrote:
Hi
Table
lwiki/Calling_Haskell_from_C
There was a promising thesis project called LambdaVM that allowed you
to compile Haskell to JVM byte codes, but it suffered the same fate as
all thesis projects.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2
an be interpreted and generated by tools, which means that a designer
can work with CSS files without knowing anything about CSS.
Is it perfect? No. But it's a lot better than trying to encode
everything in a single language that only a software developer can
safely work with.
Regards,
John
Nor does it need one: http://www.csszengarden.com/
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 3, 2009, at 10:45 AM, Heinrich Apfelmus wrote:
John A. De Goes wrote:
Layout combinators in the spirit of TeX
ile being simpler. In any case, a simple primitive
grid :: [[Rect a]] -> Rect a
that arranges widgets in a rectangular grid should be enough for GUIs.
Spoken like a true programmer who knows nothing about usability. :-)
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaborat
presentation of that content. The developer writes
the content model and the controller, while UX guys or designers get
to decide how it looks.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 2, 2009, at 9:47
How do you define "layout" in a way that has a "direct an enormous
effect on interaction semantics"???
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 2, 2009, at 4:31 PM, Conal Elliott wr
The size, color, and layout of widgets has no effect on interaction
semantics and is best pushed elsewhere, into a designer-friendly realm
such as CSS.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 2, 2009
The actual presentation and layout of widgets would be better handled
by a DSL such as CSS (which is, in fact, declarative in nature), while
event logic would be best handled purely in Haskell.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net
which unfortunately won't
see the light of day), but they are not functional languages. And for
the foreseeable future, there is one and exactly one scripting
language for the browser, and anyone who wants to use a different
language will have to do so by compiling to JavaScript.
Regards,
ve changed. Haskell -> JavaScript is a much more fruitful
direction to pursue, I think.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Jan 26, 2009, at 10:49 AM, Michael Snoyman wrote:
On Mon, Jan 26, 2009 at 9:37 AM, Jo
ent
resources.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Jan 25, 2009, at 10:54 PM, Michael Snoyman wrote:
I´m working in a web application rather than a web framework. But I
sometimes think about how a complete
hing?)
at first sight I was not able to find Haskell support in the freely
downloadable version. is this available in the commercial version?
On Thu, Jan 22, 2009 at 6:50 PM, John A. De Goes
wrote:
Not that you're looking to switch editors, but if you want something
a little more
Not that you're looking to switch editors, but if you want something a
little more hassle-free:
http://www.n-brain.net/unashots/Haskell/ErrorHighlighting.png
Regards,
John
On Jan 22, 2009, at 10:17 AM, Peter Verswyvelen wrote:
I have a silly problem.
I'm using Emacs with the Haskell
+1 to that
Regards,
John
On Jan 15, 2009, at 4:10 PM, Cale Gibbard wrote:
2009/1/15 Sittampalam, Ganesh :
Lennart Augustsson wrote:
I think the documentation should be reasonably newbie-friendly too.
But that doesn't mean we should call Monoid Appendable.
Appendable is just misleading, sin
On Jan 15, 2009, at 9:31 AM, John Goerzen wrote:
By "pure" do you mean "containing python code only"? I'm looking
through a few, and:
Search for "pure python mysql" or "pure python postgresql" and you'll
see at least two implementations. In addition, there are plenty of
pure Python databa
There's no point wasting development resources on threats that may
never emerge. If attacks become a problem, it can be dealt with then
-- when more information on the nature of the threat is available, so
a better solution can be developed than now (when there is no
information, only spe
On Jan 10, 2009, at 4:11 PM, Donn Cave wrote:
Quoth "John A. De Goes" :
| Take a language like Ruby or Python (or Java, or C#, etc.). The vast
| majority of code written in these languages does not "get down to
the
| C level". When I say, "vast majority", I'
No, it's not HDBC -- which I have not yet tried. I'll tell you what:
I'll give HDBC a try this week and let you know if it's as easy as you
say it is. :-)
Regards,
John
On Jan 10, 2009, at 10:09 AM, John Goerzen wrote:
John A. De Goes wrote:
Hi John,
Take tw
On Jan 9, 2009, at 8:23 AM, John Goerzen wrote:
Well, you pretty much always have to get down to the C level on a *nix
platform at some point, anyhow. You've got to make syscalls
somewhere.
Take a language like Ruby or Python (or Java, or C#, etc.). The vast
majority of code written in the
On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote:
2009/1/9 John A. De Goes :
If you're looking for a project to take on, I would suggest
starting with
the following:
A high-level, type-safe AMQP client written in 100% Haskell, which
provides
a clean way of handling hundreds of u
ur
statements come from your experience, and my statements come from my
experience, and the truth is probably somewhere in between."
Regards,
John
On Jan 9, 2009, at 1:42 PM, John Goerzen wrote:
John A. De Goes wrote:
Hi Austin,
How do you know it's not your experience with
On Jan 8, 2009, at 4:34 PM, Bryan O'Sullivan wrote:
I actually think that we're very close to being in fantastic shape
here.
I think that's Haskell zeal speaking. :-)
Not that I don't appreciate your zeal (I do), and I'm definitely
excited about the stuff you're working on, but we're a long
You must be referring to "erlang-0.1", an alpha release of a package
that impersonates an Erlang node.
Which is surely useful to someone, somewhere, but is not useful to
write a messaging application.
Regards,
John
On Jan 8, 2009, at 4:17 PM, Bryan O'Sullivan wrote:
On Thu, Jan 8, 200
an be processed and used to emit language-specific
code), but in finding a design that works well in Haskell.
Regards,
John
On Jan 8, 2009, at 1:16 PM, Creighton Hogg wrote:
On Thu, Jan 8, 2009 at 2:02 PM, John A. De Goes
wrote:
On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:
You repli
On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote:
The number of applications requiring the implementation of a custom
web
server is an insignificant fraction of the number of applications
requiring a messaging system. I don't think anyone would dispute
Haskell's abi
of course, but in general I view it as a bootstrapping
process leading to pure Haskell libraries -- a crutch you have to live
with until you can afford to pay the price of walking.
Regards,
John
On Jan 8, 2009, at 3:15 PM, John Goerzen wrote:
On Thu, Jan 08, 2009 at 11:14:18AM -0700, John A
Hi Austin,
How do you know it's not your experience with FFI code that isn't
biased? As far as I know, there has been no systematic attempt to
document whether pure Haskell or FFI-based libraries are better
designed and better maintained. Which means your statements come from
your experi
On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:
You replied to someone discussing using Haskell at a CDN to implement
things like web servers by saying that Haskell wasn't suitable for
the task.
That is incorrect. I replied to Achim's message asking for elaboration
on Haskell's unsuitabilit
al of RabbitMQ.
Regards,
John
On Jan 8, 2009, at 11:06 AM, Don Stewart wrote:
wchogg:
On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes
wrote:
Haskell's networking support is very rudimentary. Erlang's is quite
sophisticated. For network intensive applications, especially those
The number of applications requiring the implementation of a custom
web server is an insignificant fraction of the number of applications
requiring a messaging system. I don't think anyone would dispute
Haskell's ability to do low-level, raw networking, of the type that
few people actuall
e to build libraries such as these, but lacking any production
implementations, it's all just theory.
Regards,
John
On Jan 8, 2009, at 8:41 AM, Creighton Hogg wrote:
On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes
wrote:
Haskell's networking support is very rudimentary. Erlang'
Haskell's networking support is very rudimentary. Erlang's is quite
sophisticated. For network intensive applications, especially those
requiring messaging, fault-tolerance, distribution, and so forth,
there's no doubt that Erlang is a more productive choice.
Not because of the language,
outside a quasiquote.
Violating the "principle of least surprise" is one of the most
grievous mistakes language (and interface) designers make.
Regards,
John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]
On Nov 22, 2008, at 9:02 AM, Reiner Pope wrote
Please, oh please, get it into GHC Head! You'll be my hero.
Regards,
John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]
On Oct 27, 2008, at 3:02 PM, Brian Alliet wrote:
On Mon, Oct 27, 2008 at 10:58:11AM +, Simon Peyton-Jones wrote:
Is there an int
It's well known from numerical analysis that you can achieve the best
general behavior by rounding to even in "half" the cases, and rounding
to odd in "half" the cases. It's usually deterministic by looking at
the digit to the right of the round point.
Reg
There's a YHC that can compile to JavaScript, and JavaScript can be
run on Java...
Which means, practically speaking, there is no YHC backend for the JVM.
Regards,
John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]
On Oct 11, 2008, at 11:08 AM, Bran
machine known to man, has a wealth of cross-platform
libraries, and is getting improved support for dynamic and functional
languages (method handles, tail call).
Regards,
John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net
[n minds are better than n-1]
On Oct 11, 2008, at 10:07 AM, David Leimbach
101 - 150 of 150 matches
Mail list logo
