search

adeze / kiama

Automatically exported from code.google.com/p/kiama
GNU Lesser General Public License v3.0
2 stars 0 forks source link

Add types to strategies #26

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
At present, rewriting strategies are untyped much as in Stratego.  We are 
prevented from 
constructing ill-typed terms by Scala's static typing, but there are currently 
no constraints on 
combinations of strategies.  Adding type parameters along the lines of function 
types should be 
possible.

Original issue reported on code.google.com by inkytonik on 5 Nov 2009 at 5:04

GoogleCodeExporter commented 9 years ago

Original comment by inkytonik on 5 Nov 2009 at 5:04

GoogleCodeExporter commented 9 years ago

Original comment by inkytonik on 6 Nov 2009 at 1:29

GoogleCodeExporter commented 9 years ago

Original comment by inkytonik on 10 Nov 2009 at 5:11

GoogleCodeExporter commented 9 years ago 
Also, explore whether better typing information makes it possible to overload 
things like strategy and strategyf, 
rule and rulef.

Original comment by inkytonik on 13 Nov 2009 at 3:08

GoogleCodeExporter commented 9 years ago

Original comment by inkytonik on 21 Oct 2010 at 3:24

GoogleCodeExporter commented 9 years ago

Original comment by inkytonik on 15 Jun 2012 at 9:29

GoogleCodeExporter commented 9 years ago

Original comment by inkytonik on 4 Jul 2013 at 12:23

GoogleCodeExporter commented 9 years ago 
1.6 will change the rule combinator to take a T ==> T partial function instead 
of an Any ==> Any. The semantics will be as before (fail where the function is 
not applicable, succeed otherwise) but there are two ways to fail now: the 
subject term is not a T, or it is a T but the function is not defined at it.

This change ensures that when you write a rule body you can't accidentally make 
it change the type of the subject term. E.g., something like rule[Num] { case 
Num (i) => Add (Num (i), Num (i) } won't compile now since it changes the type 
from Num to Add. The same body with rule[Exp] { ... } will compile if Num and 
Add are sub-types of Exp. Similarly, the following are ok: rule[Num] { case Num 
(i) => Num (i + 1) } or rule[Num] { case _ => Num (1) }.

Use rule[Any] { ... } to get the same situation as in versions before 1.6 where 
the type is not checked.

We don't believe it is possible (or desirable) to try for more checking that 
strategies are applied correctly. Fundamentally, strategies have to be Any => 
Any since we can apply them anywhere in a generic traversal.

Original comment by inkytonik on 20 Dec 2013 at 1:35

GoogleCodeExporter commented 9 years ago

Original comment by inkytonik on 3 Feb 2014 at 4:24

GoogleCodeExporter commented 9 years ago

Original comment by inkytonik on 9 May 2014 at 3:49