As an experiment I changed the type of stringp to tOr(tFunc(tStr,tInt1),tFunc(tNot(tStr),tInt0))
That does however cause compilation warnings that I think are wrong:
Getopt.pmod:109: Warning: Calling non-function value. Getopt.pmod:109: Warning: Type called: function(string : int(1..1)) | function(!string : int(0..0))
That type of stuff is generally not very useful.
Not sure if it will cause any actual problems, but it's always annoying when the compiler generates a warning or error because it knows the outcome of a computation, but in the real world the value of the computation is dependant on a define or a constant which actually changes from compilation to compilation.
On the other hand, if the compiler just keeps quiet and uses the type for optimization purposes only, all is well.
/Hubbe
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-12-04 23:37: Subject: Types
As an experiment I changed the type of stringp to tOr(tFunc(tStr,tInt1),tFunc(tNot(tStr),tInt0))
That does however cause compilation warnings that I think are wrong:
Getopt.pmod:109: Warning: Calling non-function value. Getopt.pmod:109: Warning: Type called: function(string : int(1..1)) | function(!string : int(0..0))
/ Martin Nilsson (saturator)
I was thinking that perhaps it would be an idea to have a function that returns the compiled bytecodes in a symbolic way so that it is possible to write a testsuite for optimizations.
/ Martin Nilsson (saturator)
Previous text:
2003-12-05 01:21: Subject: Types
That type of stuff is generally not very useful.
Not sure if it will cause any actual problems, but it's always annoying when the compiler generates a warning or error because it knows the outcome of a computation, but in the real world the value of the computation is dependant on a define or a constant which actually changes from compilation to compilation.
On the other hand, if the compiler just keeps quiet and uses the type for optimization purposes only, all is well.
/Hubbe
/ Fredrik (Naranek) Hubinette (Real Build Master)
pike-devel@lists.lysator.liu.se