Python syntax in Lisp and Scheme

[Pascal Bourguignon]

Re: Python syntax in Lisp and Scheme


prunesquallor@c omcast.net writes:[color=blue]
> You misunderstand me. In a python block, two expressions are
> associated with each other if they are the same distance from the left
> edge. This is isomorphic to having a nametag identifying the scope
> of the line. Lines are associated with each other iff they have the
> same nametag. Change one, and all must change.[/color]

Exactly. What was that language where you wrote tags to indicate the
indenting of data structures:

01 DREP.
02 NO-REPR PIC 9999.
02 NO-SOTR PIC 9999.
02 NOM PIC X(20).
02 PRENOM PIC X(15).
02 A PIC 9.
02 B PIC 9.
02 FILLER PIC X.
02 D PIC 9.
02 FILLER PIC X(33).
01 DVTE.
02 NO-SOTV PIC 9999.
02 NO-REPV PIC 9999.
02 MTV PIC 9(6)V99.
02 FILLER PIC X(64).

[color=blue]
> If, instead, you use balanced delimiters, then a subexpression no
> longer has to encode its position within the containing expression.
> [...][/color]

--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

Do not adjust your mind, there is a fault in reality.

[Hans Nowak]

Re: Python syntax in Lisp and Scheme

Doug Tolton wrote:
[color=blue]
> If you truly believe what you are saying, you really should be
> programming in Java. Everything is explicit, [...][/color]

<nitpick>
Not really. 'this' is implicit, for example. In fact, Java people have been
known to criticize Python because it's 'self' construct is explicit. ^_^
</nitpick>

--
Hans (hans@zephyrfal con.org)

http://zephyrfalcon.org/

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

Re: Python syntax in Lisp and Scheme

Daniel P. M. Silva wrote:
[color=blue]
> Haven't some people implemented an entire class system as one huge macro?[/color]

YES! Been there, done that -- about 3 or 4 times, actually.
I went through a bit of a phase where writing OO implementations
for Scheme was one of my principal hobbies. :-)

By the way, Scheme was my Favourite Cool Language for quite
a while. Then I discovered Python, and while I still appreciate
all the things about Scheme that I appreciated then, I wouldn't
want to go back to using it on a regular basis now. So it's not
a given that any person who likes Scheme must inevitably dislike
Python!

I do "get" macros, and I appreciate having them available in
languages like Scheme, where they seem to fit naturally. But
I can't say I've missed them in Python, probably because Python
provides enough facilities of its own for constructing kinds of
mini-languages (keyword arguments, operator overloading,
iterators, etc.) to satisfy my needs without having to resort
to macros.

And I do regard macros as something that one "resorts" to, for
all the reasons discussed here, plus another fairly major one
that nobody has mentioned: Unless both the macro system and
the macros written in it are *extremely* well designed, error
reporting in the presence of macros of any complexity tends to
be abysmal, because errors get reported in terms of the expansion
of the macro rather than what the programmer originally wrote.

ALL macro systems of any kind that I have ever used have suffered
from this - cpp, C++ templates, Lisp/Scheme macros, TeX,
you name it. I'd hate to see Python grow the same problems.

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

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

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

Re: Python syntax in Lisp and Scheme

Hans Nowak wrote:
[color=blue]
> Hmm, if I recall correctly, in Latin the plural of 'virus' is 'virus'.[/color]

