search

keean / zenscript

A trait based language that compiles to JavaScript
MIT License
42 stars 7 forks source link

Lookup Rules #23

Open skaller opened 7 years ago

skaller commented 7 years ago

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 commented 7 years ago

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

sighoya commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@sighoya wrote:

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

Where did write that?

sighoya commented 5 years ago

Where did write that?

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

shelby3 commented 5 years ago

@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.