3 ms·

What about implementing your own Scheme or Lisp if you want to embed an interpreter for your C/C++ project (the first scenario discussed in the blog)? I recentl

by fspeech 12y ago

What about implementing your own Scheme or Lisp if you want to embed an interpreter for your C/C++ project (the first scenario discussed in the blog)? I recently decided to roll my own Prolog interpreter for my project. With C++11 and shared pointers it is really a breeze (of course I've thought about doing this for a long time so the actual implementation part was smooth sailing but not the only story). The advantage of rolling my own: 1. No GC. Ref counting is sufficient for my own use. 2. Integrating with the C/C++ libraries I want to use is a lot easier. I designed my implementation for the purpose of embedding in my project and gluing libraries.

username223 12y ago
> What about implementing your own Scheme or Lisp if you want to embed an interpreter for your C/C++ project (the first scenario discussed in the blog)? I've done this for a Java project many years ago, where it sort of grew out of a config file format, as so many Lisps do. I would probably take the trouble to add a standard embeddable interpreter if I did it again. Otherwise, you end up with yet another 80%-ass Scheme with its own quirks and no libraries, and the world has too many of those already.
- fspeech 12y ago
  I think it comes down to which is harder: 1) adapting your native libraries to a standard implementation or 2) adapting your implementation to your own libraries I decided that I mainly want Prolog to interact with, not to write a large amount of code in. So for me 2) was more advantageous.
- fspeech 12y ago
  "no libraries" I forgot to emphasize that this is not a real problem. You will likely have good C/C++ libraries for most things. The real issue really is to expose these libraries to your embedded language on a as-needed basis. To me the effort is better spent in creating my own targeted solution that makes interfacing easier and that is under my control than learning the minutia of the FFI of a third party implementation, after taking into account the following: 1) we are talking about effort on the scale of one or a few KLOC to roll one's own, and comparing that against the effort needed to truly master the FFI of a third party implementation; 2) my interface is no longer limited to the lowest denominator that a standard implementer would face (e.g. most use C but I can use multiple inheritance and templates of C++ to make the interfacing a lot easier); 3) supporting FFI users is typically not the highest priority on the standard implementers' agenda (if there is any support at all).
  - username223 12y ago
    > You will likely have good C/C++ libraries for most things. For most things in your domain. Then someone wants regexps, or Windows path handling, or what-not, and you find that you didn't really implement Scheme macros, or some particular style of modules, so you lose. I agree that if you want C++ integration, you're probably going to want to roll your own. The first person to write an easy FFI that groks C++ name mangling will do a tremendous service to mankind.
    - astrobe_ 12y ago
      There's no "someone" in this context, because you're not designing a language for the masses, you're making your personal language. At best, if you put it on Github you'll maybe find a bunch of people wanting the exact same thing so you'll have a bunch of users&co-implementors that know that they're basically on their own if they choose to use your language. This is where small and simple languages such as Scheme, Forth or Lua shine: you can master and hack everything from the first byte to the last. The real issue with this approach is that, if you need a particular library you have to do the bindings yourself first. You have to deal with the delay required to design, implement and test it. On the other hand, the difference between learning the API for an another popular language and learning the native API so you can make the bindings for your language tends to zero as the complexity and size of said library goes up.
    - fspeech 12y ago
      "Then someone wants regexps, or Windows path handling, or what-not" I think you would be hard pressed to find something that is available in Scheme but not C/C++. Take regex, you have std::regex, many pcre wrappers and Google re2, which has strong linear time guarantee. If you go with chibi as recommended by the blog, does it come with a good regex binding? What if you want to use Google's library? By the time you figure out how to bind iterators or coroutines in c the effort may well have been used to roll your own c++ solution in the first place. "you didn't really implement Scheme macros" I agree that is a more serious barrier. One has to honestly assess one's own true understanding and ability in implementing the target language. I am not an expert in Scheme and I couldn't tell you how easy or hard this is. I did study Prolog and its implementations extensively so I knew exactly what I needed to do. There are so many good resources out there that if one is willling to put in the effort one will be richly rewarded for the learning experience.

by fspeech 12y ago

username223 12y ago

> What about implementing your own Scheme or Lisp if you want to embed an interpreter for your C/C++ project (the first scenario discussed in the blog)? I've done this for a Java project many years ago, where it sort of grew out of a config file format, as so many Lisps do. I would probably take the trouble to add a standard embeddable interpreter if I did it again. Otherwise, you end up with yet another 80%-ass Scheme with its own quirks and no libraries, and the world has too many of those already.

fspeech 12y ago
I think it comes down to which is harder: 1) adapting your native libraries to a standard implementation or 2) adapting your implementation to your own libraries I decided that I mainly want Prolog to interact with, not to write a large amount of code in. So for me 2) was more advantageous.
fspeech 12y ago
"no libraries" I forgot to emphasize that this is not a real problem. You will likely have good C/C++ libraries for most things. The real issue really is to expose these libraries to your embedded language on a as-needed basis. To me the effort is better spent in creating my own targeted solution that makes interfacing easier and that is under my control than learning the minutia of the FFI of a third party implementation, after taking into account the following: 1) we are talking about effort on the scale of one or a few KLOC to roll one's own, and comparing that against the effort needed to truly master the FFI of a third party implementation; 2) my interface is no longer limited to the lowest denominator that a standard implementer would face (e.g. most use C but I can use multiple inheritance and templates of C++ to make the interfacing a lot easier); 3) supporting FFI users is typically not the highest priority on the standard implementers' agenda (if there is any support at all).
- username223 12y ago
  > You will likely have good C/C++ libraries for most things. For most things in your domain. Then someone wants regexps, or Windows path handling, or what-not, and you find that you didn't really implement Scheme macros, or some particular style of modules, so you lose. I agree that if you want C++ integration, you're probably going to want to roll your own. The first person to write an easy FFI that groks C++ name mangling will do a tremendous service to mankind.
  - astrobe_ 12y ago
    There's no "someone" in this context, because you're not designing a language for the masses, you're making your personal language. At best, if you put it on Github you'll maybe find a bunch of people wanting the exact same thing so you'll have a bunch of users&co-implementors that know that they're basically on their own if they choose to use your language. This is where small and simple languages such as Scheme, Forth or Lua shine: you can master and hack everything from the first byte to the last. The real issue with this approach is that, if you need a particular library you have to do the bindings yourself first. You have to deal with the delay required to design, implement and test it. On the other hand, the difference between learning the API for an another popular language and learning the native API so you can make the bindings for your language tends to zero as the complexity and size of said library goes up.
  - fspeech 12y ago
    "Then someone wants regexps, or Windows path handling, or what-not" I think you would be hard pressed to find something that is available in Scheme but not C/C++. Take regex, you have std::regex, many pcre wrappers and Google re2, which has strong linear time guarantee. If you go with chibi as recommended by the blog, does it come with a good regex binding? What if you want to use Google's library? By the time you figure out how to bind iterators or coroutines in c the effort may well have been used to roll your own c++ solution in the first place. "you didn't really implement Scheme macros" I agree that is a more serious barrier. One has to honestly assess one's own true understanding and ability in implementing the target language. I am not an expert in Scheme and I couldn't tell you how easy or hard this is. I did study Prolog and its implementations extensively so I knew exactly what I needed to do. There are so many good resources out there that if one is willling to put in the effort one will be richly rewarded for the learning experience.