/////////////////////////////
#import <flx.flxh>

type INT = "int";
fun INTOF: int -> INT = "$1";

typeclass ADD[t] {
  virtual fun add: t * t -> t;
  virtual fun mul: t * t -> t;
  reduce ASS(x:t, y:t, z:t): x * z + y * z => (x + y) * z;
}

instance ADD[INT] {
  fun add: INT * INT -> INT = "$1+$2";
  fun mul: INT * INT -> INT = "$1*$2";
}

open ADD[INT];

proc fprint: ostream * INT= "*$1<<$2;" requires iostream;

var a = INTOF 2;
var b = INTOF 3;
var c = INTOF 5;
var r = a * c + b * c;
print r;  endl;

//////////////////////////
//C PROC _init_
void FLX_REGPARM _init_(FLX_APAR_DECL_ONLY){
      PTF a = 2 ;
      PTF b = 3 ;
      PTF c = 5 ;
      PTF r = (PTF a + PTF b ) * PTF c ;
      *(&cout)<<(PTF r);
      std::cout << std::endl;
}
//////////////////////////////

This reduction was done polymorphically, i.e. on the virtual
functions.

Currently, the monomorphisation pass doesn't monomorphise
reductions, so they can't be applied after monomomorphisation.

It isn't clear if instantiating reductions is actually sound.
For example you could have:

        typeclass A[t] { fun add: t * t -> t = "$1+$2"; }
        typeclass B[t] { fun add: t * t -> t = "$1+2*$2"; }
        instance A[int]{}
        instance B[int]{}

This is perfectly fine, since in a function you say:

        fun f[t with A[t]] (x:t) => x + x;

which specifies the A version of add. However any reduction
rules for typeclass A and B, when monomorphised, could be
applied, and these rules might conflict.

The problem is once instantiated, the connection between
the typeclass and the ground type is lost: the reductions
should really be dispatched virtually, so only the one
associated with the typeclass is applied. Contrast to the
rule:

  reduce ASS(x:INT, y:INT, z:INT): x * z + y * z => (x + y) * z;

which can be applied AFTER instantiation, since it isn't
specific to any typeclass, no matter what the semantics
of * and + are in  the typeclass: after monomorhisation
these are concrete functions + and * applied to INT.

This means reductions have to be applied both before and after
monomorphisation. Note they're currently applied during inlining,
and the inliner is run twice, before and after monomorphisation.

I need an example where an expected reduction doesn't apply!
[There are sure to be some]

BTW: the distributive law (badly called ASS above) seems to
apply to floats .. is that so? I mean clearly we don't have
equality, but it looks numerically stable...

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
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
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to