Empty sequence is typed incorrectly about silver HOT 7 CLOSED

Bitbucket user bbrodowsky commented on 2013-06-03 15:33

I think the documentation of "Seq()" clearly states that it is for non-empty sequences, for exactly the reason you mentioned, if I am not mistaken. So this should just throw an exception.

from silver.

@mschwerhoff commented on 2013-06-03 15:39

The syntax overview indeed describes Seq[Int]() as the empty sequence. It does not explicitly say that Seq(...) must not be empty, but I guess you are right.

Unfortunately, parsing |Seq[Int]()| yields Parse error: Failure: 'old' expected but 'S' found.

from silver.

Bitbucket user bbrodowsky commented on 2013-06-03 15:42

I don't know the details of the parser and I did not work on it either, so I don't know what our problem here. I just remembered this thing about empty sequences.

from silver.

@alexanderjsummers commented on 2013-11-20 17:32

nicest (in my opinion) would be to be able to leave a kind of unification (type) variable, which could be determined later in type-checking. That might not be so easy (depending on how the type-checker currently works), but it's kind of annoying to have to write SeqInt in cases where the type is determined by the context.

In theory, one could carry around an environment mapping such variables to instantiations found so far during type-checking. If the whole type-checking goes through without instantiating such a variable, then its instantiation really doesn't matter for the program, and we could just pick some default (Ref / Int). Of course, leaving the unbound type variable is not a good option for downstream tools.

from silver.

Bitbucket user mnovacek on 2014-05-21 09:47:

• changed the assignee from (none) to bitbucket user juhaszu

from silver.

Bitbucket user juhaszu commented on 2014-05-28 12:33

Modified syntax so that empty collections require an explicit type

from silver.

Bitbucket user juhaszu on 2014-05-28 12:33:

• changed state from new to resolved

from silver.