353Re: Digest Number 90
- May 17 9:38 AM--- In firstname.lastname@example.org, r2q2 <zitterbewegung@...> wrote:
>Fair enough. We woundn't want `functionalists' (mis)using
> Hence it was a recommendation and not a command.
`imperatives' thereby inducing nasty `side effects',
would we ;-]
> The repl doesn't care but I don't have to tell youYou nor anybody else ... unless they're paying for it.
> how to format your code.
When I've produced source code professionally I've fully
expected that my employer was paying me to format code
as per their specifications. When I'm goofing around
on my own time I fully expect voluntacracy to prevail.
If I'm volunteering to `share' I expect to `speak' or
`express' more freely than when I'm prostituting my talents
as a professional.
> Most lispers just find that method of formattingI would -- and do -- agree.
> much easier to look at.
And most lispers -- and most programmers -- tend towards
obsessive-compulsives, it seems. Though I may be `projecting'.
And I do resemble this remark.
I did not present my stimuli in the form of a `list' or
symbolic expression' for the benefit of `most lispers'; I
presented it for the intended benefit of newbies who haven't
quite resonated with the `group grok' of either `most lispers'
or obsessive-compulsives. For what it's worth, one CAN have
it both -- if not many -- ways. One CAN write/generate lisp
and scheme code using one's own idiosyncratic style -- or
lack thereof, as in my own case -- then pretty-print one's
pro_forma `ugly' code into what `most lispers just find much
easier to look at'.
> Also I could list all of the lisp implementations but I justSure. It seems you responded in good faith to the question I posed.
> wanted to list the major ones at that time.
The point I was attempting to make was/is that Awareness
of valid-in-many-contexts possibly-repurposed nature of *most*
of the would-be `scheme' code created by Schemers at *all* levels
of proficiency/development. I, for one, don't know ML and
quite a few other members of the Lisp family of languages. So
I don't know if my lispoid symbolic expressions can be re-used
as stimuli to present to ML REPLs. But I'd like to think that
as I do become familiarized with other Lisp family members that
I can and will continue to synthesize `code' which just may
work on/with as many family members as desirable.
In closing I'll present another format which a friend has
shown some appreciation over the one which some or most
find `easier to look at':
) ;end_of let_bindings
(* x x) ; x squared
(* y y) ; y squared
)) ;end_of sqrt of sum of squares
) ;end_of let
The friend who vocalized preference for this documentation
of closing parens was taught Java in college. And he
was too uncertain/confused by the cluster of ambiguous
closing parens which typically terminates a lispoid expression.
By way of contrast here is a minimalist form of the same:
(let ((x 3)(y 4))(sqrt (+ (* x x) (* y y))))
;-- not-quite-clear closing parens -----^^^^
So, given that its all the same to a given REPL, I sometimes
choose to pander/cater to my friends who have suspended
disbelief enough to allow me to show them some lisp or
scheme. I've learned this the hard way. Most who have
allowed me to `state my case' have rejected both Lisp
and Scheme for the same reason --
Lots-of Inane Silly Parentheses.
So, rather than compell an otherwise open mind to
make a quantum leap onto a Procrustean Bed of what
`Most lispers just find much easier to look at'
(aside: Is this analogous to `The Playboy standard of beauty'?)
I sometimes attempt to provide intermediate steps
down the path to lisp acceptance.
BTW. David Touretzky, in his _Common Lisp: A Gentle Introduction to
Symbolic Computation_ doesn't even expose
those-he-attempts-to-proselytize to parenthesized expressions
until the 3rd or 4th chapter in preference to box-and-pointer
notation. But then again, D. Touretzky seems a good deal wiser
and gentler than, as you say, `most lispers'. But then again,
it seems that `most lispers' may be as obsessive about
`syntactic sugar' as those who reject lisp because it doesn't
`look like' C, C++, Java, and their ilk.
Though I could be wrong ;-]
> On 16 May 2006 14:08:43 -0000, email@example.com
> <firstname.lastname@example.org> wrote:
>> There is 1 message in this issue.
>> Topics in this digest:
>> 1. recommended formatting ... one-size-fits-all
>> From: "gene_sullivan" gene_sullivan@...
>> Message 1
>> From: "gene_sullivan" gene_sullivan@...
>> Date: Mon May 15, 2006 8:44am(PDT)
>> Subject: recommended formatting ... one-size-fits-all
>> --- In email@example.com, r2q2 <zitterbewegung@> wrote:
>> > In regards to the choice of emacs amen.
>> > Also the bit of code is both
>> > emacs and scheme and also common lisp.
>> Is qua IS. :-]
>> Might even be a few others too, don't you think?
>> All too often newbies and crusty old coders alike manifest
>> the cognitive error of is-and-only-IS while they are generating
>> whatever they believe-into-being, say, `scheme' code ... or
>> `symbolic expressions'. It seems to me that a behaviorist
>> model of computing is often more helpful; to wit, if one regards
>> the symbolic expression -- in the form of a let binding -- I sent
>> as stimuli (EG plural of stimulus) which can be presented to (m)any
>> Pavlovian REPLs in an attempt to evoke/goad/induce
>> effects_or/and_side_effects-come-`responses' -- a_la a
>> Stimuli-Responses model of `computing' --then this `one-and-only'
>> cognitive error is more likely to be-qua-be lessened or precluded.
>> Or, so it seems to me anyway.
>>> Also I recommend formatting
>>> your code like this.
>>> ((x 3)
>>> (y 4))
>>> (sqrt (+ (* x x) (* y y))))
>> Recommend pursuant to what end?
>> If you or anyone wants code formated like this there
>> are implementations of pretty-print available in all
>> the Lisp family members you mentioned, aren't there?
>> As the REPLs (EG Read-Eval-Print-Loops) don't give
>> a fuzzy rats butt one way or the other (arguably one
>> of the benefits of explicate expressions via parenthesization,
>> rather than languages which use more-sloppy implicate
>> delimiters such as carrage-returns?) it allows one to
>> format a snippet of code to highlight something the
>> human eye can more readily detect. A friend of mine
>> I've been attempting to convince of the values and virtues
>> of elisp and AutoLISP (used within AutoCAD and other
>> CAD applications) complained of the need to count parentheses.
>> Lining up matching parentheses in the format I did allows my
>> friend and others visual cortexts to notice ballanced
>> parentheses from within emails -- where emacs' parens matcher
>> is not available.
>> So -- by way of reciprocity -- I recommend that if you want
>> any of my code pretty-printed, just do it. I'm not here to
>> spoon feed you code in the format you prefer. I'll pander/cater
>> to my friends and newbies while satisfying the constraints of
>> various Lisp family REPLs. And, likewise, if I see any
>> code of yours which doesn't comply with my obsessive-compulsive
>> `need' to either `see' or `have' it otherwise I'll take on the
>> burden of re-formatting as per my one-and-only-one `right' way.
>> If you think the previous form was less-than-optimal,
>> what do you think of this one?
>> (let ;--*--*--*--*--*--*--*--*--*--*--*--*--*--*--v
>> ( ;let_bindings --------------------------v
>> (x 3)
>> (y 4)
>> ) ;let_bindings --------------------------^
>> (sqrt (+ (* x x) (* y y)))
>> ) ;--*--*--*--*--*--*--*--*--*--*--*--*--*--*--^
>> Pretty ugly, huh?
>> Okay. Now imagine, if you will, someone whose task
>> it is to scroll back and forth through Lispoid
>> code to check for ballanced parentheses without the
>> aid of emacs or some other editor which does
>> parens matching. Isn't it easier to visually scan for
>> vertically matched pairs of down-arrowish `v' and
>> up-arrowish `^' characters?
>> This `task' is one which emerges while newbie Lisp
>> and Scheme coders encounter when parens aren't matched.
>> When stimuli-to-be-fed-to-REPL is formated this way
>> it fascilitates human scanning pursuant to that end.
>> It may be aesthetically ugly vis-a-vis the pretty-print
>> standard, but it -- arguably -- may just have some
>> utilitarian merit. I'll leave this assessment to others
>> to judge for themselves. I'm sure most would agree that
>> if a given REPL doesn't care, then silly human aesthetics
>> or `human factors' are at issue; not the validity or
>> utility of the stimuli itself from the perspective of a REPL.
- << Previous post in topic