Can a language have Lisp's powerful macros without the parentheses?

That's definitely true in terms of defmacro and syntax-case. However, I do think with some effort the scripting-language community could come up with something almost as powerful as syntax-rules from R5RS, thus catching up to where the Scheme community was in 1991. With syntax-rules the person writing the macro does not have to explicitly deal with the parse tree.

But, of course, you don't have to have code files full of parens in order to have s-expressions. Alternative syntaxes have never taken hold in the Lisp world, which may mean they just offer nothing to an experienced Lisp hacker, but they're certainly not impossible.

You can have user-definable infix operators; Haskell has them and uses them to good effect. (The way Haskell does it, you can't have identifiers composed of both letters and operator characters, which Lisp people like to do, but I think we can safely treat that as a matter of taste.) You pick a symbol, say ~, and assign it a precedence and left- or right-associativity:

infixr 3 ~

infixl 7 .!.

Now (x ~ y .!. z) is parsed as ((~) x ((.!.) y z)), where (~) is the Haskell way of making the ~ operator as a prefix function. Haskell also lets you use a prefix function as an infix operator, by putting backquotes around it.

If you want to apply this in Lisp, there is the issue that (foo) means something else than foo; I would like to allow (foo x + bar y) to mean ((+) (foo x) (bar y)), but I wouldn't want (x + y) to mean ((+) (x) (y)). My solution would be that a single value is parsed as just a value, but multiple values next to each other is a function call: (foo x + y) is ((+) (foo x) y), to call y without parameters you have to write (foo x + (y)).

This leaves you with the parantheses for control structures and the like. If you like layout-based languages, you can adopt the rule that "expression + colon + newline + indented expression 1 + indented expression 2 + ..." is parsed as "expression (indented expression 1) (indented expression 2) ...".

Some examples of code from On Lisp formatted like this:

http://himalia.it.jyu.fi/~benja/2007/layoutedlisp.txt

Of course, it still looks like Lisp, with less parens.

I had a sneaking suspicion that that was the case.

This reminds me of something that an Associate Professor at Ohio State said when I was presenting on a mathematical tool that I was (and am) implementing. He couldn't remember the order of operations, so he was having trouble parsing the statement:

(forall x, y in Z)(x >= y AND x <= y ==> x = y)

That led him to ask why should I not just include the unnecessary parens, i.e. ((x >= y AND x <= y) ==> x = y), which then led to the question of where to stop adding parentheses. Finally, he recalled talking to another professor who made the case that having rules for order of operations is a bad idea (because those rules have to be memorized), and why not just parenthesize everything? I pointed out, of course, that he was almost exactly describing Lisp.

That thought, however, led me to consider the idea of making order of operations always evaluate left-to-right, except for parenthesized expressions, which would be evaluated first (in the same manner). Leveraging this idea, perhaps it would be possible to escape the hold of exclusively using s-expressions?

My main goal would be to write a general-purpose language which could be used for writing any other language by using the macro facilities, instead of being forced to write Lisp-like languages as appears to be the case with Lisp. Of course, maybe to get that general, you may as well simply use lex and yacc to write a compiler.

Well, anyways, these are mostly just ramblings, and I'm glad to see that others are interested in this idea.

Thanks for posting that. We're building a DSL for our users and this will get put on the stack of things to look into. We're Python hackers so it's a good find.

I agree, thanks for the link. Unfortunately, I find the complete lack of syntax to make it even harder to read than Lisp macros (which I don't personally find difficult, but some do). Additionally, having to use numbers to indicate operator precedence seems a bit strange. Of course, Lisp solves this by always using parentheses, but I would be curious to see if there is a more elegant way of handling this than the numeric approach (or even the approach suggested in their proposed changes to Logix).

Could you give an example that's more powerful? From the 60-second intro you linked to, these look no more powerful than C's macros.

http://en.wikipedia.org/wiki/C_preprocessor#Macro_definition_and_expansion

See the Io programming language:

"Io is a small, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self (prototype-based), NewtonScript (differential inheritance), Act1 (actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable)."

Oh, I totally get that. The "problem" is that of building languages on top of Lisp, which is really half of the point. The languages that can be trivially built on top of Lisp generally look like Lisp. I would like to be able to use a language with Lisp's capabilities to build a new language which looks completely different.

I'm not really asking for an answer here; this is really just a thought exercise on my part that I thought I'd share.