Hi all, I want to write an external that will evaluate a bit of scheme code, something along the venue of expr~ but adding the possibility of evaluate simple control structures too (but inline, not in external scripts as is the case of pyext). What kind of parameter should I declare for my external constructor? If I declared A_GIMME, can I assume that the code will have been splitted just at whitespaces and so it's safe to reassemble it joining the fragments? Thank you in advance. Cheers, Carlos
Carlos Pita wrote:
Hi all, I want to write an external that will evaluate a bit of scheme code, something along the venue of expr~ but adding the possibility of evaluate simple control structures too (but inline, not in external scripts as is the case of pyext). What kind of parameter should I declare for my external constructor? If I declared A_GIMME, can I assume that the code will have been splitted just at whitespaces and so it's safe to reassemble it joining the fragments? Thank you in advance. Cheers, Carlos
If expr/expr~/fexpr~ can do it, it must be possible.
However, these characters are treated specially by Pd:
{
}
$
;
,
which may cause problems...
I want to do the same for Haskell, and all of those characters are part of the common syntax. Guess I need to write a preprocessor...
Claude
On Fri, Jun 29, 2007 at 02:02:16AM -0300, Carlos Pita wrote:
I want to write an external that will evaluate a bit of scheme code, something along the venue of expr~ but adding the possibility of evaluate simple control structures too (but inline, not in external scripts as is the case of pyext). What kind of parameter should I declare for my external constructor? If I declared A_GIMME, can I assume that the code will have been splitted just at whitespaces and so it's safe to reassemble it joining the fragments?
Sorry, I can't answer your specific request, but I just want to say: Wow, this would be awesome! I think if expr and friends can handle the syntax they do, with brackets, operators etc being parsed just fine, then Scheme's syntax should be no problem. Maybe check out how this is done in the expr source?
Things I like about this over other languages embedded in Pd:
- Scheme's syntax lends itself naturally to one-liner's which fit in
an object box, just like expr.
- As a functional language it fits much better with Pd than some other
OO languages.
- Scheme interpreters can be very minimal[1][2][3], hence uncomplicated,
hence more likely not to cause problems and bugs. Should be much easier to embed right inside Pd than some other languages.
- 100% cross platform way to make more complicated abstractions than
are currently possible without resorting to externals, which I dislike because of the portability problems caused by externals.
- You might win an award for the first practical use of the scheme
language. ;)
For me, this would signify a sort of Pd Nirvana. I will definately help you with testing this and brush up on my scheme at the same time.
Best,
Chris.
[1] http://www.cs.indiana.edu/scheme-repository/imp/siod.html [2] http://alex.ability.ru/scheme.html [3] http://www.crockford.com/javascript/scheme.html
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
- You might win an award for the first practical use of the scheme
language. ;)
Maybe not: Larry Troxler wrote a scheme external some years ago: http://www.westnet.com/~lt/pd/
And Kjetil Matheussen did k_guile and thanks to him you also can use Snd in Pd: http://ccrma.stanford.edu/software/snd/snd/grfsnd.html#sndwithpd
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hello all,
I think there are at least three ways to go with this:
- reassemble the code from atoms.
- provide a object with a gui specialized for code edition.
- provide some symbol escaping syntax so that, for example, everything
between << and >> will be taken as a single symbol by pd.
I think 2, although a bit laborious, fit best to the goal of code edition. We could treat code as a single string, instead of dealing with symbols, and we could even (this is wishful thinking) provide some syntax highlighting and formatting. I'm pretty new to pd but I guess I could take g_bang.c and friends as examples to start working with.
Cheers, Carlos
On 6/30/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
- You might win an award for the first practical use of the scheme
language. ;)
Maybe not: Larry Troxler wrote a scheme external some years ago: http://www.westnet.com/~lt/pd/
And Kjetil Matheussen did k_guile and thanks to him you also can use Snd in Pd: http://ccrma.stanford.edu/software/snd/snd/grfsnd.html#sndwithpd
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I've thought a bit more about the subject. I find that a realisation of the idea on top of a custom gui object could have some rough edges:
(i) the code is not given at creation time, so if the number of inlets/outlets is to be inferred from it, pd objects should support adding/removing of inlets/outlets after object initialization. Is this possible?
(ii) maybe the object will show itself in outer abstractions when contained in inner abstractions with graph-in-parent activated. Is it possible to avoid this?
I ask the above to the pd savvy in order to determine if it's viable to go this way.
TIA Cheers, Carlos
On 6/30/07, Carlos Pita carlosjosepita@gmail.com wrote:
Hello all,
I think there are at least three ways to go with this:
- reassemble the code from atoms.
- provide a object with a gui specialized for code edition.
- provide some symbol escaping syntax so that, for example, everything
between << and >> will be taken as a single symbol by pd.
I think 2, although a bit laborious, fit best to the goal of code edition. We could treat code as a single string, instead of dealing with symbols, and we could even (this is wishful thinking) provide some syntax highlighting and formatting. I'm pretty new to pd but I guess I could take g_bang.c and friends as examples to start working with.
Cheers, Carlos
On 6/30/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
- You might win an award for the first practical use of the scheme
language. ;)
Maybe not: Larry Troxler wrote a scheme external some years ago: http://www.westnet.com/~lt/pd/ http://www.westnet.com/%7Elt/pd/
And Kjetil Matheussen did k_guile and thanks to him you also can use Snd in Pd: http://ccrma.stanford.edu/software/snd/snd/grfsnd.html#sndwithpd
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Carlos Pita wrote:
I've thought a bit more about the subject. I find that a realisation of the idea on top of a custom gui object could have some rough edges:
(i) the code is not given at creation time, so if the number of inlets/outlets is to be inferred from it, pd objects should support adding/removing of inlets/outlets after object initialization. Is this possible?
afaik it is possible, though the gui might not get updated accordingly.
BUT: what do you gain from that? it would break your patch everytime you send your object another code-snippet (with other iolets)
(ii) maybe the object will show itself in outer abstractions when contained in inner abstractions with graph-in-parent activated. Is it possible to avoid this?
yes: do not use "graphical" objects; all "normal" (non-graphical) objects will be invisible on the parent. if your object has to be graphical, just don't put it into the red rectangle of the child-patch, and you won't see it in the parent.
there is not much use of a graphical object which you cannot see. (there are uses for such objects, but i guess you don't want to reinvent the whell for that...)
mfg.asdr IOhannes
(i) the code is not given at creation time, so if the number of
inlets/outlets is to be inferred from it, pd objects should support adding/removing of inlets/outlets after object initialization. Is this possible?
what do you gain from that?
Nothing. I don't want to update the code in the objects once created, just that I couldn't enter it into an embedded textbox during initialization the same as I do with normal objects. Instead a dialog should be provided to enter the code snippet an then pass it to the object constructor. Or alternatively code should be allowed to change so that I can enter it afterwards. I can't see another option.
Thank you for your answers, have been very valuable.
Cheers, Carlos
On Sat, Jun 30, 2007 at 05:07:11PM -0300, Carlos Pita wrote:
- reassemble the code from atoms.
This one excites me the most because it's so lightweight and Pd-like. It's would probably be easy to build on Larry's work that Frank posted, integrating SIOD and make it reconsistute the atoms to pass to SIOD for compilation.
- provide a object with a gui specialized for code edition.
I think 2, although a bit laborious, fit best to the goal of code edition. We could treat code as a single string, instead of dealing with symbols, and we could even (this is wishful thinking) provide some syntax highlighting and formatting. I'm pretty new to pd but I guess I could take g_bang.c and friends as examples to start working with.
If you are going to go this way, why not make a generic code editing object that can be used for the other embedded languages too? That way you could use the one external for Python, Ruby, Scheme, C or whatever takes your fancy.
Best,
Chris.
Carlos Pita wrote:
Hello all,
I think there are at least three ways to go with this:
- reassemble the code from atoms.
- provide a object with a gui specialized for code edition.
- provide some symbol escaping syntax so that, for example, everything
between << and >> will be taken as a single symbol by pd.
I think 2, although a bit laborious, fit best to the goal of code edition. We could treat code as a single string, instead of dealing with symbols, and
please mind 2 things: PLEASE do not add the gui-capabilities to your interpreter object (i don't know whether you planned to do so, but just in case...)
have you had a look at beb bogarts [entry] object? it basically does what you want.
gfmads-r IOhannes
On Sat, Jun 30, 2007 at 10:55:20AM +0200, Frank Barknecht wrote:
Chris McCormick hat gesagt: // Chris McCormick wrote:
- You might win an award for the first practical use of the scheme
language. ;)
Maybe not: Larry Troxler wrote a scheme external some years ago: http://www.westnet.com/~lt/pd/
And Kjetil Matheussen did k_guile and thanks to him you also can use Snd in Pd: http://ccrma.stanford.edu/software/snd/snd/grfsnd.html#sndwithpd
Right you are, Frank! That was a poorly researched joke on my behalf. One thing missing from these previous great works is an in-line scheme interpreter a la expr style. Maybe Larry's existing work with SIOD could be used for that. As usual I am too lazy to lift a single coding finger to contribute anything except feature requests.
Rgds,
Chris.
-
Carlos Pita -
Chris McCormick -
Claude Heiland-Allen -
Frank Barknecht -
IOhannes m zmoelnig