From: Mike B. <be...@hi...> - 2003-10-27 08:09:03
|
Peter, et. al: Any chance to make Interpreter not final? And make some of the private methods "protected" rather than "private", for example constructors, etc. ? This will help in inheriting from Interpreter. My argument: Lisp is a "programmable programming language", - John Foderaro, CACM, September 1991, and this will help make ABL live up to that ... even when embedded in Java, - Mike "If you design a language that has eval, car, cdr, cons, quote, eq, cond, and a notation for functions made of conses, then you've designed a dialect of Lisp, even if you didn't mean to." Paul Graham |
From: Peter G. <pe...@ar...> - 2003-10-27 14:56:03
|
On Mon, 27 Oct 2003 at 02:06:55 -0600, Mike Beedle wrote: > > Peter, et. al: > > Any chance to make Interpreter not final? > > And make some of the private methods "protected" rather > than "private", for example constructors, etc. ? > > This will help in inheriting from Interpreter. My general policy is to give things the minimum (i.e. most restrictive) access possible, mostly as a kind of cheap documentation (if the class is final, no need to look for subclasses, etc.). If it turns out later that those things need more permissive access, it's easy to change it. That said, from my perspective, Interpreter.java is gradually losing its code to top-level.lisp. Most of the code in run() and all of the code in doCommand() and its various helper functions is already obsolete and scheduled for deletion, which will leave nothing in Interpreter.java but a tiny bit of initialization and finalization code that can't be written in Lisp. So one day soon there won't be anything left to inherit. (Note, BTW, that the constructors are currently private as a hint that you should be using Interpreter.createInstance(), which is public.) I guess the point of all of this rambling is that in the particular case of Interpreter.java, the class wasn't really intended to be inherited from, and in the sense that making things public is sometimes construed as some sort of guarantee that the interface won't change, I'm here to tell you that it ain't so... What functionality were you looking to inherit by inheriting from Interpreter.java? -Peter |
From: Mike B. <be...@hi...> - 2003-10-27 17:01:06
|
> So one day soon there won't be anything left to inherit. Peter: This is good news. A good lisp should minimize its "given" constructs. This philosophy is similar to Arc, from Paul Graham, for example. > What functionality were you looking to inherit by inheriting from > Interpreter.java? Given the above, I think it makes little sense to "inherit". I just want to add the JSR protocol in my class but given the above I think containment might be a better idea: public class JLisa implements StatefulRuleSession { private state Interpreter _interpreter = new Interpreter(); rather than: public class JLisa extends Interpreter implements StatefulRuleSession { - Mike |
From: Peter G. <pe...@ar...> - 2003-10-27 17:08:33
|
On Mon, 27 Oct 2003 at 10:56:38 -0600, Mike Beedle wrote: > I just want to add the JSR protocol in my class but given the > above I think containment might be a better idea: > > public class JLisa implements StatefulRuleSession { > > private state Interpreter _interpreter = new Interpreter(); Or as things stand: private state Interpreter _interpreter = Interpreter.createInstance(); -Peter |
From: Mike B. <be...@hi...> - 2003-10-27 18:21:54
|
> Or as things stand: > > private state Interpreter _interpreter = > Interpreter.createInstance(); Oh yeah, the Singleton thing... which begs the question: What if someone legitimately needed 3 interpreters with different images in each one of them? - Mike |
From: Peter G. <pe...@ar...> - 2003-10-27 19:09:54
|
On Mon, 27 Oct 2003 at 12:21:22 -0600, Mike Beedle wrote: > Oh yeah, the Singleton thing... which begs the question: > > What if someone legitimately needed 3 interpreters with different > images > in each one of them? If you want three interpreters running three different, independent instances of Lisp, you can do "java org.armedbear.lisp.Main" three times, from three different xterms (say), getting three different, independent OS processes. That should work fine as things stand. If you want three interpreters looking at the same instance of Lisp, that's not presently supported. It could be done, since ABL is inherently multi-threaded, but you'd have to write code to synchronize access to things that need synchronized access, and you'd have to define a protocol to answer questions like "Who owns *standard-input*?" at any given time. If you don't really need multiple interpreters, but just multiple threads, that should just (barely) work with the current code. Specials are bound per-thread, there's no locking unless you roll your own, there's no protocol for backgrounding a thread, etc. There's lots of work to do in this area, including some fundamental design work, before it's ready for serious use. The first step would be to look at some of the existing multithreaded Lisps (ACL, SBCL, Scieneer) and figure out what we want to be compatible with. I'm not going to go very far with this myself until more basic things (like full ANSI compliance) are in better shape. -Peter |
From: Mike B. <be...@hi...> - 2003-10-29 05:47:27
|
Peter writes: > If you want three interpreters running three different, > independent instances of Lisp, you can do "java org.armedbear.lisp.Main" > three times, from three different xterms (say), getting > three different, independent OS processes. That should work fine > as things stand. I was thinking more in terms of an App server with the need to instantiate 3 different Lisp interpreters within the same JVM. For example, one interpreter running a rule engine :-), another creating stores on the fly ala Yahoo stores (I am sure all of you know it runs Lisp), and another one for say flight reservations ala Orbitz, yes deep down it also uses Lisp. - Mike |
From: Slava P. <sl...@je...> - 2003-10-29 06:03:11
|
On Wed, 2003-10-29 at 00:47, Mike Beedle wrote: > another > creating stores on the fly ala Yahoo stores (I am sure all of you > know it runs Lisp), I always had a nagging suspicion they were randomly generated... :-) But seriously, aren't you concerned about performance when you run an interpreted language in an app server? I'd imagine yahoo uses a lisp engine with a JIT. -- Slava Pestov |
From: Mike B. <be...@hi...> - 2003-10-29 06:57:57
|
Slava: It all depends. If you preload the code into the Interpreter and keep it in a hash table is not that slow. Parsing files is definitely slower. We do that right now with Jess in production, for example. Also, in time, ABL may offer the ability to JIT compile. (I don't know what they do at Yahoo.) - Mike -----Original Message----- From: arm...@li... [mailto:arm...@li...] On Behalf Of Slava Pestov Sent: Wednesday, October 29, 2003 12:03 AM To: arm...@li... Subject: RE: [j-devel] Some Minor Changes On Wed, 2003-10-29 at 00:47, Mike Beedle wrote: > another > creating stores on the fly ala Yahoo stores (I am sure all of you know > it runs Lisp), I always had a nagging suspicion they were randomly generated... :-) But seriously, aren't you concerned about performance when you run an interpreted language in an app server? I'd imagine yahoo uses a lisp engine with a JIT. -- Slava Pestov ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ armedbear-j-devel mailing list arm...@li... https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
From: Peter G. <pe...@ar...> - 2003-10-29 07:00:55
|
On Wed, 29 Oct 2003 at 01:02:45 -0500, Slava Pestov wrote: > On Wed, 2003-10-29 at 00:47, Mike Beedle wrote: > > another > > creating stores on the fly ala Yahoo stores (I am sure all of you > > know it runs Lisp), > > I always had a nagging suspicion they were randomly generated... :-) > > But seriously, aren't you concerned about performance when you run an > interpreted language in an app server? I'd imagine yahoo uses a lisp > engine with a JIT. Yahoo and Orbitz use Lisps that compile to native code. -Peter |
From: Peter G. <pe...@ar...> - 2003-10-29 06:59:46
|
On Tue, 28 Oct 2003 at 23:47:14 -0600, Mike Beedle wrote: > I was thinking more in terms of an App server with the need > to instantiate 3 different Lisp interpreters within the same JVM. > > For example, one interpreter running a rule engine :-), another > creating stores on the fly ala Yahoo stores (I am sure all of you > know it runs Lisp), and another one for say flight reservations > ala Orbitz, yes deep down it also uses Lisp. I don't think you want intepreters (think REPLs) for this, just three different threads running different Lisp functions. Or three separate processes, talking (possibly) to the same database underneath. But not three separate interpreters, per se... -Peter |