Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/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: enumaratioin question
(Sumit Sahrawat, Maths & Computing, IIT (BHU))
2. Re: tower hanoi problem (Dudley Brooks)
----------------------------------------------------------------------
Message: 1
Date: Thu, 19 Feb 2015 22:52:13 +0530
From: "Sumit Sahrawat, Maths & Computing, IIT (BHU)"
<[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] enumaratioin question
Message-ID:
<cajbew8ppjdzawn+wdwhzox11mdlvbpnjzxgco5mqrsxsg3p...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes, "age p" gives the age of the person represented by "p".
On 19 February 2015 at 22:50, Roelof Wobben <[email protected]> wrote:
> Oke, I read that part.
>
> Then I would be age p = ag
>
> Roelof
>
>
>
> Sumit Sahrawat, Maths & Computing, IIT (BHU) schreef op 19-2-2015 om 18:03:
>
> When you use record syntax, accessors are automatically created for you.
> So,
>
> data Person = Person {
> name :: String
> , age :: Integer
> , favThing :: String
> }
>
> means that name, age and favThing are functions that do exactly what you
> want:
>
> name :: Person -> String
> age :: Person -> Integer
> favThing :: Person -> String
>
> So you just need to call age on a Person value to get the age.
> Due to this functionality, the names in record syntax can not start with
> an uppercase letter.
>
> On 19 February 2015 at 22:27, Roelof Wobben <[email protected]> wrote:
>
>> Thanks,
>>
>> That is not what I mean ,
>>
>> I mean this :
>>
>> data Person = Person
>> { name :: String ,
>> Age :: Integer ,
>> FavThing :: String }
>>
>>
>> and i want to get the Age I could do this :
>>
>> getAge (Person {age = ag}) = ag
>>
>> Roelof
>>
>>
>> Sumit Sahrawat, Maths & Computing, IIT (BHU) schreef op 19-2-2015 om
>> 17:37:
>>
>> I can't understand what you mean by those colons in the second
>> definition of Person. If you're thinking of type signatures, then that
>> doesn't work in haskell.
>> In an ADT, you give names to possible values. So "Name String" will work
>> whereas "Name : String" won't work.
>>
>> data Person = Name String
>> | Age Integer
>> | FavThing String
>>
>> means that Person can be *one of* these things (which is not what you
>> want).
>>
>> What you want is possible with record syntax. He'll detail it later I
>> think.
>> If you're interested in learning about it beforehand, look it up in the
>> haskell wikibook (another great haskell resource).
>>
>> More about ADTs in general:
>> http://en.wikibooks.org/wiki/Haskell/Type_declarations#data_and_constructor_functions
>> The link to the specific section:
>> http://en.wikibooks.org/wiki/Haskell/More_on_datatypes#Named_Fields_.28Record_Syntax.29
>>
>> On 19 February 2015 at 21:58, Roelof Wobben <[email protected]> wrote:
>>
>>> Hello,
>>>
>>> Im reading chapter 2 of the CIS 194 course about enumaratuin.
>>>
>>> Now they give this example :
>>>
>>> -- Store a person's name, age, and favourite Thing.data Person = Person
>>> String Int Thing
>>> deriving Show
>>> brent :: Person
>>> brent = Person "Brent" 31 SealingWax
>>> stan :: Person
>>> stan = Person "Stan" 94 Cabbage
>>> getAge :: Person -> Int
>>> getAge (Person _ a _) = a
>>>
>>> I understand how this works.
>>>
>>> But I wonder if there is no "better" way to get the Age.
>>>
>>> Is it now wise to make a person data like this :
>>>
>>> data Person = Name : String
>>> | Age : Integer
>>> | FavThing : String
>>>
>>> And if so , how can I get the age then ?
>>>
>>> Roelof
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> [email protected]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>>>
>>
>>
>> --
>> Regards
>>
>> Sumit Sahrawat
>>
>>
>> _______________________________________________
>> Beginners mailing
>> [email protected]http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>>
>>
>
>
> --
> Regards
>
> Sumit Sahrawat
>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
--
Regards
Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150219/c9370ab9/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 19 Feb 2015 09:22:25 -0800
From: Dudley Brooks <[email protected]>
To: Haskell Beginners <[email protected]>
Subject: Re: [Haskell-beginners] tower hanoi problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
And to clarify my point, I would say that mathematically you do always
have to "take care of" (worry about) the base case first ... and you
did! And in the code, not just in your thinking: Using "x:xs", rather
than "(head xs)", in the first line acknowledges the base case by making
sure to eliminate it first -- "x:xs" works precisely because it doesn't
separate the *concerns*; it contains an implicit "if this is not the
base case". What it does (why it's useful syntactic sugar) is let you
separate (and reorder) the *actions*. A guard using "x:xs" does not
actually have the very clean SOC which you recommend, with the result
that the concept "base case" is actually represented in *two* places in
your code.
Question: Could you write it without the first line using "x:xs" or
some other construction which has an implicit "if this is not the base
case"? Probably yes ... probably some kind of "where" clause might put
it typographically at the end. But that would be because Haskell's
interpreter/compiler executes the test in the "where" clause first.
Checking whether we're looking at the base case would still be the first
major execution step. I suspect that there's no way to escape that ...
the most that can be done is to "look like" you're escaping it.
On 2/19/15 4:47 AM, Joel Neely wrote:
> Just to clarify the point of my earlier comment...
>
> I suggest that the "separation of concerns" (SOC) principle has many
> applications. A common use shows up in the advice to represent each
> distinct concept exactly one place in the code, and to do so in a way
> that supports orthogonality (the freedom to mix-and-match).
>
> In this case, I used it to separate the thought process of designing
> the code from the lexical layout of the code.
>
> I have no business legislating the order in which someone else thinks
> about the cases (sometimes more than two!) encountered in decomposing
> a problem. However, in my experience, the order in which I think about
> parts of the code, and the order in which they are laid out in the
> source file, are separate concerns. And I have often found it useful
> to consider them separately.
>
> For example, in some problems (and language implementations) it may
> help performance to ensure that the most frequent case is considered
> first, especially when there are multiple cases to consider or when
> the distinguishing conditions are costly to evaluate.
>
> I find that making my guards (conditions) explicit allows me the
> freedom to order the alternatives in whatever way I find useful,
> without having to worry about introducing a defect in the code.
>
> Incidentally, I also find it interesting to see the subtle effects
> that our terminology has on the way we approach problems. Thinking of
> a list as "it may be empty or not" takes my thoughts in a different
> direction than if I think "it may have a head or not".
>
> By all means, think about your recursive functions any way you wish!
> Just please don't tell me that I must place them is a specific order
> in my code.
>
> Regards,
> -jn-
>
>
>
> On Thu, Feb 19, 2015 at 3:02 AM, Dudley Brooks
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 2/18/15 5:29 PM, Mike Meyer wrote:
>> On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> Hmm. Well, I'd say that that's a feature of, specifically,
>> Haskell's pattern-matching strategy and list-description
>> syntax, rather than of recursion in general or the structure
>> of this particular problem. In other languages with
>> recursion you might have no choice except to start with the
>> base case, even for this problem, or else you'd get the same
>> kind of error you mention below (depending on the language).
>> I think it's good when you're *learning* recursion to always
>> start with the base case(s).
>>
>> I disagree that this is a Haskell-specific feature. Any else-if
>> like structure will have this property, no matter what language
>> it's in. That Haskell provides a syntax as part of the function
>> declaration is special, but that doesn't let you avoid the
>> else-if construct when the problem requires it.
> I don't understand. I don't believe I said anything about
> avoiding else-if, or about not avoiding it. But I'm not quite
> sure what you mean. Are you referring to
>
> if condition1
> then instruction1
> elseif condition2
> then instruction2
>
> ?
>
> But what is condition1? Wouldn't it probably be the base case,
> and instruction1 the procedure on the base case?
>
> Is there something special about "elseif" that guarantees that
> instruction1 *before* it won't crash if condition1 isn't the base
> case??? I'm probably totally missing your intention here.
>
> But anyway, isn't it actually just Haskell's syntax "x:xs" that
> lets the pattern be tested and bypassed without crashing on an
> empty list, so that it *can* fall through to the base case at the
> end? If Haskell only had the syntax "(head xs), then that *would*
> crash on the empty list if the empty list had not previously been
> taken care of as a base case, as Joel Neely pointed out.
>
> I didn't mean that *no* other language might have such a
> syntactical construction. (I didn't mean "specifically Haskell",
> I meant "specifically the pattern matching". Sorry about the
> ambiguity.) So if some other language has such a construction,
> then it's still the *syntax* that lets you cheat on the base case;
> it's not the structure of the problem itself nor the basic
> underlying notion of recursion.
>
> I would also argue that in Mr Neely's first example, while the
> *explicit* base case [] is at the end, nevertheless the first line
> still *implicitly* refers to the base case: pattern matching on
> "x:xs" says "*if* the data has the structure x:xs", i.e. "if it is
> not a bunch of other stuff ... including *not the empty list*!)".
> Certainly you couldn't merely do the recursive step first without
> a condition like this particular one. The reason this syntax
> *seems* to let you avoid thinking about the base case first is
> because secretly it says "only try this step if we're not looking
> at the base case"!
>> It may be my fondness for proof by induction, but I think doing
>> the base case first is a good idea for another reason. The code
>> for the recursive cases assumes that you can correctly handle all
>> the "smaller" cases. If that's wrong because some assumption
>> about the base case turns out to be false when you actually write
>> it, then you have to rewrite the recursive cases for the correct
>> base case. So it's better to make sure your base case is going to
>> work before you start writing the code that's going to use it.
> I was a math major, not a CS major, so I'm also prejudiced in
> favor of base case first. And, as stated above, I think we *are*
> actually *considering* the base case first! (We're merely putting
> off telling what to *do* with that base case.) I think that the
> "syntactic sugar" of some languages obscures (intentionally, for
> purposes of convenience) what's really happening mathematically.
>
>
> _______________________________________________
> Beginners mailing list
> [email protected] <mailto:[email protected]>
> http://mail.haskell.org/cgi-bin/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://mail.haskell.org/pipermail/beginners/attachments/20150219/ec1be4bb/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 80, Issue 54
*****************************************
