Bill Page wrote:
>
> On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch
> <hebi...@math.uni.wroc.pl> wrote:
> > Riccardo GUIDA wrote:
> >> ...
> >> 3) The user is puzzled because
> >
> > The command line is not representative of FriCAS language.
>
> In my opinion it should be (almost) representative of FriCAS language (SPAD).
>
> > On command line interpreter evaluates things so can use actual values
> > to guess what would be useful.
>
> 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 the process it breaks several normal rules.
> >
> > Try:
> >
> > f(x) == if (x > 1) then 1
> > Type:
> > Void
> > Time: 0
> > sec
> > (7) -> f(2)
> > Compiling function f with type PositiveInteger -> Void
> > Type:
> > Void
> > Time: 0.02 (OT) = 0.02
> > sec
> > (8) -> f(0)
> > Compiling function f with type NonNegativeInteger -> Void
> > Type:
> > Void
> > Time: 0.01 (OT) = 0.01
> > sec
> >
> > In both cases you now get Void.
>
> Clearly this is a very poor (though technically correct) guess as to
> what the user might have wanted.
Maybe I should say more: compiling a function interpreter can _not_
use value, the function has to work for any value of argument, so
in compiled function interpreter has to obey rules. 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.
> > Unlike Spad compiler trying to declare type does not change the result:
> >
> > (9) -> f2(x : Integer) : Integer == if (x > 1) then 1
> > Function declaration f2 : Integer -> Integer has been added to
> > workspace.
> > Type:
> > Void
> > Time: 0
> > sec
> > (10) -> 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 .
> >
> > (10) -> f2(0)
> > Conversion failed in the compiled user function f2 .
> >
> > Cannot convert the value from type Void to Integer .
> >
>
> I cannot see any advantage in having this behavior in the
> interpreter.
Well, advantage is consistency with rules.
> 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".
--
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 fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
