zlacker

Figure I might as well post this here as well:

Numbers _are not_ functions! This kind of attitude is what gets you python's list formatting operator:

>>> "%s" % ("a string",)

'a string'

>>> "%s" % ["a string"]

"['a string']"

I've been burned by that before, and I'm not exactly stupid.

(I don't think this posted the first time. Forgive me if this turns out to be a double.)

edit: Bah, I can't get this code to format properly. How's that for ironic ;)

>>cwarre+(OP)
Arc seems to take a very implicit approach to things - rather unlike Python. I haven't written anything non-trivial in Python, but it looks like the problem with the list formatting operator is that it's an infix operator that depends on similar looking characters (paren and square bracket) for its syntax. I think it might be less confusing as a function or method:

 list_format("%s", ("a string",)
 list_format("%s", ("a string",)
 ("a string",).format("%s")
 ["a string"].format("%s")

Looking at it on the screen, making it a method call looks far less confusing. Arc treating constants and sequences as functions doesn't seem like the same kind of thinking to me.

>>Zak+h
Perhaps I should've elaborated a little. Here's a follow-up that I posted on reddit:

both of them violate the user model in subtle ways[1]. Most people don't expect numbers to act as functions. If a bug crops up because of it, more than likely they won't check to see if that's the problem. Again, I'm not against brevity. Just don't make functionality implicit in situations when the programmer isn't expecting it. If you use it so much, use a symbol prefix like `--I don't care. Just make it explicit.

In python's case, it's because it treats tuples and lists differently. Tuples and lists are almost always identical in python. The user's assumption is that they will also be identical in this case, when in fact they aren't.

[1] User interface design is surprisingly helpful when designing programming languages. It's fairly obvious why, but most people don't realize it.

>>cwarre+i
>User interface design is surprisingly helpful when designing programming languages.

I don't know why this is surprising (though I don't dispute that most people find it so). I think both Python and Arc pay a lot of attention to this principle, though their philosophies on the subject are quite different. I agree that allowing constants to be called as functions could be a source of bugs. It also seems like it could be, as PG says "quite handy". I'll have to see for myself when Arc is released.

>>cwarre+i
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.

>>Zak+h
For the record, in Python 3000, they're changing the printing and formatting around a lot, so the example above will become:

 "%s".format("a string")    #yields: a string
 "%s".format(["a string"])  #yields: ["a string"]
 "%s".format(("a string",)) #yields: ("a string",)

This will eliminate the confusing difference in the treatment of of tuples and lists when formatting a string. I think it's more clear, although I imagine some people will complain that "format" takes longer to type out than "%".

>>cwarre+i
Arc is supposed to be a LFSP. Smart people adjust their user model to the tools they have available (right?), so it's at least consistent with Arc's design principles.

It's not the choice I would've made - I tend to agree with you that "explicit is better than implicit". But languages all have to make certain assumptions about who their users are (same with UIs, really), and this design decision is consistent with Arc's previously-stated design philosophy.

>>shiro+A
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+V2
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).