This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: new experimental "part extraction" syntax
Bruce Lewis wrote:
Per Bothner <per@bothner.com> writes:
Here's the first example from the current docs:
Field parts:
(list 3 4 5)\car ==> 3
(list 3 4 5)\cdr\car ==> 4
One thing I like about the Lisp family of languages is how you see the
end result as you're looking at the very beginning.
There are definite advanages to the postfix syntax is certain contexts.
It's also nice to avoid N paren-pairs for an N-length "path expressions"
- but syntax is of course the art of trade-offs.
Looking to the end
to see the result seems a lot more procedural.
I don't see how it is "more procedural".
Additionally, this syntax requires that there be no whitespace, so
indentation for complex expressions built this way is impossible.
Yes, that is an issue I need to think about. We could remove the
requirement that there be no spaces before the \, as in:
(list 3 4 5) \cdr \car ==> 4
However, that does have some issues of knowing how far to read.
What about something like a subset of JScheme's javadot notation? For
example, the evaluator could be extended to allow keywords in the first
position:
(:car (list 3 4 5)) ==> 3
(:car (:cdr (list 3 4 5))) ==> 4
Implemented in 1.8:
(*:.car (list 3 4 5)) ==> 3
(*:.car (*:.cdr (list 3 4 5))) ==> 4
Method parts:
(#xff\toString) ==> 255
(255\equals #xff) ==> #t
Rather than making expression\name equivalent to a lambda expression
when name is a method, what about simply making syntax that invokes the
method based on the value returned from the second position?
(:toString #xff) ==> 255
(:equals 255 #xff) ==> #t
(*:toString #xff) ==> 255
(*:equals 255 #xff) ==> #t
--
--Per Bothner
per@bothner.com http://per.bothner.com/