I just thought of a specification for a weird lisp-2:
It has function and value cells but figures this out automagically (with
something like identifier-has-procedure?) without bothering the user.
It's somewhat backwards compatible with Scheme (you might want to
replace procedure? with identifier-has-procedure?), allows punning, and
have no need for explicit FUNCALL or #'. The idea should also generalize
to CL-like dialects, though Scheme is used for example code below:
(define a print)
(define a "hello")
(define (test x y) (x y))
(test a a) ; prints "hello"
Perverse!
(let ((list '(a b c d))) ; this doesn't shadow list
(list list))
=> ((a b c d))
(let ((list (lambda (x) 'hmmm))) ; this shadows list
(list list))
=> hmmm
Still allows all lovely/dubious scheme stuff like:
(rpn 1 1 +) ; my friend!
(define (bar) (identity bar))
(((((bar))))) => bar
and even some new stuff like
(define bar 'this-goes-into-value-cell)
(((((bar))))) => 'this-goes-into-value-cell ; given that the function
cell was defined as above
There's a slight problem with call-by-value, you'll have to tweak the
evaluation semantics. I think I've got some solutions to this somewhere
in my skull - it might suffice to change the semantics of
((lambda (new) ...) old)
to make new a shallow copy of all cells of the identifier old, instead
of just the value cell.
Maybe there are other problems (apart from the aesthetic and performance
(Sufficiently Smart Compiler(TM) to the rescue!) problems) I haven't
thought of yet, which'll make it unworkable.
I haven't bothered to implement this because it's so kink, and I'm lazy,
and I just thought of it, and I'm exhausted to the point of
hallucinations from an hour-long bike-ride, but do you think that anyone
would like this?
Regardless, it might be useful as a rhetorical device that both sides in
the ceaseless flamewar between lisp-1 and lisp-2 can use to their
advantage. Or maybe it can bring peace and prosperity to the world.
YEAH, RIGHT! AS IF THOSE CRACKSMOKERS WOULD EVER CHANGE THEIR MINDS, YOU
KNOW WHO I'M TALKING ABOUT. (Err... I'm talking about those with a
differing opinion in the namespace question than you, dear reader, of
course. Not you, I know you'd never touch the pipe, and I know that the
#\c in the name of your favourite lisp doesn't stand for HUGE FREAKING
ROCKS unlike THAT OTHER SHADY CAMP!)
I dub the idea DWIM-lisp-2.
(I don't claim to be the first to invent this - the lisp community has
seen its fair share of monstrosities over the last half-century - but I
haven't seen it, so I do claim independent reinvention.)
XOXOXO,
Sunnan
Follow-up set.
Sunnan wrote:
>
> (let ((list '(a b c d))) ; this doesn't shadow list
> (list list))
> => ((a b c d))
>
> (let ((list (lambda (x) 'hmmm))) ; this shadows list
> (list list))
> => hmmm
(let ((list '()))
(procedure? list)) => ? ; as if we need more ambiguity
I see that this is posted to both cls and cll. Did I misunderstand how
follow-up works?
alex goldman wrote:
> Sunnan wrote:
>
>
>>(let ((list '(a b c d))) ; this doesn't shadow list
>> (list list))
>>=> ((a b c d))
>>
>>(let ((list (lambda (x) 'hmmm))) ; this shadows list
>> (list list))
>>=> hmmm
>
>
>
> (let ((list '()))
> (procedure? list)) => ? ; as if we need more ambiguity
>
As I tried to clarify, in "freak DWIM lisp-2", you use
"identifyer-has-procedure?" to find out whether or not the function cell
of the identifier list has been bound to a function. "procedure?"
doesn't exist.
Sunnan wrote:
> I just thought of a specification for a weird lisp-2:
Oh please please tell me the spec will still only be one page long! That
is soooooo important.
>
> It has function and value cells but figures this out automagically (with
> something like identifier-has-procedure?) without bothering the user.
I see. You realize Common Lisp is winning and that it is just a matter
of months before the Scheme rebellion is pushed into the sea. Of course
you want to negotiate.
Ha! The amnesty period ends on the last day of spring. Throw down your
arms and approach the Common Lisp camp with your hands over your head
holding a copy of Practical Common Lisp. It is a little longer than one
page, so we understand if you have to stop to rest your arms every few
yards.
>
> It's somewhat backwards compatible with Scheme (you might want to
> replace procedure? with identifier-has-procedure?), allows punning, and
> have no need for explicit FUNCALL or #'. The idea should also generalize
> to CL-like dialects, though Scheme is used for example code below:
>
> (define a print)
> (define a "hello")
> (define (test x y) (x y))
> (test a a) ; prints "hello"
>
> Perverse!
Ya think? What problem are you trying to solve, other than Scheme's
imminent extinction?
>
>
> (let ((list '(a b c d))) ; this doesn't shadow list
> (list list))
> => ((a b c d))
>
> (let ((list (lambda (x) 'hmmm))) ; this shadows list
> (list list))
> => hmmm
>
> Still allows all lovely/dubious scheme stuff like:
>
> (rpn 1 1 +) ; my friend!
>
> (define (bar) (identity bar))
> (((((bar))))) => bar
>
> and even some new stuff like
> (define bar 'this-goes-into-value-cell)
> (((((bar))))) => 'this-goes-into-value-cell ; given that the function
> cell was defined as above
>
> There's a slight problem with call-by-value, you'll have to tweak the
> evaluation semantics. I think I've got some solutions to this somewhere
> in my skull - it might suffice to change the semantics of
>
> ((lambda (new) ...) old)
>
> to make new a shallow copy of all cells of the identifier old, instead
> of just the value cell.
>
> Maybe there are other problems (apart from the aesthetic and performance
> (Sufficiently Smart Compiler(TM) to the rescue!) problems) I haven't
> thought of yet, which'll make it unworkable.
>
> I haven't bothered to implement this because it's so kink, and I'm lazy,
> and I just thought of it, and I'm exhausted to the point of
> hallucinations from an hour-long bike-ride, but do you think that anyone
> would like this?
>
> Regardless, it might be useful as a rhetorical device that both sides in
> the ceaseless flamewar between lisp-1 and lisp-2 can use to their
> advantage.
Ah, there is your mistake: "ceaseless". That rumbling you hear is the
Common Lisp tank coming up behind your Scheme track bike to administer a
cessation.
> Or maybe it can bring peace and prosperity to the world.
> YEAH, RIGHT! AS IF THOSE CRACKSMOKERS WOULD EVER CHANGE THEIR MINDS, YOU
> KNOW WHO I'M TALKING ABOUT. (Err... I'm talking about those with a
> differing opinion in the namespace question than you, dear reader, of
> course. Not you, I know you'd never touch the pipe, and I know that the
> #\c in the name of your favourite lisp doesn't stand for HUGE FREAKING
> ROCKS unlike THAT OTHER SHADY CAMP!)
>
> I dub the idea DWIM-lisp-2.
>
> (I don't claim to be the first to invent this - the lisp community has
> seen its fair share of monstrosities over the last half-century - but I
> haven't seen it, so I do claim independent reinvention.)
>
> XOXOXO,
> Sunnan
> Follow-up set.
yer gonna love FUNCALL.
:)
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> Oh please please tell me the spec will still only be one page long!
Well, actually, yeah.
> That is soooooo important.
Please, tell me that your sarcastic adverbs will still have less than
seven #\os!
> Ha! The amnesty period ends on the last day of spring. Throw down your
> arms and approach the Common Lisp camp with your hands over your head
> holding a copy of Practical Common Lisp. It is a little longer than one
> page, so we understand if you have to stop to rest your arms every few
> yards.
"Practical..."? What's that? I am an idealist! I WILL NEVAR SURRENDAR!
>> It's somewhat backwards compatible with Scheme (you might want to
>> replace procedure? with identifier-has-procedure?), allows punning,
>> and have no need for explicit FUNCALL or #'. The idea should also
>> generalize to CL-like dialects, though Scheme is used for example code
>> below:
>>
>> (define a print)
>> (define a "hello")
>> (define (test x y) (x y))
>> (test a a) ; prints "hello"
>>
>> Perverse!
>
>
> Ya think? What problem are you trying to solve, other than Scheme's
> imminent extinction?
Either:
I was tossing the lisp-2 community a little breadcrumb - the ability to
use functions as arguments without the sharp-quote-eyesores - and/or I
was giving some people the opportunity to say that they LIKE
funcalls/sharp-quotes; and that it's not *only* the ability to go (list
list) that they're after.
Or:
I was tossing the lisp-1 community a little breadcrumb - the ability to
use identifiers for more than one thing at the same time, or... er...
hrm.. something something.
>> Regardless, it might be useful as a rhetorical device that both sides
>> in the ceaseless flamewar between lisp-1 and lisp-2 can use to their
>> advantage.
>
>
> Ah, there is your mistake: "ceaseless". That rumbling you hear is the
> Common Lisp tank coming up behind your Scheme track bike to administer a
> cessation.
Watch out, or I'll hit you with a flower!
> yer gonna love FUNCALL.
:)
(Have a nice spring. I hope it's a beautiful day where you are.)
Peace,
Sunnan
Sunnan wrote:
> Kenny Tilton wrote:
>
>> Oh please please tell me the spec will still only be one page long!
>
>
> Well, actually, yeah.
Ah, well, the only complaints we are getting from the hordes of newbies
stampeding into c.l.l. is that /more/ things should be standardized,
such as threads, sockets, and FFI. So I think the Scheme bet on a small
spec qua language feature sleeps with the fish.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
>
>
> Sunnan wrote:
>
>> Kenny Tilton wrote:
>>
>>> Oh please please tell me the spec will still only be one page long!
>>
>>
>>
>> Well, actually, yeah.
>
>
> Ah, well, the only complaints we are getting from the hordes of newbies
> stampeding into c.l.l. is that /more/ things should be standardized,
> such as threads, sockets, and FFI. So I think the Scheme bet on a small
> spec qua language feature sleeps with the fish.
>
Not that this wasn't about primarily about Scheme vs CL, or about
specification size.
From: Kent M Pitman
Subject: Re: An idea for a freak DWIM lisp-2
Date:
Message-ID: <uu0li7vn5.fsf@nhplace.com>
[Replying to comp.lang.lisp only.
http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
Kenny Tilton <·······@nyc.rr.com> writes:
> Sunnan wrote:
> ...
> > (define a print)
> > (define a "hello")
> > (define (test x y) (x y))
> > (test a a) ; prints "hello"
> > Perverse!
This is a semantic nightmare because it creates situations where the
compiler can't tell what words mean and it has to put off the
decision-making to runtime.
It reminds me of how in the transition from Maclisp to Common Lisp,
there was a time during which there were math operators that sometimes
did truncating arithmetic (with integers) and sometimes not (with
"flonums"). It was fine when you could see the type of the results
because you could correctly cast these from Maclisp into Common Lisp
during a translation by changing the operator (adding a truncation or
rounding operation), but it was NOT fine when you came up against just
(op random-name random-other-name). It impeded compile-time analysis
and ended up mostly dispatching to stupid runtime functions.
I took a psychology course once in "natural concepts" in which one of
the big take-home messages was that 'and' was a good constructor for
natural concepts. That is, something that is both an animal AND has
four legs easily forms a natural concept that people are happy
reasoning about. It's how subclassing is done. But 'or', by
contrast, does not form natural concepts that people are happy with.
Reasoning about the set of things that are 'green today or blue
tomorrow' (or even just 'green or blue') is a lot harder than
reasoning about things that are 'green and blue'. One gets you a
single, niclely restricted set while the other gets you unions of
unrelated sets.
Sunnan's example above leads down the unnatural path, reasoning about
things that are 'functions today but maybe variables tomorrow'.
[It hadn't occurred to me before, but the cross-posting URL above
makes the same point in a different way. It doens't allude to
"natural concepts", but in principle could.]
> Ya think? What problem are you trying to solve, other than Scheme's
> imminent extinction?
There is a legitimate issue here, which is the huge gap in
compatibility between the two communities. I'm not sure that it can
be addressed, and maybe we're better off with that big divide than
not. It's often remarked that the bitterest battles in the world come
from communities that are close cousins, not distant acquaintances.
But regarding this big division between Lisp1 and Lisp2, I did once
make a stab at thinking about it and simply ran out of time to think
further, so dumped the intermediate result to the web. I've mentioned
it before and I don't think a single person has ever sent me mail
about it, nor mentioned it publicly. So perhaps it was either
incomprehensible (and people were afraid to respond) or stupid
(and people were too polite to respond). [It did look in the web logs
like people did actually view it, so I don't expect no one reads my
posts.] I almost hesitate to mention it anew, but at least it's a
pleasant change from babbling about free software...
http;//www.nhplace.com/kent/Half-Baked/
From: Kent M Pitman
Subject: Re: An idea for a freak DWIM lisp-2
Date:
Message-ID: <ufyx1r0y9.fsf@nhplace.com>
Ingvar <······@hexapodia.net> writes:
> Kent M Pitman <······@nhplace.com> writes:
>
> [ SNIP ]
> > But regarding this big division between Lisp1 and Lisp2, I did once
> > make a stab at thinking about it and simply ran out of time to think
> > further, so dumped the intermediate result to the web. I've mentioned
> > it before and I don't think a single person has ever sent me mail
> > about it, nor mentioned it publicly. So perhaps it was either
> > incomprehensible (and people were afraid to respond) or stupid
> > (and people were too polite to respond). [It did look in the web logs
> > like people did actually view it, so I don't expect no one reads my
> > posts.] I almost hesitate to mention it anew, but at least it's a
> > pleasant change from babbling about free software...
> > http;//www.nhplace.com/kent/Half-Baked/
>
> Not having looked lately, but if this is the idea of introducing a
> "front-end" layer and a "back-end" layer, where the back-end klayer is
> (effectively) a translation from:
> (fun arg ...)
> to either:
> ((function fun) (value arg) ...)
> or:
> ((value fun) (value arg) ...)
> ;; possibly introduce a typecheck for (value fun)
Actually, to (call (function fun) (value arg) ...)
or (call (value fun) (value arg) ...). That is, the whole premise is
that EVERY fully macroexpanded form has a special form in the car, even
function calls, so that no one fights over the meaning of the shorthand
(fn x y z), which has to be contextually defined within the language's
scoping rules.
But yes, you're clearly referring to the stuff in the space I mentioned,
even if your summary is off in that one small detail. I sometimes called
this my Lisp-Omega process because even (function fun) becomes
(value fun function), where the second arg is a keyword naming the namespace,
and there can be, in principle, any number of namespaces [hence the omega].
My impression, actually, is that the Scheme folks, the ones who care about
the formal semantics part anyway, would be fine about a Lisp-Omega. It's
a Lisp-n for some finite and seemingly arbitrary n that seems to bug them.
And the lack of syntactic flexibility to bend (f x) to their needs on a
personal basis.
But the devil is in the details, and I didn't do the details. So the
project awaits somebody else to pursue it. Maybe some daring student
desperate for a thesis topic in a very questionable area of interest...
> I found the concept interesting.
Wow. Someone actually commented. Cool. Thanks.
> I am not entirely sure how *trivial*
> it would be to make it happen,
I'm thinking if it were trivial I'd probably have fully baked the idea
by now, but maybe someone will point out something I overlooked.
> but it is probably a niche in implementation-space taht is worthy of
> exploring. Paired with a "personality declaration" (so one can
> switch between different translational behaviours in the source),
> it'd probably make for a good language.
I'd hope so. But one never knows until it's tried.
Ingvar wrote:
>
> Well, people do stranger things for theses (implementing Modelica
> compilers for one).
Strange but interesting and cool! What about a Hybrid and/or Reactive
layer on top of Common Lisp? :)
Cheers
--
Marco
On Fri, 06 May 2005 11:14:30 +0100, Ingvar wrote:
> Sound principle, in a way. I can't recall where I heard it, but it was
> something along the lines of "there's no justification needed for 0, 1
> or infinite ways of doing things, anything else needs a justification".
<http://c2.com/cgi/wiki?ZeroOneInfinityRule>
Regards,
Adam
From: Kent M Pitman
Subject: Re: An idea for a freak DWIM lisp-2
Date:
Message-ID: <ud5s4qykd.fsf@nhplace.com>
Adam Warner <······@consulting.net.nz> writes:
> On Fri, 06 May 2005 11:14:30 +0100, Ingvar wrote:
> > Sound principle, in a way. I can't recall where I heard it, but it was
> > something along the lines of "there's no justification needed for 0, 1
> > or infinite ways of doing things, anything else needs a justification".
>
> <http://c2.com/cgi/wiki?ZeroOneInfinityRule>
Yeah, and I'm sure it's probably linked to or mirrored at www.mormon.org.
Kent M Pitman wrote:
> Adam Warner <······@consulting.net.nz> writes:
>
>> On Fri, 06 May 2005 11:14:30 +0100, Ingvar wrote:
>>> Sound principle, in a way. I can't recall where I heard it, but it was
>>> something along the lines of "there's no justification needed for 0, 1
>>> or infinite ways of doing things, anything else needs a justification".
>>
>> <http://c2.com/cgi/wiki?ZeroOneInfinityRule>
>
> Yeah, and I'm sure it's probably linked to or mirrored at www.mormon.org.
?
--
Gareth McCaughan
.sig under construc
From: Kent M Pitman
Subject: Re: An idea for a freak DWIM lisp-2
Date:
Message-ID: <u4qdf537v.fsf@nhplace.com>
Gareth McCaughan <················@pobox.com> writes:
> Kent M Pitman wrote:
>
> > Adam Warner <······@consulting.net.nz> writes:
> >
> >> On Fri, 06 May 2005 11:14:30 +0100, Ingvar wrote:
> >>> Sound principle, in a way. I can't recall where I heard it, but it was
> >>> something along the lines of "there's no justification needed for 0, 1
> >>> or infinite ways of doing things, anything else needs a justification".
> >>
> >> <http://c2.com/cgi/wiki?ZeroOneInfinityRule>
> >
> > Yeah, and I'm sure it's probably linked to or mirrored at www.mormon.org.
>
> ?
I was wondering if anyone was going to be confused. Since you ask, there
are two reasons I mentioned this.
First, Mormons support polygamy. Presumably they could argue, by the
aforementioned rule, that 'infinity' is a bound that requires no
justification and is simply an obviously elegant boundary.
But second, it brings up the matter that I see is confirmed later in
that entry, which is whether the rule "one, two, many" has as much weight.
And then that gets into the issue of what you're counting.
The statements "A marriage is between a man and a woman." is one I've
heard a lot in the last election. Let's ignore the gender. The point
is that the definition seems to involve two entities. Under the above
rule, that's "inelegant".
Then again, if they were saying "Everyone should be permitted only one
wife." it would become elegant again.
It made me think that perhaps we should confront the Schemers with the
idea that Lisp wants "exactly one namespace other than value." That's
elegant, right? It uses "one". And by induction, anyone wanting just
one more than someone already proved to be elegant is also elegant, using
only the zero,one,infinity rule as the base case.
- - - -
I actually do think there is some niceness to that zero-one-infinity rule.
But clearly it can be pushed only so far. It's like the emacs command set:
there are all kinds of graceful relationships between various sets of keys,
but there's very little in the way of graceful relationship between the
various graceful relationships... The world is just complicated, and no
one rule fits all cases.
Kent M Pitman wrote:
> First, Mormons support polygamy. Presumably they could argue, by the
> aforementioned rule, that 'infinity' is a bound that requires no
> justification and is simply an obviously elegant boundary.
AFAIK they used to (and some might still support it), but in
general most Mormons are monogamous.
I think Muslims can have more than one wife, if they can support them.
> But second, it brings up the matter that I see is confirmed later in
> that entry, which is whether the rule "one, two, many" has as much weight.
>
> And then that gets into the issue of what you're counting.
>
> The statements "A marriage is between a man and a woman." is one I've
> heard a lot in the last election. Let's ignore the gender. The point
> is that the definition seems to involve two entities. Under the above
> rule, that's "inelegant".
>
> Then again, if they were saying "Everyone should be permitted only one
> wife." it would become elegant again.
Ahuh? What's the difference between "involving two entities" and
"being allowed one wife"?
> It made me think that perhaps we should confront the Schemers with the
> idea that Lisp wants "exactly one namespace other than value." That's
> elegant, right? It uses "one". And by induction, anyone wanting just
> one more than someone already proved to be elegant is also elegant, using
> only the zero,one,infinity rule as the base case.
But Scheme only has one namespace for all names (functions are
only variables)? Lisp might use infinitely many, at least with
packages ;)
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
From: Kent M Pitman
Subject: Re: An idea for a freak DWIM lisp-2
Date:
Message-ID: <upsw33jij.fsf@nhplace.com>
Ulrich Hobelmann <···········@web.de> writes:
> Ahuh? What's the difference between "involving two entities" and
> "being allowed one wife"?
The use of "one" vs the use of "two". The rule under discussion does not
discuss units. It just say that the numbers 0, 1, and infinity are special,
pretty much independent of context. The fact that when one shifts context,
the numbers change kind of deflates that balloon.
> > It made me think that perhaps we should confront the Schemers with the
> > idea that Lisp wants "exactly one namespace other than value." That's
> > elegant, right? It uses "one". And by induction, anyone wanting just
> > one more than someone already proved to be elegant is also elegant, using
> > only the zero,one,infinity rule as the base case.
>
> But Scheme only has one namespace for all names (functions are only
> variables)? Lisp might use infinitely many, at least with packages ;)
No, those aren't namespaces. Those are packages. They are orthogonal.
Packages are a property of the identifier, not of the lookup technique.
Packages have effect even in data-only situations, with no compilation
or lexical analysis issues in play. Namespaces make sense only in the
context of a program's semantics as applied to an expression and rely
only on identifiers being different, not caring about whether the
difference is due to packageness or spelling/interning of variables within
a single package.
Kent M Pitman <······@nhplace.com> schrieb:
> The rule under discussion does not discuss units. It just say that
> the numbers 0, 1, and infinity are special, pretty much independent of
> context. The fact that when one shifts context, the numbers change
> kind of deflates that balloon.
It's a rule for conceptual units, and as such it doesn't govern the
number of things but rather the ways that you group them. That the
numbers change depending on your context is indeed the whole point.
(Warning: mathematicophilosophical maunderings ahead.
Proceed with caution.)
Kent M Pitman wrote:
[about the "0,1,infinity rule"]
>>> Yeah, and I'm sure it's probably linked to or mirrored at www.mormon.org.
>>
>> ?
>
> I was wondering if anyone was going to be confused. Since you ask, there
> are two reasons I mentioned this.
>
> First, Mormons support polygamy. Presumably they could argue, by the
> aforementioned rule, that 'infinity' is a bound that requires no
> justification and is simply an obviously elegant boundary.
>
> But second, it brings up the matter that I see is confirmed later in
> that entry, which is whether the rule "one, two, many" has as much weight.
[etc]
I don't think anyone seriously regards the 0,1,oo rule
as Holy Writ. It's a useful rule of thumb. Let me suggest
two other ways of stating more or less the same thing:
- Anywhere in your program or design where you have
a number, it's probably a bad sign if there isn't
a clear answer to all questions of the form "so why
not ___ instead?" with another number filled in.
(An answer might be clear by virtue of being already
there in the comments or design documents, or by
virtue of being obvious.)
- Anything in your design that needs *numbers* as such
is likely to be wrong; all numbers should be readily
explicable (and explained) in non-numerical terms.
Neither of these is intended to be more than a rule of
thumb either. And I hope I don't need to say explicitly
that, e.g., the second version doesn't justify using
9 as a magic number in a networking protocol because
you could replace it with "the number of planets in
our solar system" :-).
These are both special cases of a more general principle.
- Suppose there is some symmetry or near-symmetry of
the space of all programs. Then any respect in which
your program fails to be invariant under it needs
justification. (Likewise for designs.)
More tersely: symmetries should not be broken without
reason.
All numbers look somewhat alike, especially large-ish
ones, so if you use the number 1729 somewhere in your
program or design then there ought to be some reason
why it's better than 1728 or 729 or 9271. (Anyone who
thinks I'm denying that different numbers have
different properties should google for "hardy taxicab"
and reflect on my choice of example.)
Similarly, if your program has variables called a,b,c
then permuting them is a near-symmetry, so either your
program should be invariant under that permutation
(as e.g. if everything done with them is symmetrical)
or there should be a reason for the asymmetry (as
e.g. if you're using c for the speed of light).
Once again, if you try to treat this as a hard-and-fast
rule you'll likely get silly results.
Here's a complementary principle:
- Suppose your program is invariant under some symmetry.
Then that's probably a sign that you could make it
shorter and clearer by expressing the symmetry explicitly.
This is why you replace repeated code with loops and
functions and macros and so on, and why you replace
repeated variables with aggregate data structures,
and why you move common structure or functionality
up from subclasses into their common superclasses.
Do these principles contradict one another? Not when
rightly understood, because there are two different
ways in which something can be invariant. It can have
different parts that are the same, or it can have
single parts that are themselves symmetrical. It's
really the first case that's discouraged, not the
second.
This is all rather half-thought-through, but I need
to go and put some shelves up now. :-)
--
Gareth McCaughan
.sig under construc