Python syntax in Lisp and Scheme

[David Rush]

Re: Python syntax in Lisp and Scheme

On Fri, 3 Oct 2003 09:36:32 -0400, Terry Reedy <tjreedy@udel.e du> wrote:[color=blue]
> ... Lispers posting here have gone to pains to state that Scheme is
> not a dialect of Lisp but a separate Lisp-like language. Could you
> give a short listing of the current main differences (S vs. CL)?[/color]

Do you even begin to appreciate how inflammatory such a request is when
posted to to both c.l.l and c.l.s?

Anyway, as a fairly heavily biased Schemer:

Scheme vs Common Lisp

1 name space vs multiple name spaces
This is a bigger issue than it seems on the surface, BTW

#f vs nil
In Scheme an empty list is not considered to be the same
thing as boolean false

emphasis on all values being first-class vs ad-hoc values
Scheme tries to achieve this, Lisp is by conscious design a
compromise system design, for both good and bad

small semantic footprint vs large semantic footprint
Scheme seems relatively easier to keep in mind as an
additional language.CL appears to have several sub-languages
embedded in it. This cuts both ways, mind you.

Thos eare the most obvious surface issues. My main point is that it is
pretty much silly to consider any of the above in isolation. Both languages
make a lot of sense in their design context. I vastly prefer Scheme because
it suits my needs (small semantic footprint, powerful toolkit) far better
than CL (everything is there if you have the time to look for it). I should
point out that I build a lot of funny data structures (suffix trees and
other
IR magic) for which pre-built libraries are both exceedingly rare and
incorrectly optimized for the specific application.

I also like the fact that Scheme hews rather a lot closer to the
theoretical
foundations of CS than CL, but then again that's all part of the small
semantic
footprint for me.

david rush
--
(\x.(x x) \x.(x x)) -> (s i i (s i i))
-- aki helin (on comp.lang.schem e)

[Lulu of the Lotus-Eaters]

Re: Python syntax in Lisp and Scheme

grzegorz@pithek os.net (Grzegorz Chrupala) wrote previously:
|shocked at how awkward Paul Graham's "accumulato r generator" snippet is
|in Python:
|class foo:
| def __init__(self, n):
| self.n = n
| def __call__(self, i):
| self.n += i
| return self.n

Me too. The way I'd do it is probably a lot closer to the way Schemers
would do it:
[color=blue][color=green][color=darkred]
>>> def foo(i, accum=[0]):[/color][/color][/color]
... accum[0]+=i
... return accum[0]
...[color=blue][color=green][color=darkred]
>>> foo(1)[/color][/color][/color]
1[color=blue][color=green][color=darkred]
>>> foo(3)[/color][/color][/color]
4

Shorter, and without an awkward class.

Yours, David...

--
Buy Text Processing in Python: http://tinyurl.com/jskh
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <mertz@gnosis.c x> ]--------------------------

[Grzegorz Chrupała]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:
[color=blue]
> Guido's generally adamant stance for simplicity has been the
> key determinant in the evolution of Python. Guido is also on
> record as promising that the major focus in the next release
> of Python where he can introduce backwards incompatibiliti es
> (i.e. the next major-number-incrementing release, 3.0, perhaps,
> say, 3 years from now) will be the _elimination_ of many of
> the "more than one way to do it"s that have accumulated along
> the years mostly for reasons of keeping backwards compatibility
> (e.g., lambda, map, reduce, and filter, which Guido mildly
> regrets ever having accepted into the language).[/color]

I have some doubts about the notion of simplicity which you (or Guido) seem
to be taking for granted. I don't think it is that straightforwrd to agree
about what is simpler, even if you do agree that simpler is better. Unless
you objectivize this concept you can argue that a "for" loop is simple than
a "map" function and I can argue to the contrary and we'll be talking past
each other: much depends on what you are more familiar with and similar
random factors.

As an example of how subjective this can be, most of the features you
mention as too complex for Python to support are in fact standard in Scheme
(true lexical scope, implicit return, no expression/statement distinction)
and yet Scheme is widely regarded as one of the simplest programming
languages out there, more so than Python.

