Hello, y'all.
On my last conference, I met someone favoring C++ and expression templates
(he also mentioned the "Lisp as expression template" which was discussed
here recently). I have proposed to him that he should send me some C++
stuff which I would try to redo in CL, and I would send him some CL which
he should try to mimic in C++. Then we would compare the solutions.
Now, I have send him the task below (memoization), but have not yet
received an answer. I would like to know what people here would propose as
a challenge. (It should be something obviously useful, easy to formulate
in CL, but difficult to do in C++.)
Yours, Nicolas.
P.S.: In a talk by Norvig/Pitman which was mentioned here some time ago, a
much more elaborate memoization facility is described. Does anyone know if
the source code available somewhere?
---------------------------------------------------------------------------
A. Challenge for C++:
---------------------
Rather often it happens that some time-intensive function is called very
frequently on relatively few values. (This may happen, for example, in
recursive processes as the computation of binomials or Fibonacci numbers.
In a larger application of mine which solves partial differential equations
I use it on functions which compute finite element data on reference cells
and on a function which returns sample refinements of reference cells.) A
useful technique for accelerating programs in this case is "memoization"
which means storing already computed values in a table and retrieving them
from there if possible.
In Common Lisp, it is easy to construct a language extension which turns an
existing function into a memoized one. Furthermore, it is easy to define a
language extension which immediately constructs memoized functions.
CL Code: (17 Lines, with 2 lines comments)
--------
(defun memoize-symbol (funsym)
"Memoizes the function named by the given symbol."
(let ((unmemoized (symbol-function funsym))
(table (make-hash-table :test #'equalp)))
(setf (symbol-function funsym)
#'(lambda (&rest args)
(multiple-value-bind (value found)
(gethash args table)
(if found
value
(setf (gethash args table)
(apply unmemoized args))))))))
(defmacro defmemo (name &rest rest)
"Like defun, but constructs a memoized function."
`(progn
(defun ,name ,@rest)
(memoize-symbol ',name)))
Examples of usage:
------------------
* (defun fib (n) ; unmemoized variant
(case n
(0 0) (1 1)
(t (+ (fib (- n 1))
(fib (- n 2))))))
COMMON-LISP::FIB
* (time (fib 35))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
; Evaluation took:
; 5.16 seconds of real time
; 5.16 seconds of user run time
; 0.0 seconds of system run time
; 0 page faults and
; 0 bytes consed.
;
9227465
* (memoize-symbol 'fib) ; memoize it
* (time (fib 35))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
; Evaluation took:
; 0.0 seconds of real time
; 0.0 seconds of user run time
; 0.0 seconds of system run time
; 0 page faults and
; 552 bytes consed.
;
9227465
* ;;; Evaluate (time (fib 100))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
; Evaluation took:
; 0.0 seconds of real time
; 0.0 seconds of user run time
; 0.0 seconds of system run time
; 0 page faults and
; 7,080 bytes consed.
;
354224848179261915075
* (defmemo binomial (n k) ; binomial is constructed memoized
(when (or (minusp n) (minusp k))
(error "Arguments out of range."))
(if (or (= k 0) (= k n))
1
(+ (binomial (1- n) (1- k))
(binomial (1- n) k))))
* (time (binomial 30 15))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
; Evaluation took:
; 0.0 seconds of real time
; 0.0 seconds of user run time
; 0.0 seconds of system run time
; 0 page faults and
; 16 bytes consed.
;
155117520
*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Task: Write the "defmemo"-utility for C++. Note that CL's "defmemo" can
handle an arbitrary number of arguments. Furthermore, the arguments need
not be integers (e.g. strings are handled as well).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
B. Challenge for CL:
... coming soon ...
In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
<·············@iwr.uni-heidelberg.de> wrote:
> I would like to know what people here would propose as
> a challenge. (It should be something obviously useful, easy to formulate
> in CL, but difficult to do in C++.)
Compute the following:
1000!/999!
999!/1000!*1000
sqrt(-1)^sqrt(-1)-exp(-pi/2) ; result should be 0
E.
Erann Gat wrote:
> sqrt(-1)^sqrt(-1)-exp(-pi/2) ; result should be 0
Small correction:
FS-pi/2$i*pi$$
Clisp gives:
[1]> (- (* (sqrt -1) (sqrt -1)) (exp (* #c(0 1) pi)))
#C(0.0L0 5.0165576136843360246L-20)
Close enough for most purposes, but not /exactly/ correct.
A bug?
GCL fares a lot better:
>(- (* (sqrt -1) (sqrt -1)) (exp (* #c(0 1) pi)))
#C(0.0 0.0)
> E.
Le Hibou
--
In any large organization, mediocrity is almost by definition
an overwhelming phenomenon; the systematic disqualification
of competence, however, is the managers' own invention, for
the sad consequences of which they should bear the full blame.
-- Edsger W. Dijkstra, 1986.
In article <·················@enterprise.net>, Donald Fisk
<················@enterprise.net> wrote:
> Erann Gat wrote:
>
> > sqrt(-1)^sqrt(-1)-exp(-pi/2) ; result should be 0
>
> Small correction:
>
> FS-pi/2$i*pi$$
I can't make heads not tail of that, but I meant what I wrote:
(i^i)-exp(-pi/2), i.e.:
(- (expt (sqrt -1) (sqrt -1)) (exp (/ pi -2))) ; should be 0
E.
> Clisp gives:
>
> [1]> (- (* (sqrt -1) (sqrt -1)) (exp (* #c(0 1) pi)))
> #C(0.0L0 5.0165576136843360246L-20)
>
> Close enough for most purposes, but not /exactly/ correct.
> A bug?
>
> GCL fares a lot better:
>
> >(- (* (sqrt -1) (sqrt -1)) (exp (* #c(0 1) pi)))
> #C(0.0 0.0)
>
> > E.
>
> Le Hibou
Erann Gat wrote:
>
> In article <·················@enterprise.net>, Donald Fisk
> <················@enterprise.net> wrote:
>
> > Erann Gat wrote:
> >
> > > sqrt(-1)^sqrt(-1)-exp(-pi/2) ; result should be 0
> >
> > Small correction:
> >
> > FS-pi/2$i*pi$$
>
> I can't make heads not tail of that,
Teco: FSx$y$$ = replace x with y.
> but I meant what I wrote:
> (i^i)-exp(-pi/2), i.e.:
>
> (- (expt (sqrt -1) (sqrt -1)) (exp (/ pi -2))) ; should be 0
I should have read this more carefully. I misread ^ as
multiplication. Sorry.
Now, CLisp gives -3.2439962E-9
and GCL gives #C(0.0 1.9993932098770811E-17)
Le Hibou
--
In any large organization, mediocrity is almost by definition
an overwhelming phenomenon; the systematic disqualification
of competence, however, is the managers' own invention, for
the sad consequences of which they should bear the full blame.
-- Edsger W. Dijkstra, 1986.
> * In message <·················@enterprise.net>
> * On the subject of "Re: Challenges for C++?"
> * Sent on Wed, 19 Feb 2003 19:00:21 +0000
> * Honorable Donald Fisk <················@enterprise.net> writes:
>
> Clisp gives:
>
> [1]> (- (* (sqrt -1) (sqrt -1)) (exp (* #c(0 1) pi)))
> #C(0.0L0 5.0165576136843360246L-20)
>
> Close enough for most purposes,
the error is less than LONG-FLOAT-EPSILON, so we are good.
> but not /exactly/ correct.
Alas, this is a "feature".
CLISP does transcendental computations at the next higher precision
than the arguments so that the result would be correct to all digits.
Now, you pass PI which is a long float and by default has 64 (binary)
digits. SIN extends it to 96 digits (and it is not a good 96-bit
approximation to PI!), does the calculations (in particular, it compares
this extension with the best 96-bit approximation to PI), and then
rounds the result back to 64-bit precision.
Patches are welcome :-)
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Those who can laugh at themselves will never cease to be amused.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
> <·············@iwr.uni-heidelberg.de> wrote:
>
> > I would like to know what people here would propose as
> > a challenge. (It should be something obviously useful, easy to formulate
> > in CL, but difficult to do in C++.)
>
> Compute the following:
>
> 1000!/999!
>
> 999!/1000!*1000
OK, but the answer to this is simply to use a bignum library for C++. I am
more interested in tasks which are important/useful, but for which the
language C++ has fundamental difficulties which can not simply be taken
away by #include "bignum". Things like changing classes at runtime might
be such a thing (maybe somewhat farfetched), probably also exceptions. In
other words: ideal would be useful programs of which C++ minds cannot even
think of.
> sqrt(-1)^sqrt(-1)-exp(-pi/2) ; result should be 0
Is C++/STL support of complex numbers much worse than that of CL?
> E.
Nicolas.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
> > <·············@iwr.uni-heidelberg.de> wrote:
> >
> > > I would like to know what people here would propose as
> > > a challenge. (It should be something obviously useful, easy to formulate
> > > in CL, but difficult to do in C++.)
> >
> > Compute the following:
> >
> > 1000!/999!
> >
> > 999!/1000!*1000
>
> OK, but the answer to this is simply to use a bignum library for C++. I am
> more interested in tasks which are important/useful, but for which the
> language C++ has fundamental difficulties which can not simply be taken
> away by #include "bignum". Things like changing classes at runtime might
> be such a thing (maybe somewhat farfetched), probably also exceptions. In
> other words: ideal would be useful programs of which C++ minds cannot even
> think of.
Do you get a seamless move from fixed-length numbers to bignums in
C++? That's what so damned convenient. "Oh, look, this no longer fits
in an x-bit integer, let's make it a bignum" "Oh, look, this here
bignum can now become a fixnum".
//Ingvar
--
My posts are fair game for anybody who wants to distribute the countless
pearls of wisdom sprinkled in them, as long as I'm attributed.
-- Martin Wisse, in a.f.p
"Nicolas Neuss" <·············@iwr.uni-heidelberg.de> wrote in message
···················@ortler.iwr.uni-heidelberg.de...
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas Neuss
> > <·············@iwr.uni-heidelberg.de> wrote:
> >
> > > I would like to know what people here would propose as
> > > a challenge. (It should be something obviously useful, easy to formulate
> > > in CL, but difficult to do in C++.)
> >
> > Compute the following:
> >
> > 1000!/999!
> >
> > 999!/1000!*1000
>
> OK, but the answer to this is simply to use a bignum library for C++. I am
> more interested in tasks which are important/useful, but for which the
> language C++ has fundamental difficulties which can not simply be taken
> away by #include "bignum". Things like changing classes at runtime might
> be such a thing (maybe somewhat farfetched), probably also exceptions. In
> other words: ideal would be useful programs of which C++ minds cannot even
> think of.
Try the most basic of Lisp development paradigms, the Lisp Listener.
The ability to interactively and incrementaly program a solution. The equivalent
in C++ would to be take an isolated class, code and test it independently
of supporting (called) classes and functions. All this without creating an test executable
and invoking a debugger.
Wade
In article <························@news2.telusplanet.net>, Wade
Humeniuk wrote:
> "Nicolas Neuss" <·············@iwr.uni-heidelberg.de> wrote in
> message ···················@ortler.iwr.uni-heidelberg.de...
>> ···@jpl.nasa.gov (Erann Gat) writes:
>>
>> > In article <··············@ortler.iwr.uni-heidelberg.de>, Nicolas
>> > Neuss <·············@iwr.uni-heidelberg.de> wrote:
>> >
>> > > I would like to know what people here would propose as a
>> > > challenge. (It should be something obviously useful, easy to
>> > > formulate in CL, but difficult to do in C++.)
[snip factorial discussion]
>
> Try the most basic of Lisp development paradigms, the Lisp Listener.
> The ability to interactively and incrementaly program a solution.
> The equivalent in C++ would to be take an isolated class, code and
> test it independently of supporting (called) classes and functions.
> All this without creating an test executable and invoking a
> debugger.
I don't think this qualifies. I found two[1] C/C++ interpreters[2] in
five minutes of Googling. I haven't used (or even downloaded) either
one, but they both appear to support a read/eval/print loop.
Your task (or rather, the difficulty thereof) seems to me to depend on
a particular implementation of C++ rather than a problem of the
language itself.
-- Larry
[1] http://www.softintegration.com, http://root.cern.ch/root/Cint.html
[2] Neither claims to implement 100% of C++, but I'd consider that a
mere implementation detail.
--
Larry Clapp / ·····@theclapp.org
Use Lisp from Vim: VILisp: http://vim.sourceforge.net/script.php?script_id=221
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
In article <····················@theclapp.ddts.net>, Larry Clapp wrote:
> [2] Neither claims to implement 100% of C++, but I'd consider that a
> mere implementation detail.
Of course, on the other hand, the entire exercise is "a mere
implementation detail". *shrug*
--
Larry Clapp / ·····@theclapp.org
Use Lisp from Vim: VILisp: http://vim.sourceforge.net/script.php?script_id=221
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
"Larry Clapp" <·····@theclapp.org> wrote in message ·························@theclapp.ddts.net...
> In article <························@news2.telusplanet.net>, Wade
>
> I don't think this qualifies. I found two[1] C/C++ interpreters[2] in
> five minutes of Googling. I haven't used (or even downloaded) either
> one, but they both appear to support a read/eval/print loop.
>
> Your task (or rather, the difficulty thereof) seems to me to depend on
> a particular implementation of C++ rather than a problem of the
> language itself.
Well there you go, reduce the problem to implementing a C++
syntaxed eval (with or without compilation). Eval is useful, isn't
it??
Wade
"Wade Humeniuk" <····@nospam.nowhere> writes:
>
> Try the most basic of Lisp development paradigms, the Lisp Listener.
> The ability to interactively and incrementaly program a solution. The equivalent
> in C++ would to be take an isolated class, code and test it independently
> of supporting (called) classes and functions. All this without creating an test executable
> and invoking a debugger.
You are aware that C++ Interpreters are out there? Among others Cint
or CH...
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> You are aware that C++ Interpreters are out there? Among others Cint
> or CH...
They interpret languages "like" C++. The FAQs for both languages make
it clear that being full C++ interpreters is not one of their goals.
Of course, this is perfectly reasonable, considering the difficulty
of finding a 100% compliant C++ compiler, but it should be pointed
out that getting a full C++ interpreter is apparently beyond what
anyone can do right now.
--
Alan Shutko <···@acm.org> - In a variety of flavors!
Looking for a developer in St. Louis? http://web.springies.com/~ats/
I'm not laughing at you, I'm laughing with you!
Alan Shutko <···@acm.org> writes:
> Of course, this is perfectly reasonable, considering the difficulty
> of finding a 100% compliant C++ compiler, but it should be pointed
> out that getting a full C++ interpreter is apparently beyond what
> anyone can do right now.
I can just see it:
C++> int foo (int x) {
if (x > minimum)
do_something(x);
return x;
}
// Function int foo (int x) defined.
C++> foo(3);
// Unbound function do_something
C++> #define do_something(var) do { var += 1; var *= 3 } while (0)
OUCH!
* Nicolas Neuss wrote:
> OK, but the answer to this is simply to use a bignum library for C++. I am
> more interested in tasks which are important/useful, but for which the
> language C++ has fundamental difficulties which can not simply be taken
> away by #include "bignum". Things like changing classes at runtime might
> be such a thing (maybe somewhat farfetched), probably also exceptions. In
> other words: ideal would be useful programs of which C++ minds cannot even
> think of.
How about: take a fairly substantial system written in
<language-of-choice> with many 10s of classes at least. While this
system is running - many instances should exist - load a patch which
dynamically alters the class graph, adding or removing classes as well
as changing inheritance, adding or removing slots from some classes
and defining new methods. Have this work (define what `work' means).
(Careful: in multithreaded CLs you probably need to `passivise' the
system before doing this - I don't think it's defined what happens if,
say, a GF call is in progress while the effective method gets
changed).
As to why this is relevant: trading system (say) which needs to be up
all the time.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> (Careful: in multithreaded CLs you probably need to `passivise' the
> system before doing this - I don't think it's defined what happens if,
> say, a GF call is in progress while the effective method gets
> changed).
Be even more careful: Such conflicts can even occur in single-threaded
systems. Say, a method is replaced while it is executed on the same call
stack. This can be particularly nasty if it is a long-running method...
(But these are problems that you can't even think of in C++... ;)
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
Tim Bradshaw wrote:
> * Nicolas Neuss wrote:
>
>>OK, but the answer to this is simply to use a bignum library for C++. I am
>>more interested in tasks which are important/useful, but for which the
>>language C++ has fundamental difficulties which can not simply be taken
>>away by #include "bignum". Things like changing classes at runtime might
>>be such a thing (maybe somewhat farfetched), probably also exceptions. In
>>other words: ideal would be useful programs of which C++ minds cannot even
>>think of.
>
>
> How about: take a fairly substantial system written in
> <language-of-choice> with many 10s of classes at least. While this
> system is running - many instances should exist - load a patch
<snip>
>
> As to why this is relevant: trading system (say) which needs to be up
> all the time.
I was thinking about patching a satellite billyuns of miles out in
space. :) Or do they just reboot?
And I was /really/ thinking about the value of this during development.
It actually took me a very long time (because I work in isolation in a
cave high up the west side of a rock) before I tried restarting from a
backtrace after fixing a bug. And because I like to refactor, that can
indeed involve radical changes to the class hierarchy.
A word from our sponsor: Cells actually defeat this if I have changed a
Cell rule, but that would be fixable with a little effort. Hey, it's
Lisp, everything is fixable.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> How about: take a fairly substantial system written in
> <language-of-choice> with many 10s of classes at least. While this
> system is running - many instances should exist - load a patch which
> dynamically alters the class graph, adding or removing classes as well
> as changing inheritance, adding or removing slots from some classes
> and defining new methods. Have this work (define what `work' means).
This would take but some careful system design, I think. The following
tools should get you there:
1. Dynamic link libraries.
2. Abstract interfaces to class objects, in the manner of COM.
3. A C++ based OODB system to save and recall the objects, as
well as characterize the class changes.
4. A dynamic-upgrade layer which establishes the protocols to control
access to the relevant objects while they are being upgraded.
Alan
"Alan Baljeu" <·······@sympatico.deleteme.ca> wrote in message news:<····················@news20.bellglobal.com>...
> "Tim Bradshaw" <···@cley.com> wrote in message
> ····················@cley.com...
> > How about: take a fairly substantial system written in
> > <language-of-choice> with many 10s of classes at least. While this
> > system is running - many instances should exist - load a patch which
> > dynamically alters the class graph, adding or removing classes as well
> > as changing inheritance, adding or removing slots from some classes
> > and defining new methods. Have this work (define what `work' means).
> This would take but some careful system design, I think. The following
> tools should get you there:
> 1. Dynamic link libraries.
Nonstandard, nonportable, awkward to use in C, much more awkward from
C++.
Loading a module is a standard ANSI Lisp feature.
> 2. Abstract interfaces to class objects, in the manner of COM.
COM is not an abstract interface to class objects, but a glorified C++
wrapper for the Win32 LoadLibrary function that has been combined with
crude remote procedure calling, and hyped as language-independent.
COM is statically typed; if you have an interface pointer, all the
functions have to be callable, even if to return the ``not
implemented'' result.
> 3. A C++ based OODB system to save and recall the objects, as
> well as characterize the class changes.
Tim is talking about redefining parts of the running software, like
classes and methods, not about a database for persisting objects! No
database is involved, just loading a piece of compiled Lisp into the
active image.
> 4. A dynamic-upgrade layer which establishes the protocols to control
> access to the relevant objects while they are being upgraded.
All of this already could take years, and still doesn't actually meet
the challenge; you are piling hacks on top of each other to make it
look like you can redefine classes dynamically, but you really can't.
It would take months for someone to understand your hacks in order to
actually write a ``class'' that conforms to them. He or she could not
just write a normal C++ class.
Remember, every race has a cutoff! For this particular challenge, I
would set the cutoff to a generous four weeks, after which any works
in progress are simply declared DNF.
Okay, I concede that this would be a mess. However, let me debate a
couple points.
> > 1. Dynamic link libraries.
> Nonstandard, nonportable, awkward to use in C, much more awkward from
> C++.
>
> Loading a module is a standard ANSI Lisp feature.
Not standardized, true. But I never had any difficulty using either
VC++ or gcc to build .dll or .so on their respective platforms.
Lisp standardized module loading is source-portable only right? You
can't load a module built by another Lisp into yours, right? In
the same way, C++ importing is no harder than C importing, provided
you're using the same compiler. LISP can't import C++ modules
unless they provide C protocols (and of course this is non-portable),
and C++ can't load LISP modules unless they provide C protocols.
It's about even to me.
>
> > 2. Abstract interfaces to class objects, in the manner of COM.
>
> COM is not an abstract interface to class objects, but a glorified C++
> wrapper for the Win32 LoadLibrary function that has been combined with
> crude remote procedure calling, and hyped as language-independent.
>
> COM is statically typed; if you have an interface pointer, all the
> functions have to be callable, even if to return the ``not
> implemented'' result.
Ignore the hype. All that's really there is
1. Standard C++ calling convention (virtual function table).
2. Memory allocation protocols between modules.
3. Universal class identifiers.
You don't need Microsoft COM to do this. You just need C++ and DLL's.
Everything else is trivial. (COM also provides interprocess marshalling,
but we don't need that here.)
Using an interface protocol means you can
1. create a new object of a new class, and replace the old
object of the old class.
2. define a new improved interface on the new class. The
old interface is still functional until you upgrade the calling
module. The upgraded calling module will use the new interface.
3. To complete the transition, you'll need to write a conversion function
in the object server which replaces the old objects with new objects.
Voila! You've upgraded your running system.
In conclusion:
a) It's more work than CLOS dynamic changes
b) It won't take years, only weeks.
Alan
* Alan Baljeu wrote:
> Lisp standardized module loading is source-portable only right? You
> can't load a module built by another Lisp into yours, right?
Lisp *as a language* specifies how you can take a file of source code,
compile it and load the resulting binary into the system. C++ *as a
language* does not.
There are three standard tricks to get around limitations like these:
1. Specify additional standards (C++ + POSIX + ...);
2. Specify an implementation (gcc, ...);
3. Write a huge amount of code to implement stuff;
1 and 2 are known as `cheating', 3 is known as greenspunning.
There's no question that you can do anything `in C++', the issue is
how much of 1-3 above do you need to do to do it. In this case that
the answer is `rather a lot'.
--tim
* Alan Baljeu wrote:
> This would take but some careful system design, I think. The following
> tools should get you there:
> 1. Dynamic link libraries.
> 2. Abstract interfaces to class objects, in the manner of COM.
> 3. A C++ based OODB system to save and recall the objects, as
> well as characterize the class changes.
> 4. A dynamic-upgrade layer which establishes the protocols to control
> access to the relevant objects while they are being upgraded.
Yes, something like that. Greenspun's 10th clearly applies.
--tim
Nicolas Neuss <·············@iwr.uni-heidelberg.de> wrote in message news:<··············@ortler.iwr.uni-heidelberg.de>...
> In Common Lisp, it is easy to construct a language extension which turns an
> existing function into a memoized one. Furthermore, it is easy to define a
> language extension which immediately constructs memoized functions.
>
> CL Code: (17 Lines, with 2 lines comments)
> --------
>
> (defun memoize-symbol (funsym)
> "Memoizes the function named by the given symbol."
> (let ((unmemoized (symbol-function funsym))
> (table (make-hash-table :test #'equalp)))
> (setf (symbol-function funsym)
> #'(lambda (&rest args)
> (multiple-value-bind (value found)
> (gethash args table)
> (if found
> value
> (setf (gethash args table)
> (apply unmemoized args))))))))
>
> (defmacro defmemo (name &rest rest)
> "Like defun, but constructs a memoized function."
> `(progn
> (defun ,name ,@rest)
> (memoize-symbol ',name)))
In the Meta-CVS project, I developed a ``deluxe'' memoization package.
This was when I thought it was a great idea, and didn't look around to
see ``whodunit'' before me. ;) It's completely overblown, given that I
use it in only one place, to memoize a longest common subsequence
function, which is in turn used in only one place.
This module provides two macros: define-memoized-function and
memoized-labels. The memoization takes place over one or more
parameters, and this is handled using cascaded hash tables---which are
in turn provided by a ``multi hash'' datatype that I implemented from
scratch. Again, overblown: only the memoization module uses it! ;)
A multihash is like a regular hash, but multidimensional; you can have
more than one key, each associated with its own test function.
My macros extend the lambda list syntax, allowing you to annotate each
parameter with the desired test function to use for memoizing it:
(define-memoized-function foo ((x #'eq)
&optional (y "foo" #'equal)
&rest blah)
;; use EQ for X parameter, and EQUAL for optional Y parameter,
;; whose default value is "foo".
...)
This actually generates top-level function called FOO whose lambda
list looks normal---the test annotations are removed:
(defun foo (x &optional (y 42) &rest blah)
and it contains an inner function that handles the recursion, but has
a simplified lambda list without any &rest or &key stuff, and optional
elements replaced by non-optional ones:
(let (.. hash table stuff ...
.. test annotations factored into here ...)
(labels ((foo (x y) (.. logic for memoization ( .. your body ) )))
(foo x y))))
There is a common transformer which does the work for both the
top-level version and the labels version. Mutual recursion is achieved
in the labels vesrion by taking the list of individual labels forms,
and then factoring out the hash tables to make one giant LET, and
fusing the functions into one giant LABELS construct.
It's quite a piece of macrology; last week I tried to read it, and
ended up inserting a big docstring into every function and macro so I
would not ever have to reverse engineer it again. ;)
All that work just so I could compute the distance between two path
names by determining the length of their longest common subsequence of
components.
I think that translating this to C++ would be an even more challenging
exercise.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> P.S.: In a talk by Norvig/Pitman which was mentioned here some time
> ago, a much more elaborate memoization facility is described. Does
> anyone know if the source code available somewhere?
The original version from PAIP is here:
<http://www.norvig.com/paip/auxfns.lisp>
I seem to remember that the examples directory of Corman Lisp contains
a more elaborate version by Tim Bradshaw. As you'll know, Corman Lisp
is downloadable from:
<http://www.cormanlisp.com/download.html>
Cheers,
Edi.
Edi Weitz <···@agharta.de> writes:
> Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> > P.S.: In a talk by Norvig/Pitman which was mentioned here some time
> > ago, a much more elaborate memoization facility is described. Does
> > anyone know if the source code available somewhere?
>
> <a couple memoization implementations omitted>
There's also one called "Monterrey Memoization" because it was
presented at a the Sixth International Symposium on AI, Monterrey
Mexico, September 1993. If you use Google on Monterrey Memoization
you'll find numerous pointers.
It is a complete macro package with a nice documented interface.
--
Fred Gilham ······@csl.sri.com
[Some of the] Top ten reasons why the God of Jesus Christ makes a
better God than `Caesar':
7. God doesn't circulate worthless chunks of metal or paper with `In
Caesar we trust' written on them.
5. God only wants 10%.
4. God has fewer laws.
2. God has a better retirement plan.
1. Caesar wants you to send your sons to die for him. God sent his
Son to die for you.
Edi Weitz <···@agharta.de> writes:
> Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
>
> > P.S.: In a talk by Norvig/Pitman which was mentioned here some time
> > ago, a much more elaborate memoization facility is described. Does
> > anyone know if the source code available somewhere?
>
> The original version from PAIP is here:
>
> <http://www.norvig.com/paip/auxfns.lisp>
There is also a paper on memoization by Norvig at:
http://acl.ldc.upenn.edu/J/J91/J91-1004.pdf
> I seem to remember that the examples directory of Corman Lisp contains
> a more elaborate version by Tim Bradshaw.
There is also a much more elaborate memoization example that is on Marty
Hall's site (along with documentation):
http://www.apl.jhu.edu/~hall/lisp/Memoization/
--
Bill Clementson
On Thu, 20 Feb 2003 00:59:05 GMT, Bill Clementson <·······@attbi.com>
wrote:
> There is also a much more elaborate memoization example that is on Marty
> Hall's site (along with documentation):
>
> http://www.apl.jhu.edu/~hall/lisp/Memoization/
That code is now maintained as part of CLOCC:
http://clocc.sourceforge.net
Paolo
--
Paolo Amoroso <·······@mclink.it>
Edi Weitz <···@agharta.de> writes:
> Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
>
> > P.S.: In a talk by Norvig/Pitman which was mentioned here some time
> > ago, a much more elaborate memoization facility is described. Does
> > anyone know if the source code available somewhere?
>
> The original version from PAIP is here:
>
> <http://www.norvig.com/paip/auxfns.lisp>
There is also a paper on memoization by Norvig at:
http://acl.ldc.upenn.edu/J/J91/J91-1004.pdf
> I seem to remember that the examples directory of Corman Lisp contains
> a more elaborate version by Tim Bradshaw.
There is also a much more elaborate memoization example that is on Marty
Hall's site (along with documentation):
http://www.apl.jhu.edu/~hall/lisp/Memoization/
--
Bill Clementson
This is a multi-part message in MIME format.
--------------020804090900070107090300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Nicolas Neuss wrote:
> Hello, y'all.
>
> On my last conference, I met someone favoring C++ and expression templates
> (he also mentioned the "Lisp as expression template" which was discussed
> here recently). I have proposed to him that he should send me some C++
> stuff which I would try to redo in CL, and I would send him some CL which
> he should try to mimic in C++. Then we would compare the solutions.
>
> Now, I have send him the task below (memoization), but have not yet
> received an answer. I would like to know what people here would propose as
> a challenge. (It should be something obviously useful, easy to formulate
> in CL, but difficult to do in C++.)
What about this one?
Provide some basic support for AOP - before/after/around advice on
functions. See attachment.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
--------------020804090900070107090300
Content-Type: text/plain;
name="defunq.lisp"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="defunq.lisp"
(defmacro defunq (fun-name qualifier (&rest original-args) &body body)
(let ((original-fun (gensym "ORGFUN")))
(ccase qualifier
(:around (let ((new-args (gensym)))
`(let ((,original-fun #',fun-name))
(defun ,fun-name ,original-args
(flet ((call-next-fun (&rest ,new-args)
(if ,new-args
(apply ,original-fun ,new-args)
(funcall ,original-fun ,@original-args))))
,@body)))))
(:before `(let ((,original-fun #',fun-name))
(defun ,fun-name ,original-args
,@body
(funcall ,original-fun ,@original-args))))
(:after `(let ((,original-fun #',fun-name))
(defun ,fun-name ,original-args
(multiple-value-prog1
(funcall ,original-fun ,@original-args)
,@body)))))))
--------------020804090900070107090300--
On 19 Feb 2003 17:13:16 +0100, Nicolas Neuss
<·············@iwr.uni-heidelberg.de> wrote:
> Rather often it happens that some time-intensive function is called very
> frequently on relatively few values. (This may happen, for example, in
> recursive processes as the computation of binomials or Fibonacci numbers.
> In a larger application of mine which solves partial differential equations
> I use it on functions which compute finite element data on reference cells
> and on a function which returns sample refinements of reference cells.) A
Maybe also in dynamic programming.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Nicolas Neuss wrote:
> Now, I have send him the task below (memoization), but have not yet
> received an answer. I would like to know what people here would propose as
> a challenge. (It should be something obviously useful, easy to formulate
> in CL, but difficult to do in C++.)
Something that uses multiple dispatch in CL. Say, a fragment
of a geometrical modelling program that needs to compute the
intersection of a pair of shapes.
(defmethod intersection ((x rectangle) (y rectangle))
...)
(defmethod intersection ((x circle) (y circle))
...)
and so on. It's somewhat tiresome in any language, but it's
much worse in C++ than in CL. By the way, the code above would
need to be in its own package that shadows INTERSECTION. :-)
*
A program that uses EVAL or COMPILE. For instance, say you're
a number theorist and you're interested in finding prime numbers
in particular sequences. Then you might want a program that you
interact with like this:
Enter an expression in terms of N: (1+ (* n n))
Primes of the form (1+ (* n n)):
n=1, p=2
n=2, p=5
n=4, p=17
n=6, p=37
There are <however many it is> primes of this form with 0<=n<1000.
In C++ you'd need to write an expression parser. That isn't
all that hard, but it's completely unnecessary in CL. And in CL
you can compile the function at run time and get much better
performance than is likely to be feasible in C++ without
seriously hairy and unportable tricks.
--
Gareth McCaughan ················@pobox.com
.sig under construc
Nicolas Neuss asked for:
> a challenge. (It should be something obviously useful, easy to formulate
> in CL, but difficult to do in C++.)
Gareth McCaughan suggested:
> A program that uses EVAL or COMPILE.
Or, similarly, a program that manipulates and then executes code on
the fly. My favorite here would be a genetic programming example (see
http://www.genetic-programming.org). Lisp is natural for this kind of
taskboth because it is easy to "crossover" two syntactically valid
programs and get another syntactically valid program, and because you
can then COMPILE and EVAL the generated result without having to write
your own parser.
Larry
--
Lawrence Hunter, Ph.D.
Director, Center for Computational Pharmacology
Associate Professor of Pharmacology, PMB & Computer Science
phone +1 303 315 1094 UCHSC, Campus Box C236
fax +1 303 315 1098 School of Medicine rm 2817b
cell +1 303 324 0355 4200 E. 9th Ave.
email: ············@uchsc.edu Denver, CO 80262
PGP key on public keyservers http://compbio.uchsc.edu/hunter
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Hello, y'all.
>
> On my last conference, I met someone favoring C++ and expression templates
> (he also mentioned the "Lisp as expression template" which was discussed
> here recently). I have proposed to him that he should send me some C++
> stuff which I would try to redo in CL, and I would send him some CL which
> he should try to mimic in C++. Then we would compare the solutions.
>
> Now, I have send him the task below (memoization), but have not yet
> received an answer.
You're not nice. :-)
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie
Nicolas Neuss <·············@iwr.uni-heidelberg.de> wrote in message news:<··············@ortler.iwr.uni-heidelberg.de>...
> received an answer. I would like to know what people here would propose as
> a challenge.
Here is a challenge.
Write an ANSI C++ program that accepts from the user a piece of text
representing some kind of computational formula: it could be
arithmetic, or a regular expression for pattern matching, a logic
proposition, whatever.
The C++ program must parse the formula, translate it to some
intermediate representation such as an abstract syntax tree, and then
compile it to some efficient form. On at least one C++ implementation
and run-time platform, chosen by the programmer, this form should be
native machine language.
It must then executing that compiled code in the same program image,
which evaluates the formula. The result of the evaluation is printed
back to the user. The intermediate representation as well as the
disassembled code is also printed to the user to show how the formula
was translated.
No I/O should be used other than to read the formula and print the
result, and no external program may be run (assuming that some tool
can be accessed via system() wouldn't be standard C++ anyway).
> Write an ANSI C++ program that accepts from the user a piece of text
> representing some kind of computational formula: it could be
> arithmetic, or a regular expression for pattern matching, a logic
> proposition, whatever.
>
> The C++ program must parse the formula, translate it to some
> intermediate representation such as an abstract syntax tree, and then
> compile it to some efficient form. On at least one C++ implementation
> and run-time platform, chosen by the programmer, this form should be
> native machine language.
>
> It must then executing that compiled code in the same program image,
> which evaluates the formula. The result of the evaluation is printed
> back to the user. The intermediate representation as well as the
> disassembled code is also printed to the user to show how the formula
> was translated.
>
> No I/O should be used other than to read the formula and print the
> result, and no external program may be run (assuming that some tool
> can be accessed via system() wouldn't be standard C++ anyway).
Well, this would be difficult in C++ no doubt, but it's an artificial
challenge. A typical C++ program would have _no_ need for such a thing,
nor in fact would a LISP program*. However if it was needed, one could
build Python as a linked-in library, and make a call.
* Okay, a LISP program uses such capabilities all the time. But I think
you need a concrete scenario of using this, which would be hard to
imitate in C++ without it. Otherwise, run-time compilation is perceived
as a gee-whiz gizmo instead of a valuable tool.
To half answer, I suggest that for most purposes, run-time code generation
is just a convenience that allows you to avoid writing things like
if (...)
{
...
}
else if (...)
{
...
}
else if (...)
{
...
}
else if (...)
{
...
}
....
in a few places. I challenge you to find a practical example where it does
more.
Alan
From: Christopher C. Stacy
Subject: Re: Challenges for C++?
Date:
Message-ID: <ur8a0the4.fsf@dtpq.com>
Maybe the programs one writes in C++ are typically solving problems in
a different way than in LISP. Maybe one way lends itself more to
faster, more maintainable solutions to problems. Maybe one way lends
itself more towards solving "impossibly difficult" problems.
"Christopher C. Stacy" <······@dtpq.com> wrote in message
··················@dtpq.com...
> Maybe the programs one writes in C++ are typically solving problems in
> a different way than in LISP. Maybe one way lends itself more to
> faster, more maintainable solutions to problems. Maybe one way lends
> itself more towards solving "impossibly difficult" problems.
I'll paraphrase this as "maybe LISP is better suited for solving
impossibly difficult problems". Okay, but the goal of this thread
is to make a concrete example where this is true.
My post was more focussed. I'm suggesting that run-time compilation
is not necessarily a necessary tool to effectively solve most problems,
and doesn't significantly improve the solution.
I imagine I'm wrong, and I'm looking for a scenario to demonstrate that.
That scenario, if found, would be genuinely interesting to C++ programmers.
Alan
"Alan Baljeu" <·······@sympatico.deleteme.ca> writes:
[SNIP]
> I imagine I'm wrong, and I'm looking for a scenario to demonstrate that.
> That scenario, if found, would be genuinely interesting to C++ programmers.
Interactive graphing of user-defined functions? It's a narrow(ish)
field, but most certainly useful. See Matlab and similar stuff.
Where else would it be useful? I can see it being damned useful in
interactive development of movement functions and character AI in
computer game development and I can also see interactive development
being useful (as opposed to "edit code, recompile, re-launch image,
observe behaviour").
//Ingvar
--
"No. Most Scandiwegians use the same algorithm as you Brits.
"Ingvar is just a freak."
Stig Morten Valstad, in the Monastery
"Alan Baljeu" <·······@sympatico.deleteme.ca> wrote in message news:<·······················@news20.bellglobal.com>...
> My post was more focussed. I'm suggesting that run-time compilation
> is not necessarily a necessary tool to effectively solve most problems,
> and doesn't significantly improve the solution.
Your opinion is noted, but I'm glad that my text editor lets me type a
complex search pattern, and then executes it.
In article <·······················@news20.bellglobal.com>,
"Alan Baljeu" <·······@sympatico.deleteme.ca> wrote:
>My post was more focussed. I'm suggesting that run-time compilation
>is not necessarily a necessary tool to effectively solve most problems,
>and doesn't significantly improve the solution.
>
>I imagine I'm wrong, and I'm looking for a scenario to demonstrate that.
>That scenario, if found, would be genuinely interesting to C++ programmers.
I'm not convinced you would recognize that scenario would it be
presented to you. This is not a knock at you personally, but
rather reflects my general belief that programming languages
work like Kuhnian worldviews. They structure how their adherents
think about computation, including which kinds of computation they
dismiss as contrived and which represent genuine anomalies.
For example, when presented with a computation that is easy in
Lisp but difficult in C++, you wrote:
In article <······················@news20.bellglobal.com>,
"Alan Baljeu" <·······@sympatico.deleteme.ca> wrote:
>Well, this would be difficult in C++ no doubt, but it's an artificial
>challenge. A typical C++ program would have _no_ need for such a thing,
>nor in fact would a LISP program*.
When presented with several illustrations of the utility of such
computation, you retreated to:
In article <····················@news20.bellglobal.com>,
"Alan Baljeu" <·······@sympatico.deleteme.ca> wrote:
>Sounds useful alright. Of course, you better make sure the passed in
>filter code isn't
>(progn
> (delete-all-local-files)
> (send-usenet-message :address "comp.lang.lisp"
> :subject "LISP SUCKS!"
> :body "...."))
> (loop forever))
This is a reasonable problem, but of course there are well-known
solutions in the Lisp community.
So now you have retreated from not granting the legitimacy of
a computation handled awkwardly (at best) in C++ to understanding
its utility, but complaining about problems of the naive solution
in Lisp. When these are remedied for you, will you reflect on
the holes in C++'s computational worldview, some of which are
filled by Lisp? Or will you run from these genuine anomalies?
"sv0f" <····@vanderbilt.edu> wrote in message
·······························@news.vanderbilt.edu...
> In article <·······················@news20.bellglobal.com>,
> "Alan Baljeu" <·······@sympatico.deleteme.ca> wrote:
>
> >My post was more focussed. I'm suggesting that run-time compilation
> >is not necessarily a necessary tool to effectively solve most problems,
> >and doesn't significantly improve the solution.
> >
> >I imagine I'm wrong, and I'm looking for a scenario to demonstrate that.
> >That scenario, if found, would be genuinely interesting to C++
programmers.
>
> I'm not convinced you would recognize that scenario would it be
> presented to you. This is not a knock at you personally, but
> rather reflects my general belief that programming languages
> work like Kuhnian worldviews. They structure how their adherents
> think about computation, including which kinds of computation they
> dismiss as contrived and which represent genuine anomalies.
Fear not, I'm listening. I've always believed C++ is a kludge of
a language with potholes everywhere. (I'd abandon it if I could,
but FFI is not good enough yet to manage a complete transition.)
I also know that LISP provides many very useful features, including
quality macros, lambda expressions, multiple-dispatch, etc.
You're entirely right that learning a new paradigm is not easy, and
that's why so many out there don't 'get' lisp. I posted to say,
abstract features need concrete examples to demonstrate their
power. I also posted to say, there are ways in C++ which you
might not be aware of. Not that C++ is better than LISP. It's
just "less inferior" than you might guess.
Re: security over foreign code, you wrote:
> This is a reasonable problem, but of course there are well-known
> solutions in the Lisp community.
Any pointers? I'd be interested to know....
> So now you have retreated from not granting the legitimacy of
> a computation handled awkwardly (at best) in C++ to understanding
> its utility, but complaining about problems of the naive solution
> in Lisp. When these are remedied for you, will you reflect on
> the holes in C++'s computational worldview, some of which are
> filled by Lisp? Or will you run from these genuine anomalies?
I don't view this as retreat, but progress. I'm not trying to win
an argument, but to genuinely discuss LISP vs. C++ as they are,
and to discover the truth about what is good or not about each.
My understanding of LISP has grown in the process, and I hope
some people learned a bit of C++.
In this case, you (collectively) have demonstrated a valuable use
of run-time compilation of LISP.
> Re: security over foreign code, you wrote:
> > This is a reasonable problem, but of course there are well-known
> > solutions in the Lisp community.
> Any pointers? I'd be interested to know....
Cancel that request. I just read the sandbox articles.
* Alan Baljeu wrote:
> Any pointers? I'd be interested to know....
I'm not sure there's a publically available technique for safe code
loading because it's simple enough to do that it's not worth a big
library. Typically you do it by defining a safe mini-language (so no
file operations &c &c), then when you read the source check that it
doesn't contain any references to things that aren't in the safe mini
language. This check is not hard since you have access to the data
structure of the source. The major problem with doing this in CL is
that it's hard to make READ be completely safe: in particular you
can't get a handle on the point just before a symbol is interned. In
practice this can cause memory leakage due to lots of symbols being
created that you don't want. Also `safe mini language' does not
include tests for things like non-termination and stack overflow if
you compile this language to CL, although if you write a little
interpreter for it then you can check these things (well: put a bound
on the time and space you can use, anyway).
--tim
"Alan Baljeu" <·······@sympatico.deleteme.ca> writes:
> Well, this would be difficult in C++ no doubt, but it's an artificial
> challenge. A typical C++ program would have _no_ need for such a thing,
> nor in fact would a LISP program*. However if it was needed, one could
> build Python as a linked-in library, and make a call.
OK, so you want an example. Here goes nothin.
Imagine a real time message distribution server (MDS) that keeps a
cache of messages to distribute to client programs running on remote
machines. Clients of MDS can subscribe for changes to particular
messages, and can send their own updates to MDS.
The goal is to allow MDS clients to specify the subscription filter
arbitrarily. MDS handles many thousands of updates per second, and
there are a lot clients, so the filter functions must be fast.
Imagine that I want to see only one out of every ten messages, where
the bid_price >= 100, and the ticker_symbol=IBM, for example. The
important point is that the complexity of the filter function should
be unlimited.
Using Lisp, the subscription protocol could be for clients to send
some Lisp code over the network to MDS. MDS would compile the
subscription functions into machine code, and store the resulting
function into a data structure associated with the client. When an
update happens, MDS runs through the client lisp, funcall'ing these
functions to see who is interested.
People pay big money for stuff like this, only it's a lot less
flexible (Rueters amongst others markets products that do this sort of
thing). Through these commercial products, one can usually only
subscribe based on a regular expression match of a magic field in each
message, called the key. I've often had need of the more general
functionality, but instead have been forced to subscribe to lots of
data that I only have to throw away after running the filter function
in the client. If you are across a WAN, this is a huge lose.
Instead of moving the data to the code, move the code to the data.
Actually, I bet that there is a market opportunity for this sort of
stuff on Wall Street, and that creating a robust and fast real-time
XML message distributor in Lisp would be relatively easy, especially
compared to C++.
-russ
Russell McManus wrote:
> Instead of moving the data to the code, move the code to the data.
Sound bite! Sound bite! :) Good one, too.
The key to me in what you said was that this lets you use filters of
arbitrary complexity. Lotsa folks offered a mini-language, if you will,
of ways to "program" dynamically, and each one of those is implicit
testimony to Lisp.
The CliniSys app beats on "code as data" like it was its Daddy.
Probably one reason folks don't see a need for this feature is that,
never having had it, solutions involving code-as-data never occur to
them, even when the problem cries out for one.
One cannot see what one cannot conceive.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
"Russell McManus" <···············@yahoo.com> wrote in message >
> Imagine a real time message distribution server (MDS) that keeps a
> cache of messages to distribute to client programs running on remote
> machines. Clients of MDS can subscribe for changes to particular
> messages, and can send their own updates to MDS.
....
> Using Lisp, the subscription protocol could be for clients to send
> some Lisp code over the network to MDS. MDS would compile the
> subscription functions into machine code, and store the resulting
> function into a data structure associated with the client. When an
> update happens, MDS runs through the client lisp, funcall'ing these
> functions to see who is interested.
>
Sounds useful alright. Of course, you better make sure the passed in
filter code isn't
(progn
(delete-all-local-files)
(send-usenet-message :address "comp.lang.lisp"
:subject "LISP SUCKS!"
:body "...."))
(loop forever))
It will take a bit of work to filter undesirable code but allow desirable
code. The Ruby language has a "safe mode" dedicated to allowing such
run-time code evaluation and simultaneously preventing stupid stuff. It
might be wiser to spin your own language (which lisp can do well enough), to
avoid these security issues.
Alan
This will need a sandbox. A subset of Lisp would need to be defined,
possibly defining even the symbols which can be referenced.
From what I know, even all that is much simpler in Lisp than in, well,
anything else I know of that would end up with a dynamically-changing
funcallable list of compiled functions. What would one do in C, compile
the dynamic requests into DLL's after the sandbox check? COM, or XPCOM?
Use Lex and Yacc to build the syntax checker? Unload/reload entire DLLs
at a time?
A good sandbox would be useful elsewhere, too. Imagine being able to
send safe Lisp to browsers, maybe making a plug-in out of something like
CLisp.
Russell McManus wrote:
>...
> MDS handles many thousands of updates per second, and
> there are a lot clients, so the filter functions must be fast.
...
> Using Lisp, the subscription protocol could be for clients to send
> some Lisp code over the network to MDS. MDS would compile the
> subscription functions into machine code, and store the resulting
> function into a data structure associated with the client. When an
> update happens, MDS runs through the client lisp, funcall'ing these
> functions to see who is interested.
...
> Actually, I bet that there is a market opportunity for this sort of
> stuff on Wall Street, and that creating a robust and fast real-time
> XML message distributor in Lisp would be relatively easy, especially
> compared to C++.
...
Jeff Caldwell <·····@yahoo.com> writes:
> This will need a sandbox. A subset of Lisp would need to be defined,
> possibly defining even the symbols which can be referenced.
>
> From what I know, even all that is much simpler in Lisp than in,
> well, anything else I know of that would end up with a
> dynamically-changing funcallable list of compiled functions. What
> would one do in C, compile the dynamic requests into DLL's after the
> sandbox check? COM, or XPCOM? Use Lex and Yacc to build the syntax
> checker? Unload/reload entire DLLs at a time?
>
> A good sandbox would be useful elsewhere, too. Imagine being able to
> send safe Lisp to browsers, maybe making a plug-in out of something
> like CLisp.
Good point about security.
Of course one could write a expression parser/compiler pretty easily
in Lisp to provide the necessary safety, and still generate native
machine code. This would not be easy to do in C++.
-russ
Russell McManus wrote:
> Jeff Caldwell <·····@yahoo.com> writes:
>
>
>>This will need a sandbox. A subset of Lisp would need to be defined,
>>possibly defining even the symbols which can be referenced.
>>
>> From what I know, even all that is much simpler in Lisp than in,
>>well, anything else I know of that would end up with a
>>dynamically-changing funcallable list of compiled functions. What
>>would one do in C, compile the dynamic requests into DLL's after the
>>sandbox check? COM, or XPCOM? Use Lex and Yacc to build the syntax
>>checker? Unload/reload entire DLLs at a time?
>>
>>A good sandbox would be useful elsewhere, too. Imagine being able to
>>send safe Lisp to browsers, maybe making a plug-in out of something
>>like CLisp.
>
>
> Good point about security.
On VMS we'd just deny such users any dangerous privileges and let them
code whatever they liked. Lock them in their own directory if they
needed write-access for anything, let them delete themselves only. :)
Can the unices do anything like that?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> Russell McManus wrote:
> > Jeff Caldwell <·····@yahoo.com> writes:
> >
>
> >>This will need a sandbox. A subset of Lisp would need to be defined,
> >>possibly defining even the symbols which can be referenced.
> >>
> >> From what I know, even all that is much simpler in Lisp than in,
> >>well, anything else I know of that would end up with a
> >>dynamically-changing funcallable list of compiled functions. What
> >>would one do in C, compile the dynamic requests into DLL's after the
> >>sandbox check? COM, or XPCOM? Use Lex and Yacc to build the syntax
> >>checker? Unload/reload entire DLLs at a time?
> >>
> >>A good sandbox would be useful elsewhere, too. Imagine being able to
> >>send safe Lisp to browsers, maybe making a plug-in out of something
> >>like CLisp.
> > Good point about security.
>
>
> On VMS we'd just deny such users any dangerous privileges and let them
> code whatever they liked. Lock them in their own directory if they
> needed write-access for anything, let them delete themselves only. :)
>
>
> Can the unices do anything like that?
Not nearly so easily, the closest thing is giving them a jail to
play around in. If you start to play around with the regular system
things can get ugly quickly. The ACL stuff that is becoming mainstream
would help here though. You have to remember Unix is a trust oriented OS,
VMS(I am talking about DEC's) was not as trusting. From what I have read
neither was Multics.
marc
ps I never worked with IBM's VMS OS
>
>
> --
>
> kenny tilton
> clinisys, inc
> http://www.tilton-technology.com/
> ---------------------------------------------------------------
> "Cells let us walk, talk, think, make love and realize
> the bath water is cold." -- Lorraine Lee Cudmore
Marc Spitzer <········@optonline.net> writes:
> ps I never worked with IBM's VMS OS
I have in no way any complete knowledge about IBM systems, but as far
as I know, IBM had (among others) VM and MVS, but no VMS.
Regards,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
>>>>> "mr" == Martin Rydstr|m <rydis> writes:
mr> Marc Spitzer <········@optonline.net> writes:
>> ps I never worked with IBM's VMS OS
mr> I have in no way any complete knowledge about IBM systems, but
mr> as far as I know, IBM had (among others) VM and MVS, but no
mr> VMS.
VMS was a DEC OS used on Vaxen. I've had almost no exposure to it, but
it seemed to have its fans.
--
It's a small world, but I wouldn't want to have to paint it.
-- Steven Wright
Tim Lavoie wrote:
>>>>>>"mr" == Martin Rydstr|m <rydis> writes:
>>>>>
>
> mr> Marc Spitzer <········@optonline.net> writes:
> >> ps I never worked with IBM's VMS OS
>
> mr> I have in no way any complete knowledge about IBM systems, but
> mr> as far as I know, IBM had (among others) VM and MVS, but no
> mr> VMS.
>
> VMS was a DEC OS used on Vaxen. I've had almost no exposure to it, but
> it seemed to have its fans.
count me in there. they came up with a standard FFI for all their
languages, so it was relatively easy to mix and match. The coolest thing
was using it to call VMS system functions -- no matter what language you
used you could do /anything/ the system could do. Only access control
lists (user privileges etc) held you back. DCL was a scripting command
language that in later years got fancy with true subroutines. Even EDT
the editor was cool, with a neat macro capability programmed by "watch me".
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> Tim Lavoie wrote:
> >>>>>>"mr" == Martin Rydstr|m <rydis> writes:
> >>>>>
> > mr> Marc Spitzer <········@optonline.net> writes:
>
> > >> ps I never worked with IBM's VMS OS
> > mr> I have in no way any complete knowledge about IBM systems,
> > but
>
> > mr> as far as I know, IBM had (among others) VM and MVS, but no
> > mr> VMS.
> > VMS was a DEC OS used on Vaxen. I've had almost no exposure to it,
> > but
>
> > it seemed to have its fans.
>
> count me in there. they came up with a standard FFI for all their
> languages, so it was relatively easy to mix and match. The coolest
> thing was using it to call VMS system functions -- no matter what
> language you used you could do /anything/ the system could do. Only
> access control lists (user privileges etc) held you back. DCL was a
> scripting command language that in later years got fancy with true
> subroutines. Even EDT the editor was cool, with a neat macro
> capability programmed by "watch me".
Me too, now if HP would just figure out how to market it and come
up with a good price point they could really screw with MS in the
server space.
marc
From: Christopher C. Stacy
Subject: Re: Challenges for C++?
Date:
Message-ID: <uk7fpgg6k.fsf@dtpq.com>
>>>>> On 24 Feb 2003 16:02:56 -0600, Tim Lavoie ("Tim") writes:
>>>>> "mr" == Martin Rydstr|m <rydis> writes:
mr> Marc Spitzer <········@optonline.net> writes:
>>> ps I never worked with IBM's VMS OS
mr> I have in no way any complete knowledge about IBM systems, but
mr> as far as I know, IBM had (among others) VM and MVS, but no
mr> VMS.
Tim> VMS was a DEC OS used on Vaxen. I've had almost no exposure to
Tim> it, but it seemed to have its fans.
There are probably hundreds, if not thousands, of sites that are
running VMS right at this very moment in time. I think they would
have all switched from VAX to Alpha hardware by now. The last VMS
machine that I programmed (for a telephone company) was purchased
brand new at the very end of 1999. VMS was very popular in the
financial sector, I'm told.
>>>>> "CCS" == Christopher C Stacy <······@dtpq.com> writes:
CCS> There are probably hundreds, if not thousands, of sites that
CCS> are running VMS right at this very moment in time. I think
CCS> they would have all switched from VAX to Alpha hardware by
CCS> now. The last VMS machine that I programmed (for a telephone
CCS> company) was purchased brand new at the very end of 1999.
CCS> VMS was very popular in the financial sector, I'm told.
Cool. I've been a Unix fan for a long time, but then I've seen enough
to be comfortable. The ones I saw were at Environment Canada, but were
slowly getting phased out in favor of NT boxes, while HP workstations
were all over the place, at least in the techie weather area. So what
would the problem with VMS have been? Single-vendor lock-in?
--
You're a good example of why some animals eat their young.
-- Jim Samuels to a heckler
Martin Rydstr|m wrote:
> Marc Spitzer <········@optonline.net> writes:
>
>>ps I never worked with IBM's VMS OS
>
>
> I have in no way any complete knowledge about IBM systems, but as far
> as I know, IBM had (among others) VM and MVS, but no VMS.
right. I meant DEC VMS. I did work with IBMs VM for a year. Once I
learned all that DOS/VSE and JCL crap it was pretty cool.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Marc Spitzer <········@optonline.net> writes:
> ps I never worked with IBM's VMS OS
Few people have. There's IBM's MVS and there's
Dec^WDigital^WCompaq^WHP's VMS.
--
And I'm wilder than her and it drives her out of her mind
I guess she thought that she was just one of a kind
But she's a summer storm and I'm a hurricane
One just blows through town, one blows the town away
Kenny Tilton <·······@nyc.rr.com> writes:
>
> On VMS we'd just deny such users any dangerous privileges and let them
> code whatever they liked. Lock them in their own directory if they
> needed write-access for anything, let them delete themselves only. :)
>
>
> Can the unices do anything like that?
Unix has things like chroot (which means that you'll only be
able to access files below a specific point in the directory) and rsh,
which is a shell that lets you execute only a limited set of
commands. Lately, there's a mechanism called 'jail', which (I think!)
is somewhat more flexible (this may be limited to FreeBSD, *BSD, or
*BSD and Linux).
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
On 8300 day of my life Raymond Wiker wrote:
^^^^
Wow, it is jubilee :)
> Unix has things like chroot (which means that you'll only be
> able to access files below a specific point in the directory) and rsh,
> which is a shell that lets you execute only a limited set of
> commands. Lately, there's a mechanism called 'jail', which (I think!)
> is somewhat more flexible (this may be limited to FreeBSD, *BSD, or
> *BSD and Linux).
AFAIK, jail is chroot jail, which is chroot :)
--
Ivan Boldyrev remove .microsoft.com from my address
PGP fp: 3640 E637 EE3D AA51 A59F 3306 A5BD D198 5609 8673 ID 56098673
Outlook has performed an illegal operation and will be shut down.
If the problem persists, contact the program vendor.
* Ivan Boldyrev wrote:
> AFAIK, jail is chroot jail, which is chroot :)
No, there is more to jail than chroot, although it is, of course based
on the same idea.
Ivan Boldyrev <········@uiggm.nsc.ru.microsoft.com> writes:
> AFAIK, jail is chroot jail, which is chroot :)
No, at least FreeBSD's jail does more than a chroot. For example,
there are additional restrictions on IP connections, a process cannot
see other processes outside the jail, even root cannot do some things
like creating device nodes, etc.
See for example <http://docs.freebsd.org/44doc/papers/jail/jail.html>.
Regards
Henrik
Raymond Wiker <·············@fast.no> writes:
> Unix has things like chroot (which means that you'll only be
> able to access files below a specific point in the directory)
Code which runs in a chroot jail still has full network access (in
particular to localhost). So running untrusted code in a chroot jail
is a bad idea. 8-(
Kenny Tilton <·······@nyc.rr.com> writes:
> On VMS we'd just deny such users any dangerous privileges and let them
> code whatever they liked. Lock them in their own directory if they
> needed write-access for anything, let them delete themselves only. :)
>
> Can the unices do anything like that?
It's a quality-of-implementation issue. Look at OpenBSD, the BSD that
strives for security and generally assumed to be better off than the
rest. The last local kernel exploit was fixed about half a year ago.
C rears its ugly head in all places UNIX.
"Alan Baljeu" <·······@sympatico.deleteme.ca> wrote in message news:<······················@news20.bellglobal.com>...
> > Write an ANSI C++ program that accepts from the user a piece of text
> > representing some kind of computational formula: it could be
> > arithmetic, or a regular expression for pattern matching, a logic
> > proposition, whatever.
> >
[ snip ]
> Well, this would be difficult in C++ no doubt, but it's an artificial
> challenge. A typical C++ program would have _no_ need for such a thing,
> nor in fact would a LISP program*. However if it was needed, one could
> build Python as a linked-in library, and make a call.
Nonsense! Look at the popular packet capture library libpcap, which
serves as a platform for network monitoring utilities like tcpdump,
Ethereal and such.
This library includes its own compiler for packet filtering
expressions; it converts them to a bytecode which is then interpreted.
A Lisp implementation of this would be far, far smaller, and could
compile the filters to optimized *native* machine code.
On a fast network, your packet filtering can require a substantial
chunk of CPU time; it's important to do it with low overhead, which is
why libpcap has a compiler and byte code interpreter in the first
place, rather than, say, something which evaluates a raw syntax tree.
Another example is the POSIX <regex.h> facility, which provides a way
to compiler and interpret regular expressions.
Don't tell me that C and C++ software never needs dynamic compiling!
As for ``build Python as a linked-in library and make a call''. Well,
no kidding! We could also build some Lisp as a library and make a
call. But then we are no longer programming in C++; we have escaped to
another language for help.
What a stupid argument.
By the way, call up your CEO and tell him you are about to add Python
to the product.
> * Okay, a LISP program uses such capabilities all the time. But I think
> you need a concrete scenario of using this, which would be hard to
> imitate in C++ without it. Otherwise, run-time compilation is perceived
> as a gee-whiz gizmo instead of a valuable tool.
If you can't see the value and application of scanning expression at
run time, and dynamically compiling it, I don't know what the hell you
are doing in computing.
> To half answer, I suggest that for most purposes, run-time code generation
> is just a convenience that allows you to avoid writing things like
> if (...)
> {
> ...
> }
> else if (...)
> {
> ...
> }
Are you stoned? A static if/else ladder isn't even close to Turing
complete, for one thing.
> in a few places. I challenge you to find a practical example where it does
> more.
Ever heard of a program called a ``spreadsheet application''? People
write formulas into these things, and it evaluates them.
Man, why don't you just stick a sign on your back that says ``torch
me''?
"Kaz Kylheku" <···@ashi.footprints.net> wrote in message
································@posting.google.com...
*a zillion excellent points, which I snipped*
> Man, why don't you just stick a sign on your back that says ``torch
> me''?
Well, I'm embarrassed. Apologies for being so obtuse, and kudos
to you for pointing this out so well.
Alan
I'll try to make my angles more acute.
Hello!
Alan Baljeu <·······@sympatico.deleteme.ca> wrote:
>[...]
>To half answer, I suggest that for most purposes, run-time code generation
>is just a convenience that allows you to avoid writing things like
>if (...)
>{
> ...
>}
>else if (...)
>{
> ...
>}
>else if (...)
>{
> ...
>}
>else if (...)
>{
> ...
>}
>....
>in a few places. I challenge you to find a practical example where it does
>more.
I'd not use run-time compilation for this, but some macro - if its
use is locally contained, using macrolet.
>Alan
Kind regards,
Hannah.
How about anything involving macros. Ask him to define a new keyword
in C++ called "unless" that is the equivalent of an "if( ! ... )".
(defmacro unless (test &rest body)
`(if (not ,test) ,@body))
This is more in-line with the general concept of bottom-up
programming, or language extension.
Ask him for his own implementation of "if".
(defmacro if (test then else)
`(cond (,test ,then) (t ,else)))
Ask him for anything involving lexical scoping or lambdas. Try doing
this in C++ in a way that is easy to read:
(defun make-adder (n)
(lambda (x) (+ x n)))
Ask him to take a bunch of OO code that he doesn't have access to
change, and write code to detect when a call is made to a certain
method of a certain class. Ask him to print out some manner of log
data whenever the foo() method of class bar is called, without
changing the implementations of foo or bar.
;;; Original code
(defclass bar () ())
(defmethod foo ((b bar))
(print "In foo::bar"))
;;; Solution to problem
(defmethod foo :before ((b bar))
(print "Log: Entering foo::bar()"))
(defmethod foo :after ((b bar))
(print "Log: Exiting foo::bar()"))
Just some ideas,
Justin Dubs
Justin Dubs wrote:
> How about anything involving macros. Ask him to define a new keyword
> in C++ called "unless" that is the equivalent of an "if( ! ... )".
>
> (defmacro unless (test &rest body)
> `(if (not ,test) ,@body))
#define unless(expression) if (!(expression))
> Ask him for anything involving lexical scoping or lambdas. Try doing
> this in C++ in a way that is easy to read:
>
> (defun make-adder (n)
> (lambda (x) (+ x n)))
It's not as elegant as the Lisp version, but it's not unreadable,
either, for someone with a basic familiarity with the language:
class adder {
public:
adder(int a): a(a) { }
int operator()(int b) { return a + b; }
private:
int a;
};
Jeremy.
Jeremy Yallop <······@jdyallop.freeserve.co.uk> wrote in message news:<···············@ID-114079.news.dfncis.de>...
> Justin Dubs wrote:
> > How about anything involving macros. Ask him to define a new keyword
> > in C++ called "unless" that is the equivalent of an "if( ! ... )".
> >
> > (defmacro unless (test &rest body)
> > `(if (not ,test) ,@body))
>
> #define unless(expression) if (!(expression))
namespace my_namespace {
int unless(bool x) // syntax error
{
// ...
}
}
> > Ask him for anything involving lexical scoping or lambdas. Try doing
> > this in C++ in a way that is easy to read:
> >
> > (defun make-adder (n)
> > (lambda (x) (+ x n)))
>
> It's not as elegant as the Lisp version, but it's not unreadable,
> either, for someone with a basic familiarity with the language:
It's not unreadable, but it's not as easy to read.
> class adder {
> public:
> adder(int a): a(a) { }
>
> int operator()(int b) { return a + b; }
>
> private:
> int a;
> };
Now add a sprinkling of memory management issues:
adder *ap = new adder(3); // oops, compute lifetime by hand
adder a(3); // oops, destroyed at termination of block scope
counted_ref<adder> ar = new adder(3); // okay, ref counted
a = b; // maybe use simple value semantics for trivial functors
Next issue: static typing. What if you have two adder-like objects
that have an operator int ()(int)? You want to use them
interchangeably, but unless they are derived from the same base, or
templates are used to generate a variant of the calling code for every
type, they are not substitutable.
Lisp closures are substitutable at the language level based on
straightforward argument list compatibility.
The more issues of this type that you try to address, the more the C++
code explodes and tramples over the expression of the original
meaning.
Kaz Kylheku wrote:
> Jeremy Yallop <······@jdyallop.freeserve.co.uk> wrote in message news:<···············@ID-114079.news.dfncis.de>...
>> Justin Dubs wrote:
>> > How about anything involving macros. Ask him to define a new keyword
>> > in C++ called "unless" that is the equivalent of an "if( ! ... )".
>> >
>> > (defmacro unless (test &rest body)
>> > `(if (not ,test) ,@body))
>>
>> #define unless(expression) if (!(expression))
>
> namespace my_namespace {
> int unless(bool x) // syntax error
> {
> // ...
> }
> }
Er, yes. It's a *keyword*, remember, like 'if':
namespace my_namespace {
int if(bool x) // syntax error
{
// ...
}
}
>> > Ask him for anything involving lexical scoping or lambdas. Try doing
>> > this in C++ in a way that is easy to read:
>> >
>> > (defun make-adder (n)
>> > (lambda (x) (+ x n)))
>>
>> It's not as elegant as the Lisp version, but it's not unreadable,
>> either, for someone with a basic familiarity with the language:
>
> It's not unreadable, but it's not as easy to read.
>
>> class adder {
>> public:
>> adder(int a): a(a) { }
>>
>> int operator()(int b) { return a + b; }
>>
>> private:
>> int a;
>> };
>
> Now add a sprinkling of memory management issues:
>
> adder *ap = new adder(3); // oops, compute lifetime by hand
>
> adder a(3); // oops, destroyed at termination of block scope
>
> counted_ref<adder> ar = new adder(3); // okay, ref counted
>
> a = b; // maybe use simple value semantics for trivial functors
Value semantics will do just fine in this case.
> Next issue: static typing.
This is the real problem. Trying to use unrelated functors
interchangeably is pretty unpleasant.
> The more issues of this type that you try to address, the more the C++
> code explodes and tramples over the expression of the original
> meaning.
Right. Simulating closures isn't easy or pleasant in C++, except in
the most trivial cases, so the challenge only needs to be slightly
more difficult than "anything involving lexical scoping or lambdas".
Jeremy.
Jeremy Yallop <······@jdyallop.freeserve.co.uk> writes:
> Justin Dubs wrote:
>> How about anything involving macros. Ask him to define a new keyword
>> in C++ called "unless" that is the equivalent of an "if( ! ... )".
> #define unless(expression) if (!(expression))
if (i==0)
unless (j>0)
/* do stuff */
else
/*do other stuff */
Ahem.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> Jeremy Yallop <······@jdyallop.freeserve.co.uk> writes:
>
>> Justin Dubs wrote:
>>> How about anything involving macros. Ask him to define a new keyword
>>> in C++ called "unless" that is the equivalent of an "if( ! ... )".
>
>> #define unless(expression) if (!(expression))
>
> if (i==0)
> unless (j>0)
> /* do stuff */
> else
> /*do other stuff */
I think that a case could be made for an 'else' clause to 'unless', as
in Perl. In any case, my 'unless' above /is/ 'the equivalent of an
"if( ! ...)"'.
Jeremy.
Jeremy Yallop <······@jdyallop.freeserve.co.uk> writes:
> Daniel Barlow wrote:
>> Jeremy Yallop <······@jdyallop.freeserve.co.uk> writes:
>>
>>> Justin Dubs wrote:
>>>> How about anything involving macros. Ask him to define a new keyword
>>>> in C++ called "unless" that is the equivalent of an "if( ! ... )".
>>
>>> #define unless(expression) if (!(expression))
>>
>> if (i==0)
>> unless (j>0)
>> /* do stuff */
>> else
>> /*do other stuff */
>
> I think that a case could be made for an 'else' clause to 'unless', as
> in Perl. In any case, my 'unless' above /is/ 'the equivalent of an
> "if( ! ...)"'.
It's not the equivalent of the Lisp macro that Justin gave, though,
which IMO had significantly more useful behaviour - double negatives
don't make it less hard to program. Can you define an 'unless' in C
(or in the preprocessor) which executes its body if the condition is
false, and which has no 'else' branch?
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> Jeremy Yallop <······@jdyallop.freeserve.co.uk> writes:
>
>> Daniel Barlow wrote:
>>> Jeremy Yallop <······@jdyallop.freeserve.co.uk> writes:
>>>
>>>> Justin Dubs wrote:
>>>>> How about anything involving macros. Ask him to define a new keyword
>>>>> in C++ called "unless" that is the equivalent of an "if( ! ... )".
>>>
>>>> #define unless(expression) if (!(expression))
>>>
>>> if (i==0)
>>> unless (j>0)
>>> /* do stuff */
>>> else
>>> /*do other stuff */
>>
>> I think that a case could be made for an 'else' clause to 'unless', as
>> in Perl. In any case, my 'unless' above /is/ 'the equivalent of an
>> "if( ! ...)"'.
>
> It's not the equivalent of the Lisp macro that Justin gave, though,
> which IMO had significantly more useful behaviour - double negatives
> don't make it less hard to program. Can you define an 'unless' in C
> (or in the preprocessor) which executes its body if the condition is
> false, and which has no 'else' branch?
I can't, and I strongly doubt that it's possible. The C preprocessor
is pretty useless for manipulating statements, or anything that
doesn't look like a function call. However, UNLESS still seems a
bit weak to demonstrate the superior facilities Lisp macros offer for
syntactic abstraction. How about LOOP?
Jeremy.
Daniel Barlow wrote:
> Can you define an 'unless' in C (or in the preprocessor) which
> executes its body if the condition is false, and which has no 'else'
> branch?
Jeremy Yallop wrote:
> I can't, and I strongly doubt that it's possible.
Oops. It clearly _is_ possible: see the other replies to your
message:
<··························@melkinpaasi.cs.Helsinki.FI>
<····················@ID-132458.news.dfncis.de>
Jeremy.
<···@telent.net> wrote:
>It's not the equivalent of the Lisp macro that Justin gave, though,
>which IMO had significantly more useful behaviour - double negatives
>don't make it less hard to program. Can you define an 'unless' in C
>(or in the preprocessor) which executes its body if the condition is
>false, and which has no 'else' branch?
#define unless(x) if (x) {} else
(... but why would you want to?)
--
Juho Snellman
Hello,
Daniel Barlow <···@telent.net> writes:
> don't make it less hard to program. Can you define an 'unless' in C
> (or in the preprocessor) which executes its body if the condition is
> false, and which has no 'else' branch?
>
Don't think so. But you could simply write
#define unless(expr) if (expr) ; else
Daniel
> #define unless(expression) if (!(expression))
This is a horribly broken cludge.
Try using it like this:
unless
(cond) {
dostuff;
}
You can do it with if, why not with your unless?
Try using it with any code that makes other use of the work unless.
Try defining a class called unless. Good luck using it's constructor.
Justin Dubs
I wrote:
> #define unless(expression) if (!(expression))
Justin Dubs wrote:
> Try using it like this:
>
> unless
> (cond) {
> dostuff;
> }
>
> You can do it with if, why not with your unless?
Instead of displaying your ignorance you should learn how the
preprocessor works. Even compiling the code would have been
enlightening:
$ cat unless.cc
#include <stdio.h>
#define unless(expression) if (!(expression))
int main()
{
unless
(false) {
puts("Hey, this wasn't supposed to compile.");
}
}
$ g++ -ansi -pedantic -W -Wall unless.cc
$ ./a.out
Hey, this wasn't supposed to compile.
> Try using it with any code that makes other use of the work unless.
Look up "keyword".
> Try defining a class called unless.
Why on earth would I want to do such a silly thing?
Jeremy.
Jeremy Yallop <······@jdyallop.freeserve.co.uk> wrote in message news:<···············@ID-114079.news.dfncis.de>...
> I wrote:
> > #define unless(expression) if (!(expression))
>
> Justin Dubs wrote:
> > Try using it with any code that makes other use of the work unless.
>
> Look up "keyword".
Okay, why not? I don't have my PDF of the C++ standard handy, so a web
searcgh for the the old Dec 1996 draft will do.
2.11 Keywords
The identifiers shown in Table 3 are reserved for use as keywords
...
Table 3 -- keywords
-------------------------------------------------------------
asm do inline short typeid
auto double int signed typename
bool dynamic_cast long sizeof union
break else mutable static unsigned
case enum namespace static_cast using
catch explicit new struct virtual
char extern operator switch void
class false private template volatile
const float protected this wchar_t
const_cast for public throw while
continue friend register true
default goto reinterpret_cast try
delete if return typedef
--------------------------------------------------------------
I can't see ``unless''. Can you see it?
Just because your stupid macro intrudes into the global namespace and
breaks anything that clashes with it doesn't make it a reserved
keyword.
Anyway, reserved keywords are idiocy. Just because the C++ designers
can add new keywords and break existing code does not mean that in a
Lisp versus C++ challenge, it is acceptable to do the same thing.
Here, you must meet a higher standard.
> > Try defining a class called unless.
>
> Why on earth would I want to do such a silly thing?
Right, you work entirely alone; every line of code in the entire
system is written by you. Thus you can enforce your arbitrary
namespace rules, like ``nobody shall define a class named "unless",
lest it clash with a macro of the same name''. There is no other
programmer in your one man team who might want some object that
somehow controls evaluation and calls it ``unless''.
Kaz Kylheku wrote:
> I can't see ``unless''. Can you see it?
Sorry, I don't have time for this sort of thing. In case you've
forgotten,
``It is reasonable of you to ask, in a debate, that others not
address you with inane rhetoric devices that don't contribute
anything useful.''
>> > Try defining a class called unless.
>>
>> Why on earth would I want to do such a silly thing?
>
> Right, you work entirely alone; every line of code in the entire
> system is written by you.
?
A class is entirely the wrong mechanism here. I wouldn't use a class
to write `unless' in Common Lisp, either.
Jeremy.
"Jeremy Yallop" <······@jdyallop.freeserve.co.uk> wrote in message
····················@ID-114079.news.dfncis.de...
> Kaz Kylheku wrote:
> >> > Try defining a class called unless.
> >>
> >> Why on earth would I want to do such a silly thing?
> >
> > Right, you work entirely alone; every line of code in the entire
> > system is written by you.
>
> ?
>
> A class is entirely the wrong mechanism here. I wouldn't use a class
> to write `unless' in Common Lisp, either.
Kaz's point is, macros are dangerous in C++. If you put them in a header,
you never know what they will affect. Consequently, you can't expect to
publish your 'unless' as a portable solution, because my library
(hypothetically) defines class unless, and will be broken when the
preprocessor converts it. Witness the result:
class unless
{
int x;
public:
if(int x) { this->x = x; } // was a constructor
};
Alan
Alan Baljeu wrote:
> "Jeremy Yallop" <······@jdyallop.freeserve.co.uk> wrote in message
>> ?
>
> Kaz's point is [...]
Yes, thanks. I realized that after posting. Clearly C++ has rotted
my brain. I think I'll go and join the reading-for-comprehension
classes that they hold over in comp.lang.c. Sorry for the noise.
Jeremy.
OK, how about the following rather simple macro:
WITH-0PEN-FILE
Even in its simplest form (without all the options), it is difficult to
write a macro that takes entire programming language forms as its body
and wraps them with scoped variables and the unwind-protect...
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
In article <···············@sevak.isi.edu>, ···@sevak.isi.edu (Thomas A.
Russ) wrote:
> OK, how about the following rather simple macro:
>
> WITH-0PEN-FILE
>
> Even in its simplest form (without all the options), it is difficult to
> write a macro that takes entire programming language forms as its body
> and wraps them with scoped variables and the unwind-protect...
That one's actually rather easy.
class with_open_file :: file {
with_open_file(string filename) { file::open(filename); }
~with_open-file() { file::close(); }
}
or something like that.
Then:
{
with_open_file f;
...
}
does more or less the right thing.
E.
···@sevak.isi.edu (Thomas A. Russ) writes:
> OK, how about the following rather simple macro:
>
> WITH-0PEN-FILE
>
> Even in its simplest form (without all the options), it is difficult to
> write a macro that takes entire programming language forms as its body
> and wraps them with scoped variables and the unwind-protect...
Bad example. C++ does not have GC, so objects (e.g. a file wrapper)
are destroyed once they leave scope. Just create an instance of a file
class (with an appropriate destructor) at the desired scope level.
--
H�kon Alstadheim, hjemmepappa.
From: Christopher C. Stacy
Subject: Re: Challenges for C++?
Date:
Message-ID: <ufzqdgg4h.fsf@dtpq.com>
>>>>> On 25 Feb 2003 00:11:42 +0100, H�kon Alstadheim ("H�kon") writes:
H�kon> ···@sevak.isi.edu (Thomas A. Russ) writes:
>> OK, how about the following rather simple macro:
>>
>> WITH-0PEN-FILE
>>
>> Even in its simplest form (without all the options), it is difficult to
>> write a macro that takes entire programming language forms as its body
>> and wraps them with scoped variables and the unwind-protect...
H�kon> Bad example. C++ does not have GC, so objects (e.g. a file wrapper)
H�kon> are destroyed once they leave scope. Just create an instance of a file
H�kon> class (with an appropriate destructor) at the desired scope level.
Does that make sure the file gets closed properly, or just
that the object gets destroyed? What happens if there is
a problem in the destructor code?
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 25 Feb 2003 00:11:42 +0100, H�kon Alstadheim ("H�kon") writes:
>
> H�kon> ···@sevak.isi.edu (Thomas A. Russ) writes:
> >> OK, how about the following rather simple macro:
> >>
> >> WITH-0PEN-FILE
> >>
> >> Even in its simplest form (without all the options), it is
> >> difficult to write a macro that takes entire programming
> >> language forms as its body and wraps them with scoped variables
> >> and the unwind-protect...
>
> H�kon> Bad example. C++ does not have GC, so objects (e.g. a file
> H�kon> wrapper) are destroyed once they leave scope. Just create an
> H�kon> instance of a file class (with an appropriate destructor) at
> H�kon> the desired scope level.
>
> Does that make sure the file gets closed properly, or just
> that the object gets destroyed? What happens if there is
> a problem in the destructor code?
Well, both of those obviously depend on what you put in the destructor
of your file objects. A destructor can do anything a C++ program can
do, so yes, it can also crash and burn without closing files properly.
As can with-open-file. A properly coded file class is just as good/bad
as a properly coded with-open-file.
The only thing lisp buys you over C++ in the case of closing files
automatically, is a mature (as in well tested) standardised solution.
In C++ you will have to use a 3rd party lib or roll your own. This is
just one case where the lisp standard gives you more than the C++
standard. The debate over "which standard has got the right things in
it" is a whole other debate.
--
H�kon Alstadheim, hjemmepappa.
···@sevak.isi.edu (Thomas A. Russ) writes:
> OK, how about the following rather simple macro:
>
> WITH-0PEN-FILE
This is quite easy, using the RAII scheme. Something like
WITH-TRANSACTION which executes the body as often as necessary to make
a transaction succeed (with database specific retry schemes and so
on) is quite a challenge.
However, you can model such things with local classes and templates in
C++. There's quite a syntactic overhead, but it's not *too* bad.
Languages with generics (templates) and local functions are even
better off (think of Ada).
Florian Weimer <··@deneb.enyo.de> writes:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
> > OK, how about the following rather simple macro:
> >
> > WITH-0PEN-FILE
There is no such macro, at least in Common-Lisp.
(mapcar (lambda (x) (insert (format "%c %d\n" x x))) "WITH-0PEN-FILE")
W 87
I 73
T 84
H 72
- 45
0 48 <---
P 80
E 69
N 78
- 45
F 70
I 73
L 76
E 69
> This is quite easy, using the RAII scheme. Something like
> WITH-TRANSACTION which executes the body as often as necessary to make
> a transaction succeed (with database specific retry schemes and so
> on) is quite a challenge.
>
> However, you can model such things with local classes and templates in
> C++. There's quite a syntactic overhead, but it's not *too* bad.
> Languages with generics (templates) and local functions are even
> better off (think of Ada).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie
In article <··············@ortler.iwr.uni-heidelberg.de>,
Nicolas Neuss <·············@iwr.uni-heidelberg.de> wrote:
> Now, I have send him the task below (memoization), but have not yet
> received an answer. I would like to know what people here would propose as
> a challenge. (It should be something obviously useful, easy to formulate
> in CL, but difficult to do in C++.)
I've done memoization in Dylan by adding a closure to a Generic
Function, with singleton specializers on the arguments.
module: memo
define open generic fib(n);
define method fib(n == 1) 1 end;
define method fib(n == 2) 1 end;
define method fib(n)
let result = fib(n - 1) + fib(n - 2);
add-method(fib, method(arg == n) result end);
result;
end fib;
format-out("fib 40 = %d\n", fib(40));
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Hello, y'all.
>
> On my last conference, I met someone favoring C++ and expression templates
> (he also mentioned the "Lisp as expression template" which was discussed
> here recently).
By any chance, was that someone Todd Veldhuizen of Blitz++ fame (
http://www.oonumerics.org/blitz/ )? About 3 years ago I wrote an
application in C++ (25,000+ LOC) using his and 2 other libraries.
Well, it works and provides very nice (for a C++ land) array functions
that make it look almost like Matlab & Co. However, if anything goes
wrong during compilation, error messages are so many and
undecipherable as to be totally useless.
If you take a look at that library, he makes a quite decent job on
making C++ compiler to behave like Lisp's defmacro function (IMHO).
> I have proposed to him that he should send me some C++ stuff which I
> would try to redo in CL, and I would send him some CL which he
> should try to mimic in C++. Then we would compare the solutions.
I have such a problem that I have implemented in Lisp. Write a
library that operates on histograms of unknown (during compile time)
dimensions. Especially interesting would be an implementation of pdf
to cumulative pdf (and back) transformations. Last time I checked,
Blitz++'s Array class implementation was limited to 12 dimensions ("I
had to stop somewhere").
--ET.
--
"Markets can remain irrational longer than
you can remain solvent." -- J. M. Keynes
Mean Gene <·······@please.net> writes:
> Blitz++
> About 3 years ago I wrote an application in C++ (25,000+ LOC) using
> his and 2 other libraries.
> I have such a problem that I have implemented in Lisp.
You sound like you are someone who uses lisp to do some intensive
numerics. Would you mind saying something about what you do with Lisp,
and maybe in what context ?