[philly-lambda] Re: Do you keep wishing for the patterns from other languages?

[Ed Watkeys <edw@poseur.com>]

On Aug 24, 1:27 pm, "Kyle R. Burton" <kyle.bur...@gmail.com> wrote:

> > for(elem = list; elem != NULL; elem = elem->next) {
> >   /* do something */
> > }
> > Should a clueful C programmer look at that and see an idiomatic C list
> > iterator, or should she see an missing feature in the language?
>
> I do :)  With no name, I have to look more closely at the structure
> and what's going on - also it forces the developer to type more,
> raising the risk of typos and other bugs :)

I don't think it's a weakness of English that words are made of
letters. Similarly, I don't mind that C doesn't have a feature for
every task.

letters -> words -> idioms ; This is OK!

> In scheme (JScheme) there is an iterate form, which uses
> define-method, to allow iteration over lots of stuff (cons based
> lists, javas List, Map [over the entries], vectors, etc):
>
>   (iterate (lambda (elt) do-something) iterable-thing ...)

This is a pet peeve of mine: MAP should iterate over anything
iterable. I've written versions of map that do that, but none that
don't consume too much space. (Would a streams-based MAP be the
answer?)

> In C, using HOFs or extending the language are uncommon development
> practices (there is always the whole embedded sql approach though).

C and function pointers are good friends; see qsort(3). But you're
right, it's nothing like Lisp.

> Which is another problem altogether - when creating new syntactic
> constructs is a normal part of the development process in those
> languages, it makes it really difficult to know what you're looking at
> without knowing all the context that has built up to the
> statement/code you're reading.  This is one thing that really scares
> non-lispers.  It goes back to the premise that there should be
> referential integrity to the code and that what you're reading should
> depend as little as possible on what has been done above/before/in
> other modules.

I think the real argument is against excessive macrology; see my
recent post in the SYNTAX-CASE thread. Macros frustrate program
understanding unless they're designed in harmony with Scheme's core
idioms.

> I don't see how the lambda gets called?  Is that what the '=>' does?
> The way I read that is that the first clause in the cond returns a
> function, while the second clause returns false.  The function, if
> given a cons cell will return the cdr...I am used to seeing code like:
>
> (define (test-assoc people)
>   (cond ((assoc 'kyle people)
>          (cdr (assoc 'kyle people)))
>         (else
>          #f)))

Your guess about => is correct. It addresses the anaphoric IF need.
The code above should be re-written with => as it ASSOCs twice in the
case of 'kyle existing in people.

> Well, the verboseness of some of those languages makes automated
> refactoring tools _necessary_.  Yegge's blog post about that was on
> the mark:

I've been thinking about Scheme refactoring recently, trying to nail
down the particulars of the operations I perform when generalizing
Scheme programs, and wondering if requires little enough human
intervention to make worth automating in a way more involved than
using something like paredit-mode in Emacs.

  http://mumble.net/~campbell/darcs/parscheme/

>  http://www.oreillynet.com/ruby/blog/2006/03/transformation.html
>
> Thanks for the discussion!

Thanks for the link!

Ed


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Philly Lambda" group.
To unsubscribe from this group, send email to philly-lambda-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/philly-lambda?hl=en
-~----------~----~----~----~------~----~------~--~---