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
  • 1
  • 7
  • 2
    I would find a scripting language you like that has a C Foreign Function Interface, and use that. [This one](http://www.squirrel-lang.org/) looks promising. There is also Lua. Even Python would work. – Robert Harvey Jul 30 '15 at 00:16
  • The benefit of an existing language is that you don't need to write a book on how to use your language. Lua and Python are already well-documented. – MSalters Jul 30 '15 at 07:38
  • 1
    Something you might want to keep in mind: Your job is to give your users what they need to do their jobs, as easily as possible. This is not necessarily the same as what they think they want. – John R. Strohm Jul 30 '15 at 15:05

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
  • 5,895
  • 1
  • 21
  • 28
  • 1
    This seems like the most in-depth answer to me, and agrees well with others. Lua seems like a fairly good choice for this and the syntax will be less exotic to the users. (I'll avoid python though as previous adventures embedding it led to many issues) – Goobley Jul 30 '15 at 09:21
5

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,090
  • 8
  • 8
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,043
  • 5
  • 46
  • 56
  • 4
    He says that "the [Lisp] syntax will be quite foreign to the users" and you recommend something that is even more obtuse than Lisp. Then you recommend Lisp. Are you sure you read the question? – Robert Harvey Jul 30 '15 at 02:30
  • If I go back to lisp I'll look into those packages, I think the users would be happier off if I didn't though – Goobley Jul 30 '15 at 09:18
  • 1
    @RobertHarvey, what I saw was that (a) he wanted a REPL, (b) he didn't want to write a complicated parser, (c) he wanted a programming language, and (d) he wanted something that was easy for non-programmers to use. FORTH and LISP have been thoroughly demonstrated to meet all of those criteria. The trick, as Xerox learned, is "Don't call it programming and don't call it a programming language." (Note that HP for all practical purposes taught lots and lots of engineers the basics of FORTH, without every saying FORTH, in the HP RPN calculators.) – John R. Strohm Jul 30 '15 at 13:13
  • Factor (factorcode.org) is a modern Forth that may have good C++ interop (good C interop is claimed here http://fun-factor.blogspot.com/2007/10/getting-started-with-factor-easy-ffi.html . – Reb.Cabin Aug 14 '15 at 17:38
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,434
  • 6
  • 84
  • 125