Arc Forumnew | comments | leaders | submitlogin
2 points by shader 4291 days ago | link | parent

Well, almkglor and I had talked once about having [ .. : .. ] syntax, which overloads the normal brackets if the reader detects the colon. In this version, the variable names come before the colon, and the function body after. Zero arguments should also work. I don't know if it was ever included into anarki, but it seems like it should be useful.

Here's the link to the thread:

Near the bottom is almkglor's implementation. It is backwards compatible with the [ .. _ .. ] form.

1 point by rkts 4291 days ago | link

Those proposals shorten fns by at most three characters. Are multi-arg fns used often enough to warrant this? news.arc contains 23 multi-arg fns in 1769 lines of code; therefore they would save about 1 char every 26 lines.

That would be ok if the proposals were simple and elegant, but personally I find them hackish and inconsistent with the rest of the language. They also don't fully replace fn because they lack an equivalent for (fn args ...).

Here's my idea: just replace 'fn with a special symbol, like \. This seems to work:

  --- brackets0.scm       2008-11-11 17:06:01.000000000 -0600
  +++ brackets.scm        2008-11-11 17:06:17.000000000 -0600
  @@ -18,7 +18,8 @@
   ; a readtable that is just like the builtin except for []s
   (define bracket-readtable
  -  (make-readtable #f #\[ 'terminating-macro read-square-brackets))
  +  (make-readtable #f #\[ 'terminating-macro read-square-brackets
  +                     #\\ 'non-terminating-macro (lambda _ 'fn)))
   ; call this to set the global readtable
Now we can say

  arc> (map (\(a b) (prn a ", " b)) '(1 2 3) '(3 2 1))
  1, 3
  2, 2
  3, 1
  (1 2 3)
  arc> ((\args args) 1 2 3)
  (1 2 3)
This saves two chars and is relatively unintrusive.

P.S. Please nobody add any more comments to the thread linked above. It's making my threads page very wide :-(


1 point by shader 4290 days ago | link

personally, I think that (fn (a b) (+ a b)) is more readable than (\(a b) (+ a b)), and readability matters much more than number of characters.

Also, the [:] form could save more characters, if it automatically applied the outer set of parens to the body form.

However, I don't think it's really that much of an improvement; fn works well enough unless you really like extra syntax.

What was it the original poster wanted, anyway? It sounded like something that was more readable than _1 etc. for the var names; thus my dredging of the old thread. If not, then obviously, it wouldn't be a good choice. Maybe the [:] form should be capable of only naming some of the args, and leaving the rest to the other naming convention? Then the [] form can name the first n arguments by putting them before a :, and have the args after that referenced by $, $0, $1, $2, etc. or some better character set, if _ looks bad.


1 point by andreyf 4290 days ago | link

Yuk, the point I was making is that we should skip argument lists if our function is tiny - for example...

    (fn (a b) (- (/ b (* 2 a))))
...has "fn (a b) ", or 9/29 characters ~ 30% code is in some sense superfluous.


1 point by rkts 4289 days ago | link

It's only a problem if fns of two or more args are common, and they don't seem to be. In news.arc, srv.arc and blog.arc they appear once every 123 lines. In my CL code they appear every 250 lines. Are they more common in your code?


1 point by andreyf 4291 days ago | link

> It is backwards compatible with the [ .. _ .. ] form.

I agree that this is important - it's hard to beat the elegance of [ .. _ .. ] when you have one variable.

From the thread you linked, I'm a big fan of:

    [a b -> (- (/ b (* 2 a)))]
While this seems a bit obfuscated:

    [(- (/ _1 (* 2 _0)))]


1 point by shader 4290 days ago | link

The only things I don't like about arrow form are 1) two characters, and 2) it looks like other math symbols.

I like the colon form, but some text editors make it almost invisible. If the font makes it bold enough, it can be easier to recognize than many of the others.

I originally like the pipe form, as it's also pretty obvious. However, since this is a lisp, you can always rewrite it to suite your individual tastes ;) How about writing a "config" file for arc, and various conversion tools, that allow us to all write in our own style, and easily convert between them? Then we wouldn't have to argue over which separator to use.


1 point by andreyf 4290 days ago | link

How about writing a "config" file for arc, and various conversion tools, that allow us to all write in our own style, and easily convert between them?

Good call, but this doesn't address the problem of having to explicitly list parameters, which can be the majority of the code in a small function.


1 point by rincewind 4291 days ago | link

I implemented something like the first one in my m-expression reader, "a -> b;" is translated into "(fn a b)". It could be used with cchooper's customisable reader, so you can still use s-exprs most of the time, like this:

  (map #m[a;b]-> 0 - b / 2 / a; my-list)
it would be read as

  (map (fn (a b) (- 0 (/ b 2 a))) my-list)