Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lookup Rules #23

Open
skaller opened this issue Oct 4, 2016 · 7 comments
Open

Lookup Rules #23

skaller opened this issue Oct 4, 2016 · 7 comments

Comments

@skaller
Copy link

skaller commented Oct 4, 2016

I hope ppl don't mind but I'm starting a new thread about lookup rules, since the "import discussion" is too long and isn't just about syntax. The right syntax to implement is the simplest most brain dead least capable one to start with, IMHO, then go on from there.

So will someone explain, if I say

import X

what does that do? Does it put X in scope? And nothing else?

What if I say

import X.Y

What symbols are no in scope? Note that in Python, X is in scope, as well as Y. Which is inconsistent.

@shelby3
Copy link

shelby3 commented Oct 4, 2016

My thinking as of now is that only the last (rightmost) item gets imported into scope.

@sighoya
Copy link

sighoya commented Aug 13, 2018

@skaller wrote:

import X
what does that do? Does it put X in scope? And nothing else?

I'm thinking that import is the wrong way to introduce a package or library, this should be done with a separate command like addLibrary() or library() otherwise you couldn't permit to name a module with the same name in your current project.

@shelby3

What is if a library requires you to provide to implement some functions, you will need some builtin support for that in repls.

Import statement should only provide aliasing functionality, therefore import X is without meaning, if you want to import ingredients then wildcards might be appropriate or a open X

@shelby3
Copy link

shelby3 commented Aug 13, 2018

@sighoya wrote:

otherwise you couldn't permit to name a module with the same name in your current project.

As long as your module has a different directory prefix (or repository id), then it can be uniquely qualified by the prefix.

What is if a library requires you to provide to implement some functions, you will need some builtin support for that in repls.

I don’t understand this comment.

@sighoya
Copy link

sighoya commented Aug 13, 2018

I don’t understand this comment.

You said that importing modules can require the importer to provide some implementations of imported signatures.

You said you will handle this in interface files, but how you will handle this in the REPL?

@shelby3
Copy link

shelby3 commented Aug 13, 2018

@sighoya wrote:

You said that importing modules can require the importer to provide some implementations of imported signatures.

Where did write that?

@sighoya
Copy link

sighoya commented Aug 13, 2018

Where did write that?

Maybe I misunderstood it, but you said something like that in connection with strong versus weak modularity.

@shelby3
Copy link

shelby3 commented Aug 14, 2018

@sighoya wrote:

Where did write that?

Maybe I misunderstood it, but you said something like that in connection with strong versus weak modularity.

I found the discussion in the Modularity issues thread #39, that you’re referring to and added a new post on that subject.

I have never coded a REPL so probably @keean is the one who should comment on your question.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants