Python syntax in Lisp and Scheme

[Rob Warnock]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)

Christos "TZOTZIOY" Georgiou <tzot@sil-tec.gr> wrote:
+---------------
| AFAIK car stands for contents of address register and
| cdr for contents of contents of data register.
+---------------

From the IBM 704 CPU instruction format:
CAR == "Contents of Address [part of] Register".
CDR == "Contents of Decrement [part of] Register".
See <URL:http://www.catb.org/~esr/jargon/html/C/cdr.html>.

Note that the PDP-10 AOBJP/AOBJN/BLKI/BLKO/PUSH/PUSHJ/POP/POPJ
instructions used a similar format, but with the "decrement" part
being a negative count in the upper half of the word (which was
*incremented* in parallel with the address in the lower half
[or in the case of POP & POPJ only, decremented in parallel with
the address]).


-Rob

-----
Rob Warnock <rpw3@rpw3.or g>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

[Roy Smith]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)

rpw3@rpw3.org (Rob Warnock) wrote:[color=blue]
> Note that the PDP-10 AOBJP/AOBJN/BLKI/BLKO/PUSH/PUSHJ/POP/POPJ
> instructions used a similar format.[/color]

I havn't thought about that stuff for many years. Now you've made my
brain hurt again.

[David Eppstein]

Re: Science is a human activity (was: Python syntax in Lisp and Scheme)

In article <1jclovopokeogr dajo6dfmhm090cd llfki@4ax.com>,
Michele Dondi <bik.mido@tisca linet.it> wrote:
[color=blue][color=green]
> >It's certainly true that mathematicians do not _write_
> >proofs in formal languages. But all the proofs that I'm
> >aware of _could_ be formalized quite easily. Are you
> >aware of any counterexamples to this? Things that
> >mathematicia ns accept as correct proofs which are
> >not clearly formalizable in, say, ZFC?[/color]
>
> I am not claiming that it is a counterexample, but I've always met
> with some difficulties imagining how the usual proof of Euler's
> theorem about the number of corners, sides and faces of a polihedron
> (correct terminology, BTW?) could be formalized. Also, however that
> could be done, I feel an unsatisfactory feeling about how complex it
> would be if compared to the conceptual simplicity of the proof itself.[/color]

Which one do you think is the usual proof?

http://www.ics.uci.edu/~eppstein/junkyard/euler/

Anyway, this exact example was the basis for a whole book about what is
involved in going from informal proof idea to formal proof:

http://www.ics.uci.edu/~eppstein/junkyard/euler/refs.html#Lak

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Christos TZOTZIOY Georgiou]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)

On Tue, 21 Oct 2003 01:52:07 -0500, rumours say that rpw3@rpw3.org (Rob
Warnock) might have written:
[color=blue]
>+---------------
>| AFAIK car stands for contents of address register and
>| cdr for contents of contents of data register.
>+---------------
>
>From the IBM 704 CPU instruction format:
>CAR == "Contents of Address [part of] Register".
>CDR == "Contents of Decrement [part of] Register".
>See <URL:http://www.catb.org/~esr/jargon/html/C/cdr.html>.[/color]

Thanks for correcting me :)
--
TZOTZIOY, I speak England very best,
Ils sont fous ces Redmontains! --Harddix

[Ken Shan]

Re: Express What, not How.

Raffael Cavallaro <raffael@mediao ne.net> wrote in article <aeb7ff58.03101 91822.726f6b16@ posting.google. com> in comp.lang.funct ional:[color=blue]
> Ken Shan <ken@digitas.ha rvard.edu> wrote in message news:<bmulki$8r g$1@news.fas.ha rvard.edu>...[color=green]
> > So according to you, I need to find a name for function
> > application, and not just any name -- it needs to be a name from the
> > problem domain.[/color]
> From the problem domain _at_that_level_ . If, at that level, we're
> dealing with array bounds checking (assuming, for the moment that
> we're using a language that doesn't have that built in), then function
> names like check-index, report-invalid-index-error, etc. are names
> from the problem domain at that level.[/color]

I'm not sure if I understand your notion of problem-domain levels. For
instance, in a preceding example

amount_due = sum(item_prices ) * (1 + tax_rate)

is the problem domain possibly "functions and their arguments", or is
the problem domain possibly "customer billing"? If the former, would
you rewrite the above expression with names in the problem domain, as in

