1. Suggestion for Future Implementation
Rob: How about implementing the Euphoria interpreter - or a large
subset thereof - as a DLL or semantic equivalent (Linux .so?) on
the supported platforms? This would allow J. Random Appwriter to
write an application - in any language, including Euphoria itself
- that could support Euphoria as a scripting/macro language, much
as has been done in the past with BASIC, REXX, LISP, and other
languages. Increased accessibility of the language - especially
given that it is _not_ a difficult language to gain proficiency
in - would allow for increased penetration into the marketplace,
and potentially gain respect for Euphoria in that community that
still considers it a "toy" language.
--
Jeff Zeitlin
jzeitlin at cyburban.com
2. Re: Suggestion for Future Implementation
Jeff Zeitlin writes:
> Rob: How about implementing the Euphoria interpreter - or a large
> subset thereof - as a DLL or semantic equivalent (Linux .so?) on
> the supported platforms?
Thanks for the suggestion. I would need some
specific examples of what someone would do
with a Euphoria .dll.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Suggestion for Future Implementation
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."
Jeff Zeitlin wrote:
> Rob: How about implementing the Euphoria interpreter - or a large
> subset thereof - as a DLL or semantic equivalent (Linux .so?) on
> the supported platforms? This would allow J. Random Appwriter to
> write an application - in any language, including Euphoria itself
> - that could support Euphoria as a scripting/macro language, much
> as has been done in the past with BASIC, REXX, LISP, and other
> languages. Increased accessibility of the language - especially
> given that it is _not_ a difficult language to gain proficiency
> in - would allow for increased penetration into the marketplace,
> and potentially gain respect for Euphoria in that community that
> still considers it a "toy" language.
> --
> Jeff Zeitlin
> jzeitlin at cyburban.com
4. Re: Suggestion for Future Implementation
To write a WinAMP plugin, for example visualisation, or sound filters.
To write a Vbx control 
lol .. just kidding.
To write a Photoshop plugin.
In other words, for all applications where we can use DLL's as
plugin-plugouts.
What would be the ideal solution for implementation ?
1) for those which develop in Euphoria, all include files in a specific
subdirectory of Euphoria will be callable as DLL (they are registered,
etc.ready for use). the files themselves use the already existing C
interface, only all callback routines are now registered.
2) Supply an option to bind to a DLL for registered users, so they can
publish DLL's usable for those who don't have the Euphoria Development
stuff.
Then again, come to think of it. It sounds like a lot of work, debugging,
testing, three platforms. The support would be neat, but it shouldn't be the
highest priority, if you ask me.
Ralf N.
nieuwen at xs4all.nl
5. Re: Suggestion for Future Implementation
On Fri, 7 Jul 2000 00:20:11 -0400, Robert Craig
<rds at ATTCANADA.NET> wrote:
>Jeff Zeitlin writes:
>> Rob: How about implementing the Euphoria interpreter - or a large
>> subset thereof - as a DLL or semantic equivalent (Linux .so?) on
>> the supported platforms?
>Thanks for the suggestion. I would need some
>specific examples of what someone would do
>with a Euphoria .dll.
I'll have to get back to you with specifics on this; I was just
thinking in general terms (and wishing I had the time and energy
to catch up on all the projects that I've got notes on...).
--
Jeff Zeitlin
jzeitlin at cyburban.com
6. Re: Suggestion for Future Implementation
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
7. Re: Suggestion for Future Implementation
Thanks Jeff for the examples.
I'll keep the .dll idea in mind.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. 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
9. 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
