Technically LABELS and FLET do the same thing except that functions
defined with LABELS have a scope encompassing the function definitions
themselves as well as the body. FLET-defined functions are only
visible within the body. So LABELS is useful for defining mutually
calling (and thence mutually recursive) functions.
My style question, and it's *purely* a style question, is whether it
is acceptable to use LABELS even in cases where the defined functions
have no need to reference each other? Or should FLET be used instead
to point out that they are not mutually referencing? When defining a
handful of local functions I tend to prefer LABELS to keep my options
open while I'm hacking, but later I examine them and rename LABELS to
FLET if the functions have no need to call each other. I'm just
curious as to other people's practices.
Are there any other reasons to use FLET instead of LABELS?
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
·····@unlambda.com (James A. Crippen) wrote in message news:<··············@kappa.unlambda.com>...
> My style question, and it's *purely* a style question, is whether it
> is acceptable to use LABELS even in cases where the defined functions
> have no need to reference each other? Or should FLET be used instead
> to point out that they are not mutually referencing? When defining a
> handful of local functions I tend to prefer LABELS to keep my options
> open while I'm hacking, but later I examine them and rename LABELS to
> FLET if the functions have no need to call each other. I'm just
> curious as to other people's practices.
Stylistically, I prefer to use LABELS only when I need the mutual
reference semantics. I feel the same way about LET* vs. LET, DO* vs.
DO. When I run across someone else's code where LET* is used when
only LET is needed, I mentally scratch my head looking for the
dependency between the multiple clauses.
Andrew
In article <····························@posting.google.com>,
Andrew Philpot <··············@yahoo.com> wrote:
>Stylistically, I prefer to use LABELS only when I need the mutual
>reference semantics. I feel the same way about LET* vs. LET, DO* vs.
>DO. When I run across someone else's code where LET* is used when
>only LET is needed, I mentally scratch my head looking for the
>dependency between the multiple clauses.
I have the same opinion, but this seems to be a very personal issue. I've
heard people post the exact opposite opinion. They use LABELS by default
because the functions are more like the ones defined using DEFUN, and they
only use FLET when they want to prevent the functions from referring to
each other (e.g. if they're redefining a function locally, and need to
refer to the outer version).
In the case of LET* and DO*, this style is a little less prevalent,
probably because the "*" makes these functions seem "more special".
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <····························@posting.google.com>,
> Andrew Philpot <··············@yahoo.com> wrote:
> >Stylistically, I prefer to use LABELS only when I need the mutual
> >reference semantics. I feel the same way about LET* vs. LET, DO* vs.
> >DO. When I run across someone else's code where LET* is used when
> >only LET is needed, I mentally scratch my head looking for the
> >dependency between the multiple clauses.
>
> I have the same opinion, but this seems to be a very personal issue. I've
> heard people post the exact opposite opinion. They use LABELS by default
> because the functions are more like the ones defined using DEFUN, and they
> only use FLET when they want to prevent the functions from referring to
> each other (e.g. if they're redefining a function locally, and need to
> refer to the outer version).
I think that this preference for LABELS is a little less common than
the preference for FLET.
My most important reason for preferring FLET over LABELS is that it
takes two less letters to type. My second reason is that FLET has a
cooler name than LABELS. 'Flay', by analogy with French
pronounciation. 'Macrolay' too. But I haven't gone so far as to
pronounce LET as 'lay', mostly because the English word has higher
precedence in my mental dictionary. But LET pronounced 'lay' has a
pleasing connection with the French word 'le' in my mind, in that LET
announces a handful of variable bindings, and could translate as 'le
/variable/ est ...'.
Are there any other odd pronounciations of Lisp functions? Lispers
tend to pronounce acronyms as words more than most other hacker types,
I've noticed. The influence is obviously from CAR/CDR. But there's
plenty of other functions in Lisp to pronounce strangely. Obvious
ones are the many variations of CAR/CDR, the RPLACA and RPLACD
functions, and the DPB/LDB ones. Those are all well documented.
Here's my little list off the top of my head:
EQ - "eek"
EQL - "eekl"
ELT - "ellt"
SQRT - "squirt"
SXHASH - "sexhash"
RASSOC - "rassock" (rhymes with 'hassock')
PRINC - "princk"
PRIN1 - "prinwon"
PPRINT - "piprint"
#' - "fun" ("sharp quote" is just too many syllables, so is "function")
#x - "hex"
#o - "ock" (the 't' at the end of 'oct' gets swallowed)
#b - "bits" (which is shorter than "binary" and more meaningful than "bin")
,@ - "commat"
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
"James A. Crippen" <·····@unlambda.com> wrote in message ···················@kappa.unlambda.com...
>
> Are there any other odd pronounciations of Lisp functions? Lispers
> tend to pronounce acronyms as words more than most other hacker types,
> I've noticed. The influence is obviously from CAR/CDR. But there's
> plenty of other functions in Lisp to pronounce strangely. Obvious
> ones are the many variations of CAR/CDR, the RPLACA and RPLACD
> functions, and the DPB/LDB ones. Those are all well documented.
Apparently they differ from place to place. I've heard these:
cmucl "cu-MUCK-el" rather than "see em you see ell"
princ "PRIN-see" rather than "prink"
sxhash "ESSex-hash" rather than "sexhash"
eq "ee-cue", analagous to memq "mem-cue" and assq "ass-cue"
> Here's my little list off the top of my head:
>
> EQ - "eek"
> EQL - "eekl"
> ELT - "ellt"
> SQRT - "squirt"
> SXHASH - "sexhash"
> RASSOC - "rassock" (rhymes with 'hassock')
> PRINC - "princk"
> PRIN1 - "prinwon"
> PPRINT - "piprint"
> #' - "fun" ("sharp quote" is just too many syllables, so is "function")
> #x - "hex"
> #o - "ock" (the 't' at the end of 'oct' gets swallowed)
> #b - "bits" (which is shorter than "binary" and more meaningful than "bin")
> ,@ - "commat"
"Joe Marshall" <·············@attbi.com> wrote in message
···························@sccrnsc01...
>
> Apparently they differ from place to place. I've heard these:
>
> cmucl "cu-MUCK-el" rather than "see em you see ell"
> princ "PRIN-see" rather than "prink"
> sxhash "ESSex-hash" rather than "sexhash"
> eq "ee-cue", analagous to memq "mem-cue" and assq "ass-cue"
Pronunciations of "odd" words I think is based mostly on the community
you're in. With a virtual community, we never get those pronuciations, so
we're left to our own devices.
What's interesting is when the differencess ARE detectable through the
written communications.
For example, I've always pronounced "FAQ" as 'fak', rather than F-A-Q. You
can see how some people prounce when they ask about them:
"Is the a FAQ for this group?" vs. "Is that an FAQ for this group?"
Unless there is a glaring "word" that can be pronounced, I tend to spell out
the what I can't pronounce.
I'm rather liberal with how I pronounce SQL. I almost always pronounce it
"S-Q-L". But, Oracles SQLPLUS is "Sequel-Plus", because that's how everyone
here calls it. Whereas Informixs 'isql' and Postgres's 'psql' are simply
spelled. I write in S-Q-L but sometime is magically transforms into "Sequel
Code".
I'll go back and forth with MS SQL Server, using Sequel and S-Q-L
interchangably. The most amusing detail is that I only shift back and forth
when I don't pronounce it "Sybase".
Another interesting this is that while I tend to pronouce words that I read
(thus slowing down my reading, but that's another topic completely), I
rarely pronounce some of the extra characters. In my head LET and LET* are
both pronounced "LET". The * is almost always an afterthought. This is
rarely an issue, as I'm only talking to myself. I pretty much never "talk"
Lisp, only type it.
'+', plus, '-', minus, '*', times, '/', divided-by.
In Lisp I should reword those in my head to ADD, SUBTRACT, MULTIPLY and
DIVIDE. The reason is that I still fumble with prefix notation for basic
math equations. I don't internally convert 1 + 1 to (+ 1 1) naturally,
because I pronounce it 1 PLUS 1, and PLUS 1 1 sounds wrong. ADD 1 1 makes
sense. I should be more conscious of that. Probably make it easier.
But this comes back to that for language design, there is more to it than
simply the syntax. There's a whole bit of other learning and experience
involved. This may be one reason I have difficulty with Perl. Sure I can say
ess-slash-bob-slash-fred-slash, but that doesn't "say" anything about a
substituition. I can easily convert "substitute" into "ess", as in a command
for an editor, but the other way around is more difficult. It's a one-way
hash, write-only code. Clearly with more experience, this all becomes more
natural, but it's all rote memorization rather than logical leaps and
bounds. I'm sure I'd have similar issue with something like APL.
Ah, well, the mind and the thread wanders. So, I'll shut up now.
Regards,
Will Hartung
(·····@msoft.com)
"Joe Marshall" <·············@attbi.com> wrote in message
···························@sccrnsc01...
>
> Apparently they differ from place to place. I've heard these:
>
> cmucl "cu-MUCK-el" rather than "see em you see ell"
> princ "PRIN-see" rather than "prink"
> sxhash "ESSex-hash" rather than "sexhash"
> eq "ee-cue", analagous to memq "mem-cue" and assq "ass-cue"
Pronunciations of "odd" words I think is based mostly on the community
you're in. With a virtual community, we never get those pronuciations, so
we're left to our own devices.
What's interesting is when the differencess ARE detectable through the
written communications.
For example, I've always pronounced "FAQ" as 'fak', rather than F-A-Q. You
can see how some people prounce when they ask about them:
"Is the a FAQ for this group?" vs. "Is that an FAQ for this group?"
Unless there is a glaring "word" that can be pronounced, I tend to spell out
the what I can't pronounce.
I'm rather liberal with how I pronounce SQL. I almost always pronounce it
"S-Q-L". But, Oracles SQLPLUS is "Sequel-Plus", because that's how everyone
here calls it. Whereas Informixs 'isql' and Postgres's 'psql' are simply
spelled. I write in S-Q-L but sometime is magically transforms into "Sequel
Code".
I'll go back and forth with MS SQL Server, using Sequel and S-Q-L
interchangably. The most amusing detail is that I only shift back and forth
when I don't pronounce it "Sybase".
Another interesting this is that while I tend to pronouce words that I read
(thus slowing down my reading, but that's another topic completely), I
rarely pronounce some of the extra characters. In my head LET and LET* are
both pronounced "LET". The * is almost always an afterthought. This is
rarely an issue, as I'm only talking to myself. I pretty much never "talk"
Lisp, only type it.
'+', plus, '-', minus, '*', times, '/', divided-by.
In Lisp I should reword those in my head to ADD, SUBTRACT, MULTIPLY and
DIVIDE. The reason is that I still fumble with prefix notation for basic
math equations. I don't internally convert 1 + 1 to (+ 1 1) naturally,
because I pronounce it 1 PLUS 1, and PLUS 1 1 sounds wrong. ADD 1 1 makes
sense. I should be more conscious of that. Probably make it easier.
But this comes back to that for language design, there is more to it than
simply the syntax. There's a whole bit of other learning and experience
involved. This may be one reason I have difficulty with Perl. Sure I can say
ess-slash-bob-slash-fred-slash, but that doesn't "say" anything about a
substituition. I can easily convert "substitute" into "ess", as in a command
for an editor, but the other way around is more difficult. It's a one-way
hash, write-only code. Clearly with more experience, this all becomes more
natural, but it's all rote memorization rather than logical leaps and
bounds. I'm sure I'd have similar issue with something like APL.
Ah, well, the mind and the thread wanders. So, I'll shut up now.
Regards,
Will Hartung
(·····@msoft.com)
"Barry Margolin" <······@genuity.net> wrote in message
····················@paloalto-snr2.gtei.net...
> I have the same opinion, but this seems to be a very personal
> issue. I've heard people post the exact opposite opinion. They
> use LABELS by default because the functions are more like the
> ones defined using DEFUN, and they only use FLET when they want
> to prevent the functions from referring to each other (e.g. if
> they're redefining a function locally, and need to refer to the
> outer version).
>
> In the case of LET* and DO*, this style is a little less
> prevalent, probably because the "*" makes these functions seem
> "more special".
I'm one of those who uses LABELS by default, for the reason Barry
cites.
I also use LET* by default. Comparing
(let* ((foo ...)
(bar (f foo)))
...)
and
(let ((foo ...)
(bar (f foo)))
...)
the first seems normal to me but the second seems unusual and
worthy of being highlighted.
Another reason I prefer LET* is that, when editing, I often
transform code like
(let* ((foo ...)
(bar ...)
(baz (f foo bar)))
(g baz))
to
(let* ((foo ...)
(bar ...))
(g (f foo bar)))
or vice versa, either because I think the change makes things
clearer or because I want to fit things in to less horizontal or
vertical space. If I used LET in the cases where either LET or
LET* will do, such transformations would involve some thinking.