Lambda the Ultimate

This is more or less a pure version of how SICP introduces objects but you have one more layer of parentheses:

((object 'method) arg1 arg2)

Another option (perhaps a compromise) could be:

(object 'method (arg1 arg2))

In ISWIM-syntax languages, this would just be:

object 'method (arg1 arg2)

Which is only a few characters away from the dot syntax.

One issue with chaining methods is the return value of a method is not necessarily the object, e.g.

dict.get(key1).set(key2, value)

There there are two different ways to interpret:

dict.get(key2)

Will it return value or something else? In the pure version, each method would return object. In the side effect version, the return value is almost never object.

(I read both SICP and EOPL in the early 90's, but my post here conflates them so when kms says SICP I respond as if EOPL was mentioned instead ... which is sorta weird and slightly embarrassing to me. But more importantly, it makes my response even more rude because it's both inappropriate and wrong, for which I apologize.)

I like Ray's comparison of alternatives, so I added one — which is not a reference to SICP because it comes from an interpreter named Ygg I wrote in the early 90's, revised several times from 1990 to 1993. That I may do it again is boring; only green threads would make it different. I like Ray's criticism it's only single dispatch, because discussing that in docs would be useful.

This is more or less a pure version of how SICP introduces objects but you have one more layer of parentheses

Hmm, I thought I had fewer parens. I like SICP but haven't thought much about it in twenty years. At Taligent several of us started casually going through SICP, so we weren't thinking solely about C++ all the time, and because it was fun. I forget the variant of Scheme I was using for SICP, but it's macro system didn't match that assumed by SICP materials. I made a wild guess its macros might work just like non-hygienic macros I had coded for Ygg, and they did.

You can still find my SICP (cor: EOPL) contributions for define-record and variant-case online here and there, with a 1993 copyright plus edits by Friedman and other folks. So there's proof. :-) Posting them here in no way helps this topic though, and I basically detest appeal to authority. [Edit: It was MacGambit; for the curious, a clean copy appears at http://www.cs.indiana.edu/pub/eopl/gambitmacros.s, and my original Usenet post notes the odd use of eval to cause top-level definitions.]

Did my description make sense by itself? Sometimes I'm puzzled when a short and simple description causes a person to invoke a book, which adds burden on readers when they may assume they can't understand without boning up first on dusty tomes.

Change of subject: I had assumed Ray's example did not return the same object from each call. Smalltalk actually has specialized syntax to send multiple messages to the same object. But it occurs rarely enough in practice that folks feel semi-colon was wasted on such a narrow purpose.

I, too, liked the comparison of alternatives, so I added a few! When I said "you", I did not mean McCusker -- I meant generic you, as in, "If you do it this way I am about to suggest, then you have one more layer of parentheses."

I didn't mean to appeal to authority. I didn't grok objects/closures until I fully digested this bit of SICP. Your description was good! This way makes the object/closure relationship clearer for me.

Sorry for being so defensive. There I'm doing it again!

Regarding methods that would otherwise be void that return the modified object, I just was brushing up on JavaScript and Crockford refers to this style of method as a cascade. Is this terminology founded elsewhere (perhaps in PLT) or just an analogy to CSS?

Darn, my misinterpretation of your first sentence was more my fault than yours, as if you meant Above by "This" when you meant Below, and then I saw you as confirming what I expected. I fell prey to a classic error I worry about more when writing, which is, "If a reader can interpret a comment as about themselves, they usually will." So I should have known better. On re-reading your remark, I belatedly noticed there was a second interpretation, but by then it seemed best to see what you reply. Thus I'm the one owing an apology. Thanks for being good natured.

Don't worry about being defensive. I say sorry a lot myself. Somehow I used to provoke folks into barking, "Stop saying you're sorry!" Now I think they felt slightly like jerks for having used too critical a tone themselves. I'm usually keen to hear criticism about something I did, because I might learn something.

Now you mention it, Smalltalk used cascade to mean nearly that, using a semi-colon between messages to target the same object, so returning self instead of void was not necessary. But I recall no other use of the term in other contexts beyond phrases "cascading failure" and "cascading style sheets." So I'd expect precedent is Smalltalk, or perhaps another language too like Self, with which I'm not familiar.

I've never heard "cascade" used to describe that. I've heard "method chaining" and "fluent interface" (which is a truly horrible name).

"Cascade" is a term from Smalltalk. Smalltalk has built-in support for sending a bunch of messages to the same receiver. Fluent interfaces, as I understand it, were invented by a bunch of Smalltalkers to try to emulate that feature in languages like Java that didn't support it natively. See here.

The reason F# needs to use a separate syntax for .Net methods is because methods need to support overloading. Multiple .Net classes can have methods with the same name, and in addition a single class can have multiple overloads of the same method. The non-OO parts of F# are basically just Caml, which cannot support overloading functions without totally messing up type inference. So there needs to be some syntactic way of distinguishing .Net method calls from function calls, in order to allow the functional part of the language to continue to work.

(defmacro bind (object method-list)
   (if (null method-list) object
       (chain ((caar method-list) object (cdar method-list))
              (cdr method-list))))

(bind object ((method1 (arg11 arg21))
              (method2 (arg12 arg22))
              (method3 (arg13 arg23))))

This also addresses your issue in another comment: we no longer care what each method returns.

In Arc, which doesn't particularly use objects, my code would tend to look similar to examples already posted.

(method3 (method2 (method1 object arg11 arg21) arg12 arg22)
  arg13 arg23)

; anaphoric and, which short-circuits if an intermediate value is nil
(aand object
  (method1 it arg11 arg21)
  (method2 it arg11 arg21)
  (method3 it arg11 arg21))

The short-circuiting of aand isn't always convenient for this purpose, but it can come in handy elsewhere.

Switching to a more obviously OO-related viewpoint, Clojure code takes a similar approach when accessing JVM methods, from what I've seen:

(.method3 (.method2 (.method1 object arg11 arg21) arg12 arg22)
  arg13 arg23)

(-> object
    (.method1 arg11 arg21)
    (.method2 arg12 arg22)
    (.method3 arg13 arg23))

So, although the usual downside of losing lispy syntax is loss of ability to manipulate the code as data, I'm not seeing it here.

Here's a list of lisps I know of that amp up the sugar, yet still parse to the ad hoc structure of s-expressions before semantic processing. It's a frequent topic on Arc Forum.

The "infix dot" can be a reader macro as typical for lisps giving a fully-regular syntax.

A nice feature of a syntax based on stream reader macros is that once the outermost running reader macro has finished, the read operation is complete. Infix at the top level compromises that. After reading any value, the reader will have to look ahead to verify that a non-whitespace, non-infix reader macro is coming up, which is unfortunate if the input stream is a REPL.

Nevertheless, it wouldn't be the end of the world for there to be another kind of reader macro that acted as a command terminator, like a statement semicolon for lisp, but perhaps bound to newline instead. :)

Dot notation is just syntax, it works perfectly well for any kind of dispatch. a.method(b,c) ===> method(a,b,c)

As I said, I'm not quite sold on the Algol'ish function call syntax.

These are some pretty good reasons.

Quote and unquote being functions and having the syntax of function calls (parens and all) is fine. But the list/call syntax mismatch is not so fine, unless there is something else besides lists, just as general, that has the same syntax in data as a call has in code.

I'm not going to break homoiconicity; the idea that all code can be read as data is too important to get rid of. That's the main incomplete notion that still has me hesitating about embracing an Algol'ish call syntax.

Ray

..is algol'ish call syntax, I think. For the reasons I showed above. It can be done, but it ends up becoming onerous.

Everything else in an algol-like syntax can be desugared pretty easily, IMO. Statement separators/terminators can just become comment tokens :) And things like begin/end or {} can be turned into lists. You can have a seemingly-statement oriented language without creating the expression-statement divide. It's just f(x) that's the pain. Better to just use (f x) everywhere.

I discussed this before here. It's based on experiences with my toy language, Wart, that relies on a lisp-like evaluation model.

C is homoiconic: strings are data. Why doesn't C have the advantages of Lisp then? Because sexprs have more structure than strings. But sexprs don't capture all the semantic structure there is in code. (list 'if (list '<= 'a 'b) 'a 'b) is not the most structured representation of an if AST node. Lisp sexprs are just an intermediate between completely unstructured (strings) and completely structured (an abstract data type for ASTs). The problems of Lisp macros, e.g. unintentional variable capture, also come from code representation not being completely structured. Therefore you can and should be *more* homoiconic than Lisp, by representing code with an abstract data type for ASTs.

The problems of Lisp macros, e.g. unintentional variable capture, also come from code representation not being completely structured.

I view structure and hygiene as orthogonal. Scheme hygienic macro systems achieve hygiene without a full AST-based model.

Although it is possible to do hygienic macros without changing the data type you're working on, the resulting macro systems are limited (e.g. syntax-rules). So many hygienic macro systems don't work on sexprs but on their own syntax objects. If you use an AST abstract data type from the start, hygiene comes naturally rather than something you have to specifically design for.

So many hygienic macro systems don't work on sexprs but on their own syntax objects.

Yes, but those are effectively conses and symbols with hygiene information attached - the basic model is still Lisp's AST-less, list-based syntax.

Yes, they are conses and symbols plus extra structure. So structure and hygiene are not orthogonal. For another example of a problem that has to be explicitly fixed with sexprs based macros that wouldn't even exist in the first place with structured ASTs, see Fortifying Macros. The problem arises because the meaning of sexprs is not automatically aligned with the representation, so sexprs need to be parsed to extract meaning, just like strings need to be parsed to extract meaning.

C lacks ubiquitous first-class values, a true function eval, and sufficiently powerful tools for manipulating strings as structured entities. Although no tools can fully compensate for the inherent lack of structure of strings vs sexprs, there are things one can do. Add a true eval, fcvs, and regular expressions, and some aggressive mutability for good measure, and you have... javascript. I'm not fond of javascript, but I recognize that for all its faults it nevertheless taps into the fringes of the power of Lisp.

I think I need example to understand you. What could be the most structured representation of IF AST node?

Lists are collections. They are not recursively built out of cons cells as I've formulated it; In fact there is no such thing as a cons cell as distinguished from a collection of two elements. Collections can as easily be arrays or something else. One of the results is that the empty list or #nil has nothing to do with terminating a list. Another is that the "dot syntax" for pairs is not tied to that particular meaning and dot can be used instead as an infix operator for dereference.

car and cdr as functions will return #nil when you attempt them on an empty list, and in fact this is how the end of some iterations is detected. But that's nothing to do with list structure as such.

so, the traditional list syntax being a shortcut for pair syntax, or

(a b c) == (a . (b . (c . ())))

is simply not valid. Instead list syntax denotes collections whose storage format is unspecified.

So did you imagine just using some syntax like the following?

[a b c]

I think the sentence wasn't "so, this syntax (being a shortcut for that one) is simply not valid."

It was more like "so, 'this syntax being a shortcut for that one' is simply not valid."

The way I understand it, the syntax is still (a b c), but it isn't a shortcut for any other syntax. The resulting collection may or may not be implemented in terms of cons cells; this detail is invisible.

I'm not sure why I should. I'm using parens to denote collections. The only thing I've considered an alternate enclosing form for, so far, is denoting whether the collection is or is not ordered.

Ray

Hmm, if I'm following you right, it looks like you chose door 1 after all. How would you parse this?

f(a (g h))

Is it a call to f with 2 args, or with one arg that's constructed by calling a on the list (g h)? So you're forced to constrain spaces one way or another to avoid ambiguity, just like the readable project above.

When your language sees:

(a b)

Does it implicitly eval all elements of the list? Or does it assume the list is implicitly quoted? Neither option feels salubrious..

Ross Angle pointed out that my equivalence for dotted lists is incorrect:

(a b c . d) => a(b c(d))

That would instead expand to (a b (c d)). So it seems we need dot syntax even with this proposal.

Suppose there is a fairly unmodified list syntax, and we require top level function applications to be enclosed in parens. So where inside expressions we would say

f(x y z)

if we're evaluating the same thing at top level we have to say

(f(x y z)).

If y turns out to be a function with two arguments a and b, the expression can be written as:

(f (x y (a b) z))

The rule being that a list is always an argument list attaching to the function bound to the preceding element (or the function resulting from the previous expression).

The top-level forms always being lists sort of implies that they are argument lists for an "implicit" function -- which, of course, is eval curried over the persistent environment. But if we're going to do that we have to be consistent. So we need to put parens around *every* top level form, not just function applications. So instead of saying

foo[bar]

at the top level, we'd have to say

(foo[bar])

Which is, well, ugly, but better than a statement terminator because now we have evaluable top level forms always in the form of a list which we can destructure using car/cdr/etc, where a statement terminator by itself does not give the form any knowable structure.

So a list denoting a function application has two elements: a function name (or function expression) and an arglist. According to the logic that car returns the first element and cdr returns a list of the remaining elements, you get:

(car (f (x y z))) => f

(cdr (f (x y z))) => ((x y z))

which is again, consistent, but ugly. The result of the second expression is a list having one element; but that element is itself a list.

I can make a consistent homoiconic macrology here with cons, car, cdr - but the price of algol'ish procedure call syntax appears to be an additional level of list structure to deal with in macros and additional parens at top level around every complete expression.

You write really well; I hope further updates are coming as you think more, because it's a pleasure to read your reasoning. The only person whose posts I admire more is Jules Jacobs, who has a scary kind of clarity in expression. (Apologies to anyone else who feels slighted. I'm resisting a mini dialog where Crash claims Ross Angle is a member of the Geometry Clan, and a generally trig fellow.)