Skip to content
light-matters edited this page Feb 2, 2024 · 1 revision

Development notes

Proposal

‘What are you wanting to achieve with this funding?’

Currently, there is a great existing library for wolfram<>clojure interop but it’s relative lack of documentation and usability mean that it is, to the best of our knowledge, not widely known or utilized. We hope to address these issues and so bring the ease of wolfram interop towards similar bridges like clojisr and libpython-clj.

Specifically, fundamental goals would be to

  • merge recent work
  • create comprehensive inline documentation
  • create, big-picture, example namespaces: including onboarding tutorial and real-world examples (publically available in visible places like the sci-cloj website)
  • ensure easy kernel parallelism (i.e. validate and clearly document the package’s original claim: “…lets multiple Clojure threads execute Mathematica expressions without blocking others.”)
  • document how to use external wolfram packages as normal clojure namespaces
  • streamline setup so that wolfram symbols are loaded much faster, such that wolfram functions can be used almost as easily as library functions
  • start building the foundations for closely integrating wolfram with the emmy symbolic clojure system (https://github.com/mentat-collective/emmy)

‘Why is this project important to the Clojure community?’

Of the areas that the Clojure survey highlighted, this project would address the specific categories of data analysis, documentation and user growth.

Data analysis/processing, as also expressed by the Clojure leadership team, is a key growth area for the language but library coverage can be fragmented, with missing depth of functionality. Having access to specialised algorithms/functions however, can make or break analysis projects and so reestablishing a stable bridge between clojure and a first-in-class analysis language like Wolfram would go a long way in reassuring language choosers that Clojure can always meet their needs, even when there is no pure clojure library available.

Another key community area is the expansion of the community itself. Following on from above, there is a large section of the numerical scientific community who are not programmers but who rely on tools like Mathematica and Matlab and so interop in these areas will be crucial for community cross-over in the future. Generalized language interop is particurly important for safe onboarding of new users and experience suggests that there is a willing ‘market’ for integrating specialist tools within more comfortable general languages like Clojure.

Finally, this project would not only have its own benefits but it could lay the groundwork for future integration with the ‘emmy’ symbolic physics library. The emmy system is bringing open-source symbolic computation to both the back- and front-ends but it is missing key features and advanced libraries. A wolfram bridge could serve as a sure foundation and help create the real possibility of an almost unique physics programming space that clojure would be a great fit for but is not quite ready for.

Getting Started

download an engine

create a deps file

need git/url and git/sha (at the moment)

Can’t find installation

try setting up environment variable

might only be supported on MAC?

REPL doesn’t see the env variable

use emacs env setting

use path to ‘WolframEngine’ directory

all good!

Documentation

get autocompletion (maybe Emacs problem)

usage vs PlaintextUsage?

Data analysis workflow

  • Is there a better way of dealing with 2D data than using dtype-next? i.e. is the neanderthal library API intelligible?

Clay

usually have to refresh the browser on start

(get the spinner otherwise)

dtype-next

rem vs mod

  • Not easy to find!
  • doesn’t do negative numbers

Comments / ideas

Make a docker file for a demo

test on Windows partition

test Mathematica on desktop

how to find out if symbol is a function or not

currently looking at plaintextusage in core.clj (look at this)

more tests for wolfram datatypes

Do we want to use unicode characters as well?

why do symbols passed have to be alphanumeric? should we provide a conversion function?

integrate graphics with js frontend (future project?)

https://github.com/JerryI/wolfram-js-frontend

add contact links to the wolframite readme

less ambiguous naming for ‘convert’ operations (e.g. wl<-clj )

using wl/eval over and over is quite tedious

add subtract/minus tests

start wolfram manual for clojurists (no wolfram experience)

set ‘unqualify’ as the default

allow for exclusions

Questions

  • Can I eval plain mathematica syntax via strings? yes
  • how to strip namespace from symbols?
    • we need this explicitly
  • when to use convert and when to use eval?
  • what’s the deal with ‘eval’ and ‘evaluator’?
  • deal with ‘rules’. can we have a LHS and RHS operator?
  • can we use Mathematica functions in thread macros?

Troubleshooting

“MathLink connection was lost.”

opening too many kernels can fail

unlicensed mathematica present

Clone this wiki locally