[PD] Scripting

[mark]

> you could start off with .py but later or somebody else
> extend to perl,
> php4, bash, java-ecmascript, funge98, &c &c ?
>

This is not so easy in C. In Java you can use the BSF which allows java to
expose internal objects to a large number of different langauges. The
problem
in C is that each of these scripting languages has a different way of
exposing
C objects. Looking at the python stuff there is no way this would work for
other languages.

The problem is marshalling data from one language  to the other. In order to
make
this work for all langauges you would end up writing a generic scripting
engine
which knew how to marhall PD data into each separate languge probably using
some
sort of intermediate representation- not something I am wanting to do right
now
(or ever for that matter). The only way I can think to make it available to
more
languagues is to use COM (windows only) or CORBA (serious serious serious)

Making a Java scripting engine would be trivial (well it would to me - I
work
with Java most of the time at work) and possibly more cross platform and you
could
then but leap frog into other languages via BSF but you are adding layer
upon layer
of translation and perfomance will be going rapidly downhill at this point.

I also feel that python has more relvant scripting type stuff in it and
would be quite
interesting in conjunction with PD.

mark

> -----Original Message-----
> From: _-¯-_ [mailto:jdl at xdv.org]
> Sent: 25 February 2002 15:08
> To: 'Pd-List'
> Subject: Re: [PD] Scripting
>
>
>  |> I thought about perl but I have to relearn perl every
> time I need to
>  |> use it - its the only languae I use regularly that I need loads of
>  |> reference books for
>  |
>  |Don't go Perl, go Python! This is of course flamewar stuff (and has
>  |already provoked one on csound-list), but I can see a
> simple reason, why
>  |Perl is not appropriate as a PD scripting language: It uses the $ to
>  |declare $variables! Combine that with PD's own use of the
> dollar symbol
>  |and I see a big mess coming.
>
> the optimum would be something like a generic "script" object with the
> first creation argument specifying the interpreter or
> autodetection from
> file suffix whatever.
>

> -- X D v · o r 6
>
>