This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-27
Channels
- # bangalore-clj (2)
- # beginners (41)
- # cider (14)
- # cljs-dev (12)
- # cljsrn (2)
- # clojure (106)
- # clojure-austin (6)
- # clojure-dev (22)
- # clojure-dusseldorf (1)
- # clojure-france (1)
- # clojure-greece (17)
- # clojure-italy (6)
- # clojure-poland (3)
- # clojure-russia (10)
- # clojure-serbia (5)
- # clojure-spec (24)
- # clojure-uk (100)
- # clojurescript (126)
- # cursive (3)
- # data-science (5)
- # datascript (15)
- # datomic (3)
- # defnpodcast (2)
- # dirac (6)
- # emacs (10)
- # fulcro (121)
- # graphql (30)
- # hoplon (7)
- # jobs (2)
- # leiningen (20)
- # off-topic (14)
- # onyx (3)
- # other-languages (13)
- # pedestal (1)
- # perun (2)
- # planck (41)
- # re-frame (16)
- # reagent (6)
- # reitit (5)
- # remote-jobs (3)
- # ring (1)
- # ring-swagger (17)
- # shadow-cljs (137)
- # spacemacs (6)
- # sql (4)
- # uncomplicate (7)
- # unrepl (56)
- # vim (27)
is there a reason for things like #_ #doesn't-exist 42
and #_ #inst :not-a-string
to fail the reader?
I understand why it fails based on the current impl, just wasn't sure if that was an intentional design or just something nobody's bothered to change
@gfredericks it's by design
well arguably my case is somewhat intermediate
in order of severity: #_ [)
, #_ #nothing 42
, #_ (not-a-real-function)
but there are ways to call read that allow for unrecognized tags
so you could implement it as the reader shifting to a more lenient mode for the scope of the #_
oh, I think I see why that case is tricky
cool that's good enough for me
right and I'm sure there are a bunch of other cases like that where making the reader more leninent would actually cause a behavioural change
thanks, #?@
!
I would put my money on #?@
being the only problem
but not a whole lot of money
let's agree right now that one of us will pay the other an indeterminate amount of money if this issue is ever resolved