True. But anyway newtype creates a new type which is not what I'm looking
for. In this case instead of passing a string myAttrName user should pass
constructor as well. And the next step of such simplification will be a
smart constructor attrName? :) And that's all just to show user of that
Hi everyone,
Dumb question about declaring a function and type synonyms.
There are to different declarations of the same function:
attrNames :: String - AttrDict - [String]
attrNames :: AttrClass - AttrDict - AttrNames
First gives you the idea about exact types it expects (except AttrDict for
On Tue, Sep 29, 2009 at 7:40 PM, Olex P hoknam...@gmail.com wrote:
Hi everyone,
Dumb question about declaring a function and type synonyms.
There are to different declarations of the same function:
attrNames :: String - AttrDict - [String]
attrNames :: AttrClass - AttrDict - AttrNames
On Tue, Sep 29, 2009 at 11:40 AM, Olex P hoknam...@gmail.com wrote:
Hi everyone,
Dumb question about declaring a function and type synonyms.
There are to different declarations of the same function:
attrNames :: String - AttrDict - [String]
attrNames :: AttrClass - AttrDict - AttrNames
This idea with new level of abstraction is good but in some cases it can
make things overcomplicated / less efficient. Does that mean leave simple
built-in types as is?
But probably that's all is the matter of habit and style.
Thanks guys
On Tue, Sep 29, 2009 at 8:58 PM, Luke Palmer
On Tue, Sep 29, 2009 at 2:21 PM, Olex P hoknam...@gmail.com wrote:
This idea with new level of abstraction is good but in some cases it can
make things overcomplicated / less efficient. Does that mean leave simple
built-in types as is?
But probably that's all is the matter of habit and style.
Olex P wrote:
This idea with new level of abstraction is good but in some cases it can
make things overcomplicated / less efficient. Does that mean leave simple
built-in types as is?
That's what newtypes are for. A newtype is like a type alias, except
that it is type checked. All newtype
Hi guys,
There is something I think not to fully understand: what are the differences
between these two type synonyms?
type FInt x = Either One x
type FInt = Either One
Their kind is the same, so do they differ or are exactly the same type?
Thanks,
hugo
On Wednesday 26 March 2008, Hugo Pacheco wrote:
Hi guys,
There is something I think not to fully understand: what are the
differences between these two type synonyms?
type FInt x = Either One x
type FInt = Either One
Their kind is the same, so do they differ or are exactly the same type?
On 11 Oct 2007, at 4:06 pm, Tom Davies basically asked for
something equivalent to Ada's
type T is new Old_T;
which introduces a *distinct* type T that has all the operations and
literals of Old_T. In functional terms, suppose there is a function
f :: ... Old_T ... Old_T ...
On Fri, 2007-10-12 at 11:00 +1300, ok wrote:
On 11 Oct 2007, at 4:06 pm, Tom Davies basically asked for
something equivalent to Ada's
type T is new Old_T;
which introduces a *distinct* type T that has all the operations and
literals of Old_T. In functional terms, suppose there is a
Newbie question:
I was wondering the other day if type synonyms might be more useful
if they were more restricted, that is, with the definitions:
type Foo = String
type Bar = String
foo :: Foo
foo = a foo
bar :: Bar
bar = a bar
x :: Foo - ...
x f b = ...only valid for Foo Strings...
both 'x
If you change your type declarations to 'newtype' declarations, I
believe you would get the effect that you want, depending on what you
mean by 'equivalent'. In that case, Foo and Bar would essentially be
strings, but you could not use either of them in a place where the
other is expected, nor
13 matches
Mail list logo
