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:  How do you pronounce these operators? (Joel Neely)
   2. Re:  How do you pronounce these operators? (D?niel Arat?)
   3. Re:  How do you pronounce these operators? (Tony Morris)
   4. Re:  Data type definition for a list of elements of
      alternating types? (Brent Yorgey)
   5.  Definition of last: why complicate it? (Dimitri DeFigueiredo)
   6. Re:  Definition of last: why complicate it? (Rudy Matela)


----------------------------------------------------------------------

Message: 1
Date: Fri, 4 Apr 2014 07:14:28 -0500
From: Joel Neely <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] How do you pronounce these operators?
Message-ID:
        <CAEEzXAjsaNLXwOnP-Wrx92DSArj-YZv3_yN=x-zvzjbkjm_...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

As somewhat of an outsider (background in Math, working in the software
field), I find this topic a fascinating illustration of differences in
optimization.

Math (inclusive of statistics and theoretical physics) and computing
(inclusive of IT and applications programming) seem to be two of the fields
that have the greatest need for constant definition of new terms,
frequently on-the-fly in support of a larger goal. (I'm excluding the
legal, political, and marketing fields, for reasons best explained by Edwin
Newman in _Strictly_Speaking_.)

The mathematical approach optimizes for economy of writing/presentation,
favoring single-letter, context-sensitive variable names and a
typographer's paradise of symbols and alphabetic variations. Anecdotes
abound of the specialist who finds papers from a different specialty to be
cryptic.

Computing, especially of the commercial variety, tends to optimize for
recognition/hinting for the first-time or infrequent reader, with a bias
toward semantic naming, metaphor, and the palette of the QWERTY-based
keyboard. Anecdotes abound of the complex agglutination of naming patterns
in enterprise-focused frameworks.

I agree with the observation that standardizing some idiomatic,
natural-language verbalizations would tend to help bridge the gap between
those two cultures (hints toward C.P. Snow intended).

To use examples from this thread, verbalizing <*> as "apply" seems to
bridge those two optimizations, with "ap" betraying the mathematical style
of compression over obviousness, and the rest ("spaceship", etc.) showing a
hacker-style love of humor and inside-jokes that is gratifying to the
insiders but off-putting to outsiders/novices.

Each of the optimizations above is legitimate and valued by its community;
insensitivity to those cultural issues will likely continue to reinforce
the separation.

The interesting question to me is whether that's what each community
wants.


On Thu, Apr 3, 2014 at 8:32 PM, Tony Morris <[email protected]> wrote:

>  On 04/04/14 03:28, Kim-Ee Yeoh wrote:
>
>
> On Wed, Apr 2, 2014 at 6:08 AM, John M. Dlugosz 
> <[email protected]>wrote:
>
>> I'm having some difficult reading because I don't have "names" for many
>> of the operators, such as <*>.  I know that >>= is pronounced "bind", but
>> what about the others?  Is there some common consensus, a list somewhere,
>> or at least the proper mathematical names to serve as a starting point?
>
>
>  Did you try a search? There are links out there.
>
>  But it's true that a search will only get you so far. I think what we
> don't have enough is idiomatic English coupled to idiomatic Haskell.
>
>  It's like a proof/program of a proposition in Euclidean geometry. One
> just gets it visually and doesn't really bother with verbalizing on the
> tongue.
>
>  Provide a code fragment here, and folks will help you with it.
>
> -- Kim-Ee
>
>
> _______________________________________________
> Beginners mailing 
> [email protected]http://www.haskell.org/mailman/listinfo/beginners
>
>  I have heard the following for (<*>)
>
> * angle butt
> * spaceship
> * apply
> * ap
> * angry eye
>
>
> --
> Tony Morrishttp://tmorris.net/
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>


-- 
Beauty of style and harmony and grace and good rhythm depend on simplicity.
- Plato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.haskell.org/pipermail/beginners/attachments/20140404/582744ae/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 4 Apr 2014 14:40:26 +0200
From: D?niel Arat? <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] How do you pronounce these operators?
Message-ID:
        <cahvkd2jryvbmgxa7m7leh1csfsingl_b1zb6+9fbr55cerh...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I call (>>) "proceed". Not canonical or anything.

Daniel


------------------------------

Message: 3
Date: Sat, 5 Apr 2014 02:24:38 +1300
From: Tony Morris <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] How do you pronounce these operators?
Message-ID:
        <cajf6usg8lyt5wu8dzwr0h1m4eyx5b6q0vjjbobsutmwdjqm...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

 When instructing, I use the term "apply" for many reasons. I highly
recommend this term.


On Sat, Apr 5, 2014 at 1:40 AM, D?niel Arat? <[email protected]> wrote:

> I call (>>) "proceed". Not canonical or anything.
>
> Daniel
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.haskell.org/pipermail/beginners/attachments/20140405/aba2c3d6/attachment-0001.html>

------------------------------

Message: 4
Date: Fri, 4 Apr 2014 12:19:20 -0400
From: Brent Yorgey <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] Data type definition for a list of
        elements of alternating types?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Ah, yes, having a nonempty AltList and moving Empty to BiList is a
good idea.  You still do need two different constructors BA and BB,
but yes, overall this seems like a nice way to encode things.

Exercise: write a conversion function

  fromList :: [Either a b] -> Maybe (BiList a b)

