On Tue, Jul 28, 2009 at 10:05:29AM -0700, Ryan Ingram wrote:
On Tue, Jul 28, 2009 at 1:41 AM, Heinrich
Apfelmusapfel...@quantentunnel.de wrote:
While I do agree that qualified names are annoying at times, I think
that type directed name disambiguation is a Pandora's box.
I see where you
Henning Thielemann wrote:
Heinrich Apfelmus schrieb:
Note that there are alternative solution for this particular problem.
For instance, a version of qualified with different semantics will do;
something like this
import Data.List
import sometimes qualified Data.Map as Map
Heinrich Apfelmus schrieb:
Sure, overloading is useful. But to avoid headache in a polymorphic
language, I'd prefer a principled approach to it. Hence, I'm convinced
that there should be only one mechanism for overloading in Haskell;
which is type classes at the moment.
It appears that
Heinrich Apfelmus schrieb:
Note that there are alternative solution for this particular problem.
For instance, a version of qualified with different semantics will do;
something like this
import Data.List
import sometimes qualified Data.Map as Map
Isn't that quite the same as
Ryan Ingram wrote:
Heinrich wrote:
While I do agree that qualified names are annoying at times, I think
that type directed name disambiguation is a Pandora's box.
I see where you are going, but I'm not sure I agree. Let me give an
example from another language with this kind of resolution:
Ketil Malde wrote:
Cale Gibbard writes:
There was a great related idea on #haskell the other day: Make
explicit qualification unnecessary whenever there is a *unique* choice
of module qualifications from those imported which would make the
expression typecheck.
My favorite annoyance is
Jason Dagit da...@codersbase.com wrote:
My biggest fear is that of usability.
If I understand you correctly, then as you change module imports you
change the meaning of the code in potentially non-obvious ways. So
this isn't too different than using unqualified imports and flipping
Cale Gibbard wrote:
There was a great related idea on #haskell the other day: Make
explicit qualification unnecessary whenever there is a *unique* choice
of module qualifications from those imported which would make the
expression typecheck. Ambiguities would still need to be qualified,
but I
There are other possible language extension that may make qualification
easier, Pascal's with statement comes to mind.
http://freepascal.decenturl.com/with-statement-pascal
In Haskell, this would work something like this:
histogram xs =
with Data.Map
foldl' f empty xs
On Tue, Jul 28, 2009 at 1:41 AM, Heinrich
Apfelmusapfel...@quantentunnel.de wrote:
While I do agree that qualified names are annoying at times, I think
that type directed name disambiguation is a Pandora's box.
I see where you are going, but I'm not sure I agree. Let me give an
example from
Ryan == Ryan Ingram ryani.s...@gmail.com writes:
Ryan Along those lines, what about being able to elide class
Ryan names when they can be unambiguously determined from the
Ryan functions defined?
Ryan instance _ [] where fmap = map pure x = [x] fs * xs = [ f
Ryan x | f - fs,
On Jul 29, 2009, at 5:05 AM, Ryan Ingram wrote:
I see where you are going, but I'm not sure I agree. Let me give an
example from another language with this kind of resolution: C++.
Right. That settles it: TDNR is a bad idea.
Half fun and full earnest.
I'm a fan of overloading as done in
On Tuesday 28 July 2009 8:27:53 pm Richard O'Keefe wrote:
Right. That settles it: TDNR is a bad idea.
Half fun and full earnest.
I'm a fan of overloading as done in Ada, but the way
C++ does it has always struck me as a mix of under-useful
and over-complex, and my experience with it in
13 matches
Mail list logo
