Arc Forumnew | comments | leaders | submitlogin
1 point by dido 4897 days ago | link | parent

Well, it might possibly be interpreted as 1 because the length of a symbol is 1, but this then raises the question as to why (len 'symbol) should not produce an error the way taking the len of other atoms does, e.g.:

  arc> (len 1)
  Error: "length: expects argument of type <proper list>; given 1"
  arc> (len 'symbol)
  1
The way I see it the most logical value for (len nil) is 0, that is if you want it to be the same as the empty list, and taking the len of any other symbol should produce an error.


1 point by akkartik 4897 days ago | link

What arc are you using? On anarki and arc3.1 len.nil evaluates to 0.

Ah, I see rocketnia recently fixed it. Perhaps you just need to git pull?

http://github.com/nex3/arc/commit/9c0f4fb

-----

1 point by dido 4897 days ago | link

I just did a git pull on Anarki and indeed now (len nil) returns 0 as it should. However, (len 'sym) still returns 1, and I have to ask why this is so and not an error the way all other non-nil/string atomic values are.

-----

1 point by rocketnia 4897 days ago | link

Apparently Samuel Christie added it in order for Anarki's ppr.arc to work: https://github.com/nex3/arc/commit/fccf160fee607373ac15105e3...

I don't like len!sym being 1 either. I think ppr.arc is the thing that should be fixed, perhaps by having it use its own spinoff of 'len. But I didn't try to fix that; I just did the minimal change needed to get len.nil to work properly again.

It's kinda funny... I just noticed that both of my len.nil fixes (https://github.com/nex3/arc/commits/9c0f4fb2b54f4ceb11d0a2d2...) are currently living alongside each other, the older one just being dead code. :-p

-----

1 point by akkartik 4895 days ago | link

Perhaps he just wanted dotted lists to count the final element. I fixed that without breaking len!sym.

http://github.com/nex3/arc/commit/2d86c3

-----