Actually, the last discussion of this that I saw (can't remember where)
came to the conclusion that the word 'virus' didn't *have* a plural
in Latin at all, because its original meaning didn't refer to something
countable.

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

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

[Bengt Richter]

Re: Python syntax in Lisp and Scheme

On 07 Oct 2003 14:50:04 +0200, Matthias <no@spam.pls> wrote:
[color=blue]
>bokr@oz.net (Bengt Richter) writes:
>[color=green]
>> On 06 Oct 2003 12:54:30 +0200, Matthias <no@spam.pls> wrote:[color=darkred]
>> >1.) Inventing new control structures (implement lazy data structures,[/color]
>> You mean like an object olazy with olazy.x and olazy.y, where x might
>> be an integer 123 and y might be the text of the latest bug python report
>> on sourceforge? Not so hard with properties (you'd proabably want to cache
>> the latest for y and not re-check for some reasonable interval, but that
>> doesn't change client code (unless you later decide you want the value to
>> be a tuple of (timestamp, text), etc.)[/color]
>
>Actually, I meant more lazy-like-lazy-in-Haskell. Infinite data
>structures and such. "primes" being a list representing _all_ prime
>numbers for instance. You can build this as soon as you have closures
>but making the construction easy to use for the application programmer
>might be a challenge without macros. But I don't know what
>"properties " are in Python, possibly they are built for exactly that.[/color]
No, generators are closer to "exactly that" e.g., in the following function,
"yield" is the keyword that makes it into a generator. The initial call effectively
becomes a factory function call that returns an initialized generator, and calls
to the generators' .next() method resumes execution first at the beginning, running
up to the first yield, where execution is suspended and the yield value returned to
the next() method caller. A subsequent .next() call resumes execution right after the
last yield, and so on forever or until the generator exits without hitting a yield,
which terminates the sequence.
[color=blue][color=green][color=darkred]
>>> def lazyprimes(prim e_range_top):[/color][/color][/color]
... import array
... primes = array.array('l' ,[2])
... yield 2
... for prime_candidate in xrange(3,prime_ range_top,2):
... for p in primes:
... if prime_candidate %p==0: break
... else:
... primes.append(p rime_candidate)
... yield prime_candidate
...[color=blue][color=green][color=darkred]
>>> primegen = lazyprimes(1000 ) # primes under 1000
>>> primegen.next()[/color][/color][/color]
2

Properties allow you to create a class whose instances have a property attribute that
is accessed just like an ordinary attribute, but may invoke arbitrary functions to get
and/or set the apparent state. E.g.,
[color=blue][color=green][color=darkred]
>>> class Foo(object):[/color][/color][/color]
... def __init__(self, k, ptop):
... self.k = k
... self.pnext = lazyprimes(ptop ).next
... p = property(lambda self: self.pnext())
...[color=blue][color=green][color=darkred]
>>> foo = Foo(123, 32)[/color][/color][/color]

Here k is an ordinary instance attribute and p looks like another in the syntax of the
access in an expression, but it is hooked into a lazy prime generator:
[color=blue][color=green][color=darkred]
>>> foo.k[/color][/color][/color]
123[color=blue][color=green][color=darkred]
>>> foo.p[/color][/color][/color]
2[color=blue][color=green][color=darkred]
>>> foo.p, foo.p[/color][/color][/color]
(3, 5)[color=blue][color=green][color=darkred]
>>> foo.k[/color][/color][/color]
123[color=blue][color=green][color=darkred]
>>> [(foo.k, foo.p, c) for c in 'abcd'][/color][/color][/color]
[(123, 7, 'a'), (123, 11, 'b'), (123, 13, 'c'), (123, 17, 'd')][color=blue][color=green][color=darkred]
>>> foo.pnext()[/color][/color][/color]
19[color=blue][color=green][color=darkred]
>>> foo.pnext()[/color][/color][/color]
23[color=blue][color=green][color=darkred]
>>> foo.p[/color][/color][/color]
29[color=blue][color=green][color=darkred]
>>> foo.p[/color][/color][/color]
31[color=blue][color=green][color=darkred]
>>> foo.p[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 5, in <lambda>
StopIteration

Well, I should have provided for dealing with the end-of-sequence exception, most likely,
unless reaching it was an error. Not hard.

Getting back to primegen, which last yielded the first prime 2 above,
I'll bind a shorter name to the next method (bound to the particular generator),
for easier typing ;-)
[color=blue][color=green][color=darkred]
>>> pn = primegen.next
>>> pn()[/color][/color][/color]
3
Here we'll enumerate[color=blue][color=green][color=darkred]
>>> for i,p in enumerate(iter( pn,31)): print i,p[/color][/color][/color]
...
0 5
1 7
2 11
3 13
4 17
5 19
6 23
7 29[color=blue][color=green][color=darkred]
>>> pn() # we used up 31 as the sentinel ending a series of calls to pn() so,[/color][/color][/color]
37[color=blue][color=green][color=darkred]
>>> # here we got the next one after 31[/color][/color][/color]
...[color=blue][color=green][color=darkred]
>>> for i in xrange(10): print pn(), # 10 more[/color][/color][/color]
...
41 43 47 53 59 61 67 71 73 79[color=blue][color=green][color=darkred]
>>> pn() #one more[/color][/color][/color]
83[color=blue][color=green][color=darkred]
>>> primegen.next()[/color][/color][/color]
89[color=blue][color=green][color=darkred]
>>> for p in primegen: print p, # the rest[/color][/color][/color]
...
97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173 179 181 191 193 197 199 211 223 2
27 229 233 239 241 251 257 263 269 271 277 281 283 293 307 311 313 317 331 337 347 349 353 359 3
67 373 379 383 389 397 401 409 419 421 431 433 439 443 449 457 461 463 467 479 487 491 499 503 5
09 521 523 541 547 557 563 569 571 577 587 593 599 601 607 613 617 619 631 641 643 647 653 659 6
61 673 677 683 691 701 709 719 727 733 739 743 751 757 761 769 773 787 797 809 811 821 823 827 8
29 839 853 857 859 863 877 881 883 887 907 911 919 929 937 941 947 953 967 971 977 983 991 997[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

(In opportune line wrap on my console screen, but I assume it's clear enough).
[color=blue]
>[color=green][color=darkred]
>> > implement declarative control structures, etc.)[/color]
>> You mean like case or such?[/color]
>
>No. I was thinking about Prolog and such. Or nondeterministi c
>programming. Or multimethod dispatch.[/color]
For the latter in Python, see
http://www-106.ibm.com/developerwork.../l-pydisp.html[color=blue]
>[color=green][color=darkred]
>> >2.) Serve as abbreviation of repeating code. Ever used a code
>> > generator? Discovered there was a bug in the generated code? Had
>> > to fix it at a zillion places?
>> > => Macros serve as extremely flexible code generators, and there
>> > is only one place to fix a bug.
>> > => Many Design Patterns can be implemented as macros, allowing you
>> > to have them explicitly in your code. This makes for better
>> > documentation and maintainability .[/color]
>> You can generate code many ways in Python. What use case are you thinking of?[/color]
>
>I was not talking about generating code /in/ Python but generating
>code /for/ Python /within/ it. For the Design Pattern use case take a
>look at http://norvig.com/design-patterns/[/color]
I was also talking about "generating codef /for/ Python /within/ it" -- even in
a recrusive routine, see answer to 4. below ;-)
[color=blue]
>[color=green][color=darkred]
>> >3.) Invent pleasant syntax in limited domains.
>> > => Some people don't like Lips' prefix syntax. It's changeable if you
>> > have macros.
>> > => This feature can also be misused.[/color]
>> You can do this also.[/color]
>
>You can change Python's syntax? Easily?[/color]
No, I didn't mean that literally, but just as you can create source dynamically
and compile it for subsequent execution (as with the trivial text source template below),
you could define an app-specific mini language and translate and compile it for use later
in the same program run. If you create a class and populate class variables from values
in a config file, are you doing this? I think so, at a trivial level. If you wrote an
import function that could import a subset of scheme and have it dynamically translated
to something that looks like a python module to the python user, have you changed python's
syntax? No. Have you made other syntax available to the python programmer? Yes.

