Hi,
I have an optics program written in C++ that can be "programmed" using
XML-files. Unfortunately
this approach is not very flexible. I would like to use a real
programming language for that purpose.
And I would like to be able to use it interactively, like Clisp or OCaml
interacting with XEmacs. There
seem to be some canditates for this purpose. I considered to use OCaml,
that I'm quite familiar with
(and it's easy to link an OCaml toplevel with C code) but I also
considered to use Scheme (Bigloo, Guile, Elk)
or CL (Clisp ?). I considered Scheme and CL because of their dynamic
nature what makes experimentation
with the application quite comfortable and Scheme also because it has a
simple syntax (the application will also
be used by others that are not familiar with Lisp or ML). I would like
to run it under WinNT and possibly under UNIX (not highest priority).
The extension with C/C++ should be easy.
I would be very appreciative for any suggestions?
Rolf
From: Sam Steingold
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <uu220rzw9.fsf@xchange.com>
> * In message <·················@ilt.fhg.de>
> * On the subject of "ML, CL or Scheme as an extension language"
> * Sent on Fri, 01 Jun 2001 16:44:12 +0200
> * Honorable Rolf Wester <······@ilt.fhg.de> writes:
>
> I have an optics program written in C++ that can be "programmed" using
> XML-files. Unfortunately this approach is not very flexible. I would
> like to use a real programming language for that purpose.
you said it yourself - you want a "real programming language"!
(-: that leaves you with CL. :-) <http://www.podval.org/~sds/tool.html>
I recommend CLISP (http://clisp.cons.org)
--
Sam Steingold (http://www.podval.org/~sds)
Bill Gates is not god and Microsoft is not heaven.
From: Dorai Sitaram
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <9f8obi$91s$1@news.gte.com>
In article <·············@xchange.com>, Sam Steingold <···@gnu.org> wrote:
>> * In message <·················@ilt.fhg.de>
>> * On the subject of "ML, CL or Scheme as an extension language"
>> * Sent on Fri, 01 Jun 2001 16:44:12 +0200
>> * Honorable Rolf Wester <······@ilt.fhg.de> writes:
>>
>> I have an optics program written in C++ that can be "programmed" using
>> XML-files. Unfortunately this approach is not very flexible. I would
>> like to use a real programming language for that purpose.
>
>you said it yourself - you want a "real programming language"!
>(-: that leaves you with CL. :-) <http://www.podval.org/~sds/tool.html>
>
>I recommend CLISP (http://clisp.cons.org)
Is there some history of CL being used for an extension
language? With what kind of success/failure? (If there
is a URL, that would be nice to know.)
(Let's exclude the editors that ship with MCL and
CMUCL.)
--d
On 1 Jun 2001 18:53:38 GMT, Dorai Sitaram <····@goldshoe.gte.com> wrote:
> In article <·············@xchange.com>, Sam Steingold <···@gnu.org> wrote:
> >you said it yourself - you want a "real programming language"!
> >(-: that leaves you with CL. :-) <http://www.podval.org/~sds/tool.html>
> >
> >I recommend CLISP (http://clisp.cons.org)
>
> Is there some history of CL being used for an extension
> language? With what kind of success/failure? (If there
> is a URL, that would be nice to know.)
>
> (Let's exclude the editors that ship with MCL and
> CMUCL.)
>
How about AutoLisp used as extension language used in AutoCAD? I think it
is quite successful. Also EmacsLisp used by Emacs editor, which is also
quite successful (in terms of number of users, not income). I'm sure there
are more, but I cannot remember any others (I know for sure there's one
other popular commercial application that uses Lisp dialect as an extension
language).
I think Lisp is very suitable extension language, but so is Scheme. If you
decide to use Lisp, you would have to remove many unneeded features. On the
other hand, if you decide to use Scheme, you would need to add features.
Regards,
rk
>>>>> On 1 Jun 2001 18:53:38 GMT, Dorai Sitaram ("Dorai") writes:
Dorai> Is there some history of CL being used for an extension
Dorai> language? With what kind of success/failure? (If there
Dorai> is a URL, that would be nice to know.)
Applications on the Lisp Machine could well be considered extensions
of the operating platform. I just thought I'd throw that ponderance in,
but I think you're actually asking about something else.
Most applications on the Lisp Machine could be extended in Lisp,
and the ones that have been ported to Common Lisp can be extended that
way. Examples include the VLSI design tools, Concordia (the hypertext
documentation system), S-Products (CGI); Macsyma can be extended in
either Macsyma or Lisp.
What about applications written in some other language, such as C?
From: David Bakhash
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3y9rb5a29.fsf@alum.mit.edu>
>>>>> "dorai" == Dorai Sitaram <····@goldshoe.gte.com> writes:
>>> I have an optics program written in C++ that can be "programmed" using
>>> XML-files. Unfortunately this approach is not very flexible. I would
>>> like to use a real programming language for that purpose.
dorai> Is there some history of CL being used for an extension
dorai> language? With what kind of success/failure? (If there
dorai> is a URL, that would be nice to know.)
Well, first off, Common Lisp is the ultimate extension language for
any application that's already written in Common Lisp. I guess this
is where you were going when you wrote:
dorai> (Let's exclude the editors that ship with MCL and
dorai> CMUCL.)
In this sense, knowing is half the battle. If you know or believe
that your application will benefit from being extensibly programmed by
users, then choose Common Lisp. This is barely a decision -- even if
you don't already know Common Lisp, since by the time any serious
project is over, if that project is even medium in size and is
extensible, then the savings in using Common Lisp outweigh everything.
Now, if you've already coded something up in C++, e.g. like what the
author has done, I'd say that CL is still the best decision on where
to go, except that you'll want to completely restructure your
application as a CL application which calls out to the C++ stuff.
Depending on how much work this would be for the particular
application, this can be a big win. Eventually, such applications can
slowly but surely replace the foreign code too.
Some applications are so interwoven between Lisp and C that it's hard
to say what they're written in. You start to see foreign calls and
callbacks, and so how do you define the language in which the
``program'' is written? I'd say that anything that involves:
o defining/implementing a language which is itself ``complete''
o parsing the code for that language
o having that code interact with a running program
should use Common Lisp.
A few things particularly useful in Common Lisp for extension are the
extensible reader, the evaluator, macros, and the package system.
This is not to mention the compiler's ability to optimize procedural
blocks. There are hundreds of other things that make _extending_ an
application one of the things Common Lisp does better than any other
language.
dave
On 1 Jun 2001 18:53:38 GMT, ····@goldshoe.gte.com (Dorai Sitaram) wrote:
> Is there some history of CL being used for an extension
> language? With what kind of success/failure? (If there
Wasn't ECoLisp designed as an embeddable system? ECLSpain is its successor.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Sam Steingold wrote:
>
> you said it yourself - you want a "real programming language"!
> (-: that leaves you with CL. :-) <http://www.podval.org/~sds/tool.html>
>
> I recommend CLISP (http://clisp.cons.org)
>
What about OCaml? No real programming language? :-). How easy is it to link
Clisp with C/C++ code
under Windows. As far as I understood the documentation, I have to compile
the Clisp sources and link them
with my own C/C++ object files. Is it as straight forward as it is under
UNIX? Is there no way to link to
a dll?
Besides this I have another question. I tried to install mk:defsystem, port
and cllib (Clips. I downloaded the lisp sources, started Clisp and typed:
(compile-file "defsystem.lisp"). Defsystem.lisp has been compiled with no
error messages. The output is:
Compilation of file F:\Languages\Lisp\clocc\port\defsystem.lisp is finished.
0 errors, 0 warnings
The following functions were used but not defined:
....long list of function names...
Then I changed to the port directory and typed (mk:compile-system "port").
The message is:
EVAL: the function MAKE:COMPILE-SYSTEM is undefined
I would be very appreciative if somebody could help me with this problem.
Rolf
Rolf Wester <···········@t-online.de> writes:
> Sam Steingold wrote:
>
> >
> > you said it yourself - you want a "real programming language"!
> > (-: that leaves you with CL. :-) <http://www.podval.org/~sds/tool.html>
> >
> > I recommend CLISP (http://clisp.cons.org)
> >
>
> What about OCaml?
This is why the *ML languages irk me to no end.
# let x = 3 + 8.3;;
This expression (8.3) has type float but is here used with type int
#
On top of that you loose S-expressions.
> Besides this I have another question. I tried to install mk:defsystem, port
> and cllib (Clips. I downloaded the lisp sources, started Clisp and typed:
> (compile-file "defsystem.lisp"). Defsystem.lisp has been compiled with no
> error messages. The output is:
>
> Compilation of file F:\Languages\Lisp\clocc\port\defsystem.lisp is finished.
>
> 0 errors, 0 warnings
> The following functions were used but not defined:
> ....long list of function names...
What is the list of functions?
Note that COMPILE-FILE does not necessarily LOAD the file in the
running image. To be sure that the file (any file is loaded) you have
to issue
(compile-file "defsystem.lisp" :load t)
> Then I changed to the port directory and typed (mk:compile-system "port").
> The message is:
>
> EVAL: the function MAKE:COMPILE-SYSTEM is undefined
>
> I would be very appreciative if somebody could help me with this problem.
Try the above. BTW. The :load is a "keyword" argument. Another
nicety that you get with Common Lisp. :) This ain't Scheme.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Dorai Sitaram
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <9fgal9$dri$1@news.gte.com>
OCaml seems to be used successfully as an extlang
for an Emacs clone called Efuns. Since Emacs is often
the top argument for the merits of Lisp (the family, if
not the particular instance Common Lisp) as an extlang,
this looks like a great testimonial for OCaml.
I am not a sufficiently good or motivated Emacs user to
rigorously compare Efuns against Emacs. Interested
parties may want to look into it.
--d
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3ofs441ya.fsf@yahoo.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Rolf Wester <···········@t-online.de> writes:
> > Sam Steingold wrote:
> > > you said it yourself - you want a "real programming language"!
> > > (-: that leaves you with CL. :-) <http://www.podval.org/~sds/tool.html>
> > > I recommend CLISP (http://clisp.cons.org)
> > What about OCaml?
>
> This is why the *ML languages irk me to no end.
>
> # let x = 3 + 8.3;;
> This expression (8.3) has type float but is here used with type int
> #
"+" is defined to add integers and 8.3 is a float. If you want to add
floats use "+.". Are you irked because O'Caml doesn't transparently
convert between floats and ints? I can understand that, but then I
can also understand someone being irked that (+ 1 "2") doesn't produce
"3". In both cases I prefer to make the conversion explicit but
obviously tastes vary.
From: Sam Steingold
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <uy9r8873l.fsf@xchange.com>
> * In message <··············@yahoo.com>
> * On the subject of "Re: ML, CL or Scheme as an extension language"
> * Sent on Mon, 04 Jun 2001 16:58:09 GMT
> * Honorable ·············@yahoo.com (Stephen J. Bevan) writes:
>
> "+" is defined to add integers and 8.3 is a float.
> If you want to add floats use "+.".
does "3 +. 8.3" work?
what about "1 +. 3"?
does it return 4.0 or 4?
> Are you irked because O'Caml doesn't transparently convert between
> floats and ints? I can understand that, but then I can also
> understand someone being irked that (+ 1 "2") doesn't produce "3". In
> both cases I prefer to make the conversion explicit but obviously
> tastes vary.
every integer is a number, but strings and numbers are disjoint, so
your example (+ 1 "2") is totally bogus.
--
Sam Steingold (http://www.podval.org/~sds)
In the race between idiot-proof software and idiots, the idiots are winning.
Sam Steingold <···@gnu.org> writes:
> > * In message <··············@yahoo.com>
> > * On the subject of "Re: ML, CL or Scheme as an extension language"
> > * Sent on Mon, 04 Jun 2001 16:58:09 GMT
> > * Honorable ·············@yahoo.com (Stephen J. Bevan) writes:
> >
> > "+" is defined to add integers and 8.3 is a float.
> > If you want to add floats use "+.".
>
> does "3 +. 8.3" work?
Nope.
> what about "1 +. 3"?
Nope.
> does it return 4.0 or 4?
Neither.
I like this part of ocaml, has to be said. If you're going to use a
"say exactly what you mean" language you might as well go the whole
hog. I don't think it makes any real difference to programming in the
language.
Cheers,
M.
--
If your telephone company installs a system in the woods with no
one around to see them, do they still get it wrong?
-- Robert Moir, alt.sysadmin.recovery
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3lmn83tpy.fsf@yahoo.com>
Sam Steingold <···@gnu.org> writes:
> does "3 +. 8.3" work?
> what about "1 +. 3"?
> does it return 4.0 or 4?
No, no and doesn't type check respectively.
> > Are you irked because O'Caml doesn't transparently convert between
> > floats and ints? I can understand that, but then I can also
> > understand someone being irked that (+ 1 "2") doesn't produce "3". In
> > both cases I prefer to make the conversion explicit but obviously
> > tastes vary.
>
> every integer is a number, but strings and numbers are disjoint,
> your example (+ 1 "2") is totally bogus.
They are in CL, but some other languages take different approaches e.g.
$ awk 'END { print 1 + "2"; }' /dev/null
3
$
An awk user could easily get irked by CL's "restriction". Though to
be fair CL does give you the chance to do something about.
From: Tim Bradshaw
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <nkjzobn700j.fsf@tfeb.org>
·············@yahoo.com (Stephen J. Bevan) writes:
> They are in CL, but some other languages take different approaches e.g.
>
> $ awk 'END { print 1 + "2"; }' /dev/null
> 3
> $
>
I always love languages that do this. What on earth do they do in the
case of non-decimal read or print base? Oh, I know, they just don't
think about that, easy!
--tim
·············@yahoo.com (Stephen J. Bevan) writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > Rolf Wester <···········@t-online.de> writes:
> > > Sam Steingold wrote:
> > > > you said it yourself - you want a "real programming language"!
> > > > (-: that leaves you with CL. :-) <http://www.podval.org/~sds/tool.html>
> > > > I recommend CLISP (http://clisp.cons.org)
> > > What about OCaml?
> >
> > This is why the *ML languages irk me to no end.
> >
> > # let x = 3 + 8.3;;
> > This expression (8.3) has type float but is here used with type int
> > #
>
> "+" is defined to add integers and 8.3 is a float. If you want to add
> floats use "+.". Are you irked because O'Caml doesn't transparently
> convert between floats and ints?
Yes.
> I can understand that, but then I
> can also understand someone being irked that (+ 1 "2") doesn't produce
> "3".
Good point. But down this road lies the (+ 1 "three") problem...
Which can be solved easily enough in CL. :)
> In both cases I prefer to make the conversion explicit but
> obviously tastes vary.
(in-package "SUPERMATH")
(shadow '(cl:+))
(defmethod + ((x number) (y string))
(cl:+ x (funky-parse-number y)))
(defmethod + ((x string) (y number))
(cl:+ (funky-parse-number y) y))
FUNKY-PARSE-INTEGER may be made to parse things like "quattro" so that
(in-package "SUPERMATH")
(+ #C(2 4.5) "quattro")
yields
#C(6 4.5)
and
(+ "three" 1/12)
yields
1/4
In OCAML you get...
# let y = 3 * 1/12;;
val y : int = 0
The bottom line is that the environment should help you not having to
think about these sort of things. CL is still way ahead of other
environments in this respect. Even considering all the good things that
type inferencing gives you.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3g0dg3s1j.fsf@yahoo.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> In OCAML you get...
>
> # let y = 3 * 1/12;;
> val y : int = 0
which is the correct answer for integers. If you want floating point
then :-
# let y = 3.0 *. 1.0/.12.0;;
val y : float = 0.25
#
> The bottom line is that the environment should help you not having to
> think about these sort of things.
I understand it is the bottom line for you, but it is clearly not
*the* bottom line since some people don't want the help.
> CL is still way ahead of other environments in this respect.
Some yes, some no. Here's some J :-
b =: 1 2 ? 7
b
4 0
3 1
1 + b
5 1
4 2
Of course, with some work CL can do this too.
·············@yahoo.com (Stephen J. Bevan) writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > In OCAML you get...
> >
> > # let y = 3 * 1/12;;
> > val y : int = 0
>
> which is the correct answer for integers. If you want floating point
> then :-
>
> # let y = 3.0 *. 1.0/.12.0;;
> val y : float = 0.25
> #
No. I want the correct answer for numbers. I.e. I should get a
rational in the first case. :)
> > The bottom line is that the environment should help you not having to
> > think about these sort of things.
>
> I understand it is the bottom line for you, but it is clearly not
> *the* bottom line since some people don't want the help.
>
> > CL is still way ahead of other environments in this respect.
>
> Some yes, some no. Here's some J :-
>
> b =: 1 2 ? 7
> b
> 4 0
> 3 1
> 1 + b
> 5 1
> 4 2
>
> Of course, with some work CL can do this too.
http://sourceforge.net/projects/matlisp
and you can have function of more than 2 arguments in CL :)
and J ain't OCAML.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3bso3lwij.fsf@yahoo.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ·············@yahoo.com (Stephen J. Bevan) writes:
> > ... If you want floating point then :-
> >
> > # let y = 3.0 *. 1.0/.12.0;;
> > val y : float = 0.25
> > #
>
> No. I want the correct answer for numbers.
Ok, then all you need to do is tell O'Caml that you want to calculate
using numbers and not integers, the packages are there as part of the
standard library.
You can argue that this should be the default but down that route lies
the argument that the language should *by default* be able to deal
with vectors and matrices like APL/J can. Neither O'Caml nor CL can
do this by default though both can do it with the addition of
user-level libraries.
·············@yahoo.com (Stephen J. Bevan) writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > ·············@yahoo.com (Stephen J. Bevan) writes:
> > > ... If you want floating point then :-
> > >
> > > # let y = 3.0 *. 1.0/.12.0;;
> > > val y : float = 0.25
> > > #
> >
> > No. I want the correct answer for numbers.
>
> Ok, then all you need to do is tell O'Caml that you want to calculate
> using numbers and not integers, the packages are there as part of the
> standard library.
>
> You can argue that this should be the default but down that route lies
> the argument that the language should *by default* be able to deal
> with vectors and matrices like APL/J can. Neither O'Caml nor CL can
> do this by default though both can do it with the addition of
> user-level libraries.
Yes. But CL does (* 3 1/12) right. OCAML does not. I.e. the number
of libraries you have to add to CL is *less* than the number of
libraries you have to add to OCAML, moreover, CL can be extended to
look like CL even when the extra libraries are added. Doing the same
for *ML languages is far trickier.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3y9r7af6o.fsf@yahoo.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> But CL does (* 3 1/12) right. OCAML does not.
IMHO they both get it right in the context of their type system.
You've made it clear you don't like the O'Caml answer but that doesn't
mean it is wrong, any more than CL's type system is "wrong" for not
being able to do (+ 1 array) out of the box.
> I.e. the number
> of libraries you have to add to CL is *less* than the number of
> libraries you have to add to OCAML,
Agreed, but it doesn't much matter if someone else has already written
them. You just load them and forget about it.
> moreover, CL can be extended to look like CL even when the extra
> libraries are added. Doing the same for *ML languages is far
> trickier.
Tricker yes since transformations must be statically typesafe, but
some versions give you the hooks to do this e.g. the first use of ML
was in theorem proving where altering the concrete syntax was part of
implementing the theorem prover.
Stephen J. Bevan <·············@yahoo.com> wrote:
+---------------
| Marco Antoniotti <·······@cs.nyu.edu> writes:
| > But CL does (* 3 1/12) right. OCAML does not.
|
| IMHO they both get it right in the context of their type system.
| You've made it clear you don't like the O'Caml answer but that doesn't
| mean it is wrong, any more than CL's type system is "wrong" for not
| being able to do (+ 1 array) out of the box.
+---------------
And what makes you think it can't?
> (map 'vector #'1+ #(12 23 34))
#(13 24 35)
>
-Rob
-----
Rob Warnock, 31-2-510 <····@sgi.com>
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: Please don't use ·········@sgi.com or ········@sgi.com ]
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3vgmba88b.fsf@yahoo.com>
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Stephen J. Bevan <·············@yahoo.com> wrote:
> +---------------
> | Marco Antoniotti <·······@cs.nyu.edu> writes:
> | > But CL does (* 3 1/12) right. OCAML does not.
> |
> | IMHO they both get it right in the context of their type system.
> | You've made it clear you don't like the O'Caml answer but that doesn't
> | mean it is wrong, any more than CL's type system is "wrong" for not
> | being able to do (+ 1 array) out of the box.
> +---------------
>
> And what makes you think it can't?
The fact that you had to write :-
> > (map 'vector #'1+ #(12 23 34))
> #(13 24 35)
> >
rather than
> (+ 1 #(12 23 34))
#(13 24 35)
A small matter of syntax perhaps but some people seem very attatched
to it.
From: Duane Rettig
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <4pucj1nn9.fsf@beta.franz.com>
·············@yahoo.com (Stephen J. Bevan) writes:
> ····@rigden.engr.sgi.com (Rob Warnock) writes:
> > Stephen J. Bevan <·············@yahoo.com> wrote:
> > +---------------
> > | Marco Antoniotti <·······@cs.nyu.edu> writes:
> > | > But CL does (* 3 1/12) right. OCAML does not.
> > |
> > | IMHO they both get it right in the context of their type system.
> > | You've made it clear you don't like the O'Caml answer but that doesn't
> > | mean it is wrong, any more than CL's type system is "wrong" for not
> > | being able to do (+ 1 array) out of the box.
> > +---------------
> >
> > And what makes you think it can't?
>
> The fact that you had to write :-
>
> > > (map 'vector #'1+ #(12 23 34))
> > #(13 24 35)
> > >
>
> rather than
>
> > (+ 1 #(12 23 34))
> #(13 24 35)
>
> A small matter of syntax perhaps but some people seem very attatched
> to it.
But because Lisp is a language-writing language, syntax is
almost _always_ just a small matter:
CL-USER(1): (shell "cat myplus.cl")
(defpackage :mypkg
(:use :common-lisp)
(:shadow +))
(in-package :mypkg)
(defun + (a b)
(if (vectorp b)
(map 'vector #'(lambda (x) (+ a x)) b)
(cl:+ a b)))
0
CL-USER(2): :ld myplus
; Fast loading /force/duane/acl61/src/myplus.fasl
CL-USER(3): :pa mypkg
MYPKG(4): (+ 1 #(12 23 34))
#(13 24 35)
MYPKG(5): (+ 1 2)
3
MYPKG(6):
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
On 04 Jun 2001 22:50:02 -0700, Duane Rettig <·····@franz.com> wrote:
>(defun + (a b)
> (if (vectorp b)
> (map 'vector #'(lambda (x) (+ a x)) b)
> (cl:+ a b)))
Is that better than making + a generic function?
From: Duane Rettig
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <4wv6rj7xu.fsf@beta.franz.com>
··········@questions.com writes:
> On 04 Jun 2001 22:50:02 -0700, Duane Rettig <·····@franz.com> wrote:
>
> >(defun + (a b)
> > (if (vectorp b)
> > (map 'vector #'(lambda (x) (+ a x)) b)
> > (cl:+ a b)))
>
> Is that better than making + a generic function?
Not at all; this was an example for feasibility purposes. Instead
of the above, you could have just as easily done this:
(in-package :mypkg)
(defmethod + (a b)
(cl:+ a b))
(defmethod + ((a number) (b vector))
(map 'vector #'(lambda (x) (cl:+ a x)) b))
;; (more defmethods ...)
The first style is presumably faster; the second is cleaner and
more extensible.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3ofs39gf7.fsf@yahoo.com>
Duane Rettig <·····@franz.com> writes:
> > The fact that you had to write :-
> > > > (map 'vector #'1+ #(12 23 34))
> > > #(13 24 35)
> > > >
> >
> > rather than
> >
> > > (+ 1 #(12 23 34))
> > #(13 24 35)
> >
> > A small matter of syntax perhaps but some people seem very attatched
> > to it.
>
> But because Lisp is a language-writing language, syntax is
> almost _always_ just a small matter:
Sure, I implicitly agreed with this when I responded to Marco's
message referencing matlisp. The point of the example was to show
that CL's numeric tower can be irksome out of the box in a similar way
to that which Marco finds irksome about O'Caml. The fact that
user-level libraries can alleviate some or all of the issues is a
testament to flexibility of both languages.
>>>>> "Stephen" == Stephen J Bevan <·············@yahoo.com> writes:
Stephen> ····@rigden.engr.sgi.com (Rob Warnock) writes:
>> Stephen J. Bevan <·············@yahoo.com> wrote:
>> +---------------
>> | Marco Antoniotti <·······@cs.nyu.edu> writes:
>> | > But CL does (* 3 1/12) right. OCAML does not.
>> |
>> | IMHO they both get it right in the context of their type system.
>> | You've made it clear you don't like the O'Caml answer but that doesn't
>> | mean it is wrong, any more than CL's type system is "wrong" for not
>> | being able to do (+ 1 array) out of the box.
>> +---------------
>>
>> And what makes you think it can't?
Stephen> The fact that you had to write :-
>> > (map 'vector #'1+ #(12 23 34))
>> #(13 24 35)
>> >
Stephen> rather than
>> (+ 1 #(12 23 34))
Stephen> #(13 24 35)
Stephen> A small matter of syntax perhaps but some people seem very attatched
Stephen> to it.
Forget about the syntax. I still have problems with why the above is
the right answer. Why isn't it #(13 23 34)? Or some other thing?
It's not clear to me that adding the number 1 to an array should do that
to all elements of the array.
Ray
From: Tim Bradshaw
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <nkjd78jqdq3.fsf@tfeb.org>
Raymond Toy <···@rtp.ericsson.se> writes:
>
> Forget about the syntax. I still have problems with why the above is
> the right answer. Why isn't it #(13 23 34)? Or some other thing?
> It's not clear to me that adding the number 1 to an array should do that
> to all elements of the array.
>
This is a good point. Adding numbers and matrices isn't well-defined
under the normal matrix algebra rules, and the obvious way of giving
it a meaning, which is to treat:
x + M
(where x is a number and M is a matrix) as
x*I + M
(where I is the identity matrix) does *not* give the result of adding
x to each element.
Of course I'm assuming square matrices here, whereas the quoted code
is for vectors. I guess it might make sense (for vectors and general
matrices) to treat
x + M
as
x * J + M
where J is the all-ones matrix.
But in my days as a physicist I can't ever remember using any of these
shorthands, and I'd be pretty uncomfortable using a language which
didn't at least warn profusely if it did this. Apart from anything
else, if the vectors are vectors in some physical space and are not in
an orthonormal basis, adding numbers to them is likely to result in
extremely bizarre consequences with either interpretation.
--tim
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3lmn79fxg.fsf@yahoo.com>
Raymond Toy <···@rtp.ericsson.se> writes:
> Forget about the syntax. I still have problems with why the above is
> the right answer. Why isn't it #(13 23 34)? Or some other thing?
> It's not clear to me that adding the number 1 to an array should do that
> to all elements of the array.
Presumably becase that's what the J people feel is the most
appropriate/consistent definition. However, rather than get hung up
on (+ 1 #(12 23 34)), by all means change the example to
(+ #(1 1 1) #(12 23 34)) which hopefully has an unambiguous answer.
From: Tim Bradshaw
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <nkj8zj79evv.fsf@tfeb.org>
·············@yahoo.com (Stephen J. Bevan) writes:
> Presumably becase that's what the J people feel is the most
> appropriate/consistent definition. However, rather than get hung up
> on (+ 1 #(12 23 34)), by all means change the example to
> (+ #(1 1 1) #(12 23 34)) which hopefully has an unambiguous answer.
Well, if we're in spherical polars in 3d euclidean space, that's
... not what you thought.
--tim
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3n17mc170.fsf@yahoo.com>
Tim Bradshaw <···@tfeb.org> writes:
> > Presumably becase that's what the J people feel is the most
> > appropriate/consistent definition. However, rather than get hung up
> > on (+ 1 #(12 23 34)), by all means change the example to
> > (+ #(1 1 1) #(12 23 34)) which hopefully has an unambiguous answer.
>
> Well, if we're in spherical polars in 3d euclidean space, that's
> ... not what you thought.
Agreed, I retract "unambiguous" since it is just ambiguous as x+y
unless the domain of x and y (or the matrix) is clearly specified.
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Stephen J. Bevan <·············@yahoo.com> wrote:
> +---------------
> | Marco Antoniotti <·······@cs.nyu.edu> writes:
> | > But CL does (* 3 1/12) right. OCAML does not.
> |
> | IMHO they both get it right in the context of their type system.
> | You've made it clear you don't like the O'Caml answer but that doesn't
> | mean it is wrong, any more than CL's type system is "wrong" for not
> | being able to do (+ 1 array) out of the box.
> +---------------
The *ML languages abandon overloading to gain type inference. Combining type
inference AND overloading in the same langauge is very tricky.
--
miles egan
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3vgmac2fb.fsf@yahoo.com>
Miles Egan <·····@puzl.pixar.com> writes:
> The *ML languages abandon overloading to gain type inference. Combining type
> inference AND overloading in the same langauge is very tricky.
Agreed. Haskell gives it a go via the introduction of type classes
and arguable makes a better job of it than the various MLs.
From: Sam Steingold
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <u3d9f7yau.fsf@xchange.com>
> * In message <··············@yahoo.com>
> * On the subject of "Re: ML, CL or Scheme as an extension language"
> * Sent on Tue, 05 Jun 2001 01:28:04 GMT
> * Honorable ·············@yahoo.com (Stephen J. Bevan) writes:
>
> being able to do (+ 1 array) out of the box.
unless your ARRAY is a square matrix (tensors with an even number of
indexes are okay too, as are complex numbers, quaternions and Cayley
numbers :-), this expression does not have a canonical mathematical
meaning.
(* 3 1/12) means 1/4 in math, unless the Party Central Committee has
issued some new instructions recently.
--
Sam Steingold (http://www.podval.org/~sds)
Lisp is a way of life. C is a way of death.
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m31yoydhzb.fsf@yahoo.com>
Sam Steingold <···@gnu.org> writes:
> > being able to do (+ 1 array) out of the box.
>
> unless your ARRAY is a square matrix (tensors with an even number of
> indexes are okay too, as are complex numbers, quaternions and Cayley
> numbers :-), this expression does not have a canonical mathematical
> meaning.
Agreed, but that doesn't mean a language designer / library designer
can't choose one if they feel it is useful, for example ...
> (* 3 1/12) means 1/4 in math, unless the Party Central Committee has
> issued some new instructions recently.
Abstracting a bit to give
(* x y/z)
and then putting this at the end of the sentence "let x, y and z be
integers in" gives a completely different result in math to "let x, y
and z be reals in".
As you point out with the matrix case, various expressions can have
multiple meanings, it is a judgement call whether to choose one of
them. Clearly O'Caml, CL and J differ in the choices that were made.
From: Tim Bradshaw
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <nkjelsyq4dj.fsf@tfeb.org>
·············@yahoo.com (Stephen J. Bevan) writes:
> (* x y/z)
>
> and then putting this at the end of the sentence "let x, y and z be
> integers in" gives a completely different result in math to "let x, y
> and z be reals in".
>
Eh? Division and multiplication are defined over the entire complex
plane.
--tim
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3snhec2cb.fsf@yahoo.com>
Tim Bradshaw <···@tfeb.org> writes:
> ·············@yahoo.com (Stephen J. Bevan) writes:
> > (* x y/z)
> >
> > and then putting this at the end of the sentence "let x, y and z be
> > integers in" gives a completely different result in math to "let x, y
> > and z be reals in".
>
> Eh? Division and multiplication are defined over the entire complex
> plane.
So?
From: Tim Bradshaw
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <nkjd78iq3of.fsf@tfeb.org>
·············@yahoo.com (Stephen J. Bevan) writes:
>
> So?
So what do you mean by `a completely different result'? Do you simply
mean that in the case where x,y,z are integers the result is rational,
whereas otherwise they it will in general not be?
The point is that the result for numbers is well-defined: if I tell
you, as an applied mathematician, that x,y,z are numbers then x+y/z is
well-defined (up to the usual bad cases if z is zero). If I tell you
that they are matrices or numbers then it isn't, not even if we leave
out division and just ask for x+y where x & y are matrices or numbers.
--tim
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3pucic1cl.fsf@yahoo.com>
Tim Bradshaw <···@tfeb.org> writes:
> So what do you mean by `a completely different result'? Do you simply
> mean that in the case where x,y,z are integers the result is rational,
> whereas otherwise they it will in general not be?
>
> The point is that the result for numbers is well-defined: if I tell
> you, as an applied mathematician, that x,y,z are numbers then x+y/z is
> well-defined (up to the usual bad cases if z is zero).
I'm not an mathematician, applied or otherwise, but assuming x, y and
z are 3, 1 and 12 respectively then in the integer case I'd expect to
get 0 and in the (rational or) real case I'd expect to get (1/4 or) 0.25.
That's what I meant by completely different result.
From: Tim Bradshaw
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <nkjbso2q2gy.fsf@tfeb.org>
·············@yahoo.com (Stephen J. Bevan) writes:
>
> I'm not an mathematician, applied or otherwise, but assuming x, y and
> z are 3, 1 and 12 respectively then in the integer case I'd expect to
> get 0 and in the (rational or) real case I'd expect to get (1/4 or) 0.25.
> That's what I meant by completely different result.
You definitely wouldn't expect that if your brain hadn't been poisoned
by computers (:-). To almost anyone outside certain branches of
computer science, x/y for x and y integers is a rational number, and
definitely not thing various computer languages define it as, which is
some variant on round(x/y), where round is the operation that rounds
to the nearest integer.
Indeed this is true in Common Lisp too:
LC-USER 86 > (/ 1 2)
1/2
LC-USER 87 > (describe 1/2)
1/2 is a ratio
LC-USER 88 > (* 3 (/ 1 12))
1/4
I can see why you were confused now, and I'm sorry if I was a bit
agressive: it's easy for Lisp people to forget that a lot of computer
languages assume that the wrong answer quickly is the right thing to
do (we don't wrap addition either).
--tim
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3k82qc070.fsf@yahoo.com>
Tim Bradshaw <···@tfeb.org> writes:
> ·············@yahoo.com (Stephen J. Bevan) writes:
> > I'm not an mathematician, applied or otherwise, but assuming x, y and
> > z are 3, 1 and 12 respectively then in the integer case I'd expect to
> > get 0 and in the (rational or) real case I'd expect to get (1/4 or) 0.25.
> > That's what I meant by completely different result.
>
> You definitely wouldn't expect that if your brain hadn't been poisoned
> by computers (:-).
Actually it was poisoned by abstract algebra where it was made very
clear to me that I had to be precise about what group, field,
... etc. I was talking about whenever I used a symbol like +, *,
... etc.
In article <··············@yahoo.com>,
Stephen J. Bevan <·············@yahoo.com> wrote:
>Tim Bradshaw <···@tfeb.org> writes:
>> ·············@yahoo.com (Stephen J. Bevan) writes:
>> > I'm not an mathematician, applied or otherwise, but assuming x, y and
>> > z are 3, 1 and 12 respectively then in the integer case I'd expect to
>> > get 0 and in the (rational or) real case I'd expect to get (1/4 or) 0.25.
>> > That's what I meant by completely different result.
>>
I'd expect a qualification on 0, like "rounded to the nearest integer"
or "the floor of the answer" or something. Except in programming
certain computer languages.
>> You definitely wouldn't expect that if your brain hadn't been poisoned
>> by computers (:-).
>
>Actually it was poisoned by abstract algebra where it was made very
>clear to me that I had to be precise about what group, field,
>... etc. I was talking about whenever I used a symbol like +, *,
>... etc.
When I took it, it looked like there was a serious attempt to distinguish
the operators from the usual +, etc., usually by drawing a circle around
them. I suppose that that is optional, but most mathematicians that I've
known would assume that 2 + 2 = 4 first, and as questions about whether
this is (say) mod 4 later.
If C used funny symbols for addition, etc., then I'd be happy in the
concept that this was some algebraic concept that wasn't intended
as actual numbers.
Then again, what can you expect from a language that uses "=" as an
assignment operator?
(Remember, boys and girls, X = X + 1 iff X is transfinite!)
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) writes:
> (Remember, boys and girls, X = X + 1 iff X is transfinite!)
Depends whether you're talking about ordinal or cardinal addition.
1+omega = omega /= omega+1
but on the other hand
1+aleph_0 = aleph_0 = aleph_0+1
--
Lieven Marchand <···@wyrd.be>
Making laws appears to win votes. Enforcing them doesn't.
See Rule One. Roger Burton West in the monastery.
From: Tim Bradshaw
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <nkjae3mq13h.fsf@tfeb.org>
·············@yahoo.com (Stephen J. Bevan) writes:
>
> Actually it was poisoned by abstract algebra where it was made very
> clear to me that I had to be precise about what group, field,
> ... etc. I was talking about whenever I used a symbol like +, *,
> ... etc.
In this case the relevant thing is, I think the field of complex
numbers (but I forget if that's really enough to specify it), of which
things like the reals and rationals are subfields (again, I think).
--tim
·············@yahoo.com (Stephen J. Bevan) writes:
| "+" is defined to add integers and 8.3 is a float. If you want to
| add floats use "+.". Are you irked because O'Caml doesn't
| transparently convert between floats and ints? I can understand
| that, but then I can also understand someone being irked that (+ 1
| "2") doesn't produce "3".
The point is, of course, that + should operate on numbers and last I
looked both 1 and 8.3 are numbers. "3" is a string, not a number, I
can understand why somebody would want to add "3" to 1, but I wouldn't
agree that it's a good idea.
| In both cases I prefer to make the conversion explicit but obviously
| tastes vary.
1 + "3" involves a conversion. In my view, 1 + 8.3 does not involve a
conversion. But, as you said, tastes vary.
Boris
--
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>
QOTD:
"It's been real and it's been fun, but it hasn't been real fun."
From: Stephen J. Bevan
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <m3itic3t5p.fsf@yahoo.com>
Boris Schaefer <·····@uncommon-sense.net> writes:
> ·············@yahoo.com (Stephen J. Bevan) writes:
> | "+" is defined to add integers and 8.3 is a float. If you want to
> | add floats use "+.". Are you irked because O'Caml doesn't
> | transparently convert between floats and ints? I can understand
> | that, but then I can also understand someone being irked that (+ 1
> | "2") doesn't produce "3".
>
> The point is, of course, that + should operate on numbers
Perhaps, perhaps not. It depends on exactly how you define number.
CL goes quite away further than a lot of languages by including things
like rationals and complex numbers in its concept of "number".
However, what about matrices? As an APL user I'd be quite irked to
find that (+ 1 matrix) doesn't work out of the box in CL.
> and last I
> looked both 1 and 8.3 are numbers. "3" is a string, not a number, I
> can understand why somebody would want to add "3" to 1, but I wouldn't
> agree that it's a good idea.
I don't think it is a good idea either. But then I don't think that
adding 1 and 8.3 is necessarily a good idea either :-)
> | In both cases I prefer to make the conversion explicit but obviously
> | tastes vary.
>
> 1 + "3" involves a conversion. In my view, 1 + 8.3 does not involve a
> conversion.
In an abstract sense it doesn't, but then nor does "one" + 8.3. From
an implementation point of view, both will involve a conversion unless
the implementation happens to represent every number as floating point
(e.g. Perl) or a string respectively (e.g. TCL).
Marco Antoniotti <·······@cs.nyu.edu> wrote:
+---------------
| Rolf Wester <···········@t-online.de> writes:
| > Besides this I have another question. I tried to install mk:defsystem, port
| > and cllib (Clips. I downloaded the lisp sources, started Clisp and typed:
| > (compile-file "defsystem.lisp")...
...
| Note that COMPILE-FILE does not necessarily LOAD the file in the
| running image. To be sure that the file (any file is loaded) you have
| to issue
| (compile-file "defsystem.lisp" :load t)
+---------------
While CMUCL seems to have a :LOAD keyword option to COMPILE-FILE,
I don't see such a thing in the version of CLISP I have (or in CLHS,
for that matter). Is it a widely-implemented extension (e.g., ACL, LW)?
-Rob
-----
Rob Warnock, 31-2-510 <····@sgi.com>
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: Please don't use ·········@sgi.com or ········@sgi.com ]
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
> +---------------
> | Rolf Wester <···········@t-online.de> writes:
> | > Besides this I have another question. I tried to install mk:defsystem, port
> | > and cllib (Clips. I downloaded the lisp sources, started Clisp and typed:
> | > (compile-file "defsystem.lisp")...
> ...
> | Note that COMPILE-FILE does not necessarily LOAD the file in the
> | running image. To be sure that the file (any file is loaded) you have
> | to issue
> | (compile-file "defsystem.lisp" :load t)
> +---------------
>
> While CMUCL seems to have a :LOAD keyword option to COMPILE-FILE,
> I don't see such a thing in the version of CLISP I have (or in CLHS,
> for that matter). Is it a widely-implemented extension (e.g., ACL, LW)?
LWW/LWL, as well as GCL, ECL and ECLS (and likely all other KCL
derivatives) have :LOAD, ACL has :LOAD-AFTER-COMPILE (as well as the
top-level-command :cl).
Though this option doesn't buy you much, since typing
(load (compile-file "blub"))
is not that much more work (and many people use IDEs/Emacs anyway).
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
> +---------------
> | Rolf Wester <···········@t-online.de> writes:
> | > Besides this I have another question. I tried to install mk:defsystem, port
> | > and cllib (Clips. I downloaded the lisp sources, started Clisp and typed:
> | > (compile-file "defsystem.lisp")...
> ...
> | Note that COMPILE-FILE does not necessarily LOAD the file in the
> | running image. To be sure that the file (any file is loaded) you have
> | to issue
> | (compile-file "defsystem.lisp" :load t)
> +---------------
>
> While CMUCL seems to have a :LOAD keyword option to COMPILE-FILE,
> I don't see such a thing in the version of CLISP I have (or in CLHS,
> for that matter). Is it a widely-implemented extension (e.g., ACL, LW)?
My mistake.
Bottom line: you need to LOAD the compiled file.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Rolf Wester <······@ilt.fhg.de> wrote in message news:<·················@ilt.fhg.de>...
>[... looking for extension language ...]
> or CL (Clisp ?). I considered Scheme and CL because of their dynamic
> nature what makes experimentation
> with the application quite comfortable and Scheme also because it has a
> simple syntax (the application will also
> be used by others that are not familiar with Lisp or ML). I would like
> to run it under WinNT and possibly under UNIX (not highest priority).
> The extension with C/C++ should be easy.
This is going to be a heretical suggestion... In my humble experience,
the easiest thing you can use as an embedded extension language is
TCL. TCL was designed from the beginning as an extension language; i
used to be able to add TCL to a Unix C program in less than an hour.
It works fine in Windows too (it's a DLL). I believe TCL is at
http://dev.scriptics.com (or it might be ajubasolutions.com; they went
through so many names that i lost track).
If you want to stay Lisp-ish, maybe Guile would be a good choice
(Guile is the FSF's version of Scheme, and it's also meant to be used
as an extension language), but it's at least an order of magnitude
harder to implement than TCL. I've compiled Guile in Windows, but
haven't tried to embed it in another app. I believe Guile is at
http://www.gnu.org/software/guile/guile.html.
But actually if Windows is your main environment, the best option for
you might be Corman Lisp, not as an embedded language, but as a COM
server. The documentation is scarce, but Roger himself and the other
people on the email list are helpful. Corman is, of course, at
http://www.corman.net. In this case, you'd have an almost 100%
complete Common Lisp to work with, pretty nice and very fast.
Or... you could always use Perl! :-) <ducking for cover!>
g
··········@my-deja.com (glauber) writes:
> Rolf Wester <······@ilt.fhg.de> wrote in message news:<·················@ilt.fhg.de>...
>
> >[... looking for extension language ...]
>
> > or CL (Clisp ?). I considered Scheme and CL because of their dynamic
> > nature what makes experimentation
> > with the application quite comfortable and Scheme also because it has a
> > simple syntax (the application will also
> > be used by others that are not familiar with Lisp or ML). I would like
> > to run it under WinNT and possibly under UNIX (not highest priority).
> > The extension with C/C++ should be easy.
>
>
> This is going to be a heretical suggestion... In my humble experience,
> the easiest thing you can use as an embedded extension language is
> TCL. TCL was designed from the beginning as an extension language; i
> used to be able to add TCL to a Unix C program in less than an hour.
> It works fine in Windows too (it's a DLL). I believe TCL is at
> http://dev.scriptics.com (or it might be ajubasolutions.com; they went
> through so many names that i lost track).
But the syntax and semantics of TCL are *painful*. In my
opinion it's up there with Intercal and PLEX.[1]
> If you want to stay Lisp-ish, maybe Guile would be a good choice
> (Guile is the FSF's version of Scheme, and it's also meant to be used
> as an extension language), but it's at least an order of magnitude
> harder to implement than TCL. I've compiled Guile in Windows, but
> haven't tried to embed it in another app. I believe Guile is at
> http://www.gnu.org/software/guile/guile.html.
How about ELK? This is a scheme system that is designed for
use as an extension language (which may possibly also be the case with
Guile :-)
> But actually if Windows is your main environment, the best option for
> you might be Corman Lisp, not as an embedded language, but as a COM
> server. The documentation is scarce, but Roger himself and the other
> people on the email list are helpful. Corman is, of course, at
> http://www.corman.net. In this case, you'd have an almost 100%
> complete Common Lisp to work with, pretty nice and very fast.
I agree with this, except for the "very fast". I wrote some
CLOS code a year or so back that ran significantly faster in
CLISP. This could obviously be my own fault; I'm not a great CL
programmer now, but I'm a lot better than I was a year back :-)
[1] An Ericsson-proprietary language used for programming digital
telephone switches. Not to be confused with Erlang, which I kind of
liked.
--
Raymond Wiker
·············@fast.no
From: dave linenberg
Subject: Re: ML, CL or Scheme as an extension language
Date:
Message-ID: <3B1937B2.735AF2BB@home.com>
>
There are some languages *designed* to be extension languages, embedded in C (or C++)
programs. Languages that come to mind are LUA and S-Lang. I'm not sure which versions have
good interfaces to C.
I believe OCaml, Ruby and Python can be easily embedded in your C/C++ program as well.
I'm currently working on trying to make CMUCL embedded (callable) from a C program, and
realized that because of file (FILE*) input/output buffering I would have to call it from a
pseudo-terminal. (see W. Richard Stevens, Advanced Programming Unix Environment, the pty
example at the end of the book for controlling interactive processes intended to run in a
terminal, like CMUCL). The project is definitely more complex than I thought.....
Dave Linenberg
dave linenberg <········@home.com> writes:
> I'm currently working on trying to make CMUCL embedded (callable)
> from a C program, and realized that because of file (FILE*)
> input/output buffering I would have to call it from a
> pseudo-terminal. (see W. Richard Stevens, Advanced Programming Unix
> Environment, the pty example at the end of the book for controlling
> interactive processes intended to run in a terminal, like CMUCL).
> The project is definitely more complex than I thought.....
Not the usual meaning of "embedded", but ...
You might want to look at 'detachtty', which allows a process to be
run in its own pty, and copies its i/o to a unix-domain socket (which
the companion program 'attachtty' can send to the user). It uses the
forkpty() call, so may not be too portable to non-GNU systems, though.
"We're taking patches"
Try http://ww.telent.net/cliki/detachtty - it may also appear in CCLAN
soon.
Unlike every other "attach to a long-running process" program that
I've seen so far, it catches SIGINT, sending character 3 through to
the controlled process. This makes it possible to run under ILISP.
Also runs across the network, if you have ssh installed.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
dave linenberg wrote:
> >
>
> I believe OCaml, Ruby and Python can be easily embedded in your C/C++ program as well.
>
It's quite easy with OCaml (Python is a bit more complicated if not using Swig). I made it, but
the
other way around. I didn't embed OCaml in C/C++ but extended OCaml with C/C++ stuff. So I'm
able to run the OCaml toplevel to experiment with the program and for rapid prototyping. I'm
using
OCaml because it is quite fast (1/3 of C floating point performance on Windows when natively
compiled,
the toplevel is slower but the performance critical can easily be written inC/C++), it has all
the advantages of ML and a good documentation. I wanted to try CL because of so many people
claim it to be so superior and started with Clisp. I haven't done any serious programming with
it until now. I tried to compile defsystem, port and cllib
but faced some problems. The compilation succeded but when typing (mk:compile-system "port")
Clisp complaines that compile-system is not defined. The install instructions are UNIX specific
and I still have to figure out how to
do it on Windows. Another point is the FFI, the documentation of which is UNIX specific too.
I will probably use OCaml or Clisp (and not Guile, Elk or Bigloo) as an extension language for
the C/C++ optics stuff. But I'm still undecisive. I would like to use Clisp for being able to
compare OCaml and Clisp as a language and for the extension purpose. On the other hand I already
know how to link OCaml and C/C++ and doing it with Clisp seems to be more complicated (or am I
wrong?).
Rolf
>>>>> "dl" == dave linenberg <········@home.com> writes:
dl> There are some languages *designed* to be extension languages,
dl> embedded in C (or C++) programs. Languages that come to mind
dl> are LUA and S-Lang. I'm not sure which versions have good
dl> interfaces to C. I believe OCaml, Ruby and Python can be
dl> easily embedded in your C/C++ program as well.
Guile actually works very nicely as an embedded language -- used in
such projects as Gnucash, Siag, scwm, etc.
http://www.gnu.org/software/guile/guile.html
It's also, of course, an R5RS-compliant Scheme, with lots of SRFIs
supported.
~ESP
--
Evan Prodromou
····@prodromou.san-francisco.ca.us
Raymond Wiker <·············@fast.no> wrote in message news:<··············@raw.grenland.fast.no>...
> ··········@my-deja.com (glauber) writes:
>
> > Rolf Wester <······@ilt.fhg.de> wrote in message news:<·················@ilt.fhg.de>...
[...]
> > But actually if Windows is your main environment, the best option for
> > you might be Corman Lisp, not as an embedded language, but as a COM
> > server. The documentation is scarce, but Roger himself and the other
> > people on the email list are helpful. Corman is, of course, at
> > http://www.corman.net. In this case, you'd have an almost 100%
> > complete Common Lisp to work with, pretty nice and very fast.
>
> I agree with this, except for the "very fast". I wrote some
> CLOS code a year or so back that ran significantly faster in
> CLISP. This could obviously be my own fault; I'm not a great CL
> programmer now, but I'm a lot better than I was a year back :-)
[...]
"If memory serves me right", the CLOS stuff in Corman used to be
pretty slow. I think it's still slow, but getting better. I don't
normally use CLOS, so i don't know first hand.
g
"Rolf Wester" <······@ilt.fhg.de> wrote in message
······················@ilt.fhg.de...
> I have an optics program written in C++ that can be "programmed" using
> XML-files. Unfortunately
> this approach is not very flexible. I would like to use a real
> programming language for that purpose.
> And I would like to be able to use it interactively, like Clisp or OCaml
> interacting with XEmacs. There
> seem to be some canditates for this purpose. I considered to use OCaml,
> that I'm quite familiar with
> (and it's easy to link an OCaml toplevel with C code) but I also
> considered to use Scheme (Bigloo, Guile, Elk)
> or CL (Clisp ?). I considered Scheme and CL because of their dynamic
> nature what makes experimentation
> with the application quite comfortable and Scheme also because it has a
> simple syntax (the application will also
> be used by others that are not familiar with Lisp or ML). I would like
> to run it under WinNT and possibly under UNIX (not highest priority).
> The extension with C/C++ should be easy.
I don't know what your optical program is doing, but you should consider
writing it completely in CL.
I've done a small optical ray tracer in CL (Lispworks) with OpenGL
visualization of the rays.
In the same kind of program I've made an ultrasound ray tracer with OpenGL
visualization ( www.fractalconcept.com/ndt/andt6.html ) which is part of a
bigger program.
You could still use the number crunching in C++ if you want and call it
through the FFI
Marc
Marc Battyani wrote:
> I don't know what your optical program is doing, but you should consider
> writing it completely in CL.
> I've done a small optical ray tracer in CL (Lispworks) with OpenGL
> visualization of the rays.
> In the same kind of program I've made an ultrasound ray tracer with OpenGL
> visualization ( www.fractalconcept.com/ndt/andt6.html ) which is part of a
> bigger program.
> You could still use the number crunching in C++ if you want and call it
> through the FFI
>
> Marc
It's not a ray tracer, it is a wave optics program, for example for doing
fresnel propagation.
Performance is crucial (I even considered to write it in Fortran) so I will
retain the C++ stuff
(besides performance I consider the C++ array syntax to be more readable, what
helps avoiding
errors). I want to use CL (or OCaml) interactively in the top level loop with
having access to the
C++ part so that I can easily experiment with different configurations
(optical resonators for example).
How well performs LW with array access and floating point operations compared
to C++? Clisp
is quite slow, OCaml (natively compiled ) is about 3 times slower compared to
C++ and
ACL6 (free trial version) was a little slower than OCaml.
Rolf
"Rolf Wester" <···········@t-online.de> wrote
> Marc Battyani wrote:
>
> > I don't know what your optical program is doing, but you should consider
> > writing it completely in CL.
> > I've done a small optical ray tracer in CL (Lispworks) with OpenGL
> > visualization of the rays.
> > In the same kind of program I've made an ultrasound ray tracer with
OpenGL
> > visualization ( www.fractalconcept.com/ndt/andt6.html ) which is part of
a
> > bigger program.
> > You could still use the number crunching in C++ if you want and call it
> > through the FFI
> >
>
> It's not a ray tracer, it is a wave optics program, for example for doing
> fresnel propagation.
> Performance is crucial (I even considered to write it in Fortran) so I
will
> retain the C++ stuff
If you find C++ too slow you should look at VHDL ;-)
(depending of your application it's not quite a joke in fact)
> (besides performance I consider the C++ array syntax to be more readable,
what
> helps avoiding
> errors). I want to use CL (or OCaml) interactively in the top level loop
with
> having access to the
> C++ part so that I can easily experiment with different configurations
> (optical resonators for example).
Yes, but I think it would be simpler to embed the C++ code number crunching
code into Lisp than the contrary.
As you are under NT you could put the C++ code in a DLL and call from Lisp.
> How well performs LW with array access and floating point operations
compared
> to C++? Clisp
> is quite slow, OCaml (natively compiled ) is about 3 times slower compared
to
> C++ and
> ACL6 (free trial version) was a little slower than OCaml.
LW is slower than ACL6 for floating point operations. But if you keep your
C++ code for number crunching then it doesn't matter much.
Marc
Marc Battyani wrote:
>
> If you find C++ too slow you should look at VHDL ;-)
> (depending of your application it's not quite a joke in fact)
>
What is this? I have never heard ar read about it.
>
> > (besides performance I consider the C++ array syntax to be more readable,
> what
> > helps avoiding
> > errors). I want to use CL (or OCaml) interactively in the top level loop
> with
> > having access to the
> > C++ part so that I can easily experiment with different configurations
> > (optical resonators for example).
>
> Yes, but I think it would be simpler to embed the C++ code number crunching
> code into Lisp than the contrary.
> As you are under NT you could put the C++ code in a DLL and call from Lisp.
>
That's indeed what I want to do. I probably expressed myself mistakable. I guess
to call a DLL
from Lisp is possible with LW and ACL (I don't know exactly). With Clisp I have
to link
my own C/C++ stuff with the compiled Clisp sources.
>
> > How well performs LW with array access and floating point operations
> compared
> > to C++? Clisp
> > is quite slow, OCaml (natively compiled ) is about 3 times slower compared
> to
> > C++ and
> > ACL6 (free trial version) was a little slower than OCaml.
>
> LW is slower than ACL6 for floating point operations. But if you keep your
> C++ code for number crunching then it doesn't matter much.
>
Do you know how LW compares to C++ for floating point operations. ACL6 would
be fine but is quite expensive.
Rolf
"Rolf Wester" <···········@t-online.de> wrote
> Marc Battyani wrote:
> > If you find C++ too slow you should look at VHDL ;-)
> > (depending of your application it's not quite a joke in fact)
> >
>
> What is this? I have never heard ar read about it.
Here is a definition : "VHDL is an acronym which stands for VHSIC Hardware
Description Language. VHSIC is yet another achronym which stands for Very
High Speed Integrated Circuits"
The short answer is that when you compile VHDL you get logic hardware
(gates). For instance, processors (like the AMD and Intel ones) are defined
in VHDL or a similar language.
So in if you can rewrite some parts of your program in VHDL you can compile
it to hardware gates that you can put in a FPGA. The FPGA I use are from
Xilinx and they have real nice specs: several 1024 point complex FFT in less
than 1�s, 600 billion MAC/s (Multiply ACcumulate), Terabit bandwidth, etc...
When you have a client that really needs the computing speed they are OK to
pay for it. For instance for my industrial ultrasound devices, the software
is in Lisp but in Lisp I can't process 2 x 160M 16 bits words/sec data
streams in real time. So the real time number crunching is done in a FPGA
box connected to the PC by an USB2 (480Mb/s) connection. This kind of setup
is also used in bioinformatics. Another example: the 3D graphic boards chips
are what you get when you write the graphics algorithms in VHDL.
Who wants to write a Lisp machine in VHDL ? I'm sure it will only use a
small part of an FPGA.
...
> Do you know how LW compares to C++ for floating point operations. ACL6
would
> be fine but is quite expensive.
if you use declarations the generated code seems good.
FCWEB 83 > (defun add (a b)
(declare (optimize (speed 3)(debug 0)(safety 0)(space 0)(float
3))
(type double-float a)(type double-float b))
(the double-float (+ a b)))
add
FCWEB 84 > (compile 'add)
add
nil
nil
FCWEB 85 > (disassemble 'add)
20405232:
0: 55 push ebp
1: 89E5 move ebp, esp
3: 83EC14 sub esp, 14
6: C7042445140000 move [esp], 1445
13: 8B7D08 move edi, [ebp+8]
16: DD4704 fldl [edi+4]
19: DD4004 fldl [eax+4]
22: DEC1 faddp st(1), st
24: DD5DF8 fstpl [ebp-8]
27: B500 moveb ch, 0
29: FF1500370E20 call [200E3700] ;
system::box-double-aux
35: DD45F8 fldl [ebp-8]
38: DD5804 fstpl [eax+4]
41: C9 leave
42: C20400 ret 4
You can do this kind of tests with other Lisps if you want to compare. But
as all benchmarks they don't quite reflect the reality (see the other
threads on this subject) so you should try this with parts of your program.
Marc
Rolf Wester <······@ilt.fhg.de> wrote:
: I would be very appreciative for any suggestions?
% info librep
'librep' is a dialect of Lisp, designed to be used both as anextension
language for applications, and for use as a generalprogramming language. It
was originally written to be mostly-compatiblewith Emacs Lisp, but has
subsequently diverged markedly. Its aim is tocombine the best features of
Scheme and Common Lisp and provide anenvironment that is comfortable for
implementing both small and largescale systems. It tries to be a "pragmatic"
programming language.
...