Another problem with simplicity is than introducing it in one place my
increase complexity in another place.
Specifically consider the simple (simplistic?) rule you cite that Python
uses to determine variable scope ("if the name gets bound (assigned to) in
local scope, it's a local variable"). That probably makes the implementor's
job simpler, but it at the same time makes it more complex and less
intuitive for the programmer to code something like the accumulator
generator example -- you need to use a trick of wrapping the variable in a
list.

As for Ruby, I know and quite like it. Based on what you tell me about
Python's philosophy, perhaps Ruby makes more pragmatic choices in where to
make things simple and for whom than Python.

--
Grzegorz

http://pithekos.net

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Lulu of the Lotus-Eaters wrote:
[color=blue]
> grzegorz@pithek os.net (Grzegorz Chrupala) wrote previously:
> |shocked at how awkward Paul Graham's "accumulato r generator" snippet is
> |in Python:
> |class foo:
> | def __init__(self, n):
> | self.n = n
> | def __call__(self, i):
> | self.n += i
> | return self.n
>
> Me too. The way I'd do it is probably a lot closer to the way Schemers
> would do it:
>[color=green][color=darkred]
> >>> def foo(i, accum=[0]):[/color][/color]
> ... accum[0]+=i
> ... return accum[0]
> ...[color=green][color=darkred]
> >>> foo(1)[/color][/color]
> 1[color=green][color=darkred]
> >>> foo(3)[/color][/color]
> 4
>
> Shorter, and without an awkward class.[/color]

There's an important difference: with your approach, you cannot just
instantiate multiple independent accumulators like with the other --
a = foo(10)
b = foo(23)
in the 'class foo' approach, just as in all of those where foo returns an
inner-function instance, a and b are now totally independent accumulator
callables -- in your approach, 'foo' itself is the only 'accumulator
callable', and a and b after these two calls are just two numbers.

Making a cookie, and making a cookie-cutter, are quite different issues.


Alex

[David Eppstein]

Re: Python syntax in Lisp and Scheme

In article <mailman.106528 8850.20400.pyth on-list@python.org >,
Lulu of the Lotus-Eaters <mertz@gnosis.c x> wrote:
[color=blue]
> grzegorz@pithek os.net (Grzegorz Chrupala) wrote previously:
> |shocked at how awkward Paul Graham's "accumulato r generator" snippet is
> |in Python:
> |class foo:
> | def __init__(self, n):
> | self.n = n
> | def __call__(self, i):
> | self.n += i
> | return self.n
>
> Me too. The way I'd do it is probably a lot closer to the way Schemers
> would do it:
>[color=green][color=darkred]
> >>> def foo(i, accum=[0]):[/color][/color]
> ... accum[0]+=i
> ... return accum[0]
> ...[color=green][color=darkred]
> >>> foo(1)[/color][/color]
> 1[color=green][color=darkred]
> >>> foo(3)[/color][/color]
> 4
>
> Shorter, and without an awkward class.[/color]

There's an important difference between these two: the object-based
solution (and the solutions with two nested functions and a closure)
allow more than one accumulator to be created. Yours only creates a
one-of-a-kind accumulator.

I happen to like the object-based solution better. It expresses more
clearly to me the intent of the code. I don't find the class awkward;
to me, a class is what you use when you want to keep some state around,
which is exactly the situation here. "Explicit is better than
implicit." Conciseness is not always a virtue.

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

[Kenny Tilton]

Flat-schmat! [was Re: Python syntax in Lisp and Scheme]



Alex Martelli wrote:
[color=blue]
> record as promising that the major focus in the next release
> of Python where he can introduce backwards incompatibiliti es
> (i.e. the next major-number-incrementing release, 3.0, perhaps,
> say, 3 years from now) will be the _elimination_ of many of
> the "more than one way to do it"s that have accumulated along
> the years mostly for reasons of keeping backwards compatibility
> (e.g., lambda, map, reduce, and filter,[/color]

Oh, goodie, that should win Lisp some Pythonistas. :) I wonder if Norvig
will still say Python is the same as Lisp after that.
[color=blue]
> Python draws a firm distinction between expressions and
> statements. Again, the deep motivation behind this key
> distinction can be found in several points in the Zen of
> Python, such as "flat is better than nested" (doing away
> with the expression/statement separation allows and indeed
> encourages deep nesting) and "sparse is better than dense"
> (that 'doing away' would encourage expression/statements
> with a very high density of operations being performed).[/color]

In Lisp, all forms return a value. How simple is that? Powerful, too,
because a rule like "flat is better than nested" is flat out dumb, and I
mean that literally. It is a dumb criterion in that it does not consider
the application.

Take a look at the quadratic formula. Is that flat? Not. Of course
Python allows nested math (hey, how come!), but non-mathematical
computations are usually trees, too.

I was doing an intro to Lisp when someone brought up the question of
reading deeply nested stuff. It occurred to me that, if the computation
is indeed the moral equivalent of the quadratic formula, calling various
lower-level functions instead of arithmetic operators, then it is
/worse/ to be reading a flattened version in which subexpression results
are pulled into local variable, because then one has to mentally
decipher the actual hierarchical computation from the bogus flat sequence.

So if we have:

(defun some-vital-result (x y z)
(finally-decide
(if (serious-concern x)
(just-worry-about x z)
(whole-nine-yards x
(composite-concern y z)))))

....well, /that/ visually conveys the structure of the algorithm, almost
as well as a flowchart (as well if one is accustomed to reading Lisp).
Unwinding that into an artificial flattening /hides/ the structure.
Since when is that "more explicit"? The structure then becomes implicit
in the temp variable bindings and where they get used and in what order
in various steps of a linear sequence forced on the algotrithm.

I do not know what Zen is, but I do now that is not Zen.

Yes, the initial reaction of a COBOL programmer to a deeply nested form
is "whoa! break it down for me!". But that is just lack of familiarity.
Anyone in a reasonable amount of time can get used to and then benefit
from reading nested code. Similarly with every form returning a
value...the return statement looks silly in pretty short order if one
spends any time at all with a functional language.


kenny

[Alexander Schmolck]

Re: Python syntax in Lisp and Scheme

[comp.lang.funct ional removed]
Peter Seibel <peter@javamonk ey.com> writes:
[color=blue]
> which seems pretty similar to the Python version.
>
> (If of course we didn't already have the FILL function that does just
> that.)[/color]

Just for the record, in python all you'd write is: v[:] = a

'as

[Marco Antoniotti]

Re: Python syntax in Lisp and Scheme



Alexander Schmolck wrote:[color=blue]
> prunesquallor@c omcast.net writes:
>
>[color=green]
>>mike420@zipli p.com writes:
>>
>>[color=darkred]
>>>I think everyone who used Python will agree that its syntax is
>>>the best thing going for it.[/color]
>>
>>I've used Python. I don't agree.[/color]
>
>
> I'd be interested to hear your reasons. *If* you take the sharp distinction
> that python draws between statements and expressions as a given, then python's
> syntax, in particular the choice to use indentation for block structure, seems
> to me to be the best choice among what's currently on offer (i.e. I'd claim
> that python's syntax is objectively much better than that of the C and Pascal
> descendants -- comparisons with smalltalk, prolog or lisp OTOH are an entirely
> different matter).
>[/color]

