Import blocks (updated to use item lists)

[ghost]

Use blocks for same visibility imports e.g.:

public import
    math.*,
    private complex.(abs),
    printer;

Updated some libs and tests.

[stepancheg]

Looks like unnecessary complication: there is no problem with multiple public imports.

[ghost]

Well, this is not public import specific, just blocks of any imports with same visibility.

Consider core module imports:

public import __primitives__.*;
public import core.types.*;
public import core.operators.*;
public import core.sequences.*;
public import core.records.*;
public import core.tuples.*;
public import core.unions.*;
public import core.statics.*;
public import core.booleans.*;
public import core.memory.*;
public import core.operators.pod.*;
public import core.numbers.*;
public import core.numbers.overflow.*;
public import core.enumerations.*;
public import core.pointers.*;
public import core.values.*;
public import core.maybe.*;
public import core.variants.*;
public import core.variants.nested.*;

public import core.arrays.*;
public import core.coordinates.*;
public import core.ranges.*;

public import core.bytes.*;
public import core.characters.*;
public import core.strings.*;
public import core.strings.stringliterals.*;
public import core.strings.cstringrefs.*;
public import core.strings.stringrefs.*;

public import core.errors.*;
public import core.exceptions.*;

public import core.system.*;
public import core.system.platform.*;

public import core.complex.*;

Which can be written like so using a block:

public import {
    __primitives__.*;
    core.types.*;
    core.operators.*;
    core.sequences.*;
    core.records.*;
    core.tuples.*;
    core.unions.*;
    core.statics.*;
    core.booleans.*;
    core.memory.*;
    core.operators.pod.*;
    core.numbers.*;
    core.numbers.overflow.*;
    core.enumerations.*;
    core.pointers.*;
    core.values.*;
    core.maybe.*;
    core.variants.*;
    core.variants.nested.*;

    core.arrays.*;
    core.coordinates.*;
    core.ranges.*;

    core.bytes.*;
    core.characters.*;
    core.strings.*;
    core.strings.stringliterals.*;
    core.strings.cstringrefs.*;
    core.strings.stringrefs.*;

    core.errors.*;
    core.exceptions.*;

    core.system.*;
    core.system.platform.*;

    core.complex.*;
}

Which is better? (This is an extreme case, but a valid one nonetheless)

[stepancheg]

I honestly think that first is better, sorry. Because

• import list can be read from the bottom up, or from the middle
• single change diffs can be understood easier

Compare this: http://screencast.com/t/HExsxRxvTWMO with this: http://screencast.com/t/saLFAKgTy

[ghost]

Afraid I have to disagree. Also, the blocks are optional and the case exemplified by the core module is unlikely to occur in modules that provide anything other than imports. Throughout the current lib and my own code the typical import list is 5-10 lines, enough to benefit from blocking and few enough to be easily read without scrolling (which I find to be less hassle than unnecessary line noise anyway).

[jckarter]

I think you don't even need the braces:

import foo.*, bar, public bas.(zim, zang, zung);

[ghost]

@jckarter i like that idea, there really is no good reason to write import more than once per module. I'll modify the code and see how it looks.

[galchinsky]

@stepancheg definetly have worked with Java a lot. @agemogolk there's a reason to write import several times in REPL, though imports doesn't work very well in it now because of variant instances problem

[ghost]

@galchinsky multiple import statements could be supported without issue.

import foo.*;
import 
    goo.*, 
    boson.(zim, private zang, zung);
import public woo.*;

[galchinsky]

Looks fine for me. Suddenly it resemles Pascal uses

[ghost]

Updated to use comma seperated import lists. Retained top level visibility used as default for list items. List item visibility overides the default.