Closed GoogleCodeExporter closed 9 years ago
Original comment by inkytonik
on 5 Nov 2009 at 5:04
Original comment by inkytonik
on 6 Nov 2009 at 1:29
Original comment by inkytonik
on 10 Nov 2009 at 5:11
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
Original comment by inkytonik
on 21 Oct 2010 at 3:24
Original comment by inkytonik
on 15 Jun 2012 at 9:29
Original comment by inkytonik
on 4 Jul 2013 at 12:23
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
Original comment by inkytonik
on 3 Feb 2014 at 4:24
Original comment by inkytonik
on 9 May 2014 at 3:49
Original issue reported on code.google.com by
inkytonik
on 5 Nov 2009 at 5:04