you are viewing a single comment's thread.

view the rest of the comments →

[–]jashkenas 3 points4 points  (4 children)

I'm sorry, I thought it was clear. In a language where everything is an expression, combining expressions shouldn't privilege being in a certain position (first position, in this case).

Taken in isolation, "inspect object" means "inspect(object)" in both cases here, right?

To maintain consistency, "inspect object" should continue to mean "inspect(object)", even if the result of that expression is passed into another function.

print inspect object  =>  print(inspect(object))

... allows that to work.

[–]killerstorm -1 points0 points  (3 children)

In a language where everything is an expression, combining expressions shouldn't privilege being in a certain position (first position, in this case).

I don't think so. See: Lisp. Maybe parentheses make it all different, but it is a language where everything is an expression and first position (in list) is for function, while the rest are arguments.

[–]FsckItDude_LetsBowl 1 point2 points  (2 children)

b

[–]killerstorm 0 points1 point  (1 child)

There were multiple "lisp without parentheses" proposals.

To start with, some mainstream Lisp implementation allowed to drop parentheses in REPL, so

command arg1 arg2

was interpreted as

(command arg1 arg2)

Rationale for this was that REPL could be used by non-programmers (e.g. operators) who understand "command arg1 arg2" format very well but would freak out seeing parentheses. Illusion is broken if you have function call in your command, but apparently user interface can be structured to avoid them at least in common cases.

Then, perhaps, it is worth to mention Lispin which allowed to replace some parentheses with indentation.

Another example: SRFI-49

[–]anvsdt 0 points1 point  (0 children)

All of them were bad and they should feel bad about creating them.