Language Bindings

20 views
Skip to first unread message

Kenneth Miller

unread,
Nov 22, 2023, 11:40:49 AM11/22/23
to FriCAS - computer algebra system
Are there any language bindings to ocaml? Or a way to generate them, like with swig?

Waldek Hebisch

unread,
Nov 22, 2023, 12:43:08 PM11/22/23
to fricas...@googlegroups.com
On Wed, Nov 22, 2023 at 08:33:38AM -0800, Kenneth Miller wrote:
> Are there any language bindings to ocaml? Or a way to generate them, like
> with swig?

AFAIK there are no "language bindings". There were some efforts
in this direction, but not much success. Basicaly the only
successful thing is Sage interface which allows you to call
FriCAS functions from Python.

Some issuse that anybody trying to do "language binding" must
resolve:

- FriCAS is garbage collected and FriCAS may move its data
in memory whenever it wants. Currently simple solution
to this is to copy relevant data. FriCAS runs on top
of Lisp and you can use FriCAS data directly from Lisp.
When FriCAS is build on top of ECL, then you may also
access FriCAS data from C (garbage collector in ECL is
"non-moving" so access from C is safe). In principle
this allows access to FriCAS data from any language
which can call C. But such acces would go via C functions
provided by ECL for accessing Lisp data, and one stil
would need some way to make sense of the data.

Sage solves this by using textual output from FriCAS (IIUC
mostly FriCAS InputForm). On FriCAS side this is produced by
buitin routine, on Sage side they have a parser (the format is
easy to parse).

- FriCAS is organized into domains and packages. Domains
are abstract data types, they define available operations.
To make sense of FriCAS data you need to map operations
to your language. No existing language has the same
semantics, so one have to define mapping between languages.
To claryfy a bit: FriCAS has overloading and decides
which function to call based on types of arguments and
type of result. And FriCAS can generate new types at
runtime. So you need some way to represent FriCAS types
and use them for overload resolution. In untyped language
you can treat all FriCAS things as generic data and put
all concerns of correctness on the user. In Ocaml there
is question how FriCAS types play with Ocaml types (do you
want to define a "generic" type that can represent any
FriCAS data?).

Sage maps selected FriCAS types to its own types (Python
classes). IIUC it directy exposes very small number
of operations. You can access more FriCAS functionality
by passing text commands.

As you can see there are tradoffs. Really good high level
interface seem pretty hard to do. Low level interface while
easier to do still have some unpleasent tradeoffs. If
you are satisfied with passing textual data and commands,
then you need to invest some effort in parser and possibly
mapping parsed data to Ocaml types, but basicaly this
should be doable with reasonable effort.

--
Waldek Hebisch

Kenneth Adam Miller

unread,
Nov 22, 2023, 6:40:07 PM11/22/23
to fricas...@googlegroups.com
Um, actually, if I could get by with some serialization, I could work with anything I can write/read to via a subprocess. But I do need to be able to encode into the language, to submit for processing and to retrieve the results. I don't really need to reach into the runtime. But I can't use any of the results from another program if I can't read the syntax of its output. I don't want to write a parser in another language for that.

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/tKRC2d4m3oY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZV49qbgt8zJzBz4g%40fricas.org.

Waldek Hebisch

unread,
Nov 22, 2023, 6:54:49 PM11/22/23
to fricas...@googlegroups.com
On Wed, Nov 22, 2023 at 05:08:29PM -0600, Kenneth Adam Miller wrote:
> Um, actually, if I could get by with some serialization, I could work with
> anything I can write/read to via a subprocess. But I do need to be able to
> encode into the language, to submit for processing and to retrieve the
> results. I don't really need to reach into the runtime. But I can't use any
> of the results from another program if I can't read the syntax of its
> output. I don't want to write a parser in another language for that.

Well, look at:

(1) -> f := exp(x) + sin(x^2*exp(x))

2 x x
(1) sin(x %e ) + %e
Type: Expression(Integer)
(2) -> f::InputForm

(2) (+ (sin (* (^ x 2) (exp x))) (exp x))
Type: InputForm
(3) -> PRETTYPRINT(f::OutputForm)$Lisp
(+ (|sin| (* (^ |x| 2) (^ |%e| |x|))) (^ |%e| |x|))

(3) ()
Type: SExpression
(4) -> PRETTYPRINT(f::InputForm)$Lisp
(+ (|sin| (* (^ |x| 2) (|exp| |x|))) (|exp| |x|))

(4) ()
Type: SExpression

InputForm and OutputForm allow you to get FriCAS expressions
(and lot of other FriCAS data) as Lisp S-expressions. You
need a parser, but it is a simple one, you need to track parenthesis
and a bunch of escapes. InputForm is supposed to be accurate
representation of FriCAS expressions, but for some date it is
not defined. OutputForm may be lossy (that is two different things
may print the same), but it is rare if you have type in hand
(elements of two different types frequently print the same).

--
Waldek Hebisch
Reply all
Reply to author
Forward
0 new messages