3

I'm working on a medium size C++ project (will probably end up around 50k lines) and I have to provide an interactive terminal interface. The program produces scientific data as an output and the interactive interface is to let a researcher tweak a visual representation of what's going to be calculated before actually completing the calculation.

I'm not keen on interactive programs that define their own language since they're all different (leading to confusion) and if they support a lot of functions almost require the developer to implement a "proper" parser-interpreter for the syntax.

I would also like the ability to define "smart" configuration files using this program (thus avoiding the need to externally script it).

It seems to me that the correct answer is to implement an existing scripting language with its own support library that can make callbacks into C++. Since I've been playing with Common Lisp recently I decided to have a go at doing this using ECL (insanely overkill for my purposes) and I have bound functions into Lisp and built a Lisp REPL that is capable of executing these callbacks.

Whilst this more or less works, this doesn't really seem to be the use-case ECL was designed for, since I have to make quite a lot of effort to extract the user's input in a safe manner, and I'm using very few of its features.

This is not a request for a library suggestion (though I would happily accept those as well as an answer), but a methodology question. My users are not overly used to a lot of programming languages (the department uses primarily IDL), and it's uncommon that any other language is used. A full Common Lisp implementation seems like quite a sledgehammer to crack a nut and the syntax will be quite foreign to the users (which in many ways is what I wanted to avoid by using a pre-defined language).

Am I looking at the problem of building a REPL-like environment from the wrong direction - should I instead build my program into a library and use an interactive language with FFI against it?

Essentially:

  • I want to add an REPL like system to my C++ program for the user to setup their data.
  • I would rather avoid defining my own dialect/syntax/language for this purpose, instead using a ready-made interpreter and just calling back into C++
  • It would be nice to have the ability to use it for "smart" configuration files, that have logic inside them (basic control flow and arithmetic).
  • As easy to use as possible for non-programmers.

If you have solved this problem/had a similar dilemma in the past I would be interested to hear your thoughts (I understand this is quite an opinion based subject). Thanks!

Goobley
  • 191

4 Answers4

6

First, you have a false dilemma. If your users are not programmers and know only IDL, any other language (custom or existing) will look foreign to them. But that does not mean that they cannot learn something else. In fact, you would say that this is not really a problem: you'll have to write a tutorial and point them to documentation and other materials. All the languages below have good documentation. Common Lisp is a standardized language.

Lua

This is covered in another answer, but I would still recommend it. The language is made to be embedded, and works well with C++.

Python

Boost.Python is a popular way of integrating C++ code and Python. From what I heard, it seems that Python and especially NumPy is also popular for scientific computing.

Clasp

Even if you don't intend to use Common Lisp, please have a look at CLASP (video), which is an implementation of Common Lisp for C++.

A full Common Lisp implementation seems like quite a sledgehammer to crack a nut and the syntax will be quite foreign to the users (which in many ways is what I wanted to avoid by using a pre-defined language).

I see it the other way: instead of having half a language that barely works (this is not directed at above languages, but about custom ones), a full Common Lisp implementation gives you a stable and mature environment. I don't know what your scientific data is about, but your user could even work with Maxima directly from your environment, which has an infix syntax if you want.

Library/FFI

Am I looking at the problem of building a REPL-like environment from the wrong direction - should I instead build my program into a library and use an interactive language with FFI against it?

This is a possible way to do it, but I honestly cannot say which way is better for you.

Community
  • 1
coredump
  • 6,015
4

Your requirements describe Lua. Lua is designed to be embeddable as well as work as a declarative configuration language.

Other options I’ve seen or used include Tcl, Python, and JavaScript.

All of these languages can be embedded to various degrees of work and tend to be fairly easy for non-programmers (who think they can program) to use.

Bill Door
  • 1,100
2

If you really want to tick some people off, use FORTH.

You get an interactive control interface (in reverse Polish notation, admittedly) AND a programming (scripting) language.

Alternatively, you could dig up one of David Betz's little XLISP or XScheme packages. As I heard it, this is basically what Autodesk used to make AutoLISP for AutoCAD, a few decades back.

Xerox discovered, on one of their "office automation" products, that secretaries had no trouble at all learning to program in LISP, as long as they (Xerox) didn't call it "programming", but rather something like "extensions" or "customizations". I think it was the Dandelion, but don't quote me.

John R. Strohm
  • 18,161
2

You could embed some interpreter in your application. If you like Lisp as I do, you should consider embedding GNU guile or librep etc...

See also this & that & that answers

Community
  • 1
Basile Starynkevitch
  • 32,862