Arc Forum | Two things " : " " |

Arc Forum

Two things " : " " | | "

1 point by czoon 5910 days ago | 5 comments

first general version arc`s " : " operator :

      (cons a : cons b : cons c nil ) => (cons a (cons b (cons b nil ) ) )

     (+ 1 2 3 4 5 : * 6 7 8 ) => (+ 1 2 3 4 5 (* 6 7 8) )

etc.

its easy to read and it solves the MORP problem (millions of right parenthesis) .

second from Ruby: you know

      ( map lst | z | some-code  )  => (map lst (fn (x) some-code ) )

i dont know these are previously mentioned somewhere.

i am using them for a while . they are quite handy.(actually , i am in love with them).

ok question is:

are they sucks,lame, dirty etc. or - maybe - cool?

anyway, all responses are welcome. thanks.

1 point by rincewind 5910 days ago | link

Your : operator is syntactic sugar, it could be implemented with this function and then passed to load as the expander:

  (def paren-adder ((o delimiter '$))
     (rfn parens (expr)
        (if atom.expr expr
            (let (hd . tl) expr
               (if (is hd delimiter)
                  (list parens.tl)
                  (cons parens.hd parens.tl))))))

or as a macro:

  (mac nest (delimiter . body)
     ((paren-adder delimiter) body))

I think pg's : is supposed to mean function composition, with call-by-value-semantics (although is implemented as a macro).

   (compose [cons a _][cons b _][cons c _])

This is a bit longer than your version, because there is no standard for implicit currying in arc yet, but with HOFs, your example can be written:

   (rreduce cons (list a b c nil)) ;or (list a b c)

In my opinion many uses of this nesting operator indicate that you should refactor your code in a more functional way.

I am not sure whether it may help you with macros, beacuse they are not first-class enough, so nesting them becomes inevitable at some point.

-----

1 point by czoon 5909 days ago | link

  (def paren-adder ((o delimiter '$))
     (rfn parens (expr)
        (if atom.expr expr
            (let (hd . tl) expr
               (if (is hd delimiter)
                  (list parens.tl)
                  (cons parens.hd parens.tl))))))

  (def paren-adder ((o delimiter '$))
     : rfn parens (expr)
        : if atom.expr expr
            : let (hd . tl) expr
               : if (is hd delimiter)
                  (list parens.tl)
                  : cons parens.hd parens.tl )

compare them.

maybe its just me, but i dont like that ")))))))))" MORP or endless sea of right parens.

its not a big problem but "parenthes Less lisp" is better for me.

if i remember correctly, somebody mentioned here that Interlisp has solution with square brackets .

but i think this way is more readable.

probably, you are right about functional code. thanks for your reply.

-----

1 point by eds 5907 days ago | link

I don't think right parentheses are a problem for the following reasons:

* I don't type right parens. If you use Emacs and haven't tried Paredit (http://mumble.net/~campbell/emacs/paredit.el), I would highly suggest it.

* I don't read right parens, at least not in the multiline case. Instead, I read the indentation and the contents of the line, so the parens really don't get in the way at all.

I do think the : operator is an interesting idea for the single line case, when you might have something like

  (foo a (bar b (baz c))) => (foo a : bar b : baz c)

in the middle of a line.

-----

1 point by czoon 5904 days ago | link

and once get used to that , its addictive.

-----

1 point by rincewind 5903 days ago | link

Pythonic:

  (def paren-adder ((o delimiter '$)) :
     rfn parens (expr) :
        if atom.expr expr :
            let (hd . tl) expr :
               if (is hd delimiter)
                  (list parens.tl)
                  (cons parens.hd parens.tl))

-----