Re: Suggestion for Future Implementation
On Sun, 9 Jul 2000 00:02:08 -0400, Ben Fosberg
<BenFosberg at WORLDNET.ATT.NET> wrote:
>The things you've mentioned are about all I had in mind when I asked the
>question, which is why I asked, since that is what I've been using Eu for -
>as a substitute for scripting/macro languages. The majority of text editors
>I've used have had some form of "shell" or "tool" or "exec" facility that
>allowed one to run an external program, and optionally pass the program the
>name of a file, or the editor's "current/active" file and possibly some
>parameters. (The facility is usually in the editor to run compilers,
>linkers, etc., but some of them will run just about anything.)
This method is OK (barely) for an editor. What about (for
example) a scripted FTP or telnet client, or a terminal emulator,
where you have to read/write the comm port in real time? What
about a word processor that allows "interactive merge" (sometimes
called "merge from keyboard" or something like that)?
>My experience with most scripting languages are that they're no easier -
>and often harder - to use than any other programming language, often
>because they're buggy and always because they're poorly documented. (Or,
>maybe I just prefer to write my own routines than to sort out why someone
>else's isn't working as expected.) So I'm using Eu as the scripting/macro
>language for several editors. Don't need a .dll for that - just write the
>Eu code and run it from the editor. Now if I were writing the program in
>which I wanted to include a scripting facility, I think I'd do what the
>writers of those editors did, and depending on Rob's attitude either supply
>the (PD) interpreter or tell folks to get it from him.
Again, that's fine for an editor, which, admittedly, is going to
be the largest segment of the potential market. But again, what
about situation where you need the script to interact in
real-time, as in a FTP or telnet client, or a terminal emulator?
>However, my requirements are usually fairly simple, and, there are some
>shortcomings to this approach, but I'm not sure that simply binding to a dll
>structure will overcome them. For instance, macro languages are just that -
>they call, and build on, routines already existing in the "engine" of the
>software implementing the macro language, which the Eu interpreter still could
>not do if it were in a DLL. Additionally, macro and scripting languages can
>usually share and pass constants, variables, structures, etc. back and forth
>with the "parent" application in a faster and more direct fashion than is
>possible with an external program.
Which would be possible with a DLL. The idea is that the DLL is
essentially the parser and interpreter, with your application
being the memory and I/O manager. Again, think about how it
would have to work for a comm-bound app, such as a terminal
emulator - remember ProComm's ASPECT language? What did ProComm
have to do to implement ASPECT? What part of that list would
ProComm still have had to do if they wanted ASPECT to be
essentially Euphoria? The DLL would handle the part of the list
that was _not_ specific to ProComm - the parsing and
interpretation of the language.
>Eu as a .dll would not completely solve that problem, but it might be
>helpful. I suspect, depending on your application, that you could solve some
>of these problems by supplying a header file, and binding it to the user's
>Eu code before calling the interpreter (still without the EU.dll.)
No, because the key to "scripting" is that the _user_ of the
application (the _end_ user, not you as a user of Euphoria) is
going to be writing this code to accomplish a specific task, not
the _programmer_. The scripts will be "in Euphoria", but he's
not writing Euphoria, he's writing a script for MyApp. The DLL
simply provides the "black box" that converts human-readable
Euphoria into machine-executable code to actually do the work.
--
Jeff Zeitlin
jzeitlin at cyburban.com
|
Not Categorized, Please Help
|
|
