Keith Wansbrough wondered:
| Does anyone have an example of a useful data type
| involving negative recursion?
Here is an example straight from practice. If we want to
implement a datatype of predicate logic formulas, it is
convenient to use higher-order syntax:
type Name
= String
da
Thought you'd like to take a break and laugh a little. The following site
is updated daily and has funny news articles, quotes, and sections like Dog
Thoughts and Headlines. It even has a Webcam! I'm sure you'll find
something to enjoy.
http://www.laundryday.com
Spread the smiles.
P.S. Pleas
Janis Voigtlaender <[EMAIL PROTECTED]> writes:
> 2. In a '93 paper, Jan Sparud describes an implementation technique
> for avoiding space leaks when tuples are returned as function
> result, and the values accessed by pattern matching in bindings. The
> paper says this technique (of shorcircuitin
Lars Henrik Mathiesen wrote:
>
> > From: Keith Wansbrough <[EMAIL PROTECTED]>
> >
> > Hi... I'm currently looking at the semantics of recursive data types.
> > One thing that Haskell allows, but the semantics for it is very hairy,
> > is *negatively* recursive data types. That is, data types whe
Malcolm Wallace wrote
> However, if you are indeed correct, then we have an even stranger
> situation:
>
> import A (g)
>
> brings only A.g into scope, but
>
> import A hiding (f)
>
> brings both A.f and A.g into scope! So `hiding' is doing the opposite
> of hiding, and in fact _reve
> From: Keith Wansbrough <[EMAIL PROTECTED]>
> Date: Wed, 04 Jul 2001 18:27:05 +0100
>
> Hi... I'm currently looking at the semantics of recursive data types.
> One thing that Haskell allows, but the semantics for it is very hairy,
> is *negatively* recursive data types. That is, data types w
Hi... I'm currently looking at the semantics of recursive data types.
One thing that Haskell allows, but the semantics for it is very hairy,
is *negatively* recursive data types. That is, data types where the
recursion occurs to the left of a function arrow. For example:
data Neg a b = MkNe
| > Currently, you are permitted to write
| >
| > import A hiding (f)
| > import B as A (f)
| >
| > and this means that everything exported from module A is visible,
| > with the exception that function `f' is overridden by a different
| > definition from module B. Here, a reference to
Malcolm Wallace wrote
> Currently, you are permitted to write
>
> import A hiding (f)
> import B as A (f)
>
> and this means that everything exported from module A is visible,
> with the exception that function `f' is overridden by a different
> definition from module B. Here, a refere
Malcolm Wallace writes:
> I submit that the way `hiding' clauses are ignored is a vestige from
> the days when it was not possible to have overlapped module renamings.
> Now that overlapped renamings are possible, the `hiding' clauses
> should be permitted to take effect.
I think you're right.
I was considering submitting this as a bug report in the Haskell'98
definition, but I don't know whether that is the appropriate
designation or not. In any case, I think it is probably caused by
a hang-over from a previous version of Haskell that never caught up
with the newer features added in '
> 1. Is there something like a strict "let!" for avoiding function
> closures by forcing strict evaluation (to headnormalform) of local
> declarations?
Not that I am aware of. You must do it explicitly with `seq`.
> 2. In a '93 paper, Jan Sparud describes an implementation technique
> for avoid
Hello,
I've got two questions regarding bindings in Haskell:
1. Is there something like a strict "let!" for avoiding function closures by
forcing strict evaluation (to headnormalform) of local declarations?
2. In a '93 paper, Jan Sparud describes an implementation technique for avoiding
space
13 matches
Mail list logo
