Arc Forum | Factorial with the new wart interpreter

Arc Forum

2 points by akkartik 5164 days ago | 17 comments

http://github.com/akkartik/wart/blob/49f10c98/020.wart

My previous announcement of the existence of def and mac (http://arclanguage.org/item?id=14881) was highly premature. After much bugfixing, here's some hopefully working wart code.

Still lots missing. No bignums, no floats, no ssyntax, no implicit gensyms (http://arclanguage.org/item?id=13342), no fn (lambda does rest and destructured args, but no optional and certainly no keyword args). Yet.

2 points by Pauan 5164 days ago | link

By the way, I found this amusing. I took your "and" macro, and used ssyntax to remove parentheses:

  mac and args
    if no.args
      ''t
      if car.args
        if cdr.args
          `(if ,car.args
             (and ,@cdr.args))
          car.args

Ditto for iso:

  def iso (a b)
    or (_atom_equal a b)
      and cons?.a
          cons?.b
          iso car.a car.b
          iso cdr.a cdr.b

Wow! And people thought Lisp used a lot of parens...

-----

1 point by akkartik 5164 days ago | link

Yep, that's the vision :) Macros stay, anything else can go.

(I hope to also lose the parens around the recursive call to and.)

I'm not sure it'll be a good idea to rely this much on indentation. It starts looking like concatenative languages with their reliance on 'words'. But hey, it's up to the programmer to use tools tastefully, and to figure out what good taste is.

-----

1 point by Pauan 5164 days ago | link

"(I hope to also lose the parens around the recursive call to and.)"

You mean remove the parens inside quasiquote? Good luck with that.

---

"But hey, it's up to the programmer to use tools tastefully, and to figure out what good taste is."

Exactly. I'd rather have implicit parentheses, because then I can choose whether to include parens or not... if I understand your system correctly, you can still wrap everything in parens, just like in Arc. So it's up to the programmer to decide whether to use parens or not. I think that's a very good thing.

-----

1 point by akkartik 5164 days ago | link

"if I understand your system correctly, you can still wrap everything in parens, just like in Arc."

Yes, that's the hypothesis of paren-insertion. So far I've seen two troubling cases, where you have to worry about paren-insertion even if you are explicitly adding parens everywhere:

a) A long data list that wraps to multiple lines:

  (a b c d ...
    e f g h ..)

My solution is to distinguish this from code indentation by using a single space.

  (a b c d ...
   e f g h ...)

Most of the time you can use any number of spaces to indicate indent, just like in python. But I'm hoping nobody wants an indent of 1.

b) The second case is arc's multi-branch if statements:

  (if
    cond1 then1
    cond2 then2
    else)

or pg+rtm's approach:

  (if cond1
       then1
      cond2
       then2
      else)

I'm not sure what to do about that. It's why the body of and has two nested ifs where one would seem to do -- I couldn't figure out how to indent a single if :/

-----

2 points by Pauan 5164 days ago | link

"A long data list that wraps to multiple lines:"

You could just disable indentation completely while inside parens. But then things like your quasiquote fix won't work.

---

"The second case is arc's multi-branch if statements:"

For what it's worth, I indent "if" in Arc like follows:

  (if (some-condition)
        foo
      (some-condition)
        bar
      qux)

I've found this to be overall a good pattern. It doesn't work very good when the conditions are very short, though:

  (if a
        foo
      b
        bar
      qux)

If the conditions and branches line up properly, I use this pattern:

  (if a foo
      b bar
        qux)

-----

2 points by akkartik 5164 days ago | link

Hmm, now that I see your cases and mine I realize in all these cases you can always back off to inserting parens everywhere, and things will just work. Lines where the first token is a '(' never insert a fresh '(' before.

[1] Sorry I edited grandparent to add the pg+rtm case you were adding at the same time in your response.

-----

2 points by Pauan 5164 days ago | link

"Hmm, now that I see your cases and mine I realize in all these cases you can always back off to inserting parens everywhere, and things will just work. Lines where the first token is a '(' never insert a fresh '(' before."

Right. At least, that's how I would expect it to behave. Worst-case scenario, you just put in parens just like Arc. But even then, you can at least leave off the initial parens:

  if (foo)
       (bar)
     (qux)

There is one thing that concerns me, though... it's very common to want to return a value from an "if", like so:

  if (condition? x)
       + x 10
     x

Whoops, the last "x" is wrapped in parens... but you don't want to call x, you want to return it directly. So you have to wrap the "if" in parens:

  (if (condition? x)
        (+ x 10)
      x)

-----

2 points by akkartik 5164 days ago | link

"Whoops, the last "x" is wrapped in parens..."

A single word on a line is never wrapped in parens, though it may close parens inserted in a previous line.

I keep thinking there's an example similar to this one of yours that won't parse correctly unless you explicitly wrap the if in parens:

  if (foo)
       (bar)
     (qux)

But I can't think of a counter-example :)

Even if the algo is unambiguous this approach will fail if people can't easily wrap their heads around what it will do. But that's a matter of taste, I suppose.

-----

1 point by Pauan 5164 days ago | link

"A single word on a line is never wrapped in parens, though it may close parens inserted in a previous line."

Ah, great. That solves that particular problem, then.

-----

2 points by akkartik 5164 days ago | link

I really appreciate you thinking through the cases with me.

Even if this approach turns out to be bad for some reason I'm hoping that the unit tests will be valuable as documentation to those following: http://github.com/akkartik/wart/blob/0a3e09/002parenthesize....

-----

2 points by akkartik 5158 days ago | link

Ah, there's one situation where I find myself wishing I could insert parens at the start of single-word lines:

  if x
    (do
      something
      something else)

The paren wrapping do is now needed.

-----

1 point by akkartik 5164 days ago | link

"You mean remove the parens inside quasiquote? Good luck with that."

It already works: http://github.com/akkartik/wart/commit/0a3e09

Do you see something that will break because of this down the road?

-----

1 point by Pauan 5164 days ago | link

Ah, right, I thought you meant getting rid of `( ... ) Yeah, that seems okay. But in that case, you'll probably never be able to completely fix the issue where you have a long list of data, as described in the other post.

You could probably come up with a compromise that works the majority of the time, though. For instance, you could disable indentation inside of '( ... ) but still allow for indentation with `( ... )

-----

2 points by akkartik 5164 days ago | link

Yeah that's a good point. If this approach is too aggressive I can back off and disable paren-insertion inside parens. I already do that to make things like this work:

  def foo(a ? d (if x
                   3
                   4))
    ...

-----

2 points by akkartik 5164 days ago | link

"I thought you meant getting rid of `( ... )"

Yeah if I could get rid of that one we'd be able to add macros to C or python :) But imagine a language that can look like python most of the time. But if you want macros, then the parens return.

-----

2 points by akkartik 5164 days ago | link

"you could disable indentation inside of '( ... ) but still allow for indentation with `( ... )"

Ugh, that's ugly. I think I'll give up on paren-insertion before trying to remember stuff like that :)

-----

2 points by Pauan 5164 days ago | link

For the curious, here's the link to factorial:

https://github.com/akkartik/wart/commit/49f10c98921397ddde14...

-----