I had an infatuation with scheme, some years back now. I still think she was sweet ;-)
[color=blue]
>[color=green][color=darkred]
>> >4.) Do computations at compile time instead of at runtime.
>> > => Have heard about template metaprogramming in the C++ world?
>> > People do a lot to get fast performance by shifting computation
>> > to compile time. Macros do this effortlessly.[/color]
>> This also, but Python has so many possible compile times ;-)[/color]
>
>I'm not sure I understand.[/color]
[color=blue][color=green][color=darkred]
>>> import time
>>> def multicomp(maxre c=5, level=0):[/color][/color][/color]
... fooname = 'foo_level_%s'% level
... source = """
... def %s(): print 'I was compiled at level %s on %s.'
... """% (fooname, level, time.ctime())
... d={}
... exec source in d
... time.sleep(2) # to guarantee time stamp change
... if level<maxrec: return (d[fooname],)+ multicomp(maxre c,level+1)
... return (d[fooname],)
...[color=blue][color=green][color=darkred]
>>> mc = multicomp()
>>> for f in mc: print 'My name is %r and'%(f.__name_ _,),; f()[/color][/color][/color]
...
My name is 'foo_level_0' and I was compiled at level 0 on Tue Oct 07 21:19:18 2003.
My name is 'foo_level_1' and I was compiled at level 1 on Tue Oct 07 21:19:20 2003.
My name is 'foo_level_2' and I was compiled at level 2 on Tue Oct 07 21:19:22 2003.
My name is 'foo_level_3' and I was compiled at level 3 on Tue Oct 07 21:19:24 2003.
My name is 'foo_level_4' and I was compiled at level 4 on Tue Oct 07 21:19:26 2003.
My name is 'foo_level_5' and I was compiled at level 5 on Tue Oct 07 21:19:28 2003.[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Ok, the recursion was gratuitous, except that it shows compilation happening dynamically,
and you can easily see you could leave such routines compiled at the outer level for
execution any time you wanted, and thus get "many compile times" ;-)
[color=blue]
>[color=green]
>> Python is pretty sharp ;-)
>> I think we need some realistic use cases for your "specific" [categories of]
>> examples in order to compare how problems would be approached.[/color]
>
>Well, if you don't want to learn about syntactic abstraction you'll
>probably never miss it during your programming. Just keep in mind
>that before oo-abstraction became fashionable people didn't miss OOP
>either.[/color]

