Hello!
On Fri, Jun 23, 2000 at 09:52:53AM -0700, Mark P Jones wrote:
> [...]
> Hugs is also quite old; it's core goes back nearly ten years!
> With a more "modern" interface, we might solve the interface
> dilemma by arranging for fully qualified names, types, etc. to
> pop up in a "tooltip" whe
Lennart Augustsson writes:
> > Using `Left' and
> > `Right' for such cases is fundamentally confusing since it is not
> > clear what the meaning of `Left' and `Right' is.
> Well, I don't totally agree. Anyone using Right for Wrong deserves to
> have his/her head examined. :)
Unless you're l
On Tue, 27 Jun 2000, Lennart Augustsson wrote:
> > Using `Left' and
> > `Right' for such cases is fundamentally confusing since it is not
> > clear what the meaning of `Left' and `Right' is.
> Well, I don't totally agree. Anyone using Right for Wrong deserves to
> have his/her head examined. :)
> Using `Left' and
> `Right' for such cases is fundamentally confusing since it is not
> clear what the meaning of `Left' and `Right' is.
Well, I don't totally agree. Anyone using Right for Wrong deserves to
have his/her head examined. :)
-- Lennart
On 24-Jun-2000, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> When an Either result encodes a good result or an error, the error
> should be Left and the good result should be Right. Rationale:
> partially applied type is a good Functor and Monad. Seems to be
> consistently used (MonadEit
Jon Fairbairn wrote:
> Am I alone in thinking that the prelude is desperately in
> need of restructuring?
No. Personally I think it should be got rid of entirely, or rather
trimmed down to the absolute bare minimum required for the syntax.
By the way I think Sven's proposals are thoroughly exce
> > I don't have a clear picture about common practice regarding argument
> > order. Any ideas for simple rules which cover most cases?
>
> For functions that take an old version of something plus some modifiers
> and return a new version, current practice is inconsistent.
Fusion rules (cata-bui
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Sat, 24 Jun 2000 14:34:37 +0200, Sven Panne <[EMAIL PROTECTED]>
>pisze:
>
> > I don't have a clear picture about common practice regarding argument
> > order. Any ideas for simple rules which cover most cases?
>
> For functions that take a
Sven Panne <[EMAIL PROTECTED]> wrote,
> Marcin 'Qrczak' Kowalczyk wrote:
> > stToIO looks better for me. What about declaring that lowercasing
> > the first letter of an abbreviation consisting of only capital
> > letters is realized by lowercasing the whole word? [...]
>
> OK, this makes sense
Sat, 24 Jun 2000 13:10:24 -0400 (EDT), Chris Okasaki <[EMAIL PROTECTED]> pisze:
> I considered this for Edison but rejected in for two reasons.
> First, it constrains the implementation, adding an extra level
> of indirection to every access.
It does not, if extra functions for association maps
> Seems that it would get simpler if association maps were expressed as
> collections of key:=value pairs (with Eq,Ord instances ignoring the
> value component). Association maps would have extra functions, but
> they could be always treated as appropriate collections of such pairs.
>
> Is this i
24 Jun 2000 13:54:49 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> pisze:
> I am trying to make an unified system of classes that would catch
> three Edison's families: sequences, collections and associations.
> And maybe the fourth that does not fit into these and is missing:
> arrays. It's
> Edison uses
> update :: Seq s => Int -> a -> s a -> s a
> adjust :: Seq s => (a -> a) -> Int -> s a -> s a
> for what my guidelines could give
> setElem:: Seq s => s a -> Int -> a -> s a
> updateElem :: Seq s => s a -> Int -> (a -> a) -> s a
>
> Not that I don't like partial applica
Sat, 24 Jun 2000 14:34:37 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
> Please note that at least since the hslibs shipped with GHC 4.06,
> the `update' prefix has been taken by actions (namely updateIORef,
> which has accompanied by an updateSTRef lately). I'm a little bit
> reluctant to propo
Marcin 'Qrczak' Kowalczyk wrote:
> stToIO looks better for me. What about declaring that lowercasing
> the first letter of an abbreviation consisting of only capital
> letters is realized by lowercasing the whole word? [...]
OK, this makes sense and the rule is not much more complicated.
> > e.g
Fri, 23 Jun 2000 23:58:36 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
> stToIO is a misnomer (should be sTToIO),
stToIO looks better for me. What about declaring that lowercasing the
first letter of an abbreviation consisting of only capital letters is
realized by lowercasing the whole word? I
"Mark P Jones" <[EMAIL PROTECTED]> wrote,
> I'm convinced that the only way we will ever have truly
> excellent tools is by working on them together as a
> community.
Very true!
Manuel
Jon Fairbairn <[EMAIL PROTECTED]> wrote,
> > > 4) Qualified infix operators are ugly.
> >
> > Yes, I can't deny that. :)
>
> That seems like a presentation problem. One day an editor
> might be persuaded to display Prelude.+ as (till ex.) + in
> proper size and 'Prelude' in smaller type be
Frank Atanassow <[EMAIL PROTECTED]> wrote,
> Chris Okasaki writes:
> > If anybody has a good argument against using the module system in
> > this context, I would very much like to hear it, because I use the
> > module-based convention almost exclusively in Edison.
>
> To be fair, I can give
On Fri, 23 Jun 2000, Chris Okasaki wrote:
(...)
> Also, I've noticed a tendency to shorten the suffixes as much as
> possible (eg, emptyS or emptyFM), in which case you again quickly
> run into name clashes.
(...)
I agree, that is undesirable. Such names get cryptic and are usually
overlooked when
I *knew* people couldn't resist talking about names! :-) OK, I've
invited you to do this, but more than a dozen mails solely about the
first item of section 1.1.1 were a little bit surprising...
To be more serious: Perhaps I wasn't clear enough about the purpose of
these conventions. What they're
Fri, 23 Jun 2000 14:11:04 -0400 (EDT), Chris Okasaki <[EMAIL PROTECTED]> pisze:
> Suppose you have two *classes* that both need/want the same name.
> For example, you may have a class of sequences and a class of finite
> maps that both want to use an empty method. Do you call one emptyS
> and th
> > These suffixes are doing namespace management, avoiding name clashes
> > between different things that you want to call empty. But Haskell
> > already has a perfectly good language mechanism for doing this --
> > the module system! Why is emptyX preferable to X.empty? The latter
> > convent
23 Jun 2000 16:57:48 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> pisze:
> * [...]
* Overloading by the monad (like MArray) allows adding instances for
derived monads, without explicit lifting on each use.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
On Fri, 23 Jun 2000, Mark P Jones wrote:
[snip]
> Hugs is also quite old; it's core goes back nearly ten years!
> With a more "modern" interface, we might solve the interface
> dilemma by arranging for fully qualified names, types, etc. to
> pop up in a "tooltip" when the user mouses over an id
Fri, 23 Jun 2000 09:05:54 -0400 (EDT), Chris Okasaki <[EMAIL PROTECTED]> pisze:
> These suffixes are doing namespace management, avoiding name clashes
> between different things that you want to call empty. But Haskell
> already has a perfectly good language mechanism for doing this --
> the mod
| 1) Hugs's error messages don't qualify names, so they become
| very difficult to read when you use this convention.
| ...
| ... #1 is the least important in theory, since it's fixable and
| implementation-dependent, but turned out for me to be the most
| important in practice; Hugs' atro
Lennart Augustsson wrote:
> Frank Atanassow wrote:
> > 2) The Prelude doesn't use it.
>
> Well, it doesn't for historical reasons.
Am I alone in thinking that the prelude is desperately in
need of restructuring? Has anyone got any proposals for
nested modules (so we could have Prelude.List.
> "chris" == Chris Okasaki <[EMAIL PROTECTED]> writes:
chris> You've struck a pet peeve of mine. These suffixes are doing namespace
chris> management, avoiding name clashes between different things that you
chris> want to call empty. But Haskell already has a perfectly good language
chris>
Frank Atanassow wrote:
> To be fair, I can give 4 arguments against it.
>
> 1) Hugs's error messages don't qualify names, so they become very difficult
> to read when you use this convention.
That's a totally bogus reason. Tell the implementors to fix Hugs.
> 2) The Prelude doesn't u
Chris Okasaki wrote:
> I've taken a look at these. I'll limit myself to just one comment:
>
> >1.1.1. Constructor names
> >
> >Empty values of type X have the name emptyX, e.g. emptySet.
>
> You've struck a pet peeve of mine. These suffixes are doing namespace
> management, avoiding name cl
Chris Okasaki writes:
> >Empty values of type X have the name emptyX, e.g. emptySet.
>
> You've struck a pet peeve of mine. These suffixes are doing namespace
> management, avoiding name clashes between different things that you
> want to call empty. But Haskell already has a perfectly
I've taken a look at these. I'll limit myself to just one comment:
>1.1.1. Constructor names
>
>Empty values of type X have the name emptyX, e.g. emptySet.
You've struck a pet peeve of mine. These suffixes are doing namespace
management, avoiding name clashes between different things that
After some discussions in the GHC developer mailing lists a small
bunch of conventions around library design emerged. Currently things
mainly concentrate on naming issues (everybody's delight :-), but it
is only meant as a starting point:
http://www.informatik.uni-muenchen.de/~Sven.Panne/hslib
34 matches
Mail list logo
