Various Topics on Lisp

.... .. ..ueg..

Ari Johnson <ari_j@hotmail.com> wrote:
> Karl A. Krueger wrote:
>> Kenny Tilton <ktilton@nyc.rr.com> wrote:
>>
>>>Ari Johnson wrote:
>>>
>>>>Christophe Rhodes wrote:
>>>>
>>>>>Juliusz Chroboczek <jch@pps.jussieu.fr> writes:
>>>>>
>>>>>
>>>>>>Any suggestions for a good name? I'm finding myself writing the above
>>>>>>way too often. (Perhaps I should be interning my strings...)
>>>>>
>>>>>memual?
>>>>
>>>>"Much of the skill in writing unmaintainable code is the art of naming
>>>>variables and methods. They don't matter at all to the compiler. That
>>>>gives you huge latitude to use them to befuddle the maintenance
>>>>programmer."
>>>> - How to Write Unmaintainable Code
>>>
>>>So... mual?
>>
>> moo. For "Member, Object equals Other one".
>
> Well, we want to make it obvious that we're dealing with the "equal"
> operator, so how about mmmmmmmmmmm-equal or, to make the pronunciation
> more obvious, just call it homer-simpson.

donuts is easier to type, and has the advantage of sounding like it
iterates over nuts.

--
Karl A. Krueger <kkrueger@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews

..ristoph.. .. ..a..

>>>>> On Fri, 07 May 2004 21:41:22 -0500, Rob Warnock ("Rob") writes:

Rob> Barry Margolin <barmar@alum.mit.edu> wrote:
Rob> +---------------
Rob> | Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:
Rob> | > JC> #'(lambda (x y) (member x y :test 'equal))
Rob> | > Any suggestions for a good name?
Rob> |
Rob> | (defun member-equal (x y)
Rob> | (member x y :test #'equal))
Rob> +---------------

Rob> In this case that seems quite appropriate, though I often find myself
Rob> using "/" rather than "-" to indicate minor variants of functions,
Rob> e.g., "member/equal" for the above, especially when the function being
Rob> "specialized" (whoo!) already has one or more hyphens in its name, e.g.
Rob> JOIN-STRINGS vs. JOIN-STRINGS/SQL-QUOTED or:

Rob> get-bindings
Rob> get-bindings/get
Rob> get-bindings/post
Rob> and:
Rob> extract-bindings
Rob> extract-bindings/single

Rob> That sort of thing. Comments?

First impression: It's different than what I've been seeing
for the last quarter century (just FOO-BAR-BAZ, with maybe
some prepositional words), so I probably won't adopt it.
In isolation, there is nothing objectionable about it.

The examples you've shown would not be at all confusing if I came
across them in a pile of self-contained that all looked like that.
But I am not sure how aesthetically pleasing it would be to see
that convention mixed with code from the more usual convention.
If "everybody" did this, that (more confusing looking) mixed
conventions would be the norm, rather than your own idiosyncracy.
I don't think the level of discrepancy would ever die all the
way down, because there will always be code that just uses hyphens.

I'm don't want to introduce additional punctuation like that.
I think there's already a convention for that meaning, and when
I see things like "/" and "+" (and "*") in the names of things,
they draw my attention and make me wonder what's so special about
those names. It's very much like the other kind of syntactic
markers (reader macros) in the language.

Of course the meaning of "minor variant" is very subjective.
Also, I fear that someone would write things like
FROB-THIS/LIKE/THAT/WITH-FROBBING

and I think that actually looks ugly. Sorta reminds me of natural
lanugage parsers from MACLISP days before strings were invented,
or some name that was consed by a program and not normally intended
for program-writer consumption. And that kind of of hierarchical
naming system starts to look a lot like other naming conventions.
Introducing yet another such naming system is not a good idea.
Especially since we're still talking about code where we don't
want to make such boundary distinctions -- we're talking about
program elements that are conceptually at the same level,
not something that wants to be hierarchically distinct.

..liu.. ..robocz..

KK> moo. For "Member, Object equals Other one".

I rather like this one.

Juliusz

..r.. ..rgol..

In article <tp3c68un7w.fsf@lanthane.pps.jussieu.fr>,
Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:

> KK> moo. For "Member, Object equals Other one".
>
> I rather like this one.
>
> Juliusz

But wouldn't that abbreviation be just as valid for "Member, Object eq
Other one"? The abbreviation makes no distinction between EQ, EQL,
EQUAL, or EQUALP. In fact, it doesn't even use the E, so it would also
be a reasonable mnemonic for "Member, Object unequal to Other one".

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

..e.. ..e ..s

Barry Margolin wrote:

> In article <tp3c68un7w.fsf@lanthane.pps.jussieu.fr>,
> Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:
>
>> KK> moo. For "Member, Object equals Other one".
>>
>> I rather like this one.
>>
>> Juliusz
>
> But wouldn't that abbreviation be just as valid for "Member, Object eq
> Other one"? The abbreviation makes no distinction between EQ, EQL,
> EQUAL, or EQUALP. In fact, it doesn't even use the E, so it would also
> be a reasonable mnemonic for "Member, Object unequal to Other one".

That's the great part, and of course the standard doesn't specify *which*
moo you're dealing with.

We can have #'moo as equal, #'moe as eq/eql and #'mee to ask whether #'moe
uses eq or eql at the moment.

..m ..adsh..

rpw3@rpw3.org (Rob Warnock) wrote in message news:<a9-dnYqk5o5P1QHdRVn-vw@speakeasy.net>...
>
>
> get-bindings
> get-bindings/get
> get-bindings/post
> and:
> extract-bindings
> extract-bindings/single
>
> That sort of thing. Comments?
>

I do that too, although I'm told I should really say extractBindingsSingle.

..mi.. ....

Ari Johnson <ari_j@hotmail.com> writes:

> Christophe Rhodes wrote:
> > Juliusz Chroboczek <jch@pps.jussieu.fr> writes:
> >>Any suggestions for a good name? I'm finding myself writing the above
> >>way too often. (Perhaps I should be interning my strings...)
> > memual?
>
>
> "Much of the skill in writing unmaintainable code is the art of naming
> variables and methods. They don't matter at all to the compiler. That
> gives you huge latitude to use them to befuddle the maintenance
> programmer."
>
> - How to Write Unmaintainable Code

Paul Graham in _On Lisp_ (section 16.1):

The simplest use of macros is as abbreviations. Some Common Lisp
operators have rather long names. Ranking high among them (though
by no means the longest) is destructuring-bind, which has 18
characters. A corollary of Steele's principle (page 43) is that
commonly used operators ought to have short names. ("We think of
addition as cheap partly because we can notate it with a single
character: '+'") The built-in destructuring-bind macro introduces
a new layer of abstraction, but the actual gain in brevity is
masked by its long name:

(let ((a (car x)) (b (cdr x))) ...)

(destructuring-bind (a . b) x ...)

A program, like printed text, is easiest to read when it contains no
more than about 70 characters per line. We begin at a disadvantage
when the lengths of individual names are a quarter of that.

Of course, how often do people actually use "destructuring-bind"? And
for "memual":

memq ;memq => (member :test #'eq)

member/equal
member-equal
mem-equal
memequal
memqual ;memqual => (member :test #'equal)
memual

It's not like "memual" is really gaining much over "member-equal" or
"member/equal". Actually, I don't really think "memqual" is really
all that bad, if one already accepts "memq", as it mirros the "eq"
through "equalp" hierarchy:

memq
memql
memqual
memqualp

<shrug>