The best choice for code indentation in any language is M-C-q in Emacs.

Cheers
--
Marco

[David Rush]

Re: Python syntax in Lisp and Scheme

Since no one has done a point-by-point correction of the errors w/rt
Scheme...

On 03 Oct 2003 11:25:31 -0400, Jeremy H. Brown <jhbrown@ai.mit .edu> wrote:[color=blue]
> Here are a few of the (arguably) notable differences:
>
> Scheme Common Lisp
> Philosophy minimalism comprehensivene ss[/color]
orthogonality compromise
[color=blue]
> Namespaces one two (functions, variables)[/color]
more than two, actually
[color=blue]
> Continuations yes no
> Object system no yes[/color]

It really depends on how you define 'object system' as to whether or not
Scheme has one. I personally think it does, but you have to be prepared
to crawl around the foundations of OOP (and CS generally) before this
becomes apparent. It helps if you've ever lived with unconventional
object systems like Self.
[color=blue]
> Exceptions no yes[/color]
yes, via continuations which reify the
fundamental control operators in all languages
[color=blue]
> Macro system syntax-rules defmacro[/color]
most Schemes provide defmacro style macros as
they are relatively easy to implement correctly
(easier than syntax-rules anyway)
[color=blue]
> Implementations >10 ~4[/color]
too many to count. The FAQ lists over twenty. IMO
there are about 9 'major' implementations which
have
relatively complete compliance to R5RS and/or
significant extension libraries
[color=blue]
> Performance "worse" "better"[/color]
This is absolutely wrong. Scheme actually boasts
one
of the most efficient compliers on the planet in
the
StaLIn (Static Language Implementation) Scheme
system.
Larceny, Bigloo, and Gambit are also all quite
zippy
when compiled.
[color=blue]
> Standards IEEE ANSI[/color]
Hrmf. 'Scheme' and 'Standard' are slightly skewed
terms.
This is probably both the greatest weakness of
the
language and also its greatest strength. R5RS is
more
of a description to programmers of how to write
portable
code than it is a constraint on implementors.
Scheme is
probably more of a "family" of languages than
Lisp is
at that.