amount_due = apply(*, apply(sum, item_prices), apply(+, 1, tax_rate)

or

amount_due = apply(apply, *,
apply(apply, sum, item_prices),
apply(apply, +, 1, tax_rate))

or

amount_due = apply(apply, apply, *,
apply(apply, apply, sum, item_prices),
apply(apply, apply, +, 1, tax_rate))

(when do I stop?)? If the latter, how would you recommend that I
(re)write the code... certainly, since the use of function application
is so pervasive in the above code, a human-readable name in the problem
domain is in order?

--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
"Who needs drugs when we have sex and chocolate?" -- Cory Kerens

[Greg Ewing (using news.cis.dfn.de)]

Re: Python syntax in Lisp and Scheme

Jacek Generowicz wrote:[color=blue]
> Yes, you use flet (or labels) if you want a local function definition,
> and defun if you want a global one. Lisp caters for both
> possibilities. Does Python ?[/color]

If you mean the ability to have a nested function definition
that actually defines a top-level function, then yes, it
does...

Python 2.2 (#1, Jul 11 2002, 14:19:37)
[GCC 3.0.4] on linux2
Type "help", "copyright" , "credits" or "license" for more information.[color=blue][color=green][color=darkred]
>>> def f():[/color][/color][/color]
.... global g
.... def g():
.... print "Urk!"
....[color=blue][color=green][color=darkred]
>>> g()[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'g' is not defined[color=blue][color=green][color=darkred]
>>> f()
>>> g()[/color][/color][/color]
Urk![color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Although I'm having a hard time imagining why you'd
actually *want* to do such a thing!

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Michele Dondi]

Re: Science is a human activity (was: Python syntax in Lisp and Scheme)

On Tue, 21 Oct 2003 20:33:23 -0700, David Eppstein
<eppstein@ics.u ci.edu> wrote:
[color=blue][color=green]
>> I am not claiming that it is a counterexample, but I've always met
>> with some difficulties imagining how the usual proof of Euler's
>> theorem about the number of corners, sides and faces of a polihedron
>> (correct terminology, BTW?) could be formalized. Also, however that
>> could be done, I feel an unsatisfactory feeling about how complex it
>> would be if compared to the conceptual simplicity of the proof itself.[/color]
>
>Which one do you think is the usual proof?
>http://www.ics.uci.edu/~eppstein/junkyard/euler/[/color]

Uhmmm, let me see... 13! (no, not the factorial of 13)
[color=blue]
>Anyway, this exact example was the basis for a whole book about what is
>involved in going from informal proof idea to formal proof:
>http://www.ics.uci.edu/~eppstein/jun.../refs.html#Lak[/color]

D'Oh! Unfortunate choice of mine...


Michele
--[color=blue]
> Comments should say _why_ something is being done.[/color]
Oh? My comments always say what _really_ should have happened. :)
- Tore Aursand on comp.lang.perl. misc

[Raffael Cavallaro]

Re: Express What, not How.

In article <521c61-o2i.ln1@proper. ptq.dyndns.org> ,
Ken Shan <ken@digitas.ha rvard.edu> wrote:
[color=blue]
> I'm not sure if I understand your notion of problem-domain levels. For
> instance, in a preceding example
>
> amount_due = sum(item_prices ) * (1 + tax_rate)
>
> is the problem domain possibly "functions and their arguments", or is
> the problem domain possibly "customer billing"?[/color]

How about simple arithmetic, which is built into most computer languages.

However, if you do this often enough in your code (i.e., compute a
total, then add the tax), you migh want to have a named function, say
"total-with-tax," instead of just reimplimenting it every time you use
it. It's simply a matter of how much of what you're doing is specific to
the larger problem, how much is just arithmetic, using built-ins, and,
probably most importantly, how often you'll be repeting yourself in
exactly the same way.



[snip][color=blue]
> (when do I stop?)?[/color]

When you reach the built-ins of the language, of course. No need to
define a method called "add" in a language that has + as a built in
function (unless you're going to overload addition to do something that
the built-in function doesn't do yet.)

But the very telling larger picture issue is that there is such a
reluctance to name bits of code that are going to be used more than once.

[Sampo Smolander]

car, cdr; 1sr, rst

In comp.lang.schem e Andrew Dalke <adalke@mindspr ing.com> wrote:[color=blue]
> Pascal Costanza:[color=green]
>> I don't know how this could be done with 1st, rst or hd, tl respectively.[/color][/color]
[color=blue]
> Okay, I gave alternatives of "." and ">" instead of "car" and "cdr"
> "." for "here" and ">" for "the rest; over there". These are equally
> composable.[/color]
[color=blue]
> . == car[color=green]
> > == cdr[/color]
> cadr == >.
> caddr == >>.
> cddr == >>[/color]

One can also go like:

1st == car
rst == cdr
1rst == cadr
1rrst == caddr
rrst == cddr

The benefit being, it's less messy to quote these in Usenet :-)

[Raffael Cavallaro]

Re: Express What, not How.

In article <877k30ishg.wl@ strelka.synthco de.com>,
Alex Shinn <foof@synthcode .com> wrote:
[color=blue]
> If you are seriously arguing against the use of HOFs in
> general then I think you have a lot to learn.[/color]

No, I'm not arguing against HOFs in general. I'm arguing against the
repeated use of the _same_ anonymous function throughout code. These
should clearly be named funtions instead.

But I've apparently touched a nerve, because so many FPers seem to
equate eschewing repetition of the same anonymous functional idoim in
numerous places throughout ones code, with an attack on HOF use itself.