For Programmers: Free Programming Magazines  


Home > Archive > Scheme > March 2006 > interweaved let and cond









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author interweaved let and cond
Bell Foster

2006-03-08, 7:57 am

Recently I've encountered a situation where I wondered about let and
cond working together. The problem in broad terms is this:

if a list is null do something
else if the first item of a list equals something, do something else
else if the first item equals this other thing, do this other thing
else if the first item equals yet another another, do yet another
different thing.
and so on

Writing the cond:
(cond ( (null? some-list) do-something)
( (= foo (car some-list)) do-something-else)
( (= bah (car some-list)) do-this-other-thing)
( (= baz (car some-list)) yet-another-thing)
( etc. for several cases

It's really redundant to write "car some-list" for each case, and it
could get worse if in the next problem I want something with even
longer notation than car.

And a let can't be used here, because it can't be intertwined with a
cond statement.

So I thought of breaking the cond into an if and a cond, with a let
around the cond, like:

if (null? some-list)
do-something
(let ( (first-item (car some-list)))
(cond ( (= first-item foo) whatever)
..and so on with the cond

And I began to wonder if this if/cond structuring is the standard way
to handle this, or if experts know more than I.

Jens Axel Søgaard

2006-03-08, 7:57 am

Bell Foster wrote:
> Recently I've encountered a situation where I wondered about let and
> cond working together. The problem in broad terms is this:
>
> if a list is null do something
> else if the first item of a list equals something, do something else
> else if the first item equals this other thing, do this other thing
> else if the first item equals yet another another, do yet another
> different thing.
> and so on
>
> Writing the cond:
> (cond ( (null? some-list) do-something)
> ( (= foo (car some-list)) do-something-else)
> ( (= bah (car some-list)) do-this-other-thing)
> ( (= baz (car some-list)) yet-another-thing)
> ( etc. for several cases
>
> It's really redundant to write "car some-list" for each case, and it
> could get worse if in the next problem I want something with even
> longer notation than car.
>
> And a let can't be used here, because it can't be intertwined with a
> cond statement.
>
> So I thought of breaking the cond into an if and a cond, with a let
> around the cond, like:
>
> if (null? some-list)
> do-something
> (let ( (first-item (car some-list)))
> (cond ( (= first-item foo) whatever)
> ..and so on with the cond
>
> And I began to wonder if this if/cond structuring is the standard way
> to handle this, or if experts know more than I.


Variations of both approaches are widespread. In some situations
one can take advantage of specialized constructs. E.g.

(if (null? a-list)
<do-something>
(case (car a-list)])
[(foo) <do-something1>]
[(bar) <do-something2>]
[(baz) <do-something3>])

Mixing binding and cond can be cumbersome. Pattern matching
is often clearer. Your example becomes

(match a-list
[() <do-something>]
[('foo . _) <do-something1>]
[('bar . _) <do-something2>]
[('baz . _) <do-something3>])

which isn't that much of an improvement, but in more complicated
situations the advantage is greater.

--
Jens Axel Søgaard







Bell Foster

2006-03-08, 7:01 pm


> Variations of both approaches are widespread. In some situations
> one can take advantage of specialized constructs. E.g.
>
> (if (null? a-list)
> <do-something>
> (case (car a-list)])
> [(foo) <do-something1>]
> [(bar) <do-something2>]
> [(baz) <do-something3>])
>
> Mixing binding and cond can be cumbersome. Pattern matching
> is often clearer. Your example becomes
>
> (match a-list
> [() <do-something>]
> [('foo . _) <do-something1>]
> [('bar . _) <do-something2>]
> [('baz . _) <do-something3>])
>
> which isn't that much of an improvement, but in more complicated
> situations the advantage is greater.


Thanks, I'm glad that there isn't some super obvious solution which I
was missing.

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com