Re: Suggestion for Future Implementation
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.)
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.
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 imple-
menting 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.
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.)
And I never even thought of the issue of plugins raised by Ralf N.
OCXs in general, I regard as a plague. :-}
Ben Fosberg
BenFosberg at att.net
Jeff Zeitlin wrote:
> On Fri, 7 Jul 2000 00:20:11 -0400, Ben Fosberg
> <BenFosberg at WORLDNET.ATT.NET> wrote:
>
> >I'm curious as to what you could do with a Euphoria DLL that you
> >can't do with a Euphoria EXE. Maybe a dumb question, but it's been
> >a long day, and I can't seem to get my head around the notion of
> >writing a program in Euphoria that "could support Euphoria as a
> >scripting/macro language."
>
> Some examples of scripting-language use in applications, right
> off the top of my head:
>
> GNU Emacs is an editor that allows the user to write complex
> procedures for manipulating text in the buffers, using a language
> that is very similar (if not outright a subset) to LISP.
>
> Microsoft Word is a word processor that allows the user to write
> complex procedures for manipulating text in the document and
> associated files (such as merge data), using a language that is a
> large subset of Visual BASIC. Microsoft Excel, Microsoft Access,
> and Microsoft Powerpoint have similar capabilities, using
> virtually identical subsets of Visual BASIC.
>
> Hamster is a news server that allows the user to write procedures
> for automating connections and manipulating the newsbase using a
> language that is similar to BASIC.
>
> ISPF and XEDIT are mainframe editors (and I believe that there
> are PC implementations as well) that allows the user to write
> procedures for manipulating the text in the buffers, using REXX.
>
> A number of years ago, there was a terminal emulator (for DOS)
> called REXXTERM, which allowed automating of connection activity
> through the writing of procedures using a large subset of REXX as
> the language.
>
> In the case of the Microsoft applications and ISPF, the language
> interpretation is not done by the program itself, but is handed
> off to shared routines (equivalent to DLLs, in the case of the
> mainframe; actual DLLs in the case of the MS apps).
>
> In other words, the scripting/macro language is a capability that
> allows the user to do, within broad limits, functionality not
> necessarily envisioned by the developer of the application, or
> which the developer felt would not be broadly needed (and
> therefore not worth taking the time to code manually) - but which
> there would be no logical reason _not_ to allow the user to add,
> given the capability. A scripting language is a "cheap" way of
> doing that, since all the developer need do is define how the
> user and program interface to the scripting language. Euphoria,
> or a large subset, would make a good scripting language,
> regardless of what language the actual application was written in
> (for example, write a text editor in C++/Builder, with Euphoria
> as the scripting language).
> --
> Jeff Zeitlin
> jzeitlin at cyburban.com
|
Not Categorized, Please Help
|
|
