Hacker News Reader

Comment by tgbugs | Hacker News Reader

Having followed this fairly closely, I will drop a though here while it is in my head. Surely there would be no obstacle to supporting s-expression syntax and allowing additional syntax around it. Everyone seems to see this as either-or, but is it really truly impossible to have a set of rules that say "you can't start a valid sexp with `(4` so this must be the start of an infix expression" and "you can start an sexp with `(add1` so I'll keep going"? Yes there will be a cost in the reader, but moving away from sexps is already going to be costly in that sense. Further, if we are going to incur the cost of a major complication of the parsing implementation, then why not go all out and allow interleaved expressions? What are the ambiguous cases that make this impossible?

View on HN

I've always wondered if a good way to do infix would be to simply have the ability to mark an item with a character that means "move this to the front of the expression." Let's say the char is ":". Then this:

  (1 :+ 2)

Would be converted to this:

  (+ 1 2)

It would also allow for arbitrary placement, so you can do goofy stuff like pretend to be Forth without writing custom macros for the situation:

  (1 2 3 4 5 :+)

Whether or not that part is an advantage is another story ;)

This doesn't solve the "too many parens" problem, because you still have parens, but it does solve the "prefix math looks weird" problem. It's quite a bit simpler than what Dylan does, in that there's no special concept of "binary operators" and it's obvious at a glance how everything converts to sexps.

Racket currently has something like this for certain operators. `. -> . ` will allow the arrow to sit in between inputs and outputs in contracts.

> for certain operators

AFAIK it works for any operator that takes two operands (or more, but it makes less sense to be using it with three or more operands.)

e.g:

    > '(arg0 . operator . arg1 arg2)
    '(operator arg0 arg1 arg2)

Ah, interesting—thanks for pointing that out. That is practically the same thing. I only wonder if the fact that it's two dots tends to discourage it from general use for things like arithmetic, compared to a single character.

You could do this in Racket by messing with #%app. Supporting arbitrary infix operators could be a bit tricky, but just doing standard math ones wouldn’t be too difficult.

That’s an interesting idea. “Markfix” Notation?

How would it work if you had 2+ operators in one line?

Good question--just stack them up on the left on the same order as they appear in the expression, I guess.

Reply on news.ycombinator.com