Arc Forumnew | comments | leaders | submitlogin
Bug: (downcase nil) should return nil
3 points by akkartik 1701 days ago | 7 comments
Currently returns || (empty symbol)

My fix: wrap body for downcase/upcase in (if x ..)

But it raises the question of whether nil is a sym.



2 points by pg 1697 days ago | link

Oops, yes. That solution will work.

There's a corresponding bug in upcase, which I dealt with thus:

         sym    (if x (sym (map upc (coerce x 'string))) 'NIL)
Note that NIL isn't false.

-----

1 point by akkartik 1696 days ago | link

I've been treating (upcase nil) as nil, since (coerce nil 'string) isn't "nil". Haven't had occasion to need this so far, though.

-----

1 point by aw 1701 days ago | link

Yes, nil is a sym.

-----

1 point by akkartik 1701 days ago | link

Sorry, I meant, "..whether nil should be a sym"

-----

1 point by aw 1701 days ago | link

We have a number of "things" in the language: function names, a literal false value, user-defined symbols... the question is, does it make sense to use one representation for these, or to create several disjoint types?

Part of the power of Lisp is the ease of treating programs as data, to create, generate, and manipulate code with code, making Lisp as they say a "programmable programming language".

Representing all the tokens of the language as symbols simplifies manipulating code since we don't need separately recognize symbols vs. booleans.

Someone who feels that well defined, disjoint types are important to correctly reasoning about programs might prefer to have separate symbol and boolean types. But I would ask, "how does this help me actually write shorter programs?"

-----

1 point by rocketnia 1700 days ago | link

I don't have a problem with nil being a symbol, but speaking of writing shorter programs, I can't think of a single time I've actually needed to coerce nil/null to a string in any language except when printing it out for debugging purposes, and even then, in Arc:

  (is "nil" (tostring pr.nil))  ; because 'nil is sent to MzScheme's 'display
So when...

  (is "" string.nil)  ; because 'coerce special-cases 'nil to do this
...I'm taken by surprise, and I'm not sure where this discrepancy would pay off in brevity.

I suppose string-returning procedures that need to be convenient in boolean contexts can return nil instead of "" and expect anyone who calls them to wrap them up as string:foo in string contexts... but even so, I can't think of any practical examples of when doing that would be shorter than having the procedures return only strings and wrapping them up as ~empty:foo in boolean contexts.

Is there some brilliant use of (is "" string.nil) I'm not thinking of?

-----

5 points by aw 1700 days ago | link

Conditionally include things in a string:

  (string "You are going "
          (if (> speed 100) "very ")
          "fast")

-----