On Thu, Jan 26, 2023 at 10:03:12PM +0100, Ralf Hemmecke wrote:
> Is the following OK?
>
> (325) -> 4 or 3
>
> Argument number 1 to "or" must be a Boolean.
>
> (325) -> 4 or true
>
> Argument number 1 to "or" must be a Boolean.
>
> (325) -> true or 3
>
> (325) true
>
> (326) -> zero? 3 or 3
>
> Argument number 2 to "or" must be a Boolean.
>
> (326) -> zero? 0 or 3
>
> (326) true
>
> (327) -> true or "foo"
>
> (327) true
>
> Well, it is clear that a shortcut happens here, but I wonder whether we want
> the language to allow "or" to take non-boolean argument.
This is really artifact of true interpretation: true interpreter learn
types as by-product of evaluation. When second argument is not
evaluated its type is unknown and interpreter acts as if it was
good one.
This does not happen when "interpreter" compiles code:
(2) -> foo(x) == x or 3
Type: Void
(3) -> foo(false)
Argument number 2 to "or" must be a Boolean.
(3) -> foo(true)
Argument number 2 to "or" must be a Boolean.
(3) -> bar(x) == x or true
Type: Void
(4) -> bar(false)
Compiling function bar with type Boolean -> Boolean
(4) true
Type: Boolean
Maybe the above is not entirely clear, but interpreter allows
function definition "on faith". But on first use definitions
are compiled and AFAICS the errors came from compilation.
The last case is to show difference in messages when there
is correctly typed definition.
> This also is a problem in SPAD
>
> )abbrev package FOO Foo
> Foo: with
> foo: Integer -> Integer
> == add
> foo(x: Integer): Integer ==
> zero? x or
> return -13
> return x
>
> The following compiles and works as well.
>
> )abbrev package FOO Foo
> Foo: with
> foo: Integer -> Integer
> == add
> foo(x: Integer): Integer ==
> zero? x or (x := x+1)
> return x
>
> But what exactly is the type of
>
> zero? x or (x := x+1)
Would have to check compiler internals, but it is either Void or
maybe some internal equivalent. As general priciple, when
different branches of code with different types come to the
same program point compiler computes intersection of types.
It can happen that intersection has no valid values, this is
fine as long as you do not try to use such "thing". In both
your examples needed value is provided by return statement,
so conditions are satisfied.
Note that 'or' and 'and' are programming constructs. 'a or b'
essentially is the same as
if a then a else b
There may be some confusion, because Boolean defines 'or'
function. When you use function, then programming interpretation
does not apply. However, confusion is limited, when you have
pure correctly typed function, then possible short circuit
evaluation makes no difference.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20230128203541.febgdbiap4caw46u%40fricas.math.uni.wroc.pl.
