That was the first place I looked.
Actually, I am attempting to make an ILSM for Fortran. I've got a parser thats *good enough* (for now). The trick is in the glueing bit.
Unlike most other Inline modules, which are interpreted, there's no runtime to which you can delegate method calling and reflection. I suspect thats why there are only 3 compiled ILSMs, one of which is a joke, and all of which are supported by people much wiser than I.
You can't just delegate type conversion for interesting values, such as multi-dimensional arrays of structs, to the user like Inline::C does because that means they need access to the perlapi, but then I would need to rewrite many of the structs and create a ton of call-by-reference bridges. Also its a real pain to manipulate pointers in standard Fortran.
That leaves my code writing the glue. I can write the glue for any particular case, but a generic automatic solution is a little tougher especially if you want to support the features of Fortran that C does not have (which is half the point). | [reply] |
| [reply] |
Yes and no.
It provides a moderately good container for data on the Perl side of things, but thats about it. PDL::PP just wasn't cut out for the job I want to accomplish.
PDL::PP is really good at making rich, perlish interfaces.
However, since I'm generating the glue, I'm adhering to the principle of least surprise. That entails making all things coming from Fortran "feel" like they would in Fortran.
For example, in F9x calling a non- pure sub with an array that has too many dimensions is illegal. But calling a pure sub with an array with to many dims should thread. In F77, the array should be flattened.
As far as I can tell, PDL::PP can only do the second of these.
There are other issues with things like type-coercion messing up overloading.
| [reply]
[d/l]
[select] |