Actually, I would like to learn more about it. I am fascinated by the
interplay between the worlds of concrete representations and abstract entities,
and their interrelated transformations . ISTM macros definitely have a place in the pantheon.
I have yet to grok scheme's hygienic macro stuff, though ;-) One of these days...

Regards,
Bengt Richter

[Ng Pheng Siong]

Re: Python syntax in Lisp and Scheme

According to Pascal Bourguignon <spam@thalassa. informatimago.c om>:[color=blue]
> Well, I would say that kanji is badly designed, compared to latin
> alphabet. The voyels are composed with consones (with diacritical
> marks) and consones are written following four or five groups with
> additional diacritical marks to distinguish within the groups. It's
> more a phonetic code than a true alphabet.[/color]

Kanji are ideograms borrowed from Chinese. Kanji literally means "Han
character".

I think the diacritical marks you mention are pronunciation guides, much
like Hanyu Pinyin is a Mandarin pronunciation guide for Chinese.

In Hanyu Pinyin, Kanji (read as a Chinese word phrase) is rendered "han4
zi4".

In Korean, Kanji is pronounced Hanja.

Same two-character word phrase, different pronunciations.


--
Ng Pheng Siong <ngps@netmemeti c.com>

http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL

[Thomas F. Burdick]

Re: Python syntax in Lisp and Scheme

hs@heaven.nirvananet (Hartmann Schaffer) writes:
[color=blue]
> In article <xcvpth8rcfh.fs f@famine.ocf.be rkeley.edu>,
> tfb@famine.OCF. Berkeley.EDU (Thomas F. Burdick) writes:[color=green]
> > Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> writes:
> >[color=darkred]
> >> I find the Lisp syntax hardly readable when everything looks alike,
> >> mostly words and parentheses, and when every level of nesting requires
> >> parens. I understand that it's easier to work with by macros, but it's
> >> harder to work with by humans like I.[/color]
> >
> > You find delimited words more difficult than symbols? For literate
> > people who use alphabet-based languages, I find this highly suspect.
> > Maybe readers of only ideogram languages might have different
> > preferences, but we are writing in English here...[/color]
>
> well, there are a few occasions where symbols are preferrable. just
> imagine mathematics with words only[/color]

