Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> > In Aldor, we could do this by overloading. I.e., we could have something
> > like
> > SetSpecies(F: SPECIES): SPECIES
> > but I guess, it does not really pay off. We should make Compose as
> > efficient as possible.
>
> you have probably not meant it that way (or am I wrong?),
Well, yes, you are wrong. I meant it that way. Only, I believe that it is - at
least for the moment - the wrong path. Species should be finished in the *very*
near future, where "finished" means "in a usable state".
Of coure (and that's why I sent this mail), the documentation should mention
this possibility and maybe one could do a proof of concept example. But we (or
at least I) need to stop at some point. There are so many interesting and
useful things to implement! And even some basic stuff of species has barely
been touched so far: there are no virtual species, no multisorted species, no
linear species, no functorial composition, no Cartesian product, no ranking /
unranking algorithms, the generation of isomorphism types is only experimental,
molecolar decomposition is missing, heuristic testing for isomorphism of
species is missing, etc., etc.
I'm *not* saying that too little was achieved so far, quite the contrary. We
have reasonable good documentation and in my opinion an excellent design. We
have covered the most important aspects of combinatorial species.
But before I start to implement special cases for sake of efficiency, I'd like
to have better coverage of the theory.
> but yes that looks quite like a solution I would like.
thanks.
> Let us look at Compose and abbreviate
>
> macro SPECIES == (L: LabelType) -> CombinatorialSpecies L;
>
> then we have
>
> Compose: (SPECIES, SPECIES) -> SPECIES;
>
> Let us introduce the function
>
> apply: (SPECIES, SPECIES) -> SPECIES == Compose;
>
> Then if the compiler sees
>
> SetSpecies(F)
>
> it will call apply(SetSpecies, F) and thus effectively do a composition.
> Usually SetSpecies is of Type SPECIES. But nobody prevents us from
> introducing
>
> SetSpecies: SPECIES -> SPECIES;
>
> which does the obvious thing, ie, constructing E(F).
>
> If then the compiler sees SetSpecies(F) it will rather use that explicit
> constructor instead of invoking the "apply".
> In that way one can write generic code through "apply" and add specific
> improvements through special constructors that are independent of SetSpecies:
> SPECIES *and* independet of Compose/apply.
I must say that I'm very impressed with your ability to spell out my little
idea of a solution, covering all details! I couldn't have done this! Although I
must say that I'd prefer the compiler to allow something like
f(a: T1, b: T2): T3 == { generic implementation }
f(specialValueOfTypeT1, b: T2): T3 == { special implementation }
(By the way, wasn't there a problem with overloading. I cannot remember...)
Furthermore, it seems that the above does have a drawback. Imagine you write a
function f that takes three species A, B, C and returns, say, A*B(C).
Unless you implement it as a macro, it won't be able to take advantage of the
special code for the case of "special" B. I.e.,
f(A, SetSpecies, B)
will compute
Times(A, Compose(SetSpecies, B))
instead of
Times(A, SetSpecies B).
Martin
-------------------------------------------------------------------------
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