which returns Just when the input list really is alternating, and
Nothing otherwise.

-Brent

On Thu, Apr 03, 2014 at 10:04:04PM -0400, Jacek Dudek wrote:
> Thanks David, that's really clever! I was trying to do it without any
> auxiliary data types, but couldn't see how I could use an instance of
> (BiList a b) in the constructor expression for (BiList a b) without
> losing the property that the list elements alternate from one type to
> the other with each new element.
> 
> But now I see that when you write (BiList b a) in the constructor
> expression, that's written in the context provided by the (data BiList
> a b) line, so having the type variables in the opposite order makes
> all the difference.
> 
> Brent, David's definition actually solved both (1) and (2), try it out!
> 
> On 4/3/14, Denis Kasak <[email protected]> wrote:
> > On 3 April 2014 22:58, Brent Yorgey <[email protected]> wrote:
> >>
> >> data BiList a b
> >>   = BA (AltList a b)
> >>   | BB (AltList b a)
> >>
> >> data AltList a b
> >>   = Empty
> >>   | Cons a (AltList b a)
> >>
> >> So this addresses (2) but not (1).  I don't think there is any way
> >> around the need for (1).  (Note, however, that you do still have two
> >> distinct representations of the empty list: BA Empty and BB Empty.  I
> >> can't see any way around that either.)
> >
> > You could move the Empty constructor to BiList while making AltList a
> > non-empty list, i.e.
> >
> > data BiList a b
> >   = Empty
> >   | BA (AltList a b)
> >   | BB (AltList b a)
> >
> > data AltList a b
> >   = Elem a
> >   | Cons a (AltList b a)
> >
> > --
> > Denis Kasak
> > _______________________________________________
> > Beginners mailing list
> > [email protected]
> > http://www.haskell.org/mailman/listinfo/beginners
> >
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners


------------------------------

Message: 5
Date: Fri, 04 Apr 2014 12:17:48 -0600
From: Dimitri DeFigueiredo <[email protected]>
To: [email protected]
Subject: [Haskell-beginners] Definition of last: why complicate it?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I was looking at the definition of last in the prelude and saw this code

(from 
http://hackage.haskell.org/package/base-4.2.0.1/docs/src/GHC-List.html)

-- | Extract the last element of a list, which must be finite and non-empty.
last                    :: [a] -> a
#ifdef USE_REPORT_PRELUDE
last [x]                =  x
last (_:xs)             =  last xs
last []                 =  errorEmptyList "last"
#else
-- eliminate repeated cases
last []                 =  errorEmptyList "last"
last (x:xs)             =  last' x xs
   where last' y []     = y
         last' _ (y:ys) = last' y ys
#endif

Question: What does the second "eliminate repeated cases" definition of 
last gain compared to the first (simpler) one?

Thanks

Dimitri


------------------------------

Message: 6
Date: Fri, 4 Apr 2014 20:12:50 +0100
From: Rudy Matela <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Definition of last: why complicate
        it?
Message-ID:
        <calcd0b9x1ocfit_8z-_f5jvdubz4jicyovsugjegzghcx02...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Basically the second one should be faster.  I'm *guessing* here as
*I'm no Haskell wizard*, so someone correct me if I'm wrong.


In the first version, at each iteraction (applying to a non-empty
list), the program will:

1. Check for a non-empty list, with one element -- return x if true
*then*
2. Check for a non-empty list -- do something to the tail if true

So basically, at each iteration you're doing two "check operations",
and you know that the first operation will be true only for the last
element which is wasteful.  On a array with 10 elements you do roughly
19 "check operations" (2n - 1).


In the second version:

0. Check for empty list error (you only do that once) because the
recursion is on last'
then, for each element:
1. check wether the passes list is empty (1 check) -- return y if
true, apply recursion if false

On a array with 10 elements you'll do roughly 11 "check operations" (n+1).


According to a stackoverflow answer [1], this should be done
automatically by GHC.  Why it's still defined like that I don't know:
maybe because the code is for when using other compilers, or maybe I
misinterpreted the stackoverflow post and GHC is not able to do that.


[1]: https://stackoverflow.com/a/12661937, under "Case Expressions"


Regards,
Rudy

On Fri, Apr 4, 2014 at 7:17 PM, Dimitri DeFigueiredo
<[email protected]> wrote:
> I was looking at the definition of last in the prelude and saw this code
>
> (from
> http://hackage.haskell.org/package/base-4.2.0.1/docs/src/GHC-List.html)
>
> -- | Extract the last element of a list, which must be finite and non-empty.
> last                    :: [a] -> a
> #ifdef USE_REPORT_PRELUDE
> last [x]                =  x
> last (_:xs)             =  last xs
> last []                 =  errorEmptyList "last"
> #else
> -- eliminate repeated cases
> last []                 =  errorEmptyList "last"
> last (x:xs)             =  last' x xs
>   where last' y []     = y
>         last' _ (y:ys) = last' y ys
> #endif
>
> Question: What does the second "eliminate repeated cases" definition of last
> gain compared to the first (simpler) one?
>
> Thanks
>
> Dimitri
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners


------------------------------

Subject: Digest Footer

_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners


------------------------------

End of Beginners Digest, Vol 70, Issue 7
****************************************

Reply via email to