From: Joseph Morrison
Subject: seeking extension language, smoothest possible interoperation with C/C++
Date:
Message-ID: <JDM.94Feb25100906@trimaran.fmrco.com>
Hello, I'm choosing an extension language for possible use in several
applications we are building at Fidelity. My requirements are (from
most to least important):
1. Smoothest possible interoperation with C/C++. That means that I can
extend the language by writing C/C++ code, and can create or access
language data structures from C/C++.
2. Clean, powerful language semantics (reasonable syntax (parentheses
welcome), evaluation rules, dynamic typing, garbage collection,
etc. are desirable).
3. Performance (I'm assuming that I'll choose an interpreted language
so performance is an issue). This item is considerably lower
priority than (1) and (2) though.
4. Lightweight.
5. Availability of an interface to Sybase (this is really low priority
though, since if the other requirements are met, it is trivial to
add this).
I'm very familiar with TCL and ELK, and have read all of the various
FAQs (Lisp, Scheme, etc). So far, TCL scores pretty high overall, but
loses quite a few points for it's clumsy evaluation rules and weak
namespace management. ELK scores pretty high as well, though when I
last used it (version 1.1), I found that I had to think carefully
about garbage collection when I wrote extensions (thus losing some
points on item 1). It may be that any system with garbage collection
will share this problem, but I don't know for sure. I have heard that
SIOD is a little simpler in this regard, for example.
Some options I currently know little about: Common Lisp
implementations (more heavyweight but it would be nice to have a
richer language), and non-Lisp alternatives such as Python.
I would very much appreciate any information or suggestions about
which language to choose. I welcome responses by mail as well as
posted responses, and will summarize and post whatever responses I
receive.
Thanks,
- Joe
---
Joe Morrison Telephone: +1 617 570 4757
Fidelity Investments, Boston Email: ···@fmrco.com
In article <·················@trimaran.fmrco.com> ···@trimaran.fmrco.com (Joseph Morrison) writes:
>Hello, I'm choosing an extension language for possible use in several
>applications we are building at Fidelity. My requirements are (from
>most to least important):
>
>1. Smoothest possible interoperation with C/C++. That means that I can
>2. Clean, powerful language semantics (reasonable syntax (parentheses
>3. Performance (I'm assuming that I'll choose an interpreted language
>4. Lightweight.
>5. Availability of an interface to Sybase (this is really low priority
>
>I'm very familiar with TCL and ELK, and have read all of the various
>FAQs (Lisp, Scheme, etc). So far, TCL scores pretty high overall, but
>loses quite a few points for it's clumsy evaluation rules and weak
>namespace management.
TCL was designed from the start to fill the need you have. I tend to
agree with your two points of contention. However, the evaluation
rules aren't that tough to get used to and extensions are available
that address the name space issue. Concerning the other items you
desire (operation with C/C++, lightweight, etc.) TCL addresses them
better than anything else around.
Ray
--
_____________________________________
Ray Johnson
Lockheed Artifical Intelligence Center
From: Brent S Noorda
Subject: Re: seeking extension language, smoothest possible interoperation with C/C++
Date:
Message-ID: <CLstAy.F62@world.std.com>
>Hello, I'm choosing an extension language for possible use in several
>applications we are building at Fidelity. My requirements are (from
>most to least important):
I hope that you will consider the Cmm (C minus minus) language for
your purposes, as I have developed the language after years of frustration
with the available options. Cmm was designed to provide the power of
C with the simplicity of a macro language--and to also be portable.
The CEnvi Cmm interpreter is currently available as shareware for
DOS, OS/2, and Windows, with a new version due in a week and and NT
version soon to follow.
My company, Nombas, is also working with application developers to
create the Cmm Application-developer toolkit so that the Cmm
interpeter engine can be integrated with application of all types,
creating a common, powerful, C-like macro and scripting language
across applications and operating systems.
Whether Cmm and CEnvi suit your needs or not, I would like to
hear your opinions on the language, because it is for purposes
such as yours that Cmm was developed. You can start learning
about Cmm and CEnvi by downloading the CEnvi shareware for DOS,
OS/2, or windows via anonymous ftp from world.std.com in the
pub directory; look for cenvi*.* files.
>1. Smoothest possible interoperation with C/C++. That means that I can
> extend the language by writing C/C++ code, and can create or access
> language data structures from C/C++.
Indeed, Cmm completes the C-language "family". Where C++ extended
C to the large-project domain, Cmm extends it to the small macro-
language/cli domain.
>2. Clean, powerful language semantics (reasonable syntax (parentheses
> welcome), evaluation rules, dynamic typing, garbage collection,
> etc. are desirable).
If you like C, then you'll love Cmm. It has the semantics and
evaluation rules of C, but no static type declarations and so
you get the dynamic typing you want, and garbage collection ensures
that all memory is freed whenever you're not using. (in fact you
would almost never explicitly allocate or free memory, as any array
or BLOb element you use is automatically allocated and freed for
you by Cmm.
>3. Performance (I'm assuming that I'll choose an interpreted language
> so performance is an issue). This item is considerably lower
> priority than (1) and (2) though.
Cmm, at least as interpreted by CEnvi, is not fast. However
you can call DLL or C-linked routines of your own when you need
to perform some complex function quickly.
>4. Lightweight.
The current CEnvi implementation, which includes the Cmm interpreter,
command-line startup/parsing/etc./ plus the entire standard-C library,
lots of additional functions, and links to any operating-system or
DLL call, is only about 150K.
>5. Availability of an interface to Sybase (this is really low priority
> though, since if the other requirements are met, it is trivial to
> add this).
The key here is that Cmm "understands" C, and so it links into
external C functions. If you have a Sybase DLL library, for
example, the Cmm could call those functions directly.
>Thanks,
>- Joe
Thanks, Joe, for giving me this excuse to describe CEnvi and Cmm.
I welcome any questions or comments regarding CEnvi and Cmm, and look
forward to hearing from you.
Brent
···@world.std.com
In article <·················@trimaran.fmrco.com> ···@trimaran.fmrco.com (Joseph Morrison) writes:
Hello, I'm choosing an extension language for possible use in several
applications we are building at Fidelity.
Interestingly enough, I've embarked upon a similar exploration for
Bridge. I'm obviously interested as to your final decision.
I'm very familiar with TCL and ELK, and have read all of the various
FAQs (Lisp, Scheme, etc). So far, TCL scores pretty high overall, but
loses quite a few points for it's clumsy evaluation rules and weak
namespace management. ELK scores pretty high as well, though when I
last used it (version 1.1), I found that I had to think carefully
about garbage collection when I wrote extensions (thus losing some
points on item 1). It may be that any system with garbage collection
will share this problem, but I don't know for sure. I have heard that
SIOD is a little simpler in this regard, for example.
I have already settled upon using a dialect of Scheme for our
extension language. Elk is now in version 2.2, and I have found
writing extensions to be relatively painless. Yes, you do have to
take some care as to protecting local objects against garbage
collection, but the macros provided for the purpose are adequate to
the task.
Another alternative I have yet to explore is SCM. SCM is distantly
related to SIOD, but is a much more complete implementation. It's
primary advantages over Elk are speed and its (alleged) ability to
garbage collect directly off the C runtime stack. Its disadvantage is
lack of documentation.
// Kaelin Colclasure --------------------------------------------------------
// EMail: ······@bridge.com Mail: Bridge Information Systems, Inc.
// Voice: (314)567-8463 717 Office Parkway
// Fax: (314)432-5391 St. Louis, MO 63141