, you always have to drag h around.
Regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
to wait on an (uncertain) inclusion into the Haskell
standard, you can implement a small helper function to that effect
yourself; essentially using encodeFloat .
Regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-prime mailing list
library standard.
Regards,
apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
~) where
(.) = ()
Regards,
apfelmus
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
for all eternity :)
Regards,
apfelmus
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
) - a - b
for the /identity functor/. In other words, the current ($) and (.) are
just special cases of the general fmap . Unfortunately, the identity
functor currently can't be overloaded, although I think it would be
unambiguous.
Regards,
apfelmus
are not reported early via the consistency
condition but late when actually constructing terms. The consistency
condition should be enough for soundness (no inconsistent axioms
accepted), but I didn't dwell enough into FD to know such things for sure.
Regards,
apfelmus
, they have to stand some test of time before Haskell' can pick one
of the two (probably the latter).
Regards,
apfelmus
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Iavor Diatchki wrote:
apfelmus wrote:
fundeps are too tricky to get powerful and sound at the same time.
I am not aware of any soundness problems related to functional
dependencies---could you give an example?
http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies
apfelmus wrote:
In the end, I think that applicatively used monads are the wrong
abstraction.
Simon Peyton-Jones wrote:
Can you be more explicit? Monadic code is often over-linearised.
I want to generate fresh names, say, and suddenly I have to name
sub-expressions. Not all sub-expressions
the join.
In any case, I'm *strongly against* further syntactic sugar for monads,
including #1518. The more tiresome monads are, the more incentive you
have to avoid them.
Regards,
apfelmus
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http
the limits of Haskell syntax.
True. Compared to Template Haskell, a preprocessor allows syntactic
extensions but is weak at type correctness.
Regards,
apfelmus
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman
apfelmus suggested to use '=' for this purpose, so that,
wherever monadic generators
are permitted
pattern = expr ~~ pattern - return expr
It was to late when i realized that = is already used as smaller than
or equal to :)
Obviously, the difference between the pattern guard
be
r - lookup m x
Regards,
apfelmus
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
are to be allowed in pattern
matching.
Regards,
apfelmus
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
fixity levels are useful, too. A further
step to complex numbers is not advised because those cannot be ordered.
But ordering of the computable reals is not computable. So it could
cause the compiler to loop during parsing. :)
Actually, that's one of the use cases ;)
Regards,
apfelmus
fixity levels as fixed points of
continuous functionals!
Regards,
apfelmus
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Right q - return p
guard (p 5)
return (p-5)
One last thing is to eliminate fromJust:
f x
| (interesting things here)
should be syntactic sugar for
f x = fromJust $
| (interesting things here)
Regards,
apfelmus
18 matches
Mail list logo
