simonpj wrote:
What do I envy about object-oriented languages? Not state, not subtyping,
not inheritance. But I do envy the power of type-based name resolution.
Here's what I mean:
Programers can explore a library, with the help of an IDE, by typing x., at
which point a list of x's methods
Enrique enriqu...@gmail.com wrote:
So, I think that it was not a good design decision not to use RPN as
the basic notation for Haskell, but it is late for changing it :( .
I don't think you want that anyway. First of all, meet van Laarhoven
lenses [1]:
x ^. field . subfield
This has the
On Mon, Jul 27, 2009 at 04:41:37PM -0400, John Dorsey wrote:
I'm assuming that name resolution is currently independent of type
inference, and will happen before type inference. With the proposal this is
no longer true, and in general some partial type inference will have to
happen before
John Meacham wrote:
On Mon, Jul 27, 2009 at 04:41:37PM -0400, John Dorsey wrote:
I'm assuming that name resolution is currently independent of type
inference, and will happen before type inference. With the proposal this is
no longer true, and in general some partial type inference will have
One issue I have which I haven't seen anyone mention is that it's not
useful with qualified names, by which I mean always importing
qualified. Of course if you have no problem always using qualified
names, the problem this extension is solving doesn't exist. Though I
do like short names I'm not
2009/7/28 Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com:
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
Cale Gibbard cgibb...@gmail.com 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.
[...]
This would mean that
On 28/07/2009, at 6:41 AM, John Dorsey wrote:
I'm assuming that name resolution is currently independent of type
inference, and will happen before type inference. With the proposal
this is
no longer true, and in general some partial type inference will have
to
happen before conflicting
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
Sittampalam, Ganesh wrote:
... it would make it substantially less likely that
subexpressions could be abstracted into a separate declaration without
giving a type signature to fix the type of the new declaration.
OK, then give a type signature to fix the type of
(really, to document) the new
(To be clear, this about Cale's proposal, not simonpj's one)
Johannes Waldmann wrote:
Sittampalam, Ganesh wrote:
... it would make it substantially less likely that subexpressions
could be abstracted into a separate declaration without giving a type
signature to fix the type of the new
While browsing Haskell-Prime I found this:
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
This is not some April Fool's day hoax? Because, it might actually
turn Haskell into a somewhat usable (and marketable) language ...
well, you know what I mean.
Is there 'ghc
Hello Johannes,
Monday, July 27, 2009, 7:58:11 PM, you wrote:
While browsing Haskell-Prime I found this:
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
haskell-prime is future haskell standard now in development and on
this wiki anyone can write his proposals
this wiki anyone can write his proposals [...]
sure, but this anyone is simponpj ...
signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
2009/7/27 Johannes Waldmann waldm...@imn.htwk-leipzig.de:
While browsing Haskell-Prime I found this:
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
This is not some April Fool's day hoax? Because, it might actually
turn Haskell into a somewhat usable (and
Cale Gibbard wrote:
What do people think of this idea? Personally, it really annoys me
whenever I'm forced to give explicit module qualifications, and I
think this would really help. It would also subsume the
DisambiguateRecordFields extension rather handily.
A disadvantage - and this is not
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
2009/7/27 Jules Bean ju...@jellybean.co.uk:
Cale Gibbard wrote:
What do people think of this idea? Personally, it really annoys me
whenever I'm forced to give explicit module qualifications, and I
think this would really help. It would also subsume the
DisambiguateRecordFields extension
On Mon, Jul 27, 2009 at 9:29 AM, Cale Gibbard cgibb...@gmail.com wrote:
2009/7/27 Johannes Waldmann waldm...@imn.htwk-leipzig.de:
While browsing Haskell-Prime I found this:
http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
This is not some April Fool's day
2009/7/27 Jason Dagit da...@codersbase.com:
On Mon, Jul 27, 2009 at 9:29 AM, Cale Gibbard cgibb...@gmail.com wrote:
2009/7/27 Johannes Waldmann waldm...@imn.htwk-leipzig.de:
While browsing Haskell-Prime I found this:
about qualified imports and TDNR:
for x.f to work (as in the proposal),
the name f must be in scope (that is, be imported unqualified)?
That would be bad
(unqualified imports should be discouraged).
In Java, the methods of a type are automatically in scope,
e.g., the .bitCount() works
Cale et al,
I have a concern about the implementation of the proposed
TypeDirectedNameResolution. (I'm not familiar with the internals of any of
the compilers, so it could be that my concern isn't well founded.)
I'm assuming that name resolution is currently independent of type
inference, and
I would find a third meaning for dot in Haskell just a little
bit too many.
Especially with hierarchical modules, Haskell encourages
writing small modules, or at any rate no larger than they
have to be. (SML goes further, of course.) So if we're
doing what the software engineering books say
23 matches
Mail list logo
