oops, I realized now that my answer did not go to the list.
For the record here is it:
Thanks to everybody for the answers and to Henning Thielemann for the
useful links:
http://haskell.org/haskellwiki/Qualified_names
http://haskell.org/haskellwiki/Category:Style
I agree with apfelmus
Bulat Ziganshin wrote:
Hello Fawzi,
Monday, March 19, 2007, 8:26:33 PM, you wrote:
Maybe I did not express me clearly enough, I think that classes are
useful (and the language that I was speaking of, aldor, has them), but
it is not nice that the only way to have an overloaded function is
David House wrote:
On 19/03/07, Fawzi Mohamed [EMAIL PROTECTED] wrote:
Vectors don't act like numbers, a vector space is not a field, even if
they have some common operations.
As I said in my previous email, this is because Num is too big. We
need to split it down, but there's no sane way of
Hello Fawzi,
Tuesday, March 20, 2007, 1:47:48 PM, you wrote:
That was the reason that is spoke of aldor ( http://www.aldor.com ), as
it has type inference, but yes indeed this makes type inference much
more difficult and undefined in some cases (also haskell extensions make
inference in
Bulat Ziganshin wrote:
Hello Fawzi,
Tuesday, March 20, 2007, 1:47:48 PM, you wrote:
That was the reason that is spoke of aldor ( http://www.aldor.com ), as
ehm http://www.aldor.org
it has type inference, but yes indeed this makes type inference much
more difficult and undefined in
Bulat Ziganshin wrote:
Hello Fawzi,
Tuesday, March 20, 2007, 5:37:45 PM, you wrote:
ambiguous function call at line xxx.
Possible instances are:
f: Int - String - Double - a
f: String - Int - [Int] - a
please explicitly annotate the type to disambiguate
Note that you
The nice thing about Haskell's overloading is that every function,
like f, has a type.
Not two different types, but one general type you can give it. It's
a different approach to overloading.
-- Lennart
On Mar 20, 2007, at 14:37 , Fawzi Mohamed wrote:
Bulat Ziganshin wrote:
Thanks for the long answer David,
David House wrote:
On 17/03/07, Fawzi Mohamed [EMAIL PROTECTED] wrote:
[...]
Surely within a group of related types there'd be no overlapping names
anyway?
yes, but I found out that I would have an overlap with functions that I
wanted to use and function I
On Sat, 17 Mar 2007, Philippa Cowderoy wrote:
On Sat, 17 Mar 2007, Fawzi Mohamed wrote:
So I am wondering how people cope with them, share your opinion,
for me the best thing seem to be to try to use one
module per big type, and then import qualified x as y, what are
good coding
On Mon, 19 Mar 2007, Fawzi Mohamed wrote:
A practice I've seen a lot in small- to mid-sized programs is to have
a Types module that contains definitions of the types used in the
program.
ok I will think about it
I'd avoid that and suggest a more decentralized design, where each module
Quoth Henning Thielemann, nevermore,
On Mon, 19 Mar 2007, Fawzi Mohamed wrote:
A practice I've seen a lot in small- to mid-sized programs is to have
a Types module that contains definitions of the types used in the
program.
ok I will think about it
I'd avoid that and suggest a
On Mar 19, 2007, at 9:56 AM, Henning Thielemann wrote:
On Mon, 19 Mar 2007, Fawzi Mohamed wrote:
A practice I've seen a lot in small- to mid-sized programs is to
have
a Types module that contains definitions of the types used in the
program.
ok I will think about it
I'd avoid that and
Robert Dockins wrote:
On Mar 19, 2007, at 9:56 AM, Henning Thielemann wrote:
On Mon, 19 Mar 2007, Fawzi Mohamed wrote:
A practice I've seen a lot in small- to mid-sized programs is to have
a Types module that contains definitions of the types used in the
program.
ok I will think about
On Mon, 19 Mar 2007, Chris Kuklewicz wrote:
I used a Types module for most of the types in the all haskell regex-*
backends I wrote. Doing anything else tended to lead to cycles, like Rob
mentioned.
This seems to be a result of module/import being the one-true-and-unique-way
to create a
On 19/03/07, Fawzi Mohamed [EMAIL PROTECTED] wrote:
This is is very ugly in my opinion, because for me a type class should
represent something more than just a way to overload, is something is
not a number then it should not have the class Num.
Num is a collection of types whose members can be
David House wrote:
On 19/03/07, Fawzi Mohamed [EMAIL PROTECTED] wrote:
This is is very ugly in my opinion, because for me a type class should
represent something more than just a way to overload, is something is
not a number then it should not have the class Num.
Num is a collection of types
Hello Fawzi,
Monday, March 19, 2007, 8:26:33 PM, you wrote:
Maybe I did not express me clearly enough, I think that classes are
useful (and the language that I was speaking of, aldor, has them), but
it is not nice that the only way to have an overloaded function is to
define a type class
Hello Fawzi,
Monday, March 19, 2007, 1:20:37 PM, you wrote:
Also arrays, inset,... have quite some overlapping.
For array the use of the IArray typeclass kept the things nice also
using Arrays and UArrays together, but adding IntSet to the whole worked
only qualifying, and then I also
On 19/03/07, Fawzi Mohamed [EMAIL PROTECTED] wrote:
Vectors don't act like numbers, a vector space is not a field, even if
they have some common operations.
As I said in my previous email, this is because Num is too big. We
need to split it down, but there's no sane way of doing this without
G'day all.
Quoting David House [EMAIL PROTECTED]:
Surely within a group of related types there'd be no overlapping names
anyway?
[...]
I like to prefix my record accessors with three letters that describe
the type.
I do pretty much that too, but I wouldn't say that I like to do it.
You're
Hi everybody,
I came to haskell recently (one month) and I have now written my first
serious program.
I am still busy improving it, but here is a small report of what I
learned and and my impressions of the language.
I found no show stoppers, but a couple of things that I didn't like much.
*
On Sat, 17 Mar 2007, Fawzi Mohamed wrote:
So I am wondering how people cope with them, share your opinion,
for me the best thing seem to be to try to use one
module per big type, and then import qualified x as y, what are
good coding practices?
Do that and use hierarchical modules if
On 17/03/07, Fawzi Mohamed [EMAIL PROTECTED] wrote:
* namespaces *
First off something that disturbed me but does not seem to be discussed
much are namespaces, or rather the lack of them.
I'm also in the middle of writing a medium-sized program in Haskell,
but my experiences have been
23 matches
Mail list logo
