> I 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.
> I 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.
> So, today morning I thought:
> We 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.
> So, 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.
> Of 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
_______________________________________________
Aldor-combinat-devel mailing list
Aldor-combinat-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aldor-combinat-devel
