import path names vs keywords

[Jay Han]

import treats its argument as code?

> import is.foo.bar;

1:9: Expected type identifier, not '.' in the type expression

> import it.foo.bar;

>

Many TLD names cannot be used in import path such as in, is, fi? 

Moreover, import rejects some keywords and std function names but not others, for example:

> list

<yeti.lang.std$list> is map<'_a, '_b> -> list<'_b>

> import list.making.gone.bad;

> import b_and.more;

1:8: Expected class path after 'import', not a `b_and'

> import as.cii;

1:9: Expected type identifier, not '.' in the type expression

> import classOf.whatever;

1:15: Expected class name, not a `.whatever'

> import xor.rox;

1:8: Expected class path after 'import', not a `xor'

> import end.all.the.wars;

> import var.iety;

> import with.without.you;

1:8: Expected class path after 'import', not a `with'

> import load.lock;

1:12: Expected module name after 'load', not a `.lock'

> import loop.y.loops;

1:8: Expected class path after 'import', not a `loop'

> import unshare.separate;

> import typedef.fedepyt

1:15: Expected typename, not a `.fedepyt'

> import static.electricity;

>

[Madis]

On Sat, 11 Oct 2014, Jay Han wrote:

> import treats its argument as code?
>
> > import is.foo.bar;
> 1:9: Expected type identifier, not '.' in the type expression
> > import it.foo.bar;
> >
>
> Many TLD names cannot be used in import path such as in, is, fi? 
>
> Moreover, import rejects some keywords and std function names but not
> others, for example:

That way you can determine what really are keywords for Yeti. ;)

But yes, the dotted class names (as used after import, new,
instanceof, classOf, extends, ...) should really allow anything.
I'll add it to the TODO list.

[Jay Han]

On Wednesday, October 15, 2014 2:38:47 PM UTC-7, Madis wrote:

On Sat, 11 Oct 2014, Jay Han wrote:

> import treats its argument as code?
>
> > import is.foo.bar;
> 1:9: Expected type identifier, not '.' in the type expression
> > import it.foo.bar;
> >
>
> Many TLD names cannot be used in import path such as in, is, fi? 
>
> Moreover, import rejects some keywords and std function names but not
> others, for example:

That way you can determine what really are keywords for Yeti. ;)

But yes, the dotted class names (as used after import, new,
instanceof, classOf, extends, ...) should really allow anything.
I'll add it to the TODO list.

Another maybe issue is whether import checks its arguments against the classpath?

In the REPL, I rather get an error when I do

> import incorrectly.named.package; // sometimes typos ruin your day

so that I get to fix that error before trying to use it.

[chrisichris]

Created a pull-request so that import parses all Java Class names, (which hopefully works).

https://github.com/mth/yeti/pull/16

It does not check wheter the class indeed exists so.

(You see, I like the Parser more and more ;).

Chris

[Madis]

On Wed, 15 Oct 2014, Jay Han wrote:

> Another maybe issue is whether import checks its arguments against the
> classpath?
>
> In the REPL, I rather get an error when I do
> > import incorrectly.named.package; // sometimes typos ruin your day
> so that I get to fix that error before trying to use it.

It would make the compilation slower. Verifying that the class really
exists requires reading it. In many cases it would be the only reason to
read it, as for passing instances around you really don't care what the
class is.

You also should get compilation error in most cases while still compiling
the same module, as either you try match the type with some type expected
by other code, or directly when trying to create new instance or access
methods/fields.

The error messages could be improved - unknown class errors could point
directly to the import. Type mismatches could include the import in
error as comment, if only the package part of name is different.

[Jay Han]

sounds reasonable.