Python and Rev

MisterX b.xavier at internet.lu
Sat Apr 9 06:06:47 EDT 2005


Dan Said,

> I agree, Frank. The key seems to lie in finding a way to 
> essentially create the OSA (Open Scripting Architecture) as a 
> Rev framework, no small task to be sure but one that perhaps 
> the famous MonsieurX is up to?

> > Extending Rev to support this would allow this to be used 
> > cross-platform, as most of these scripting languages are available 
> > cross-platform.

> >> At 11:13 AM -0400 4/4/05, Frank D. Engel, Jr. wrote:
> >>> Rev allows AppleScript via the "do ... as AppleScript" command. 
> >>> Perhaps this could be extended to support things like

> >>> do ... as Python
> >>> do ... as Ruby
> >>> do ... as AmericanEnglish   ;-)

> >>> or whatever?

Sorry, im late responding... Sorry for the length, it's quite a subject I
like to explore and experiment with!

What I can add is that a compatibility layer can be built into your APIs
using a stackinuse. Emulate "whatever" command names or functions from any
language and then, you have the language layer. These can be emulated script
or archived script objects. I think you get the picture... 

Detecting the language is not hard but better left to a previous or lower
level layer stack in use for correct code execution distribution/assignment.
Sorry for the lame language talk. Just think of it as abstract object pseudo
grammar programming logic engine. 

Parsing "message box" commands in natural language (because executing a
script is quite different) or using a handler doasAppleScript can be an
intermediary or tertiary library. This function interceptor grabs any script
as parameter (or a function call from the taoo[-applescript eg]-agent) and
throws it at the os in a sugar/honey AppleEvent or shell... So to speak.

The hard part is translating or doing the real time execution of "translated
code". Not impossible, not that accurate (up to a 50% success/failure), you
can imagine it's too much processing to add to an execution queue too unless
it's a once a year ordeal. ;)

The TAOO solution to this is to attack all sides of the equation. A simple
expression recognition algorithm and then assembling the " contextual
objects" between a verb (or series of), a source(s), a target(s), a mode of
operation and expressing it in a script if it didn't exist already
post-recognition. 

But that's TAOO Stage 4 which is in 3rd priority for the moment. Stage 1
being ready or near! 

The recently released Andre's iCalendar, Alejandro's graphic objects,
Chipp's plugins, Richard's Devolution, and many more can be easily adapted.
Any plugin addition doesn't 'add' features but 'multiplies' them by the
number of possible actions in a lower level managing that agent. You imagine
now what that can do with an addition language added... As far as Im
concerned, it's much better to be poliglot than not! 

http://www.monsieurx.com/hyper/xos/screenshots/ The first 3 xos images are
some of these layers of libraries. 

I know Python and perl and many other language can be easily managed in TAOO
and also without TAOO in RunRev. There is a trade off naturally. You have to
use the TAOO library (or at least a script in stackinuse/library form) and
the languages are missing the intermediary levels to detect language
(unassembled but independently ready in the Transcriptolator) to name a bit
of the tricks under development. 

While I saw a msg from Richard waiting for a plug-in standard, which I agree
to, im going on with a rather more intricate design (with the needed stuff
in on demand - rather than on request). The plugins are more like scripts
than like stacks and loaded dynamically. But i have still to see what limits
I find in the IDE so I can build a controller. All I can say is that a
plug-in language and api is better than just a standard! And to this Im
writing 

But the secret is allowing ambiguity... And that's a whole other topic in
logic and dynamic parsing for relational lookups and indexing maintenance
cycles... It can get complicated depending how you want to implement this.
My problem is keeping a nuclear, simple, congruent and flexible model that
allows easy language connectivity for objects including language words and
their meaning. Dont overdose on this food for thought!

Again, TAOO is a groupping of plugins, agents, libraries, context managers,
I invite anyone to inquire in their areas of interest and add as once
Alejandro asked a couple years ago, your own language keywords... So I see
the ambiguity is the key object to manage before we can get there... But
there's nothing stopping the gathering of tools to make the TAOO the most
complete script encyclopedia or most featured tool available on any and all
platforms... 

If you dont mind software under construction and there is interest, I will
do my best to make a rapid release of TAOO. If someone knowledgeable with
international IP legal and patent licensing protection can contact me I'd be
overjoyed to get that along even faster. 

For now, TAOO is just a wiki RAD and platform made in Rev with its own
rev-made ingredients if you want a simple comparison. I'll start working
more on wiki and object layer apis in the coming months. I find it
interesting to say the least.

cheers
Xavier
--
http:// monsieurx.com/runrev



More information about the use-livecode mailing list