zlacker

As far as you're thinking in procedural mind, probably there seems to be a big difference between constants and procedures (functions).

Once you are converted to functional mind, difference between a constant and a function that returns a constant is very subtle. When you use combinators a lot, you no longer think functions as something "invoked" or "called" in the similar sense as in procedural languages.

A possible pitfall in this case is that Arc is dynamically typed language. I usually program in Scheme, but when I'm passing function-returning-function-returning-...-functions around a lot, sometimes the 'one-function-level-off' error becomes hard to track down. Implicitly promoting a numeric constant into a constant function possibly delays catching this bug (since it masks the function level difference) but I doubt that it makes situation much worse. I think optional type declarations and type inference would be a lot of help.

>>shiro+(OP)
It's not really a procedural vs. functional distinction - I'm fluent in Haskell and had the same initial reaction as cwarren. Rather, Arc is "weakly typed". The same bit of program data can be interpreted as different types depending upon the context where it's used. (This is distinct from strong-but-dynamic-typing like in Scheme or Python, where you have to explicitly convert between types.) It joins the club of Perl, PHP, and assembly in this regard.

I mentioned elsewhere on this thread that I think this is the right design decision given Arc's design principles, but that those design principles are flawed. In my experience, bugs resulting from implicit coercions are rare, but they're also really difficult to track down. That was a major reason I switched from PHP to Python.

>>nostra+l2
OK, I stand corrected. Statically-typed minds also frown on this. It might be only Lispers that feel differently (after all, they've been conflating an empty list, a boolean false, and a symbol NIL and insisting it's the right thing).