)if foo

[Ralf Hemmecke]

Interesting that I had to look into i-bugs.input in order to find
how to work with the )if directive and learn about ")assert".

)assert blah
)if blah
print "blah"
)else
print "foo"
)endif

Unfortunately, I am a bit reluctant to use undocumented stuff.
Any idea where such documentation could go to?

Ralf

[Ralf Hemmecke]

I seem to learn something new every day.

With the code below in a file f.input I get

(1) -> )r f

)assert blah
)if blah
print "blah"

"blah"
Type: Void

But if I enter )assert manually in a fricas session I get the following.

(2) -> )assert blah
Unknown system command: assert

So I suspected, that the )if construction might work inside a jfricas
cell. Since jfricas essentially creates a file with the content of a
cell and then let's fricas reads that. "Essentially", because it
actually does that without ever creating a file on disk using
"interpret_block".

The behaviour is weird as you see from the result. It accepts )assert,
but completely ignores )if, )else and )endif.

====== jfricas cell
)assert foo
x:=0
y:=0
)if foo
x := 1
)else
y := 1
)endif
[x,y]
====================
====== output ======
0
NonNegativeInteger

0
NonNegativeInteger

1
PositiveInteger

1
PositiveInteger

[1, 1]
List(PositiveInteger)
======= END =======

Waldek, do you know why interpret_block in src/interp/int-top.boot
behaves different from reading a file?
It's not a big deal, but I would like that virtually a jupyter cell can
be considered as a file, that is read by fricas.

Ralf

[Waldek Hebisch]

Well, in 2020 I wrote:

: However, this
: mechanizm is quite limited (and this appiles to Aldor too).
: Old Spad allowed arbitrary Boot expressions as conditions, which
: may be too general and had clearly big disadvange was usage of
: Boot. But I am not sure if we should emulate Aldor here.
: Minimal reasonable machanizm should allow Boolean conditions
: based on variables (assertions). But ability to do computations
: would be quite useful. ATM sources use ')if false' which is
: compatible with any reasonable future machanizm. And since
: existing mechanizm is incompatible with most replacements
: clearly I do not want to advertize it, in particular it
: is "actively undocumented", that is I do not want to document it.

To expand this a bit: one reasonable replacement would add
expressions + a few built in functions. Another possibility
is to assume availability of interpreter and use interpreter
to evaluate conditions.

--
Waldek Hebisch