Arc Forumnew | comments | leaders | submitlogin
Vote up if you think a:b.c should be (a (b c))
5 points by drcode 6119 days ago | 21 comments
Seems to me the current meaning of a:b.c is not practical in real code and might be wasted semantic space- Although I'd be happy to be corrected and shown that it is actually useful, if someone disagrees.

(I'm sure everyone appreciates my use of reddit-style "vote up" links... pretty soon the arc forum will be overrun with Ron Paul stories :-)



4 points by kennytilton 6119 days ago | link

I don't know what to think about all this syntax. I think it is fine for pg to look for ways to make Lisp more concise and parens-free cuz he is a master of Lisp. But is everyone piling onto this experiment as savvy about the benefits of those parnes? Or are some just trying to turn Arc into C to get back to their comfort zone?

As for it being optional, the danger I see is that this punctuation stampede is encouraging noobs in their fear of parens. The fact is, anyone who gives Lisp a serious try never ends up in week two saying damn Lisp rocks but how do you people tolerate those damn parentheses!!??

That said, I did as much punctubreviation as I could doing Arccells and I did not hate it. Time will tell....

-----

1 point by drcode 6119 days ago | link

I am more than happy to bow to pg and have him weed out my stupid ideas as he sees fit :)

What's the point of having a benevolent dictator if you can't post questionable ideas with abandon?

-----

1 point by kennytilton 6119 days ago | link

The problem is that instead of learning Lisp/Arc people are spinning their wheels trying to design it. I see very little sign here of people actually programming in Arc. If pg had just laid down the law folks would be using Arc instead of trying to fix a language whose excellent heritage is unknown to them. But I think some good ideas came out of the first wave of suggestions so I am undecided on the merits of the dictator's three-microphone town meeting.

-----

2 points by drcode 6119 days ago | link

I, myself, definitely am, but won't have anything worth releasing for months...

Jeech, it hasn't even been out a month yet- Don't rush me :)

-----

3 points by kennytilton 6118 days ago | link

"won't have anything worth releasing for months..."

Er, um, dude... it's Lisp, you are supposed to be able to release it every day. Please don't tell us you are still running the system specification document past the user acceptance committees.

-----

1 point by sacado 6119 days ago | link

Well, I do not totally agree with you there. I have programmed in Arc both for fun and work, and have also coded in Scheme a little, and I really find the . and ! syntax is really a good thing for structure access, mainly when you have nested structures. You know, when you have 3 or 4 opening parentheses at the same time. Too sad you can't fully use it in these situations.

But it's not a problem of fear of parentheses ; actually I couldn't find other cases where . and ! could be used without feeling a bit ugly (i.e. in calling functions or macros). Yes, parentheses & s-exprs are great, but I don't believe they should be the only syntax for accessing structures.

Don't worry anyway, I don't think Paul would integrate suggestions he considers weak, even if many of us asked it.

-----

4 points by Jekyll 6119 days ago | link

I can't vote down initial posts in threads, so this isn't going to be much of a poll.