Oh, certainly. Unlike most languages, Lisp lets you use symbols for
your own names (which is easily abused, but not very often). A bad
example:

;; Lets you swear in your source code, cartoonishly
(define-symbol-macro $%^&!
(error "Aw, $%^&! Something went wrong..."))

;; An example use
(defun foo (...)
(cond
...
(t $%^&!)))

And, although you generally use symbols from the KEYWORD package for
keyword arguments, you don't have to, and they don't have to be words:

(defgeneric convert-object (object new-type)
(:documentation "Like an extensible COERCE."))

(defun convert (object &key ((-> to)))
"Sugary"
(convert-object object to))

(defconstant -> '-> "More sugar")

;; Example usage
(convert *thing* -> (class-of *other-thing*))

Of course, these are lame examples, but they show that Lisp *can*
incorporate little ascii-picture-symbols. Good examples would
necessarily be very domain-dependant.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

[Daniel P. M. Silva]

Re: Python syntax in Lisp and Scheme

Greg Ewing (using news.cis.dfn.de ) wrote:
[color=blue]
> Daniel P. M. Silva wrote:
>[color=green]
>> Haven't some people implemented an entire class system as one huge macro?[/color]
>
> YES! Been there, done that -- about 3 or 4 times, actually.
> I went through a bit of a phase where writing OO implementations
> for Scheme was one of my principal hobbies. :-)
>[/color]

Nice! I was alluding to MzScheme's class.ss but I guess that's a fun hobby
to have. :) Do you have your class systems available anywhere to download?
I would be especially interested in them if they allow multiple
inheritance, run-time pillaging of class contracts, and explicit "this"
arguments to methods...

[color=blue]
> By the way, Scheme was my Favourite Cool Language for quite
> a while. Then I discovered Python, and while I still appreciate
> all the things about Scheme that I appreciated then, I wouldn't
> want to go back to using it on a regular basis now. So it's not
> a given that any person who likes Scheme must inevitably dislike
> Python!
>
> I do "get" macros, and I appreciate having them available in
> languages like Scheme, where they seem to fit naturally. But
> I can't say I've missed them in Python, probably because Python
> provides enough facilities of its own for constructing kinds of
> mini-languages (keyword arguments, operator overloading,
> iterators, etc.) to satisfy my needs without having to resort
> to macros.[/color]

You still can't add new binding constructs or safe parameterizatio ns like a
with_directory form:

with_directory( "/tmp", do_something())

Where do_something() would be evaluated with the current directory set to "
tmp" and the old pwd would be restored afterward (even in the event of an
exception).

Last year -- I think at LL2 -- someone showed how they added some sort of
'using "filename": ' form to Python... by hacking the interpreter.
[color=blue]
> And I do regard macros as something that one "resorts" to, for
> all the reasons discussed here, plus another fairly major one
> that nobody has mentioned: Unless both the macro system and
> the macros written in it are *extremely* well designed, error
> reporting in the presence of macros of any complexity tends to
> be abysmal, because errors get reported in terms of the expansion
> of the macro rather than what the programmer originally wrote.[/color]

I've yet to encounter this problem in the standard library included with my
Scheme implementation of choice, but ok.
[color=blue]
> ALL macro systems of any kind that I have ever used have suffered
> from this - cpp, C++ templates, Lisp/Scheme macros, TeX,
> you name it. I'd hate to see Python grow the same problems.
>[/color]

Some people use Python's hooks to create little languages inside Python (eg.
to change the meaning of instantiation), which are not free of problems:

