I'm as excited about the possibility of a limited form of compile time
evaluation via rewrite rules but I'm a getting a bit worried that no-one
has made any examples where there's an laziness to consider: I really
wouldn't want semantic differences depending on the degree of optimization
I compile
This is the eGroups.com service.
You have been added to the [EMAIL PROTECTED] group.
Here is a welcome message provided by [EMAIL PROTECTED]:
--
Hi there,
You are invited to participate in a discussion about deploying Haskell in real
world web applications. This discussion wil
As far as I remember, this was considered by the original Haskell committee
in 1988.
The argument then against non-linear patterns was that, in the interests of
equational reasoning, it
was desirable to define a function using disjoint cases, and there was no
way of defining,
using a pattern, a
More on rules and properties.
Imagine the improved language Haskell-2. I suggested for its library
(see "basic algebra proposal" on haskell.org)
the classes Additive (with +), Multiplicative (with *).
And it appears now, the implementors think of dealing with the rules.
This arranges *almost*
At 12:25 +0100 1999/05/05, Jerzy Karczmarczuk wrote:
>Operations within a class are not Objects (instances of).
I have noticed that there is a simple principle of abstraction (or generality):
If one wants to achieve a greater generality, allow the operations to be
objects.
It a achieves a great
Egroups has a feature so that when you set up a list, it emails
a set of addresses you select. I had not realized that it worked by
asking for a reply and did not include an alternate method of subscribing.
The result is that anyone on the list who just replies automatically
subscribes the haske
Hans Aberg:
> The thing is though that Haskell fixes the names of the symbols one can use
> in say a group. So if one cannot express a group as a quadruple (G, e, *,
> ^-1), then there is no way from the concept of a group to derive the
> concept of an Abelian group, and then by derivation saying
On Tue, 4 May 1999, Sarah Thompson wrote:
> >I'd hate to think that anyone might misinterpret Alex's comments here.
> >Haskell is not limited to the Win32 platform, and neither are the tools
> >that I think Alex was refering to. Both Hugs and GHC can be used on a
> >range of different platforms,
Just to add to the list of reasons against non-linear patterns:
In term rewriting, they have a number of known negative properties.
- non-overlapping rules may fail to be confluent, but only in the presence
of non-linear patterns (non-orthogonality) [mentioned by Bjorn]
- the disjoint union of
On Wed, 5 May 1999, Kevin Atkinson wrote:
> Normally given the class.
>
> class Listable c b where
> toList :: c -> [b]
>
> to list will never be able to be resolved unless the signature is given
> when toList is called because there is no way to derive the type of b
>from the function call
Term rewriting theory indicates that non-linear patterns should be treated
with care. For instance, a term rewriting systems with a non-linear rule
will in general not have a normalizing rewrite strategy which is sequential,
and nonlinear term rewriting systems are not orthogonal which means they
I should point out that cleaner solution is possible is the Overloaded
resolutions rules are modified a bit.
Normally given the class.
class Listable c b where
toList :: c -> [b]
to list will never be able to be resolved unless the signature is given
when toList is called because there is
Ok I think I found a solution to my problem however it requires a new
data type thus the is not completely transparent to the end user.
However using implicit conversion (which to my knowledge haskell does
not have) it can be made completely transparent.
import qualified Array
data Array_ c ix
13 matches
Mail list logo
