Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Possible to update Haskell syntax (Tillmann Rendel)
2. Ensuring consistency in typeclass instances? (Colin Paul Adams)
3. Re: Ensuring consistency in typeclass instances? (Brent Yorgey)
4. Not quite another Haskell tutorial, but ... (Janis Voigtlaender)
5. Re: Possible to update Haskell syntax (cm)
6. Re: Possible to update Haskell syntax (Tillmann Rendel)
7. Re: Possible to update Haskell syntax (cm)
8. Re: Possible to update Haskell syntax (Brent Yorgey)
9. Re: Possible to update Haskell syntax (Michael Snoyman)
10. Re: Ensuring consistency in typeclass instances?
(Colin Paul Adams)
----------------------------------------------------------------------
Message: 1
Date: Tue, 25 Nov 2008 12:10:06 +0100
From: Tillmann Rendel <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Possible to update Haskell syntax
To: cm <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
cm wrote:
> In this ideal world, another example would be that [(fun1 3 4) 7] would
> be a valid expression and be a two-element list equivalent to [fun1 3 4,
> 7].
But [(fun1 1 3 4) 7] already is a valid expression, equivalent to [(fun1
1 3 4 7)] and [fun1 1 3 4 7]. The "whitespace operator" can have only
one meaning.
Haskell, being a functional language, makes function application as easy
as possible. Lisp, being a list processing language, makes construction
of lists as easy as possible.
Tillmann
------------------------------
Message: 2
Date: Tue, 25 Nov 2008 17:52:06 +0000
From: Colin Paul Adams <[EMAIL PROTECTED]>
Subject: [Haskell-beginners] Ensuring consistency in typeclass
instances?
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Hello,
I'm just reading through Real World Haskell - chapter 6 (typeclasses).
The definition of Eq is shown, and it mentions that you can define
either one or both of the two classes.
What would happen if I were two define both == and /= for an instance,
in such a way that they were not opposites?
If I were doing this in Eiffel, the function definitions would have
postconditions to state the relationships, and the first execution
would trigger a violation, telling me what was wrong. Is there any
similar facility in Haskell?
--
Colin Adams
Preston Lancashire
------------------------------
Message: 3
Date: Tue, 25 Nov 2008 13:59:13 -0500
From: Brent Yorgey <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Ensuring consistency in typeclass
instances?
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On Tue, Nov 25, 2008 at 05:52:06PM +0000, Colin Paul Adams wrote:
> Hello,
>
> I'm just reading through Real World Haskell - chapter 6 (typeclasses).
>
> The definition of Eq is shown, and it mentions that you can define
> either one or both of the two classes.
>
> What would happen if I were two define both == and /= for an instance,
> in such a way that they were not opposites?
>
> If I were doing this in Eiffel, the function definitions would have
> postconditions to state the relationships, and the first execution
> would trigger a violation, telling me what was wrong. Is there any
> similar facility in Haskell?
Nope. You will just get (possibly) inconsistent results. There are
many other typeclasses like this as well (Functor, Monoid, Monad...)
where the methods are supposed to satisfy certain laws about how they
relate to one another, but Haskell has no way to guarantee this.
A meta-level point is that Haskell (and strongly-typed languages in
general) are all about *static* (compile-time) verification. Having a
program which dynamically (at run-time) checks that certain properties
hold, a la Eiffel, is generally a rather un-Haskellish way of doing
things. As much as possible, I would like to know for sure that if my
Haskell program compiles, it will not exhibit any run-time errors.
So, to check constraints statically rather than dynamically, they must
be put in the type system. But the sorts of constraints you're asking
about (type class laws) often need dependent types (which Haskell
doesn't have) to be expressed elegantly.
-Brent
------------------------------
Message: 4
Date: Tue, 25 Nov 2008 13:37:58 +0100
From: Janis Voigtlaender <[EMAIL PROTECTED]>
Subject: [Haskell-beginners] Not quite another Haskell tutorial, but
...
To: [EMAIL PROTECTED], [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
... I submitted my Habilitation thesis last week. The first few chapters
of it try to give an introduction to Haskell with emphasis on types and
reasoning principles. That might be an interesting read for some, so I
made it accessible at http://wwwtcs.inf.tu-dresden.de/~voigt/habil.pdf.
And yes, the November HCAR will also be coming. Rather soon now that
this cause for delay is out of the way.
Ciao, Janis.
--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:[EMAIL PROTECTED]
------------------------------
Message: 5
Date: Tue, 25 Nov 2008 19:18:10 -0800
From: "cm" <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Possible to update Haskell syntax
To: <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
The logic of making "function application as easy as possible" in Haskell is
compelling, yet I can't help but wonder if an alternate context dependent
syntax would be desribable? Specifically, when inside a pair of brackets
make construction of lists as easy as possible as opposed giving priority to
functions.
There was an earlier reply also about mapping of a "$" construct, but I
don't quite understand that issue yet.
I appreciate the answers by Haskell experts to my somewhat unusual question.
----- Original Message -----
From: "Tillmann Rendel" <[EMAIL PROTECTED]>
To: "cm" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Tuesday, November 25, 2008 3:10 AM
Subject: Re: [Haskell-beginners] Possible to update Haskell syntax
> cm wrote:
>> In this ideal world, another example would be that [(fun1 3 4) 7] would
>> be a valid expression and be a two-element list equivalent to [fun1 3 4,
>> 7].
>
> But [(fun1 1 3 4) 7] already is a valid expression, equivalent to [(fun1 1
> 3 4 7)] and [fun1 1 3 4 7]. The "whitespace operator" can have only one
> meaning.
>
> Haskell, being a functional language, makes function application as easy
> as possible. Lisp, being a list processing language, makes construction of
> lists as easy as possible.
>
> Tillmann
>
------------------------------
Message: 6
Date: Wed, 26 Nov 2008 05:25:07 +0100
From: Tillmann Rendel <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Possible to update Haskell syntax
To: cm <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
cm wrote:
> The logic of making "function application as easy as possible" in
> Haskell is compelling, yet I can't help but wonder if an alternate
> context dependent syntax would be desribable? Specifically, when inside
> a pair of brackets make construction of lists as easy as possible as
> opposed giving priority to functions.
I guess that would be possible, but there are some technical problems,
e.g. what to do with binary operators. Would [a + b c] mean [(+) a (b
c)], [(+) a b, c], [a, (+), b, c], [a, (+), b c] or something else?
Currently, it means the first of these choices.
However, I don't see why it would be a good idea. The obvious
disadvantage is making the syntax more complicated, and more fragile.
For example, you no longer could move an expression inside a brackets
while refactoring your code.
Regarding possible advantages: Do you have a specific use case in mind,
which could be written easier or cleaner with this list syntax?
Tillmann
------------------------------
Message: 7
Date: Tue, 25 Nov 2008 21:09:47 -0800
From: "cm" <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Possible to update Haskell syntax
To: "Tillmann Rendel" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
From: "Tillmann Rendel" <[EMAIL PROTECTED]>
[...]
>
> However, I don't see why it would be a good idea. The obvious disadvantage
> is making the syntax more complicated, and more fragile. For example, you
> no longer could move an expression inside a brackets while refactoring
> your code.
>
> Regarding possible advantages: Do you have a specific use case in mind,
> which could be written easier or cleaner with this list syntax?
I would just like as simple an input syntax as possible (minimum of
punctuation) for interactive use, for both lists and tuples. For instance,
if all entries in a list or tuple are numbers, then I think eliminating the
commas would be convenient and look nicer.
As a use case, one might have
" permute (2 3 4) [7 9 11 0 1 5]", which would be a function which
cyclically permutes elements 2 3 4 of a list.
Regarding your question of what [a + b c] in "altered consciousness syntax"
would resolve to in real world Haskell, it would be [a, (+), b, c]. [(a +
b) c] would resolve to [a + b, c]. The rule would be that whitespace inside
a bracket becomes a comma delimiter. If there are parentheses inside the
bracket, then the expression inside the parentheses reverts to normal
syntax.
These are probably not workable ideas. I'm just annoyed by extra
punctuation which I consider to be visual clutter.
------------------------------
Message: 8
Date: Wed, 26 Nov 2008 10:33:25 -0500
From: Brent Yorgey <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Possible to update Haskell syntax
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
On Tue, Nov 25, 2008 at 09:09:47PM -0800, cm wrote:
> From: "Tillmann Rendel" <[EMAIL PROTECTED]>
> [...]
>>
>> However, I don't see why it would be a good idea. The obvious disadvantage
>> is making the syntax more complicated, and more fragile. For example, you
>> no longer could move an expression inside a brackets while refactoring
>> your code.
>>
>> Regarding possible advantages: Do you have a specific use case in mind,
>> which could be written easier or cleaner with this list syntax?
>
> I would just like as simple an input syntax as possible (minimum of
> punctuation) for interactive use, for both lists and tuples. For instance,
> if all entries in a list or tuple are numbers, then I think eliminating the
> commas would be convenient and look nicer.
I can probably count on one hand the number of times I've had to
literally type in an explicit list of more than three or four elements
-- mostly because Haskell has so many easy ways to algorithmically
construct lists (list comprehensions, Prelude functions like
filter, map, unfoldr, replicate, repeat, etc.). But I can see how
this would be annoying when doing certain things.
Why not use a lightweight custom list-parser function? Something like this:
l = map read . words
Then you could type
permute (2,3,4) (l "7 9 11 0 1 5")
which is still a little extra clutter, but surely much nicer than
typing all the commas.
-Brent
------------------------------
Message: 9
Date: Wed, 26 Nov 2008 07:39:22 -0800
From: "Michael Snoyman" <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Possible to update Haskell syntax
To: cm <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"
On Tue, Nov 25, 2008 at 9:09 PM, cm <[EMAIL PROTECTED]> wrote:
> I would just like as simple an input syntax as possible (minimum of
> punctuation) for interactive use, for both lists and tuples. For instance,
> if all entries in a list or tuple are numbers, then I think eliminating the
> commas would be convenient and look nicer.
>
> As a use case, one might have
> " permute (2 3 4) [7 9 11 0 1 5]", which would be a function which
> cyclically permutes elements 2 3 4 of a list.
>
You might be interested in this article I saw on variadic functions in
Haskell: http://okmij.org/ftp/Haskell/vararg-fn.lhs. The first example shows
how you could create a build function to create a list.
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20081126/ed64a00b/attachment-0001.htm
------------------------------
Message: 10
Date: Wed, 26 Nov 2008 17:04:52 +0000
From: Colin Paul Adams <[EMAIL PROTECTED]>
Subject: Re: [Haskell-beginners] Ensuring consistency in typeclass
instances?
To: Brent Yorgey <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
>>>>> "Brent" == Brent Yorgey <[EMAIL PROTECTED]> writes:
Brent> On Tue, Nov 25, 2008 at 05:52:06PM +0000, Colin Paul Adams wrote:
>> Hello,
>>
>> I'm just reading through Real World Haskell - chapter 6
>> (typeclasses).
>>
>> The definition of Eq is shown, and it mentions that you can
>> define either one or both of the two classes.
>>
>> What would happen if I were two define both == and /= for an
>> instance, in such a way that they were not opposites?
>>
>> If I were doing this in Eiffel, the function definitions would
>> have postconditions to state the relationships, and the first
>> execution would trigger a violation, telling me what was
>> wrong. Is there any similar facility in Haskell?
Brent> Nope. You will just get (possibly) inconsistent results.
Brent> There are many other typeclasses like this as well
Brent> (Functor, Monoid, Monad...) where the methods are supposed
Brent> to satisfy certain laws about how they relate to one
Brent> another, but Haskell has no way to guarantee this.
Brent> A meta-level point is that Haskell (and strongly-typed
Brent> languages in general) are all about *static* (compile-time)
Brent> verification. Having a program which dynamically (at
Brent> run-time) checks that certain properties hold, a la Eiffel,
Brent> is generally a rather un-Haskellish way of doing things.
I don't see why. Eiffel is strongly typed too. But current compiler
technology doesn't necessarily permit us to check all we would like
statically (as you say below).
It seems to me, having read further, that QuickCheck does just this
(and is an answer to my own original question).
But so far I'm only reading. I guess when I try it out I might find
out different.
Brent> So, to check constraints statically rather than
Brent> dynamically, they must be put in the type system. But the
Brent> sorts of constraints you're asking about (type class laws)
Brent> often need dependent types (which Haskell doesn't have) to
Brent> be expressed elegantly.
--
Colin Adams
Preston Lancashire
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 5, Issue 15
****************************************
