Can't require a namespace in a try block and use it simulaneously

[ikappaki]

Hi,

I can't seem to be able to require a namespace as and use it simultaneously in a try form

  exception: <class 'basilisp.lang.compiler.exception.CompilerException'>
      phase: :analyzing
    message: unable to resolve symbol 'abc/read-string' in this context

To reproduce

1. Open up the REPL and attempt to require and use basilisp.edn with an alias, an unable to resolve symbol error is thrown

basilisp.user=>   (try (require '[basilisp.edn :as abc])
                       (println :x abc/read-string)
                       (finally :done))

  exception: <class 'basilisp.lang.compiler.exception.CompilerException'>
      phase: :analyzing
    message: unable to resolve symbol 'abc/read-string' in this context
       form: abc/read-string
   location: <REPL Input>:2

The same works fine in a do block

basilisp.user=>   (do (require '[basilisp.edn :as abc])
                       (println :x abc/read-string))
:x <function read_string at 0x0000019460C6E520>
il

A workaround is to use requiring-resolve

basilisp.user=>   (try (let [rs (requiring-resolve 'basilisp.edn/read-string)]
                         (println :x @rs))
                       (finally :done))
:x <function read_string at 0x0000019460C6E520>
nil

(maybe has the same root cause as #1065?)

Thanks

[chrisrink10]

@ikappaki As best as I can tell this does not work in Clojure either. It's a little hard to test since at least using clj most of the core namespaces are already loaded so it won't appear to fail in certain cases:

user=> (try (require '[clojure.edn :as abc])
                       (println :x abc/read-string)
                       (finally :done))
Syntax error compiling at (REPL:2:24).
No such namespace: abc
user=> (try (require '[clojure.edn])
                       (println :x clojure.edn/read-string)
                       (finally :done))
:x #object[clojure.edn$read_string 0xceb4bd2 clojure.edn$read_string@ceb4bd2]
nil

I did try to create a small project with a separate namespace that would not be loaded by default and I was able to reproduce there as well.

At any rate, I'd probably like to close this and #1065 since I don't think they can easily be fixed and requiring-resolve is a workaround.

[ikappaki]

I did try to create a small project with a separate namespace that would not be loaded by default and I was able to reproduce there as well.

At any rate, I'd probably like to close this and #1065 since I don't think they can easily be fixed and requiring-resolve is a workaround.

Right, thanks for investigating. As you've confirmed, the same error occurs in Clojure indeed.

requiring-resolve it is the way forward then. Do you think it would be useful to add a note in the require docstring about this issue and the workaround?

I'll update #1065 separately. I’ve already come across a case that could benefit from something like the importing-resolve idea that you mentioned ...

[chrisrink10]

requiring-resolve it is the way forward then. Do you think it would be useful to add a note in the require docstring about this issue and the workaround?

I'll update #1065 separately. I’ve already come across a case that could benefit from something like the importing-resolve idea that you mentioned ...

I will submit a PR with the importing-resolve (which I coded up just to see if it would work) and I will also update the docstrings of require and import to reference those functions as a workaround to these issues.

If you don't mind, I'll close #1065 as a duplicate?

[chrisrink10]

Merged #1072 and hoping that will address both of your issues for now @ikappaki

It includes a docstring reference to the -resolve variants and also adds importing-resolve so you can dynamically import Python names.

[ikappaki]

I will submit a PR with the importing-resolve (which I coded up just to see if it would work) and I will also update the docstrings of require and import to reference those functions as a workaround to these issues.

If you don't mind, I'll close #1065 as a duplicate?

Thanks @chrisrink10, this is perfect!