class FLModule to translate/import foreign-source-lang modules? [Was: Re: Why don't people like lisp?]

[Bengt Richter]

On Mon, 20 Oct 2003 21:25:55 +0200, Pascal Costanza <costanza at web.de> wrote:

>Alex Martelli wrote:
[...]
>> ...you can't "just alter Python's own syntax with your own changes":
>> you have plenty of choices (implement your chosen semantics within
>> Python's syntax, use any of N available parsers to parse your favourite
>> syntax -- user EITHER "program generators" OR interpreters at any
>> level on the parsed forms -- etc, etc).  You just don't have the one
>> choice of *altering Python's own syntax wholly within Python itself*.
>
>Exactly. Lisp-style Macros make these things a breeze. The other 
>alternatives you suggest are considerably more complicated. As I have 
>said before, Lisp makes the simple things a little bit harder (-> syntax 
>for beginners), so that the hard things become considerably simpler (-> 
>adding sophisticated abstractions in order to considerably reduce the 
>amount of code for complex tasks).
>
>> Describing a situation of having 99 available strategies rather than
>> 100 as "doesn't give you a choice" can be charitably described as
>> "ridiculous", it seems to me.
>
>I know about these choices, I have tried them all. I have written 
>compilers, interpreters, with and without parser generators, and have 
>co-designed and used transformation frameworks. These things are 
>considerably harder to build, and you need to spend a considerable 
>amount of time on the technology itself which distracts you from solving 
>the problem at hand. With Lisp-style macros, these things are much 
>simpler to handle once you have gotten it.
>
>> But _in practice, people don't_, except for play and experiments
>> of various kinds.  You can find a bazillion extremely varied
>> extensions to Python of all imaginable kinds, *BUT* they're ALL
>> *add-ons*, NEVER alteration of syntax or fundamental semantics
>
>You still have a wrong idea of how macros work. Macros are of course 
>also only add-ons. You don't alter unrelated syntax or unrelated 
>portions of source code, and you don't change fundamental semantics.
>
>Instead of spreading misconceptions you should really start to get to 
>know the things better that you criticize.
>
Maybe we can put this thing to bed by a Python foreign-language-module-encapsulating class,
and a functionally equivalent lisp a macro for lispers, so we could write something like (sketch)

    module_from_lisp = FLModule('lisp','lisp_file_path_or_remote_spec',
                                'interface spec string', 'make info string')

where the last args would have sensible defaults, but all would be expected to be passed
to a translation process selected by the language name (the first arg) unless a cached module
could be accessed without calling for any translation.

For C or C++ this could generate a DLL extension module and import that, assuming the
relevant tools are available. Otherwise an informative exception could be raised.

For other languages, a DLL that serves as an access proxy for whatever. Letting the source
be specified by a remote spec like an URL with some authentication requirement might open
some interesting uses (language name 'python' would be allowed ;-) (maybe even 'python1.5.2' ;-)

I know there are already pieces for integrating/accessing C, but the idea here is to
unify the concept into one standard general form expressed by a standard class which could
always have a presence in builtins.

Just an alpha idea at this point ;-)

Hm, think I'll switch the title, in case people aren't reading the old subject thread ;-)

Regards,
Bengt Richter