On Thu, Oct 9, 2008 at 3:09 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> The question is, are people willing to deal with the breakage in the
> short term?
I certainly am, but that may not mean much. :-)
Nobody has spoken out against it yet -- that's a got to be a good sign.
> Could there be a reader warning, if \\ is seen in patterns?
Not really, in general such patterns are valid. For example #"\\w*"
currently means match zero or more word"characters. Proposed, #"\\w*"
would mean match a backslash followed by any number of "w"s
I suppose we could have a warning that flags "likely" errors, and then
a way to turn it off, but that doesn't sound like a nice solution.
> Is there a possible conversion or safe interpretation of existing
> patterns (esp. \\\" and \\\\)
I'm not quite sure what you mean. Is this the part of the previous question?
#"\\\"" Currently matches the single char double-quote, Proposed would
match a backslash followed by a double-quote
#"\\\\" Currently matches the single char backslash. Proposed would
match a backslash followed by another backslash.
If you mean could old patterns be programmatically converted to new
ones, the answer is yes. Somehow I don't think you're asking for a
code walker that spits out what it reads, except with old regex
literals replaced with new ones, but I suppose that could be done.
The only pattern I've found that is currently valid that wouldn't be
under the proposal was mentioned in my earlier email: #"\\(" currently
matches a literal open paren. Proposed would be interpreted as a
backslash and the beginning of a group, but without the closing paren
Pattern/compile will throw an exception.
> How tricky is the print side?
Simple for Patterns created using the proposed literal form, as the
Pattern hangs on to the original string -- just slap #"" around it.
But I suppose that's not quite good enough, as you can build Patterns
other ways: (Pattern/compile "\"")
I think the only cause of trouble is the " char, so the Pattern's
string would have to be scanned looking for " and determining if it's
already quoted. If quoted, leave it alone; if unquoted, insert a
backslash. I'll code it up, unless this proposal is already dead on
one of the other points.
Thanks,
--Chouser
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
