richardhundt
commented
10 years ago On 3/31/14 9:31 AM, romix wrote:
HI Richard,
We discussed some of the ideas in the #38 https://github.com/richardhundt/shine/issues/38 already, but I thought that moving them into a dedicated issue would make it easier to track the progress.
Currently, guards are supported for function parameters. It would be nice to support them at more places, e.g.:
1) Inside the cases of a |given|statement (at the end of the cases, as an additional condition). We discussed it and it should be fairly easy to implement.
still TODO
2) It would be interesting to support guards for variables as a counterpart of guards for function parameters. I think they can be seen as invariants. It can be type guards, which should check that only values of a certain type are assigned to a variable. Or it can be more generic guards that may check that values of variables satisfy a certain invariant (e.g. >= 10 and <= 100). Obviously, it may be even more complex. I don't know if it is feasible at all in a general case and to which extent. But if it would be possible, it would basically provide an optional typing for Shine, which can be very interesting and useful. The big question if it can be done at all and efficiently. It would be also interesting to see how far LuaJIT can go in optimizing it away and making use of provided information. More over, in some cases, some kind of a local type analysis or inference could probably eliminate a lot of checks introduced by guards, because their results can be computed statica lly....
I think this feature is probably the most difficult/controversial of all that I mention here.
I've pushed a commit which associates guards to variables.
Destructuring works too:
o = { answer = 42 }
-- later
local { answer = x is Number } = oThe way guards work is simple: any object which implements an __is
method can be used as the right-hand-side in an is assertion. Classes
and modules have the hook already implemented (there's special handling
of cdata and primitive types).
Check out util.guards which lets you say things like:
import ge from "util.guards"
local n is ge 0 = 42
n = 69 -- OK
n = -1 -- Error: (ge 0 expected got Number)On the efficiency side, it depends on what the guard is doing. If the
guard has short loops then it's likely to cause a trace abort (i.e. the
like guard which does structural checks). Simple checks such as
Number or class checks are very fast. I have to crank a micro
benchmark up to 100M iterations to notice any difference.
3) If we have support for parameter guards and/or variable guards, one can think about different way of describing them. Currently, you directly attach them to the declaration of a parameter or variable. But one can think of annotations/decorators. Or even AOP (Aspect Oriented Programming)-like approaches, where you could say "all parameters/variables whose name starts with i should be of type int", "all objects of class Point should be immutable", etc. This approach is very powerful, because with just one such definition you can cover any number of real parameter/variable declarations...
I'll need to think about this some more.
4) And, as we discussed, there could be a compiler/run-time switch to disable/enable guards. This way one could use guards in development mode to ensure that her app is type-correct, etc and disable them for production, if performance is more important.
TODO
— Reply to this email directly or view it on GitHub https://github.com/richardhundt/shine/issues/49.
romix
HI Richard,
We discussed some of the ideas in the #38 already, but I thought that moving them into a dedicated issue would make it easier to track the progress.
Currently, guards are supported for function parameters. It would be nice to support them at more places, e.g.:
1) Inside the cases of a
givenstatement (at the end of the cases, as an additional condition). We discussed it and it should be fairly easy to implement.2) It would be interesting to support guards for variables as a counterpart of guards for function parameters. I think they can be seen as invariants. It can be type guards, which should check that only values of a certain type are assigned to a variable. Or it can be more generic guards that may check that values of variables satisfy a certain invariant (e.g. >= 10 and <= 100). Obviously, it may be even more complex. I don't know if it is feasible at all in a general case and to which extent. But if it would be possible, it would basically provide an optional typing for Shine, which can be very interesting and useful. The big question if it can be done at all and efficiently. It would be also interesting to see how far LuaJIT can go in optimizing it away and making use of provided information. More over, in some cases, some kind of a local type analysis or inference could probably eliminate a lot of checks introduced by guards, because their results can be computed statically....
I think this feature is probably the most difficult/controversial of all that I mention here.
3) If we have support for parameter guards and/or variable guards, one can think about different way of describing them. Currently, you directly attach them to the declaration of a parameter or variable. But one can think of annotations/decorators. Or even AOP (Aspect Oriented Programming)-like approaches, where you could say "all parameters/variables whose name starts with i should be of type int", "all objects of class Point should be immutable", etc. This approach is very powerful, because with just one such definition you can cover any number of real parameter/variable declarations...
4) And, as we discussed, there could be a compiler/run-time switch to disable/enable guards. This way one could use guards in development mode to ensure that her app is type-correct, etc and disable them for production, if performance is more important.