Clojure

GC Issue 13: validate in (keyword s) and (symbol s)

Details

  • Type: Enhancement Enhancement
  • Status: Closed Closed
  • Resolution: Declined
  • Affects Version/s: None
  • Fix Version/s: Backlog
  • Component/s: None
  • Labels:
    None

Description

Reported by richhickey, Dec 17, 2008
Make sure they create readable keywords/symbols

Comment 1 by p...@hagelb.org, Apr 27, 2009
Could this be done with a regex, or should it try to confirm the name using the reader?
Comment 2 by p...@hagelb.org, Apr 27, 2009
I've implemented this in the attached patch. One thing that could be improved is that
invalid names simply raise an Exception, though it seems LispReader's ReaderException
would be more appropriate. I wasn't sure how to raise that though since it needs a
line number; it's not clear how to get the current line number.

The patch is still an improvement on the current state of things, though I'd
appreciate a tip as to how to raise the right exception.

I've also attached a patch to the test suite that ensures (symbol s) and (keyword s)
work properly in the context of invalid names. I can re-submit this to the contrib
project if that's desired if the core patch is accepted.
 0001-Test-invalid-symbol-keyword-names-raise-exceptions.patch
1.6 KB Download
Comment 3 by p...@hagelb.org, Apr 27, 2009
Last patch had a problem; used things like defn- etc. before they were defined in
core.clj. This attachment fixes that.
 validate-symbol-keyword-names.patch
2.1 KB Download
Comment 4 by p...@hagelb.org, Jun 13 (3 days ago)
This exists as a git branch too now: 
http://github.com/technomancy/clojure/tree/validate-symbols-issue-13

Activity

Hide
Assembla Importer added a comment -

cemerick said: [file:cpC-Qow3ar3P8LeJe5afGb]

Show
Assembla Importer added a comment - cemerick said: [file:cpC-Qow3ar3P8LeJe5afGb]
Hide
Assembla Importer added a comment -

cemerick said: [file:cpDbtWw3ar3P8LeJe5afGb]

Show
Assembla Importer added a comment - cemerick said: [file:cpDbtWw3ar3P8LeJe5afGb]
Hide
Assembla Importer added a comment -

richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)

Show
Assembla Importer added a comment - richhickey said: Updating tickets (#8, #19, #30, #31, #126, #17, #42, #47, #50, #61, #64, #69, #71, #77, #79, #84, #87, #89, #96, #99, #103, #107, #112, #113, #114, #115, #118, #119, #121, #122, #124)
Hide
Assembla Importer added a comment -

technomancy said: These patches no longer cleanly apply. Working on an updated version.

Show
Assembla Importer added a comment - technomancy said: These patches no longer cleanly apply. Working on an updated version.
Hide
Assembla Importer added a comment -

technomancy said: [file:d61sHuVFer3OGKeJe5afGb]: test and implementation

Show
Assembla Importer added a comment - technomancy said: [file:d61sHuVFer3OGKeJe5afGb]: test and implementation
Hide
Assembla Importer added a comment -

richhickey said: I just wonder if we can afford the overhead of this validation all the time

Show
Assembla Importer added a comment - richhickey said: I just wonder if we can afford the overhead of this validation all the time
Hide
Assembla Importer added a comment -

richhickey said: Anyone have any bright ideas on how to avoid the overhead?

Show
Assembla Importer added a comment - richhickey said: Anyone have any bright ideas on how to avoid the overhead?
Hide
Assembla Importer added a comment -

cemerick said: I'm sure this was brought up a long time ago in prior discussions, but: should validity of symbols and keywords even be defined? Insofar as libraries use them for naming things, especially as read from external representations (e.g. XML, RDF, SGML, etc), it seems like any validation would be an entirely artificial limitation.

For my money, having keywords and symbols print in a failsafe-readable way, e.g. #|symbol with whitespace| (maybe checking at print-time to see if the more common printing is suitable, as would be most common) would:

  • guarantee that symbols and keywords are readably printable
  • not limit libraries from using keywords and such in very convenient ways
  • provide a pleasant shortcut for using symbols and keywords that might not be "valid", but still somehow necessary
Show
Assembla Importer added a comment - cemerick said: I'm sure this was brought up a long time ago in prior discussions, but: should validity of symbols and keywords even be defined? Insofar as libraries use them for naming things, especially as read from external representations (e.g. XML, RDF, SGML, etc), it seems like any validation would be an entirely artificial limitation. For my money, having keywords and symbols print in a failsafe-readable way, e.g. #|symbol with whitespace| (maybe checking at print-time to see if the more common printing is suitable, as would be most common) would:
  • guarantee that symbols and keywords are readably printable
  • not limit libraries from using keywords and such in very convenient ways
  • provide a pleasant shortcut for using symbols and keywords that might not be "valid", but still somehow necessary
Hide
Rich Hickey added a comment -

Runtime validation off the table for perf reasons. cemerick's suggestion that arbitrary symbol support will render them valid is sound, but arbitrary symbol support is a different ticket/idea.

Show
Rich Hickey added a comment - Runtime validation off the table for perf reasons. cemerick's suggestion that arbitrary symbol support will render them valid is sound, but arbitrary symbol support is a different ticket/idea.

People

  • Assignee:
    Unassigned
    Reporter:
    Anonymous
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: