erlport vs. effi

[joergen7]

Originally stated by @zampino:
ja, @joergen7 erlport is a very likely choice for a "local" cuneiform platform which is not involving effi, and we were having module name conflicts which prevented erlang releases to build.

In general (at level of code organisation) we could even consider a cuneiform-lib as
a separate erlang project which doesn't carry default platform code (like condor or local modules at present) and hence does not depend on any other library.
At present we need the local module and hence effi as a dip because the command line tool defaults to it..... thoughts? Maybe just for the long term plan...

[joergen7]

@zampino As stated, I had to consider the question whether to use erlport or to create a new library to support foreign function interfacing for Cuneiform. I was quite positive about erlport but, obviously, I went with my own library which has become effi.

Still, I have not abandoned the thought of using erlport entirely and I'm open for new ideas or experiments in this direction.

There would be some things that would have to work a little differently when using erlport. E.g., instead of binding input variables in the preamble of the user script we would have to create a function definition. Well enough. We would still have to inject some code to generate the return value of the function but getting the return value back to Erlang would come for free which is particularly ugly in Effi.

On the other hand, Python and Ruby alone are indeed not enough. Effi already supports 4 languages even if I have been super-lazy adding foreign languages. Things are a little easier if you have to operate only on strings (like Effi does). But in the long run being restricted to strings is a bad thing anyway.

So indeed, we might just give erlport a shot.

[joergen7]

To be a bit more specific, we wouldn't abandon effi for Cuneiform (if that was the suggestion). The question is rather whether to execute a foreign function with erlport or with Erlang's built in open_port.

[zampino]

we wouldn't abandon effi for Cuneiform (if that was the suggestion).

no, I didn't suggest that :-)! cuneiform as a language definitely needs effi because of the
command line.

I was thinking if we could excorporate the cuneiform semantic and reducer
in a core cuneiform lib package which would be a dependency (along with effi) of the cuneiform language package, this one covering the command line tools usw.

[zampino]

also we're using erlport because we need a more fein-grained results-set (like per-line evaluations of the task) but nothing against the effi approach...

[joergen7]

whatever works.