(I'm not saying I want to, it's just that it's not going to tell you anything about what proportion of people like your idea.)

-----

-3 points by drcode 6119 days ago | link

I agree it's a poor poll- I admit it's a silly gimmick pandering for points.

-----

1 point by dplabs 6119 days ago | link

i have to most respectfully disagree friend. so far i like most everything i see in arc, but this ssyntax business does not resonate well with me. i thought it was only me (i'm getting old and all) but now i see some other people that are bothered by it so i feel i should say something. i think there is something to this.

-----

4 points by byronsalty 6119 days ago | link

I think there is way too much discussion on this forum of new syntax without much clear gain. It's rather overwhelming listening too and I'm afraid it will make arc much more difficult to learn if it all gets adopted.

As mentioned, I'd vote down but I can't.

-----

4 points by drcode 6119 days ago | link

You have a point, but let's distinguish between optional syntax (like : ' !) and mandatory syntax (as is used copiously in most languages)

Optional syntax has far fewer minuses, I would argue- New users wouldn't need to use it if they prefer not to.

Also, we're not talking about increasing syntax here, just using the existing syntax in a different way.

My personal thinking, though, is that it would be OK to go all out with the other special characters to generate optional syntax, as long as it is really, really, really well thought out. (other arc users, such as yourself, would probably disagree with this argument, however) Some special character for currying (such as described in the current arc.arc comments) would be a strong plus, I think.

-----

2 points by dplabs 6119 days ago | link

the problem is that people will use it. i don't want to read through a:b.c code. my eyes are already optimized for (a (b c)) and i like it thank you very much.

-----

2 points by Jesin 6119 days ago | link

I think that if a:b.c means anything, it should be (a (b c)). I can understand that : is normally right-associative, i.e. a:b:c:d means (compose a (compose b (compose c d))) rather than (compose (compose (compose a b) c) d). However, it's really counterintuitive that a:b.c currently means (compose a (b c)) rather than ((compose a b) c).

While I agree wholeheartedly that "Should the programmer be allowed to...?" should be answered "yes" as much as possible, the a.b syntax confuses me. While it's totally understandable that a.b means (a b), it's weird that a.b.c means (a b c).

I like the function composition syntax a lot. (a:b foo) is easier to type than (a (b foo)), and the benefits scale linearly; compare (a:b:c:d foo) with (a (b (c (d foo)))), and (baz a:b:c:d) with (baz (fn args (a (b (c (apply d args)))))).

I fail to see the benefits of the function application syntax. Typing a.b is hardly any easier to type than (a b), and is also harder to understand instantly upon reading. As you add more arguments, the bad gets worse and the good doesn't get better. The gains in brevity and typing speed in writing a.b.c.d rather than (a b c d) are no better than those of writing a.b rather than (a b). However, once you start using the syntax for more than one argument, you have to remember that a.b.c.d means (a b c d), rather than (((a b) c) d) or (a (b (c d))). It gets worse when you try to mix them, as in a:b.c, a.b:c, or a:b.c:d (what would this last one even mean?).

Some proposals: Drop the a.b syntax altogether Do not allow mixing of . and : Allow only one . per thing At the very least, drop a!b and let us just use a.'b; it's easier to understand and no harder to type.

I am not comfortable with disallowing anything, partly due to bad experiences with languages that do so. The other syntax at least makes sense (things like [ _ ], :, and the usual Lisp stuff like ' ` , ,@). I don't see the point of a.b, why not drop it entirely?

-----

2 points by almkglor 6119 days ago | link

You know what I really think should happen? Well:

  (mac test-mac (x)
    (prn x)
    nil)

  arc> (test-mac:foo:bar)
  (foo (bar))
  nil
  arc> (test-mac (foo:bar))
  (foo (bar)) ;doesn't happen; you get (foo:bar)
  nil
Having macros hack through composed forms using ssyntax and ssexpand is a pain.

-----

5 points by sacado 6119 days ago | link

I'd like a.b.c to be ((a b) c) too !

-----

2 points by drcode 6119 days ago | link

I agree- using dots/exclamations in multiparameter functions is definitely pretty scuzzy, so it makes sense to use this semantic space for something else, too...

The reader (I would argue) should always make the assumption that the dot/excl implies single-parameter functions. This would be particularly nice in nested tables... Imagine we had a table of tables of city populations:

countries!usa!atlanta --> "5 million"

-----

2 points by cooldude127 6119 days ago | link

this would be the ideal behavior.

-----

2 points by araujo 6119 days ago | link

I like the idea of the alternatives syntax ! , . , : and ~ ; so I vote up for it.

What I find annoying or confusing is the way they are currently implemented.

I think these operators should be used with literals and first-class objects too, instead of them being only tied to names/symbol merely , the productivity and the usefulness will greatly increase with this change , and it is something probably needed for these operators to survive in the long term.

-----

1 point by dplabs 6119 days ago | link

this is make or break for me. if the ssyntax stuff stays, i'm just taking all the macros i like and staying with sbcl.

-----

1 point by dplabs 6119 days ago | link

I'd like a.b.c to be ((a b) c) too !

-----

-1 points by xTERM 6117 days ago | link

No

-----