class Object(object):
def __init__(this, *args, **kwargs):
this.rest = args
this.keys = kwargs

def new_obj_id(coun t=[0]):
count[0] = count[0] + 1
return count[0]

def tag_obj(obj, id):
obj.object_id = id
return obj

def obj_id(obj): return obj.object_id

type.__setattr_ _(Object, "__new__", staticmethod(la mbda type, *args:
tag_obj(object. __new__(type), new_obj_id())))


Great, now all object instantiations (of our own Object class) will also tag
new objects with an ID:

obj = Object()
print "id: ", obj_id(obj)
print "another id: ", obj_id(Object() )

Which gives you 1 and then 2. Hurrah.
Have you caught the bug yet?

# forgot to check for this case...
print Object(foo="bar ")

This is of course illegal and I get the following error message:

Traceback (most recent call last):
File "n.py", line 27, in ?
print Object(foo="bar ").rest
TypeError: <lambda>() got an unexpected keyword argument 'foo'

Hmm...

[Carlo v. Dango]

Re: Python syntax in Lisp and Scheme

[color=blue]
> I'd humbly suggest that if you can't see *any* reason why someone
> would prefer Lisp's syntax, then you're not missing some fact about
> the syntax itself but about how other language features are supported
> by the syntax.[/color]

sure, but it seems like noone was able to let CLOS have
(virtual) inner classes,
methods inside methods,
virtual methods (yeah I know about those stupid generic functions :),
method overloading,
A decent API (I tried playing with it.. it doesn't even have a freaking
date library as standard ;-p

Yes I agree with the compile time macro expansion is a nice thing.
However, if I want to do some serious changes to the structure of objects
and classes (i.e. create a new kind of objects) then I have to spend a
long time finding out how the CLOS people hacked together their
representation of classes, methods, method call etc... it has been far
easier for me to just do some small changes using __getattribute_ _ and
metaclasses in python. So in that respect Im not really sure the macro
idea is advantageous for other than 'straight away' macros...

yes this mail is provocative.. please count slowly to 10 before replying
if you disagree with my point of view (and I know Pascal will disagree ;-)
.... not that I ever seen him angry ;-)


Carlo van Dango

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[james anderson]

Re: Python syntax in Lisp and Scheme



"Carlo v. Dango" wrote:[color=blue]
>[color=green]
> > I'd humbly suggest that if you can't see *any* reason why someone
> > would prefer Lisp's syntax, then you're not missing some fact about
> > the syntax itself but about how other language features are supported
> > by the syntax.[/color]
>
> sure, but it seems like noone was able to let CLOS have
> (virtual) inner classes,
> methods inside methods,
> virtual methods (yeah I know about those stupid generic functions :),
> method overloading,
> A decent API (I tried playing with it.. it doesn't even have a freaking
> date library as standard ;-p
>
> Yes I agree with the compile time macro expansion is a nice thing.
> However, if I want to do some serious changes to the structure of objects
> and classes (i.e. create a new kind of objects) then I have to spend a
> long time finding out how the CLOS people hacked together their
> representation of classes, methods, method call etc... it has been far
> easier for me to just do some small changes using __getattribute_ _ and
> metaclasses in python. So in that respect Im not really sure the macro
> idea is advantageous for other than 'straight away' macros...
>
> yes this mail is provocative.. please count slowly to 10 before replying
> if you disagree with my point of view (and I know Pascal will disagree ;-)
> ... not that I ever seen him angry ;-)[/color]

one might benefit more from reasoned examples, comparisons, and questions than
from vacuous vitriol.

....

[Mario S. Mommer]

Re: Python syntax in Lisp and Scheme

Peter Seibel <peter@javamonk ey.com> writes:[color=blue]
> corey.coughlin@ attbi.com (Corey Coughlin) writes:
>[color=green]
> > Using parentheses and rpn everywhere makes lisp very easy to parse,
> > but I'd rather have something easy for me to understand and hard for
> > the computer to parse.[/color][/color]

