Bill Page wrote:
>
> On Sat, Jun 30, 2018 at 9:40 AM, Waldek Hebisch
> <[email protected]> wrote:
> >>
> >> On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch
> >> <[email protected]> wrote:
> >> > On command line interpreter evaluates things so can use actual
> >> > values to guess what would be useful.
> >>
> > Bill Page wrote:
> >> Yes, one should expect that the interpreter would try harder to
> >> guess reasonable types in order to relieve the user of (some)
> >> of this responsibility.
> >>
> > In command line expression interpreter can use values.
> > Sometime you get message that compilation failed, and
> > that function will be interpreted. In such case interpreter
> > uses similar rules as on command line. However, for serious
> > computation such cases should be avoided because assigning
> > types takes quite a lot of time. In compiled functions this is
> > done once per type, when interpreting type assignment is
> > re-done on every execution of a statement.
> >
>
> Yes. There is a system command:
>
> )set function compile off/on (on by default)
>
> which is described as
>
> compile compile, don't just define function bodies
>
> but when I set function compile off, I still got the following result:
>
> (1) -> )set function compile off
> (1) -> f2(x : Integer) : Integer == if (x > 1) then 1
> Function declaration f2 : Integer -> Integer has been added to
> workspace.
> Type: Void
> (2) -> f2(2)
> Compiling function f2 with type Integer -> Integer
> Conversion failed in the compiled user function f2 .
>
> Cannot convert the value from type Void to Integer .
>
> --
>
> Does this option still work? Perhaps my expectation was wrong.
"Compile" have many meanings. The option concerns _Lisp_ compilation.
I wrote about higher level, where compilation assentially means
type assignment. AFAIK intepreter always tries to compile that
is perform types assignment. Only when it fails function is
interpteted (and this is lot slower then executiong function
compilered by interpteter to Lisp and intepreted by Lisp
implementation).
> >> ...
> >> I cannot see any advantage in having this behavior in the
> >> interpreter.
> >
> > Well, advantage is consistency with rules.
> >
>
> Could you site specifically what rule is being violated?
The one that Ricardo was asking about: that 'if' always works,
but for one armed 'if' you get Void as a type.
>
> >> I think the interpreter should be changed to do the same
> >> thing as the Spad compiler. The function should attempt to coerce
> >> the result of the if-then expression
> >>
> >> if (x > 1) then 1
> >>
> >> to Integer. Of course this might cause an error for certain values
> >> of x but the user is not likely to be surprised by this.
> >
> > Well, there are folks that want static checking, that is no type
> > errors at runtime. They prefer Void as a result type. And
> > there are folks who want to bend the rules. IMO some sloppines
> > on command line is OK. But already for "interpreter" functions
> > stricter type rules may be beneficial.
> >
> > Of course, having more relaxed rule in Spad compiler and stricter
> > rule in intepreter is counterintuitive. The only explanation I
> > see is that original authors decided to change rules. Remember
> > that Spad is "old compiler" and compiler included in intepreter
> > is "new compiler".
> >
>
> In fact the Spad compiler does not always do what I had hoped. For
> example compiling the following function using Spad:
>
> f(x:Integer):PositiveInteger == if x<1 then 1
>
> --
>
> (1) -> f(0)
>
> (1) 1
> Type: PositiveInteger
> (2) -> f(1)
> Internal Error
> Interpreter code generation failed for expression(|f| 1)
The message looks fishy. Do you really used _Spad_ function here?
The message looks like coming from interpreter and given Spad
function of correct type interpreter should just blindly call it.
> --
>
> This is a rather unexpected and obscure errror message.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
