I found Simon Peyton Jones' proposal for guarded equations very
interesting and convincing. However, I see situations where yet more
flexibility in guarded expressions would be useful, and I have included
a suggestion for an extension below. I hope the following is
understandable and makes sense,
Here are some more thoughts about qualifier lists as guards (this time
starting with the less important ones).
Heribert.
1. I agree that my "simplify" example was not so good. In fact, one
could do without nested qualifiers/guards easily because the first
two qualifiers
"s <- Just
Alex Ferguson writes:
> Heribert Schuetz:
>
> > 3. From Alex' example (version 5a) one could have learned that we do not
> >need guards at all, [...]
>
> I don't know if Heribert suggests this in earnest, or as a reductio
> ad absurdum of my suggestion,
I've marked the most interesting part of this mail with "#" signs below.
Alex Ferguson writes:
> Let me rephrase then; it wasn't a convincing example, because the
> non-pattern-guarding version (5a vs. 5) was actually simpler and
> cleaner, but in basically the same style.
Meanwhile it has b
Here comes the example for a non-Maybe monad that can be used in guard
qualifiers. At first, I found it hard to contrive an example that does
not look too contrived, but now the example is about to convince me that
it makes sense to extend guard qualifiers from Maybe to a more general
class.
Thi
Simon L Peyton Jones writes:
> The discussion about pattern guards has raised two interesting and
> (I think) independent questions:
I think these questions are independent to some degree, but not entirely
unrelated. I have written a few sentences on this in an earlier message,
but perhaps the c
erik writes:
> [...]
> instance Read A where
>readsPrec _ s = case s of { "1" -> [(A,"")]; "2" -> [(AA,"")] ; _ ->
> []}
>
> [...]
>
> Test> read (show X{a=A}) :: X
>
> Program error: PreludeText.read: no parse
Try the following (one could write it even nicer, but I tried to change
the
Ralf Hinze writes:
> [...]
> To turn Haskell into a serious language, several
> *extensions* are absolutely necessary:
> [...]
Another area that should be standardized in order to make Standard
Haskell more serious is the interaction with other programming
languages. However, I don't know whether
S. Alexander Jacobson writes:
> > class ODBCTransaction transaction where
> > odbcSelect::transaction -> SQLSelect -> [ODBCResult]
> > odbcChange::transaction -> SQLChange -> IO()
> > [...]
I am afraid that this cannot work properly.
A transaction may consist of several queries and updates. I
This is a suggestion for a more orthogonal list syntax. When I was using
list comprehensions recently, the following happened to me: I wanted to
do something like a map over a list, but the result should contain *two*
members for every member of the argument list. Of course, this can be
written a
Hi,
The appended patch to Hugs98 (to be applied in the src subdirectory)
might be of some help for those who want to do shell scripting in
Haskell. It modifies IO.openFile as follows:
- If the name of a file opened in ReadMode ends in "|", then the part
before the "|" is considered a program a
Hi,
my patch for the use of `popen' is just an ad-hoc solution (aka hack)
that might be useful for people trying to do some shell-scripting in
hugs, before anything more fundamental becomes available. The security
problem (thanks to Fergus Henderson and Carl Witty for pointing it out)
must be dea
Hello,
I'm trying to get a bit deeper understanding about how type classes are
(or could be) implemented.
At least in simple cases it seems possible to eliminate class and
instance declarations from Haskell programs. See the example below.
The idea is that for every class assertion in the type
Hi Mark,
at the end of section 2 of http://www.cse.ogi.edu/~mpj/fds.html you
might want to mention that there is a "standard" work-around whenever a
type constructor is needed but not available: Introduce a newtype.
> import Bits
> class Collects e c where
>empty :: c e
>insert :: e ->
Hi Mark,
thanks a lot for the private lesson. I have downloaded various papers
and started to read them. I'm just done with the Wadler/Blott paper.
I already suspected that I was partly reinventing the wheel with my
translation of type classes. It turned out that my approach is exactly
the same
Hi,
IMHO there is a problem with the choice of the example: As a newcomer to
a programming language you start with simple examples, of course. And
how do you judge the simplicity of an example? By your programming
experience with other languages. So you will use examples that are
simple in, say,
Marcin 'Qrczak' Kowalczyk writes on [EMAIL PROTECTED]:
> Let's imagine that I will want to allow writing scripts to customize
> a hypothetical text editor written in Haskell, similarly as one can
> write S-Lang in jed/slrn or LISP in Emacs. What choices will I have?
> Asking for advices.
Some tim
Jonathan King writes:
> How about:
>
> f |> g |> h |> ...
>
> for [reverse composition], and
>
> g <| f
>
> for "normal" composition?
I like this because it follows the easy-to-remember rule
"Use symmetric glyphs for commutative operations and asymmetric glyphs
for non-commutativ
Hello,
I am currently working on the redesign of some software system that has been
developed in-house at a bank. To get a proof-of-principle implementation up
and running quickly, I decided to use a high-level programming language. I
returned to Haskell, which I used a few years ago in an academi
19 matches
Mail list logo
