Ryan Ingram wrote:
I maintain that in Haskell, trying to get this same generality often
leads to abuse of the typeclass system for things where the types
should trivially be determined at compile time.
I don't see how that is abuse. The type class system is there for types
which can be (more
Andrew Coppin [EMAIL PROTECTED] wrote:
This quickly boils down to an argument along the lines of
Haskell doesn't support container neutrality very well,
which as I understand it is already a known problem.
In all fairness, this complaint boils down to there is no
container typeclass -- a
The point of having a strongly typed language is so the compiler can
do more work for you. But right now I do a lot of typing (pun not
intended) to appease the compiler.
Let me give you an example:
module Prob where
import qualified Data.Map as M
...
newtype Prob p a = Prob { runProb ::
Am Sonntag, 31. August 2008 20:21 schrieb Ryan Ingram:
The point of having a strongly typed language is so the compiler can
do more work for you. But right now I do a lot of typing (pun not
intended) to appease the compiler.
Let me give you an example:
module Prob where
import qualified
My proposal is to allow ad-hoc overloading of names;
+1, although ...
this could interact badly with the (still common?)
practice of leaving out type declarations.
(of course having allowed this in the first place
is another language design error :-)
when considering language changes
Hello Ryan,
Sunday, August 31, 2008, 10:21:44 PM, you wrote:
Cons: potentially exponential compile time?
yes, and exponential programming complexity growth, going to brain explosion :)
don't forget that OOP languages that supports ad-hoc overloading
doesn't allow to infer types in both
On 2008 Aug 31, at 14:58, Daniel Fischer wrote:
Am Sonntag, 31. August 2008 20:21 schrieb Ryan Ingram:
Do you see it? All those M. just seem dirty to me, especially
because the compiler should be able to deduce them from the types of
the arguments.
Another Con is that the compiler can catch
Well, I was thinking that way when I was starting learning Haskell.
But then I realized that this feature would make code much harder to
read. Suppose you have different thing all named insertWith. You've
got one somewhere in your program; how do YOU know when looking at the
code after a
Ryan Ingram wrote:
My proposal is to allow ad-hoc overloading of names; if a name is
ambiguous in a scope, attempt to type-check the expression against
each name. It is only an error if type-checking against all names
fails. If type-checking succeeds for more than one then the
expression is
On 2008.08.31 11:21:44 -0700, Ryan Ingram [EMAIL PROTECTED] scribbled 1.0K
characters:
The point of having a strongly typed language is so the compiler can
do more work for you. But right now I do a lot of typing (pun not
intended) to appease the compiler.
Let me give you an example:
Gwern Branwen wrote:
I think this would be very nice in GHCi, because there the situation is even
*worse*.
I think we've all experienced importing Data.Map or Data.ByteString and
discovering we need to tediously write it out in *full*, because we can't even
do qualified imports of it!
Erm... Why can't we?
On 1 Sep 2008, at 00:43, Gwern Branwen wrote:
I think we've all experienced importing Data.Map or Data.ByteString
and discovering we need to tediously write it out in *full*, because
we can't even do qualified imports of it!
--
gwern
BND fritz FKS 1071 Face
Oh, sorry, haven't noticed you said ghcI.
On 1 Sep 2008, at 00:59, Miguel Mitrofanov wrote:
Erm... Why can't we?
On 1 Sep 2008, at 00:43, Gwern Branwen wrote:
I think we've all experienced importing Data.Map or Data.ByteString
and discovering we need to tediously write it out in *full*,
On 2008.09.01 01:01:21 +0400, Miguel Mitrofanov [EMAIL PROTECTED] scribbled
0.5K characters:
Oh, sorry, haven't noticed you said ghcI.
On 1 Sep 2008, at 00:59, Miguel Mitrofanov wrote:
Erm... Why can't we?
The GHC API just doesn't support it. See the bug report filed on this issue:
Miguel Mitrofanov wrote:
Suppose you have different thing all named insertWith. You've got one
somewhere in your program; how do YOU know when looking at the code
after a month or so, which one is this?
We already have that situation when classes are involved. If you replace
specialised
Well, I was thinking that way when I was starting learning Haskell.
But then I realized that this feature would make code much harder to
read. Suppose you have different thing all named insertWith. You've
got one somewhere in your program; how do YOU know when looking at the
code after a
On Sun, Aug 31, 2008 at 2:10 PM, Claus Reinke [EMAIL PROTECTED] wrote:
Indeed. Too much overloading can be a lot of trouble.
You can do adhoc overloading already:
{-# LANGUAGE FlexibleInstances #-}
class Adhoc a where adhoc :: a
instance Adhoc ((a-b)-([a]-[b])) where adhoc = map
On Sun, 2008-08-31 at 16:08 -0700, Ryan Ingram wrote:
In particular I do NOT want each function in its own typeclass; the
previous post saying:
foo x = map (bar x)
should be rejected as ambiguous without a type signature somewhere
What type signature do you propose?
It seems as if you're
As to the argument that a sufficiently smart IDE would insert the
M. for me, I think that is flawed. First, there isn't a
sufficiently smart IDE yet,
I do believe there will be.
What we do now is sort of putting down requirements ...
and second, it'd be better for the
type-aware IDE to
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-check the expression against
each name. It is only an error if type-checking against all names
fails. If type-checking succeeds for more than one
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
On Sun, Aug 31, 2008 at 4:21 PM, Jonathan Cast
[EMAIL PROTECTED] wrote:
It seems as if you're proposing that
doubleSet :: Set.Set Int - Set.Set Int
doubleSet = map (*2)
doubleList :: [Int] - [Int]
doubleList :: map (*2)
work, but that you not be allowed to notice that the definitions
On Sun, Aug 31, 2008 at 5:11 PM, David House [EMAIL PROTECTED] wrote:
Here's an example of such a concern: you write the following:
module Amb where
import Data.Map
foo = map
What is the type of `foo'?
Exactly the same as now: it has no type:
amb.hs:4:6:
Ambiguous occurrence `map'
On Sun, Aug 31, 2008 at 11:21:44AM -0700, Ryan Ingram wrote:
[..]
Any thoughts?
-- ryan
Nice problem, nice idea..
Maybe the time is better spend on IDEs than extending the (or all)
compilers..
Right now I've something like this in my vim script files:
function!
On Sun, 2008-08-31 at 19:06 -0700, Ryan Ingram wrote:
On Sun, Aug 31, 2008 at 4:21 PM, Jonathan Cast
[EMAIL PROTECTED] wrote:
It seems as if you're proposing that
doubleSet :: Set.Set Int - Set.Set Int
doubleSet = map (*2)
doubleList :: [Int] - [Int]
doubleList :: map (*2)
25 matches
Mail list logo
