On Thursday, May 20, 1999 3:58 PM, Kevin Atkinson [SMTP:[EMAIL PROTECTED]]
wrote:
> True ad-hoc overloading can lead to unreadable programs if it is
> misused. However it can make code more readable and concise if used
> properly.
>
I can't disagree with this. But I can object to it. The word
Dear Alex Jacobson,
> For example, how does overloading interact with the module system?
I think these matters are ortogonal. In my view, parameterised modules
should be *the* nice way of grouping related functions/declarations
(modules could also be a form of type: see also "A View on Type
Dec
[EMAIL PROTECTED]:
> While it makes sense to think about
> alternative representations at the outset (and possibly use them
> internally), the absence of a full-featured string processing library
> is more of an obstacle than it's lack of efficiency.
>
> --
> Jón Fairbairn
Exactly. At least 5
At 13:29 +0200 1999/05/20, Jan de Wit wrote:
>I think ad-hoc overloading should be restricted to functions with the same
>number of arguments, otherwise translating Java's
>int sum(int a,int b) { /* obvious code here */ }
>int sum(int a,int b,int c) { /* ditto */ }
>into overloaded Haskell would g
Fergus Henderson writes:
>
> For that kind of thing, you should use type classes and, if need be,
> existential types.
Hmm. Thanks. I misunderstood what "ad hoc polymorphism" is. I thought
ad hoc polymorphism in the new Haskell was accomplished by the use of
existential types.
What is it th
On 20 May, Frank A. Christoph wrote:
>
> > > I would welcome either. However, there is a huge body of code that
> > > assumes strings are lists of chars.
> >
> > Yes, obviously... this is for new programs (which people aren't writing
> > because of Haskell's inefficiency in dealing with strings
On 20 May, Kevin Atkinson wrote:
> Sorry typo. That should be optional.
Is this a job for overloading? I think it would be better to provide
some syntactig sugar and compile-time checks for something like this:
data Argtype = Arg {a::Int, b::Bool, c::Char}
arg = Arg {a = 1, b = True, c = erro
On 20-May-1999, Brian Boutel <[EMAIL PROTECTED]> wrote:
>
> Of course it *can* be done, but *should* it be done?
>
> Uncontrolled overloading means that when you see a function application
> you can't immediately see what function is being applied - you see its
> name but not its semantics, beca
On 19-May-1999, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> Kevin Atkinson wrote:
>
> > I was wondering what the generally felling to allowing true ad-hoc
> > overloading like it is done in C++ in Java but more powerful because
> > functions can also be overloaded by the return value.
>
> Ye
On 19-May-1999, Hans Aberg <[EMAIL PROTECTED]> wrote:
> At 09:36 +0100 1999/05/19, D. Tweed wrote:
> >What I've always understood as the main argument for not allowing
> >overloading by return value still applies in a weaker form in Haskell,
> >namely:
> >
> >int f(int a) & double f(int a) can't b
On 20-May-1999, Nigel Perry <[EMAIL PROTECTED]> wrote:
> > On Wed, 19 May 1999, Kevin Atkinson wrote:
> >
> > > I was wondering what the generally felling to allowing true ad-hoc
> > > overloading like it is done in C++ in Java but more powerful because
> > > functions can also be overloaded by t
The discussion of overloading seems very abstract.
The question is really how overloading interacts with other language features.
For example, how does overloading interact with the module system?
When you import a function from another module, do you need to specify a
type as well as a name? I
Here's my two cents: (Maybe a little obvious)
I think ad-hoc overloading should be restricted to functions with the same
number of arguments, otherwise translating Java's
int sum(int a,int b) { /* obvious code here */ }
int sum(int a,int b,int c) { /* ditto */ }
into overloaded Haskell would give
At 12:29 pm +1200 20/5/99, Brian Boutel wrote:
> In response to a question about ad hoc overloading:
>
> On Thursday, May 20, 1999 9:10 AM, Nigel Perry [SMTP:[EMAIL PROTECTED]] wrote:
> >
> > So to answer the question: it can be done, by a simple existance proof :-)
>
> Of course it *can* be don
In response to a question about ad hoc overloading:
On Thursday, May 20, 1999 9:10 AM, Nigel Perry [SMTP:[EMAIL PROTECTED]] wrote:
>
> So to answer the question: it can be done, by a simple existance proof :-)
>
Of course it *can* be done, but *should* it be done?
Uncontrolled overloading mea
At 19:41 +1200 1999/05/20, Brian Boutel wrote:
>Haskell is a general purpose language. It is not a specialised language for
>doing mathematics. It should not be
>a language that can only be written and understood by specialist experts.
>If we believe that functional languages
>are superior and wan
At 15:02 +1000 1999/05/20, Fergus Henderson wrote:
>The reason that C++ doesn't allow overloading on the return type is that
>this feature was seen as being too complex to implement. The complexity
>is high mainly because C++ allows implicit type conversions, and this
>interacts badly with overlo
> What would be gained by allowing ad hoc overloading? If
> operations on different types have similar meaning
> there is a case for defining a new class. If you have existing
> different functions with similar names you can
> qualify them to avoid the ambiguity. When else would you want
> this fe
Dear Jan,
there is no need to restrict overloading with functions with the same
number of arguments.
In your example:
int sum(int a,int b) { /* obvious code here */ }
int sum(int a,int b,int c) { /* ditto */ }
apply :: Int -> a -> a
apply (n::Int) _ = error "Can't apply intege
> 1) Allowing operational parameters to be used.
Sorry, I don't know what you mean by `operational parameters'.
> 2) Allow record names to be reused. Most langauges have a special
> syntak for record names but haskell does not. Record names are just
> treated as selector functions.
Yes, that
> > I would welcome either. However, there is a huge body of code that
> > assumes strings are lists of chars.
>
> Yes, obviously... this is for new programs (which people aren't writing
> because of Haskell's inefficiency in dealing with strings).
While I think Haskell should also support primi
Brian Boutel writes:
>
> Programs for real world applications and programs which will be
> read by other people (or even by the author some time after writing
> them) must be correct, clear and unambiguous. Unambiguity implies
> not just that the compiler will not be confused, but that Joe
At 9:36 am +0100 19/5/99, D. Tweed wrote:
> On Wed, 19 May 1999, Kevin Atkinson wrote:
>
> > I was wondering what the generally felling to allowing true ad-hoc
> > overloading like it is done in C++ in Java but more powerful because
> > functions can also be overloaded by the return value.
etc.
Olaf Chitil wrote:
>
> > 1) Allowing operational parameters to be used.
>
> Sorry, I don't know what you mean by `operational parameters'.
Sorry typo. That should be optional.
>
> > 2) Allow record names to be reused. Most langauges have a special
> > syntak for record names but haskell doe
24 matches
Mail list logo
