[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: variable command interpretter

From: Redford, John
Subject: RE: variable command interpretter
Date: Tue, 19 Jun 2001 13:06:47 -0400

> From: Evan Prodromou [mailto:address@hidden
> >>>>> "PE" == Paul Emsley <address@hidden> writes:
>     PE> Do I take it then that it can't be done today - but I
>     PE> should relax and let them choose python in the knowledge that
>     PE> sometime in the future I will be able drop python and link
>     PE> with guile and  python-> guile?
> Two things, really quickly. First, if you really want to have custom
> syntax for your particular system, you should use Guile. Guile, like
> most Schemes, has a language extension mechanism, so you can actually
> make up new language primitives that will be more fit to your system.
> Second, why not start with Guile, and then let them use a
> Python-language compatibility module in the future? B-) Seriously,
> Python programmers tend to pick up lisp-like languages pretty easily.

I don't think that heartfelt Guile advocacy is quite the answer needed here.

Paul: If they build in Python or Guile as their langauge, then you will
likely find it impossible to change it.  The C programmer's interface to
both of these, as well as Perl and others, is such that one gets locked in.
This is all the more likely if the programmer makes use of the APIs for
things other than just interfacing, like memory management.

The best, real-world example of a system that permits interfacing multiple
languages is the Windows Script Host system produced by Microsoft.  This
permits the interchangable use of Visual Basic, JScript, and Perl code.
(There may also be a Python interface by now).  This is the kind of thing
that you would need to study in order to usefully be able to add additional
languages in the future.

John Redford
AKA GArrow

reply via email to

[Prev in Thread] Current Thread [Next in Thread]