Intrestingly enough, I think this is a question of getting used to
it. The notation is so relentlessly regular that once you got it,
there are no more syntactical ambiguities. None. Ever.

It is the difference (for me) between reading roman numerals (that
would be the baroque-ish syntax of other languages, full of
irregularities, special cases, and interference patterns), and arabic
numerals (that would be lisp). I never have a doubt about what the
S-expr. representation encodes.

[Matthias]

Re: Python syntax in Lisp and Scheme

Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> writes:
[color=blue]
> All Lisp code I've read uses lots of parentheses
> and they pile up at the end of each large subexpression so it's hard to
> match them (an editor is not enough, it won't follow my eyes and won't
> work with printed code).[/color]

The paranthesis argument. Are there really no new things under the sun? ;-)

Well, in Lisp as in most other languages (esp. Python) you read source
code by indentation, not by matching parentheses. That is why some
Lispers are a bit intolerant against non-standard indentation. They
use it (mentally) to parse the language. The parenthesis really are a
personal-taste-only issue.

[David Rush]

OT: Japanese Orthography (was Re: Python syntax in Lisp and Scheme)

On 08 Oct 2003 <spam@thalassa. informatimago.c om> wrote:
[color=blue]
> Marcin 'Qrczak' Kowalczyk <qrczak@knm.org .pl> writes:[color=green]
>> A richer alphabet is often more readable. Morse code can't be read as
>> fast as Latin alphabet because it uses too few different symbols.
>> Japanese say they won't abandon Kanji because it's more readable
>> as soon as you know it -[/color][/color]

Rather like Lispers ;)
[color=blue][color=green]
>> you don't have to compose words from many small pieces which look alike
>> but each word is distinct.[/color][/color]

Very -ish. Kanji is pictographic and the Japanese borrowed their usage
from China several times over the course of a thousand years so from
what a westerner might call reading POV, it's a mess. Having learned
to read Kanji; however, I have to say that the leverage you get from
the pictograms is amazing. I found myself quite able to navigate myself
to (and through) government offices whose name I didn't even begin to
know,but whose function was clear from the kanji on the door.
[color=blue][color=green]
>> Of course *too* large alphabet requires long
>> learning and has technical difficulties,[/color][/color]

Indeed Japanese children spend most of gradeschool learning the first 2000
or so Kanji. By the time you finish university it can be necessary to know
up to 10,000 (or so my wife tells me).
[color=blue][color=green]
>> but Lisp expressions are too
>> little distinctive for my taste.[/color][/color]

I'll grant that Lisp is rough in vanilla VI, but who uses that anymore?
Syntax coloring and auto-indenting make it virtually identical to Python.
I would go so far as to say that I *read* lisp via indentation.
[color=blue]
> Well, I would say that kanji is badly designed, compared to latin
> alphabet. The voyels are composed with consones (with diacritical
> marks) and consones are written following four or five groups with
> additional diacritical marks to distinguish within the groups. It's
> more a phonetic code than a true alphabet.[/color]

Sorry, but that's all any alphabet is. The Kana are particularly aptly
suited to the Japanese language which is phonetically *very* simple. The
Kana encode the basic syllables - *all* of them. English/Latin is a
disaster by comparison.

All of which goes to show something like: languages make sense in the
context
where they are used - otherwise they wouldn't be used...

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

[David Rush]

Re: Python syntax in Lisp and Scheme

On Tue, 07 Oct 2003, Peter Seibel <peter@javamonk ey.com> wrote:[color=blue]
> But Lisp's syntax is not the way it is to make the compiler writer's
> job easier. <macros> *That's* why we don't mind, and, in
> fact, actively like, Lisp's syntax.[/color]

In fact, I have also noticed that programming in nearly all other languages
(Smalltalk, APL, and FORTH are the exceptions) tends to degenerate towards
a fully-parenthesized prefix notation in direct proportion to the size of
the code. This fully-parenthesized prefix notation is just everyday
function calls, BTW. Method invocations aren't really any different.

