Arc Forumnew | comments | leaders | submitlogin
5 points by drcode 6120 days ago | link | parent

  arc> +.3.3
  6

  arc> isa!x!sym
  t

  arc> cdr!(1 2 3)
  Error: "Can't take cdr of #<eof>"

  arc> (= x '(1 2 3))
  (1 2 3)
  arc> cdr.cdr.x
  Error: "procedure ...rcode/arc/ac.scm:561:11: expects 1 argument, given 2: #<procedure:...rcode/arc/ac.scm:561:11> (1 2 3 . nil)"
This one has me stumped:

  arc> (def foo (x) [+ 10 _])
  #<procedure: foo>
  arc> foo.3
  #<procedure>
  arc> (+:foo.3 5)
  15


7 points by pg 6120 days ago | link

! and . are for separating symbols and integers.

x.y.z means (x y z)

-----

3 points by eds 6120 days ago | link

Playing around with combining ":" and "."....

  arc> (= x [+ 10 _])
  #<procedure: x>
  arc> (prn:prn.x 5)
  #<procedure: x>
  15
  15
  arc> (prn:prn.x 5)
  #<procedure: x>
  15
  15
  arc> (prn (prn.x 5))
  #<procedure: x>
  15
  15
  arc> (prn ((prn x) 5))
  #<procedure: x>
  15
  15
Is this actually the way the first expression is being expanded? I can think of situations where I would want (foo:bar.arg) to be expanded to (foo (bar arg)) not (foo ((bar arg))). Just a thought.

-----

2 points by sjs 6119 days ago | link

I think it makes sense.

  arc> (def add (x) [+ x _])
  #<procedure: add>
  arc> (map [prn:add.40:idfn _] (range 1 5))
  41
  42
  43
  44
  45
  (41 42 43 44 45)

-----

5 points by kens 6120 days ago | link

I'd expect that "abc".1 would return #\b?

-----

5 points by pg 6120 days ago | link

No, it would read as two separate things, a string and the number .1; symbol-syntax has lower "precedence" than Lisp read.

-----

4 points by sjs 6119 days ago | link

  arc> (= s "abc")
  "abc"
  arc> s.1
  #\b

-----

6 points by oconnor0 6120 days ago | link

Is there a reason you limit ! and . to work only for symbols and integers?

-----

7 points by pg 6120 days ago | link

The plan with intrasymbol syntax is (a) not to break traditional Lisp read and (b) to expand in place. If you have those two constraints, instead of just saying "ok, put any syntax anywhere," you can introduce syntax into Lisp without getting too unLispy.

-----

1 point by oconnor0 6118 days ago | link

Right. Maybe it's the traditional Lisp read that's the main factor here because it seems that you could expand in place without issue given even arbitrary expressions.

If a.b expands to (a b) then (f v w).(g x y) would just expand to ((f x y) (g x y)). At first glance, that definitely appears to be a cool way to grab just one of the results from a function return (ala (f x y).2).

Hmm, on the down side, you could have statements like (or worse):

    (bst-find tree 45 f<).(if (< 10 42) (/ 4 3)
                              (> 4 2)   x
                                        'r)
That being said, having to change read to get this to work may affect far too much and make arc too ugly.

-----

3 points by treef 6120 days ago | link

i think the code will look rather harry if they are allowed to be every where.

-----