2008/4/24 David Menendez <[EMAIL PROTECTED]>:
> On Thu, Apr 24, 2008 at 6:06 PM, Twan van Laarhoven <[EMAIL PROTECTED]> wrote:
> > Cale Gibbard wrote:
> >
> >
> > > Hello,
> > >
> > > In keeping with my small but seemingly extremely controversial
> > > suggestions for changes to the Prelude,
On Wed, Apr 23, 2008 at 6:21 PM, Niklas Broberg
<[EMAIL PROTECTED]> wrote:
> > I'm very suspicious about the power/weight ratio of this change.
> > Normally, for simple value-level stuff like this, provide both options:
> >
> > mapM / forM. =<< >>=
> >
> > So how about, rather than break
On Thu, Apr 24, 2008 at 6:06 PM, Twan van Laarhoven <[EMAIL PROTECTED]> wrote:
> Cale Gibbard wrote:
>
>
> > Hello,
> >
> > In keeping with my small but seemingly extremely controversial
> > suggestions for changes to the Prelude, here's a suggestion which I
> > think is elegant and worth consideri
2008/4/24 Twan van Laarhoven <[EMAIL PROTECTED]>:
> Cale Gibbard wrote:
>
>
> > Hello,
> >
> > In keeping with my small but seemingly extremely controversial
> > suggestions for changes to the Prelude, here's a suggestion which I
> > think is elegant and worth considering for the Haskell' Prelude:
Cale Gibbard wrote:
Hello,
In keeping with my small but seemingly extremely controversial
suggestions for changes to the Prelude, here's a suggestion which I
think is elegant and worth considering for the Haskell' Prelude:
Rename fmap to map (like it was in Haskell 1.4), and define (.) as a
sy
2008/4/24 Dan Doel <[EMAIL PROTECTED]>:
> On Thursday 24 April 2008, Wolfgang Jeltsch wrote:
> > I don't think that this is reasonable. (.) corresponds to the little
> > circle in math which is a composition. So (.) = (<<<) would be far better.
>
> Were I building a library, this might be the
Haskell 2 (whatever it is), does not have the goals that were stated for
Haskell', so I can accept disruptive changes.
Haskell' has (had?) some very clear goals, and breaking every existing
program was not one of them.
On Thu, Apr 24, 2008 at 8:41 PM, Wolfgang Jeltsch <
[EMAIL PROTECTED]> wrote:
On Thursday 24 April 2008, Wolfgang Jeltsch wrote:
> I don’t think that this is reasonable. (.) corresponds to the little
> circle in math which is a composition. So (.) = (<<<) would be far better.
Were I building a library, this might be the direction I'd take things.
They're two incompatible
2008/4/24 Chris Smith <[EMAIL PROTECTED]>:
> 3. Don't get me wrong; I'm definitely not arguing for this ($)
> associativity change, for example, and my objection is the backward
> compatibility. But ultimately, it's more like a combination of
> incompatibility and the lack of a really compelli
2008/4/24 Wolfgang Jeltsch <[EMAIL PROTECTED]>:
> Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard:
> > […]
>
> > Rename fmap to map
>
> This would be really great! There is no point in having a map just for lists
> and a general map for functors since the list map is the same as the lis
Am Donnerstag, 24. April 2008 21:27 schrieb John Meacham:
> On Thu, Apr 24, 2008 at 08:48:15PM +0200, Wolfgang Jeltsch wrote:
> […]
> > I also have some remark: Why not write
> >
> > > class Eq a => Num a = (Additive a, Multiplicative a)
> >
> > instead of
> >
> > > class Num a = Eq a => (Additive
On 2008-04-23, Simon Marlow <[EMAIL PROTECTED]> wrote:
> Johan Tibell wrote:
>> An interesting question. What is the goal of Haskell'? Is it to, like
>> Python 3000, fix warts in the language in an (somewhat) incompatible
>> way or is it to just standardize current practice? I think we need
>> both
Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard:
> […]
> Rename fmap to map
This would be really great! There is no point in having a map just for lists
and a general map for functors since the list map is the same as the list
instance’s functor map. And identifiers with a single lower
On Thu, Apr 24, 2008 at 3:41 PM, Wolfgang Jeltsch
<[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson:
>
> > Haskell has now reached the point where backwards compatibility is something
> > that must be taken very seriously.
>
> Would you be opposed to a Ha
On Thu, Apr 24, 2008 at 09:38:22PM +0200, Wolfgang Jeltsch wrote:
> Am Donnerstag, 24. April 2008 00:43 schrieb Ian Lynagh:
> > […]
>
> > Please see
> > http://www.haskell.org/haskellwiki/Library_submissions
> >
> > > f $$ x = f x
> >
> > Note that this clashes with Text.PrettyPrint
>
> I also do
Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson:
> Haskell has now reached the point where backwards compatibility is something
> that must be taken very seriously.
Would you be opposed to a Haskell 2 which would break lots of things?
> […]
Best wishes,
Wolfgang
_
Am Donnerstag, 24. April 2008 00:43 schrieb Ian Lynagh:
> […]
> Please see
> http://www.haskell.org/haskellwiki/Library_submissions
>
> > f $$ x = f x
>
> Note that this clashes with Text.PrettyPrint
I also doesn’t correspond to $!. We should introduce $$! then.
> […]
Best wishes,
Wolfgang
___
On Thu, Apr 24, 2008 at 08:48:15PM +0200, Wolfgang Jeltsch wrote:
> Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham:
> > On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote:
> > > Is this the most up-to-date description of the proposal?
> > > http://repetae.net/recent/
Am Donnerstag, 24. April 2008 05:13 schrieb Manuel M T Chakravarty:
> […]
> Hence, anything that is *important* to change, we should change now.
Although I can follow your arguments, I thought that the large and disruptive
changes should be done for Haskell 2. If they should really be done now,
Am Mittwoch, 23. April 2008 10:06 schrieb Cale Gibbard:
> […]
> I believe that migrating code will be quite a task regardless of the
> outcome here, but at least for the packages that are in Hackage, the
> system helpfully reports build failures, so we'll know where the
> breakages are, and roughl
Am Mittwoch, 23. April 2008 09:58 schrieb Bulat Ziganshin:
> […]
> my main point is that considering space-less operators as having
> larger priority is our natural habit.
Really??? I‘ve never heard of people using spaceless operators for stating
precedence before. And it contradicts nice type
2008/4/24 Wolfgang Jeltsch <[EMAIL PROTECTED]>:
> Am Mittwoch, 23. April 2008 01:20 schrieb Duncan Coutts:
> > […]
>
>
> > Surely there was a justification to having $ be the opposite
> > associativity from application and not just a different precedence. Does
> > anyone know what it was?
>
>
Am Mittwoch, 23. April 2008 01:20 schrieb Duncan Coutts:
> […]
> Surely there was a justification to having $ be the opposite
> associativity from application and not just a different precedence. Does
> anyone know what it was?
Probably the fact that you can write
> f $ g $ h $ u $ v $ w $ x
in
2008/4/24 Wolfgang Jeltsch <[EMAIL PROTECTED]>:
> Am Dienstag, 22. April 2008 01:58 schrieb John Meacham:
> Why should the fixity of $ being changed? I thought, the reason for $ was
> that you can write a $ b $ c.
Well, the reasons for this were discussed on another thread recently,
but in brie
Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham:
> On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote:
> > Is this the most up-to-date description of the proposal?
> > http://repetae.net/recent/out/classalias.html
>
> There were a few changes proposed in the discussio
Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham:
> On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote:
> > Is this the most up-to-date description of the proposal?
> > http://repetae.net/recent/out/classalias.html
>
> There were a few changes proposed in the discussio
Am Dienstag, 22. April 2008 09:33 schrieb Simon Peyton-Jones:
> […]
> One reason I've failed to do so is because I have not come under enough
> pressure! If I thought there were dozens of people slavering at the chops
> for class aliases, that would put it more firmly on my radar.
I would really
Am Dienstag, 22. April 2008 01:58 schrieb John Meacham:
> […]
> There is also the proposal to change the fixity of '$'.
Why should the fixity of $ being changed? I thought, the reason for $ was
that you can write a $ b $ c.
> […]
Best wishes,
Wolfgang
_
Am Freitag, 18. April 2008 11:54 schrieb Sittampalam, Ganesh:
> Simon Peyton Jones wrote:
> > Not allowing infix functions on the LHS would be a notable simplification.
>
> This would significantly weaken a useful property of Haskell, that
> definitions and uses often share the same concrete syntax
Iavor Diatchki wrote:
I should also point out that if we were to adopt the MBP rule, we
would have to adjust the definition of what pattern bindings mean.
For example, I think that this is how things are desugared at the
moment:
(x,y) = e
becomes
new_var = e
x = case new_var of (v,_) -> v
y = c
On Wed, Apr 23, 2008 at 8:13 PM, Manuel M T Chakravarty
<[EMAIL PROTECTED]> wrote:
> We should be careful about where we break existing code, and we should try to
> support automatic translation of H98 to H' code, but any changes that we do
> not make now will become even more difficult in the fu
Chris Smith wrote:
I'm definitely not arguing for this ($)
associativity change, for example, and my objection is the backward
compatibility. But ultimately, it's more like a combination of
incompatibility and the lack of a really compelling story on why it
should be one way or the other. I
| Iavor:
| the change is valid. I do believe that you can probably work around
| the problem in many situations but the question in my mind is "why
| should we have to work around stuff when we have a system that already
| works?" In other words, what problem do MBPs solve?
...
| Neil:
| Haskell
Manuel wrote:
>> As John Launchbury has said, given Haskell's current rise in
>> popularity, anything that we do not fix with H' will be much harder, if
>> not impossible, to fix in the future.
On Thu, 24 Apr 2008 09:21:41 +0100, Neil Mitchell wrote:
> That is a very good point. Perhaps we're alre
Manuel Chakravarty wrote:
> Care for legacy code is important, but H' will have to break
> backwards compatibility in some places. And especially where
> you already rely on GHC extensions, you can't really expect
> that H' will adopt features that have been available as GHC
> extensions in ex
Hello Neil,
Thursday, April 24, 2008, 12:21:41 PM, you wrote:
> Some questions:
don't forget about most complex part: does this tool will convert
human minds? :D
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskel
Simon Marlow <[EMAIL PROTECTED]> writes:
> * add ""Make $ left associative, like application"
I'm an end user of Haskell rather than an FP researcher, and I'm very
strongly against this change because I don't think of $ as being
function application; I think of it as the "brackets from here to
Hi all,
Manuel wrote:
> As I have argued before on the committee list, I also think we should
> *not* worry about backwards incompatible changes too much in cases
> where a simple automatic translation from H98 to H' code is possible.
Yes, tools can and should help with migration, and we shou
Hi
I think Henrik's criteria are pretty close to perfect.
> As I have argued before on the committee list, I also think we should *not*
> worry about backwards incompatible changes too much in cases where a simple
> automatic translation from H98 to H' code is possible. Even for a large
> proje
Haskell has now reached the point where backwards compatibility is something
that must be taken very seriously.
The motivation behind Haskell' was to bring the most common extensions into
the standard, it was all going to be done in a year.
Haskell' is not a new language, but growing Haskell98 with
40 matches
Mail list logo
