Post by Martin RubeyI played around with things like Tuple Cross(T: PrimitiveType, List T) and
couldn't get it to work.
Oh, what did you want to put into the List T thing? I have already tried
something with
Object LabelType (see AUG)
instead of
Cross(T: PrimitiveType, List T)
But the *big* problem with Object is that one immediately loses type safety.
One would have a tuple of objects. And one is free to put an object in
the tuple that would not fit.
Remember that I would like to have something like
multiset(sm1: S M.1, ..., smk: S M.k): % == per (sm1, ..., smk);
with the Object approach all sm_i's are objects so one cannot ensure
that there is an S(M.i). I would like to move as much burden as possible
to the compiler. I don't like runtime-checking.
Post by Martin RubeyI believe that is due to the fact that Tuples are not
updateable, as the AUG says, and that makes sense, too.
That is certainly a problem. But also Array instead of Tuple would
probably not help. And with Array one loses a nice (and natural) syntax.
Post by Martin RubeyWe really want to be able to "see" the "arity" (is this the right term?) of our
multisort species, since, for Plus, Times, Composition and Functorial
Composition and in fact all transformations there are compatibility
restrictions on the arity.
But that is not a problem. Have you seen
#: I
in the mspecies code? It is exactly for that purpose.
Post by Martin RubeySo, maybe we want something like
MSPECIES(k: PositiveInteger) ==
(L: DirectProduct(k, LabelType)) -> MultiSortSpeciesCategory(L, ???)
and then, for example,
FunctorialCompose(m: PositiveInteger, F: MSPECIES m,
k: PositiveInteger, G: DirectProduct(m, MSPECIES k))
(L: DirectProduct(k, LabelType)): MultiSortSpeciesCategory(L, ???) == add {
Rep == F G
...
}
Looks like a good idea to include the arity in FunctorialCompose. It's a
bit like matrix multiplication. But on the other hand, I don't like it.
BLL also writes F(G1,...,Gm) and the arities are implicit. I am not yet
sure whether to include the arity in the signature. I tend not to have
it, but then, of course, the compiler has no chance to check that the
arities are OK. That would become a run-time check. However, given the
fact, that we probably cannot achieve compile-time type-safety with
either construction, I'd rather life with better syntax than this small
integer comparison overhead that will not happen too often anyway.
Post by Martin RubeyOf course, I don't know yet whether this would work...
What will probably not work is
Rep == F G.
The arities are then missing and things get a bit more complicated.
Ralf
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV