Arc Forumnew | comments | leaders | submitlogin
7 points by pg 4222 days ago | link | parent

And the problem with Arc is that currently the default value for an entry in a hash table is nil, rather than zero. If h is a hash table and you know (h 'foo) is 1, you can safely say

  (++ (h 'foo))  
But if you don't know whether (h 'foo) has a value yet you have to check explicitly:

  (= (h 'foo) (+ 1 (or (h 'foo) 0)))


1 point by metageek 4222 days ago | link

How about if <code>h</code> takes an optional second argument, which is the default, and the macros are smart enough that you can do <code>(++ (h 'foo 0))</code>?

-----

1 point by greatness 4218 days ago | link

I agree, this is probably the best solution.

-----

1 point by reitzensteinm 4222 days ago | link

Perhaps (++ containsnil) should result in 1 anyway? Is there any case where that would break anything?

-----

2 points by simonb 4222 days ago | link

For one it breaks the expectation of a strongly typed language.

If something goes wrong and you want to fail as soon as possible not propagate the defect through the system.

-----

1 point by reitzensteinm 4222 days ago | link

Oh, it definitely throws strong typing right out of the window.

The reason I suggested it is because it would seem that almost all of the time where you go to do an increment on a nil value, you're working with an uninitialized element (not necessarily in a hash map) and treating that as 0 (as you're doing an increment) would in a certain sense be reasonable behaviour.

But I guess you're right, in the case where nil does represent an error, it'll be two steps backwards when you go to debug the thing.

-----

1 point by william42 4215 days ago | link

Or perhaps just set containsnil to 0 when you do that. (Knowing pg, this would probably work.)

-----