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

Enable default module.ceylon (review only) #1022

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Enable default module.ceylon (review only) #1022

wants to merge 3 commits into from

Conversation

akberc
Copy link
Member

@akberc akberc commented Jul 14, 2014

This pull request is just for review and discussion. Default module with name "default" with package "" seems to compile and run fine, with no detrimental effect on existing compilation or compilation of default module without module.ceylon:

module  { // no name, it is parsed to "default/unversioned"
    import ceylon.collection "1.1.0";
}

package;  // no name, it is parsed to ""

Although the compilers compiles the default module with module.ceylon and package.ceylon fine without imports, it does not add dependencies to the module annotation, although they are present in the typechecker. Some additional errors are also thrown.

@lucaswerkmeister
Copy link
Member

CC #200, the module { import …; } syntax was suggested there IIRC – or did you come up with it independently? (Either way, it’s a great step towards Scriptable Ceylon IMO.)

@quintesse
Copy link
Member

@lucaswerkmeister This is just so you can add a module.ceylon file for a default module. I don't think it does much yet to improve scripting. Although being able to import from a default module is a necessary step forward for scripting as well of course.

@lucaswerkmeister
Copy link
Member

Right, for a script this needs to be allowed in a regular CU (not the three kinds of CU we have today).

@akberc
Copy link
Member Author

akberc commented Jul 14, 2014

@lucaswerkmeister Yes, it is. I have followed #200 before, but I think it is logical, as the word 'default' should not be in the user vocabulary, but implied, in order to keep the folder structure in sync with the naming. So, souce root = no folder name = no module name = no package name -- as far as the user is concerned. Running it needs 'default'.

@gavinking Does the grammar look OK?, as that will drive the code and testing.

As the language allows multiple type declarations in a source file, is the need for both module.ceylon and package.ceylon a bit overdone? IMHO, the most natural thing would be for a module.ceylon at the root of the module, with an optional package declaration in the same file if needed to share -- otherwise it is the root package. Within the sub-packages, only package.ceylon is possible.

@gavinking
Copy link
Member

I dunno, I'm not totally convinced that we shouldn't make them write module default { ... }. Can't seem to make up my mind...

@quintesse
Copy link
Member

Can't seem to make up my mind...

Writing module default was also the first thing that came into my mind, but I think I prefer @akberc 's version in the end.

@quintesse
Copy link
Member

@gavinking we never decided what to do with this and has been sitting here for a long time. Don't you think this could be worthwhile?

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

Successfully merging this pull request may close these issues.

None yet

4 participants