Anyway, Nobody really pays much attention to
IEEE, although
that may change since it's being reworked this
year. The
real standard thus far has been the community
consensus
document called R5RS, the Revised^5 Report on the
Algorithmic
Language Scheme. There is a growing consensus
that it needs
work, but nobody has yet figured out how to make
a new version happen (And I believe that the IEEE effort is just
bringing IEEE up to date w/R5RS)
[color=blue]
> Reference name R5RS CLTL2
> Reference length 50pp 1029pp
> Standard libraries "few" "more"[/color]
Well, we're up to SRFI-45 (admittedly a number of
them have been withdrawn, but the code and specification are still
available) and there's very little overlap.
Most of the SRFIs have highly portable
implementations .
[color=blue]
> Support Community Academic Applications writers[/color]
in outlook, perhaps, but the academic component
has dropped fairly significantly over the years. The best implementations
still come out of academia, but the better libraries are starting to come
from people in the industry.
There is also an emphasis on heavily-armed
programming
which is sadly lacking in other branches of the
IT
industry. Remember - there is no Scheme
Underground.

david rush
--
(\x.(x x) \x.(x x)) -> (s i i (s i i))
-- aki helin (on comp.lang.schem e)

[Mario S. Mommer]

Re: Python syntax in Lisp and Scheme


jcb@iteris.com (MetalOne) writes:[color=blue]
> I have tried on 3 occassions to become a LISP programmer, based upon
> the constant touting of LISP as a more powerful language and that
> ultimately S-exprs are a better syntax. Each time, I have been
> stopped because the S-expr syntax makes we want to vomit.[/color]

:-)

Although people are right when they say that S-exprs are simpler, and
once you get used to them they are actually easier to read, I think
the visual impact they have on those not used to it is often
underestimated.

And to be honest, trying to deal with all these parenthesis in an
editor which doesn't help you is not an encouraging experience, to say
the least. You need at least a paren-matching editor, and it is a real
big plus if it also can reindent your code properly. Then, very much
like in python, the indent level tells you exactly what is happening,
and you pretty much don't see the parens anymore.

Try it! In emacs, or Xemacs, open a file ending in .lisp and
copy/paste this into it:

;; Split a string at whitespace.
(defun splitatspc (str)
(labels ((whitespace-p (c)
(find c '(#\Space #\Tab #\Newline))))
(let* ((posnew -1)
(posold 0)
(buf (cons nil nil))
(ptr buf))
(loop while (and posnew (< posnew (length str))) do
(setf posold (+ 1 posnew))
(setf posnew (position-if #'whitespace-p str
:start posold))
(let ((item (subseq str posold posnew)))
(when (< 0 (length item))
(setf (cdr ptr) (list item))
(setf ptr (cdr ptr)))))
(cdr buf))))

Now place the cursor on the paren just in front of the defun in the
first line, and hit ESC followed by <ctrl-Q>.
[color=blue]
> If a set of macros could be written to improve LISP syntax, then I
> think that might be an amazing thing. An interesting question to me
> is why hasn't this already been done.[/color]

Because they are so damned regular. After some time you do not even
think about the syntax anymore.

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Grzegorz Chrupa?a wrote:
...[color=blue]
> I have some doubts about the notion of simplicity which you (or Guido)
> seem to be taking for granted. I don't think it is that straightforwrd to
> agree about what is simpler, even if you do agree that simpler is better.
> Unless you objectivize this concept you can argue that a "for" loop is
> simple than a "map" function and I can argue to the contrary and we'll be
> talking past each other: much depends on what you are more familiar with
> and similar random factors.[/color]

I have both learned, and taught, many different languages -- and my
teaching was both to people already familiar with programming, and to
others who were not programmers but had some experience and practice
of "more rigorous than ordinary" thinking (in maths, physics, etc),
and to others yet, of widely varying ages, who lacked any such practise.

I base my notions of what is simple, first and foremost, on the experience
of what has proved easy to teach, easy to learn, and easy for learners to
use. Secondarily, on the experience of helping experienced programmers
design, develop and debug their code (again in many languages, though
nowhere as wide a variety as for the learning and teaching experience).

None of this (like just about nothing in human experiential knowledge about
such complicated issues as the way human beings think and behave) can be
remotely described as "objective" .

[color=blue]
> As an example of how subjective this can be, most of the features you
> mention as too complex for Python to support are in fact standard in
> Scheme (true lexical scope, implicit return, no expression/statement[/color]

Tut-tut. You are claiming, for example, that I mentioned the lack
of distinction between expressions and statements as "too complex for
Python to support": I assert your claim is demonstrably false, and
that I NEVER said that it would be COMPLEX for Python to support such
a lack. What I *DID* say on the subject, and I quote, was:

"""
Python draws a firm distinction between expressions and
statements. Again, the deep motivation behind this key
distinction can be found in several points in the Zen of
Python, such as "flat is better than nested" (doing away
with the expression/statement separation allows and indeed
encourages deep nesting) and "sparse is better than dense"
(that 'doing away' would encourage expression/statements
with a very high density of operations being performed).
"""

Please read what I write rather than putting in my mouth words that
I have never written, thank you. To reiterate, it would have been
quite simple to design Python without any distinction between
expressions and statement; HOWEVER, such a lack of distinction
would have encouraged programs written in Python by others to
break the Python principles that "flat is better than nested"
(by encouraging nesting) and "sparse is better than dense" (by
encouraging high density).
[color=blue]
> distinction) and yet Scheme is widely regarded as one of the simplest
> programming languages out there, more so than Python.[/color]

But does encourage nesting and density. Q.E.D..
[color=blue]
> Another problem with simplicity is than introducing it in one place my
> increase complexity in another place.[/color]

It may (which is why "practicali ty beats purity", yet another Zen of
Python principle...), therefore it becomes important to evaluate the
PRACTICAL IMPORTANCE, in the language's environment, of that "other
place". All engineering designs (including programming languages)
are a rich tapestry of trade-offs. I think Python got its trade-offs
more nearly "right" (for my areas of interest -- particularly for large
multi-author application programs and frameworks, and for learning
and teaching) than any other language I know.
[color=blue]
> Specifically consider the simple (simplistic?) rule you cite that Python
> uses to determine variable scope ("if the name gets bound (assigned to) in
> local scope, it's a local variable"). That probably makes the
> implementor's job simpler, but it at the same time makes it more complex
> and less intuitive for the programmer to code something like the
> accumulator generator example -- you need to use a trick of wrapping the
> variable in a list.[/color]

It makes the _learner_'s job simple (the rule he must learn is simple),
and it makes the _programmer_'s job simple (the rule he must apply to
understand what will happens if he codes in way X is simple) -- those
two are at least as important as simplifying the implementor's job (and
thus making implementations smaller and more bug-free). If the inability
to re-bind outer-scope variables encourages all programmers to use
classes whenever they have to decide how to bundle some code and some
data, i.e. if it makes classes the "one obvious way to do it" for such
purposes, the resulting greater uniformity in Python programs is deemed
to be a GOOD thing in the Python viewpoint. (In practice, there are of
course always "other ways to do it" -- as long as they're "non-obvious",
that's presumably tolerable, even if not ideal:-).

[color=blue]
> As for Ruby, I know and quite like it. Based on what you tell me about
> Python's philosophy, perhaps Ruby makes more pragmatic choices in where to
> make things simple and for whom than Python.[/color]

I thought the total inability to nest method definitions (while in Python
you get perfectly normal lexical closures, except that you can't _rebind_
outer-scope names -- hey, in functional programming languages you can't
rebind ANY name, yet nobody every claimed that this means they "don't have
true lexical closures"...!-), and more generally the deep split between
the space of objects and that of methods (a split that's simply not there
in Python), would have been show-stoppers for a Schemer, but it's always
nice to learn otherwise. I think, however, that deeming the set of
design trade-offs in Ruby as "more pragmatic" than those in Python is
a distorted vision, because it fails to consider the context. If my main
goal in programming was to develop experimental designs in small groups,
I would probably appreciate certain features of Ruby (such as the ability
to change *ANY* method of existing built-in classes); thinking of rather
large teams developing production applications and frameworks, the same
features strike me as a _negative_ aspect. The language and cultural
emphasis towards clarity, simplicity and uniformity, against cleverness,
terseness, density, and "more than one way to do-ity", make Python by
far the most practical language for me to teach, and in which to program
the kind of application programs and frameworks that most interest me --
but if my interest was instead to code one-liner scripts for one-off
system administration tasks, I might find that emphasis abominable...!


Alex

[Bengt Richter]

Re: Python syntax in Lisp and Scheme

On Sat, 04 Oct 2003 17:02:41 GMT, Alex Martelli <aleax@aleax.it > wrote:
[...][color=blue]
>
>def make_accumulato r(initial_value ):
> accumulator = Bunch(value=ini tial_value)
> def accumulate(adde nd):
> accumulator.val ue += addend
> return accumulator.val ue
> return accumulate
>
>accumulate = make_accumulato r(23)
>print accumulate(100) # emits 123
>print accumulate(100) # emits 223
>
>
>(using the popular Bunch class commonly defined as:
> class Bunch(object):
> def __init__(self, **kwds):
> self.__dict__.u pdate(kwds)
>). There is, of course, a cultural gulf between this
>verbose 6-liner [using an auxiliary class strictly for
>reasons of better readability...!] and the terse Ruby
>1-liner above, and no doubt most practitioners of both
>languages would in practice choose intermediate levels,
>such as un-densifying the Ruby function into:
>[/color]
I like the Bunch class, but the name suggests vegetables to me ;-)

Since the purpose (as I see it) is to create a unique object with
an attribute name space, I'd prefer a name that suggests that, e.g., NS,
or NSO or NameSpaceObject , so I am less likely to need a translation.


BTW, care to comment on a couple of close variants of Bunch with per-object class dicts? ...

def mkNSC(**kwds): return type('NSC', (), kwds)()

or, stretching the one line a bit to use the instance dict,

def mkNSO(**kwds): o=type('NSO', (), {})(); o.__dict__.upda te(kwds); return o

I'm wondering how much space is actually wasted with a throwaway class. Is there a
lazy copy-on-write kind of optimization for class and instance dicts that prevents
useless proliferation? I.e.,
[color=blue][color=green][color=darkred]
>>> type('',(),{}). __dict__[/color][/color][/color]
<dictproxy object at 0x00901570>[color=blue][color=green][color=darkred]
>>> type('',(),{}). __dict__.keys()[/color][/color][/color]
['__dict__', '__module__', '__weakref__', '__doc__']

seems like it could be synthesized by the proxy without a real dict
until one was actually needed to hold other state.

For qnd ns objects, I often do

nso = type('',(),{})( )
nso.att = 'some_value'

and don't generally worry about the space issue anyway, since I don't make that many.
[color=blue]
>
>def outer(a)
> proc do |b|
> a+b
> end
>end
>
>or shortening/densifying the Python one into:
>
>def make_accumulato r(a):
> value = [a]
> def accumulate(b):
> value[0] += b
> return value[0]
> return accumulate
>[/color]
Or you could make a one-liner (for educational purposes only ;-)
[color=blue][color=green][color=darkred]
>>> def mkacc(a): return (lambda a,b: a.__setitem__(0 ,a[0]+b) or a[0]).__get__([a])[/color][/color][/color]
...[color=blue][color=green][color=darkred]
>>> acc = mkacc(100)
>>> acc(3)[/color][/color][/color]
103[color=blue][color=green][color=darkred]
>>> acc(5)[/color][/color][/color]
108

Same with defining Bunch (or even instanciating via a throwaway). Of course I'm not
suggesting these as a models of spelling clarity, but it is sometimes interesting to see
alternate spellings of near-if-not-identical functionality.
[color=blue][color=green][color=darkred]
>>> Bunch = type('Bunch',() ,{'__init__':la mbda self,**kw:self. __dict__.update (kw)})
>>> bunch=Bunch(val ue='initial_val ue')
>>> bunch.value[/color][/color][/color]
'initial_value'

[color=blue]
>but I think the "purer" (more extreme) versions are
>interesting "tipization s" for the languages, anyway.
>[/color]
Oh goody, a new word (for me ;-). Would you define "tipization "?

Regards,
Bengt Richter

[Frode Vatvedt Fjeld]

Re: Python syntax in Lisp and Scheme

prunesquallor@c omcast.net writes:
[color=blue]
> But syntactic abstractions *are* a change to the language, it just
> sounds fancier.[/color]

Yes, this is obviously true. Functional abstractions also change the
language, even if it's in a slightly different way. Any programming
language is, after all, a set of functional and syntactic
abstractions.
[color=blue]
> I agree that injudicious use of macros can destroy the readability
> of code, but judicious use can greatly increase the readability. So
> while it is probably a bad idea to write COND1 that assumes
> alternating test and consequence forms, it is also a bad idea to
> replicate boilerplate code because you are eschewing macros.[/color]

I suppose this is about the same differentiantio n I wanted to make by
the terms "syntactic abstraction" (stressing the idea of building a
syntax that matches a particular problem area or programming pattern),
and "changing the language" which is just that, not being part of any
particular abstraction other than the programming language itself.

--
Frode Vatvedt Fjeld

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Bengt Richter wrote:
...[color=blue]
> I like the Bunch class, but the name suggests vegetables to me ;-)[/color]

Well, I _like_ vegetables...
[color=blue]
> BTW, care to comment on a couple of close variants of Bunch with
> per-object class dicts? ...
>
> def mkNSC(**kwds): return type('NSC', (), kwds)()[/color]

Very nice (apart from the yecchy name;-).
[color=blue]
> or, stretching the one line a bit to use the instance dict,
>
> def mkNSO(**kwds): o=type('NSO', (), {})(); o.__dict__.upda te(kwds);
> return o[/color]

I don't see the advantage of explicity using an empty dict and then
updating it with kwds, vs using kwds directly.
[color=blue]
> I'm wondering how much space is actually wasted with a throwaway class. Is
> there a lazy copy-on-write kind of optimization for class and instance
> dicts that prevents useless proliferation? I.e.,[/color]

I strongly doubt there's any "lazy copy-on-write" anywhere in Python.
The "throwaway class" will be its dict (which, here, you need -- that's
the NS you're wrapping, after all) plus a little bit (several dozen bytes
for the typeobject, I'd imagine); an instance of Bunch, probably a bit
smaller. But if you're going to throw either away soon, who cares?

[color=blue][color=green]
>>but I think the "purer" (more extreme) versions are
>>interesting "tipization s" for the languages, anyway.
>>[/color]
> Oh goody, a new word (for me ;-). Would you define "tipization "?[/color]

I thought I was making up a word, and slipped by spelling it
as in Italiano "tipo" rather than English "type". It appears
(from Google) that "typization " IS an existing word (sometimes
mis-spelled as "tipization "), roughly in the meaning I intended
("characterizat ion of types") -- though such a high proportion
of the research papers, institutes, etc, using "typization ",
seems to come from Slavic or Baltic countries, that I _am_
left wondering...;-).


Alex

[Terry Reedy]

Re: Python syntax in Lisp and Scheme

"David Rush" <drush@aol.ne t> wrote in message
news:oprwi0800f 3seq94@news.nsc p.aoltw.net...[color=blue]
> On Fri, 3 Oct 2003 09:36:32 -0400, Terry Reedy <tjreedy@udel.e du>[/color]
wrote:[color=blue][color=green]
> > ... Lispers posting here[/color][/color]
By 'here', I meant comp.lang.pytho n ...
[color=blue][color=green]
>> have gone to pains to state that Scheme is
> > not a dialect of Lisp but a separate Lisp-like language. Could[/color][/color]
you[color=blue][color=green]
> > give a short listing of the current main differences (S vs. CL)?[/color][/color]
[color=blue]
> Do you even begin to appreciate how inflammatory such a request is
> when posted to to both c.l.l and c.l.s?[/color]

As implied by 'here', I did not originally notice the cross-posting
(blush, laugh ;<). I am pleased with the straightforward , civil, and
helpful answers I have received, including yours, and have saved them
for future reference.

....[color=blue]
> compromise system design, for both good and bad[/color]
....[color=blue]
> embedded in it. This cuts both ways, mind you.[/color]
....

I believe in neither 'one true religion' nor in 'one best
algorithm/computer language for all'. Studying Lisp has helped me
better understand Python and the tradeoffs embodied in its design. I
certainly better appreciate the issue of quoting and its relation to
syntax.

Terry J. Reedy