On Feb 14, 2009, at 2:29 PM, Luke Palmer wrote:
To me, typeclasses are at their best when you have a real
abstraction to encode.
I agree.
If you are having trouble using a typeclass and need C++-style ad-
hoc overloading, it's likely you are trying to encode a fake
abstraction -- one
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 not a
On Thu, Feb 19, 2009 at 7:09 AM, John A. De Goes j...@n-brain.net wrote:
On Feb 14, 2009, at 2:29 PM, Luke Palmer wrote:
To me, typeclasses are at their best when you have a real abstraction to
encode.
I agree.
If you are having trouble using a typeclass and need C++-style ad-hoc
I agree that type classes should not be used for this purpose. That's
part of the reason I support linguistic overloading -- to stop the
type class abuse.
Type classes should be used, as you say, when there are algorithms
that work for arbitrary members -- i.e. the type class encodes
On 20 Feb 2009, at 3:24 am, John A. De Goes wrote:
It is precisely this abuse of notation which makes, for instance,
statistics textbooks impossible to read (without already knowing
the material).
Hmmm, I don't find statistics books difficult to read.
I'm interested in a technique called
On Feb 19, 2009, at 9:09 AM, John A. De Goes wrote:
Let's try a little test:
1. If the parameter is a tree, what do you think flatten
would do?
I would imagine that it would be join on trees -- i.e. take a tree
of trees and turn it into a tree. But perhaps it would be arbitrarily
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
Take, for example, this function:
f :: [Char] - Char
f [] = chr 0
f (c:cs) = chr (ord c + ord (f cs))
[] is typed as [Char], even though it could be typed in infinitely
many other ways. Demonstrating yet again, that the compiler *does* use
the additional information that it gathers to
John A. De Goes wrote:
Take, for example, this function:
f :: [Char] - Char
f [] = chr 0
f (c:cs) = chr (ord c + ord (f cs))
[] is typed as [Char], even though it could be typed in infinitely many
other ways. Demonstrating yet again, that the compiler *does* use the
additional
On Sat, Feb 14, 2009 at 7:56 AM, John A. De Goes j...@n-brain.net wrote:
Don't overlook the advantages of using familiar operators and names: you
have some intuition about '+' and 'map', so if you see them, then you'll
have some idea what they do (assuming the author is neither stupid nor
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 not a contradiction when the symbol is unambiguously
Colin Adams wrote:
If you have two functions that do two different things, then they
certainly OUGHT to have different names.
Well, they do the same thing but for different arguments; it's like this:
Table is a table of name-value pairs I want to substitute in a tree-like
structure using:
2009/2/13 Daniel Kraft d...@domob.eu:
Colin Adams wrote:
If you have two functions that do two different things, then they
certainly OUGHT to have different names.
Well, they do the same thing but for different arguments; it's like this:
Table is a table of name-value pairs I want to
Hi
Table is a table of name-value pairs I want to substitute in a tree-like
structure using:
substitute :: Table - Tree - Tree
For substituting a single name-value pair I want to define this utitlity
routine so I don't have to construct a Table all the time in the user code:
substitute
On Fri, 2009-02-13 at 11:40 +0100, Daniel Kraft wrote:
Colin Adams wrote:
If you have two functions that do two different things, then they
certainly OUGHT to have different names.
Well, they do the same thing but for different arguments; it's like this:
Table is a table of name-value
Daniel Kraft wrote:
Is this kind of overloading (instead of the polymorphism based
overloading) possible in Haskell? Namely to have two functions with the
same name but different signatures so they could be distinguished by a
call's parameters? I fear not... So I guess I have to name the
Chances are the program you're using to write your e-mails was written
in C++ (or at least C), so don't knock it. :-)
In any case, no one has really addressed the original poster's
question: No, name overloading is not possible in Haskell, and
surprisingly, there are no blocking
On Fri, 13 Feb 2009, John A. De Goes wrote:
In any case, no one has really addressed the original poster's question: No,
name overloading is not possible in Haskell, and surprisingly, there are no
blocking technical issues why this must be the case.
Prefixing names with module names is good
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,
John A. De Goes
Hi
Chances are the program you're using to write your e-mails was written in
C++ (or at least C), so don't knock it. :-)
Firefox (Javascript + C++) and Gmail (Python, so I think I read, no
doubt with C underneath somewhere). However, I am sat writing C++ at
the moment - which I think gives me
Why do you say every name and operator ? Why do you say fully qualified ?
When there is some clash, hiding the offending name or importing
qualified as is
quite satisfying imho.
Thu
2009/2/13 John A. De Goes j...@n-brain.net:
The signal-to-noise ratio with fully qualified names/operators goes
I come from a mathematical background (in which it is quite common to
overload function names and operators in particular), so from my
point of view, the lack of name overloading is a wart on Haskell. That
such a feature would complicate type inference is more a concern to an
On Fri, 2009-02-13 at 11:12 -0700, John A. De Goes wrote:
I come from a mathematical background (in which it is quite common to
overload function names and operators in particular)
Usually `when no ambiguity can arise', no? Plenty of mathematical
practice rests on imprecision and the
On Feb 13, 2009, at 11:23 AM, Jonathan Cast wrote:
Usually `when no ambiguity can arise', no? Plenty of mathematical
practice rests on imprecision and the expectation that the human
reader
will understand what you mean. Haskell has to be understandable by
the
machine (which is less
On Fri, 2009-02-13 at 11:29 -0700, John A. De Goes wrote:
On Feb 13, 2009, at 11:23 AM, Jonathan Cast wrote:
Usually `when no ambiguity can arise', no? Plenty of mathematical
practice rests on imprecision and the expectation that the human
reader
will understand what you mean. Haskell
On Feb 13, 2009, at 11:32 AM, Jonathan Cast wrote:
I believe the last time it was brought up, the proposal was that type
inference should fail on certain typeable terms. That doesn't count.
I'm referring to a rather conservative proposal wherein if there is
one and exactly one definition
On Fri, 2009-02-13 at 11:45 -0700, John A. De Goes wrote:
On Feb 13, 2009, at 11:32 AM, Jonathan Cast wrote:
I believe the last time it was brought up, the proposal was that type
inference should fail on certain typeable terms. That doesn't count.
I'm referring to a rather conservative
Am Freitag, 13. Februar 2009 19:49 schrieb Jonathan Cast:
On Fri, 2009-02-13 at 11:45 -0700, John A. De Goes wrote:
On Feb 13, 2009, at 11:32 AM, Jonathan Cast wrote:
I believe the last time it was brought up, the proposal was that type
inference should fail on certain typeable terms.
On Feb 13, 2009, at 11:49 AM, Jonathan Cast wrote:
It breaks type inference. I explained this at the time. I can
explain
it again:
import Data.List
import Data.Set
import Data.Map
warmFuzzyThingFirstOperation = map
This gives an error currently. Quite properly. But if *any* use of
On Fri, 2009-02-13 at 20:06 +0100, Daniel Fischer wrote:
Am Freitag, 13. Februar 2009 19:49 schrieb Jonathan Cast:
On Fri, 2009-02-13 at 11:45 -0700, John A. De Goes wrote:
On Feb 13, 2009, at 11:32 AM, Jonathan Cast wrote:
I believe the last time it was brought up, the proposal was that
On Fri, 2009-02-13 at 12:06 -0700, John A. De Goes wrote:
On Feb 13, 2009, at 11:49 AM, Jonathan Cast wrote:
It breaks type inference. I explained this at the time. I can
explain
it again:
import Data.List
import Data.Set
import Data.Map
warmFuzzyThingFirstOperation =
Hi Daniel,
A more functional approach might be:
type Substitution = String - Maybe Value
single :: String - Value - Substitution
table :: Table - Substitution
substitute :: Substitution - Tree - Tree
For better performance and a lot more features, you could switch to
type
On Feb 13, 2009, at 12:07 PM, Jonathan Cast wrote:
Exactly! But if it fails, why on earth should any other use of map in
the module succeed?
Because more information is known about other usages of map. Such is
the nature of type inference.
If you wanted to go a step further, then I
On Fri, 2009-02-13 at 12:15 -0700, John A. De Goes wrote:
On Feb 13, 2009, at 12:07 PM, Jonathan Cast wrote:
Exactly! But if it fails, why on earth should any other use of map in
the module succeed?
Because more information is known about other usages of map. Such is
the nature of type
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
Am Freitag, 13. Februar 2009 20:06 schrieb Jonathan Cast:
On Fri, 2009-02-13 at 20:06 +0100, Daniel Fischer wrote:
Am Freitag, 13. Februar 2009 19:49 schrieb Jonathan Cast:
It breaks type inference. I explained this at the time. I can explain
it again:
import Data.List
On Fri, Feb 13, 2009 at 1:29 PM, John A. De Goes j...@n-brain.net wrote:
On Feb 13, 2009, at 11:23 AM, Jonathan Cast wrote:
Usually `when no ambiguity can arise', no? Plenty of mathematical
practice rests on imprecision and the expectation that the human reader
will understand what you mean.
On Feb 13, 2009, at 1:38 PM, Daniel Fischer wrote:
? Well, still easy, we must unify with (a - b) - c - [d], only one
possibility, fine. Or is it? What if we have another 'take' in scope?
Say take :: Int - Set a - Set a ? Oops.
So, where draw the line?
You draw the line exactly when you cannot
Am Freitag, 13. Februar 2009 21:08 schrieb Jonathan Cast:
On Fri, 2009-02-13 at 12:15 -0700, John A. De Goes wrote:
On Feb 13, 2009, at 12:07 PM, Jonathan Cast wrote:
Exactly! But if it fails, why on earth should any other use of map in
the module succeed?
Because more information is
On Fri, 2009-02-13 at 21:57 +0100, Daniel Fischer wrote:
Am Freitag, 13. Februar 2009 21:08 schrieb Jonathan Cast:
On Fri, 2009-02-13 at 12:15 -0700, John A. De Goes wrote:
On Feb 13, 2009, at 12:07 PM, Jonathan Cast wrote:
Exactly! But if it fails, why on earth should any other use of
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 not a contradiction when the symbol is
unambiguously typeable. Do you think math
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 mutually contradictory things.
By definition, it's not a
-- John A. De Goes wrote:
Adding information cannot remove a contradiction from the information
set available to the compiler.
But it can and often does, for example, for [] or 4. What's the type of
either expression without more information?
[] :: [a]
4 :: Num a = a
Do I win something?
John A. De Goes j...@n-brain.net writes:
I'm referring to a rather conservative proposal wherein if there is
one and exactly one definition that allows an expression to type, then
name overloading in the same scope is permitted.
Perhaps this was discussed in the context of records and field
44 matches
Mail list logo