So if you're going to write in parenthesized prefix notation *anyway*, you
might as well get some benefit out of it -> s-expressions and macros

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

[Marcin 'Qrczak' Kowalczyk]

Significant whitespace

On Tue, 07 Oct 2003 21:25:53 +0100, Alexander Schmolck wrote:
[color=blue]
> Python removes this significant problem, at as far as I'm aware no real cost
> and plenty of additional gain (less visual clutter, no waste of delimiter
> characters ('{','}') or introduction of keywords that will be sorely missed as
> user-definable names ('begin', 'end')).[/color]

There are three choices for a lanuage syntax:
1. Line breaks and indents are significant (Haskell, Python).
2. Line breaks only are significant (Ruby, Unix shell, Visual Basic).
3. Neither is significant (most languages).

I found the syntax of Haskell and Python aesthetic, and tried to introduce
significant whitespace into my own little language. It was surprisingly hard.

The first attempt used a quite minimalistic syntax and had significant
indents. In effect indentation errors usually went undetected and the
program suddently had a different meaning. Since you wouldn't want to
consistently use indentation for all local functions, they used either
braces or indentation - but not both! so it looked very differently
depending on whether you wanted to make use of significant indents or not.
And since it was a functional language, it used quite a lot of nesting.
I quickly abandoned this version.

Although misindenting Haskell code can produce a valid parse, the error
is usually caught either by scoping rules or by the typechecker; my
language was dynamically typed. Haskell doesn't have the "inconsiste ncy"
problem because when you omit a line break which would introduce or close
indentation, you usually don't have to insert braces - syntax rules say
that virtual closing braces are inserted when not inserting it would cause
a parse error. Unfortunately this rule is almost impossible to implement
correctly (current compilers fail to use it correctly in some subtle cases).
There are cases when the language requires a different indentation than
I would like to use (mostly 'if-then-else' and 'let' inside 'do').

Python has a simpler syntax, where indentation is used on the level of
statements as the only delimiting mechanism, and not on the level of
expressions - which can't contain statements. It doesn't allow to replace
indentation with explicit delimiters. Since most expressions have pending
open parens or brackets when cut in the middle (because of mandatory
parens around function arguments), most line breaks inside expressions are
identifiable as insignificant without explicit marking. So it's easy to
design rules which use indentation, at the cost of the inability to
express various things as expressions. It's an imperative language and
such syntax won't fit a functional language where you would want to have
a deeper nesting, and where almost everything can be used inside an
expression.

Moral: Haskell and Python happen to succeed with significant indents
but their rules are hard to adapt to other languages. Significant
indentation constrains the syntax - if you like these constraints, fine,
but it would hurt if a language were incompatible with these constraints.

Having failed with significant indents, I tried to use significant line
breaks in next incarnations of my language, which looked like a good
compromise. The language had a richer syntax this time and it worked
quite well, except that one too often wanted to break a line in a place
which had to be explicitly marked as an insignificant break. I had
troubles with designing a good syntax for some constructs, mainly
if-then-else, being constrained to syntaxes which can be nicely split
into lines.

After experimenting with various syntaxes which used significant line
breaks to separate declarations and statements (delimiting was first done
by an opening word and 'end', later by braces), I tried how it would look
like with explicit semicolons. Surprisingly this opened new ways to build
some syntactic constructs. I finally got an 'if' which I was happy with,
I was no longer forced to choose to either not break a particular long
line or to mark the line break as insignificant, and I could abandon
designing a built-in syntax for catching exceptions because using a
suitable function no longer interfered with line breaking.

Moral is the same. Although designing and implementing a syntax with
significant line breaks and insignificant indentation is much easier than
with significant indentation, it still takes away some freedom of syntax
design which might be noticeable. Perhaps there are subtle ways to apply
significant line breaks to various languages, which you might find with
some luck or experience... I've given up, designing a syntax with
insignificant whitespace is much safer.

--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org. pl
^^ http://qrnik.knm.org.pl/~qrczak/