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" when
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 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. :)
I
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
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
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 4
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 beneath it or
"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
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?
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.
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 propose it
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 application, but Edison's order
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 hard
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 idea
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 are
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 and the
[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 an old
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 clashes
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 use
"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 mechanism
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
| 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'
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 module
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
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/
\__/
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
convention is
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 the
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
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
29 matches
Mail list logo
