From: Peter G. <pe...@ar...> - 2003-12-09 16:01:02
|
On Tue, 9 Dec 2003 at 17:23:57 +0100, Andr=E1s_Simon wrote: > These are just the files that are affected. Thanks for testing them! The changed files test out OK: the test suite reports no new errors. It should be safe to check them in. There is one minor problem: CL-USER(4): (arglist 'cons) "object-1 object-2" T CL-USER(5): (arglist 'subseq) (SEQUENCE SYSTEM::START &OPTIONAL SYSTEM::END) T The arglists added to the .java files (e.g. CONS) come out as strings, but what we really need (I think) are Lisp lists (as in the SUBSEQ case). Compare Allegro: CL-USER(1): (arglist 'cons) (EXCL::X EXCL::Y) T CL-USER(2): (arglist 'subseq) (SEQUENCE EXCL::START &OPTIONAL EXCL::END) T This can be fixed either in the Function 2-arg constructor or in the ARGLIST function itself, by breaking the string into whitespace- delimited tokens, generating symbols from the tokens (in the EXT package?) and consing them into a list. It would probably minimize overhead to do this in the ARGLIST function. Once the list is generated, it can be stored back into the function object to avoid having to generate it again. What do you think? -Peter |
From: <as...@ma...> - 2003-12-09 17:30:58
|
On Tue, 9 Dec 2003, Peter Graves wrote: > On Tue, 9 Dec 2003 at 17:23:57 +0100, Andr=E1s_Simon wrote: > > These are just the files that are affected. Thanks for testing them! > > The changed files test out OK: the test suite reports no new errors. It > should be safe to check them in. Good! I haven't checked them in yet, because the actual form of these strings may affect how we get the argLIST; see below. > > There is one minor problem: > > CL-USER(4): (arglist 'cons) > "object-1 object-2" > T > CL-USER(5): (arglist 'subseq) > (SEQUENCE SYSTEM::START &OPTIONAL SYSTEM::END) > T > > The arglists added to the .java files (e.g. CONS) come out as strings, > but what we really need (I think) are Lisp lists (as in the SUBSEQ > case). > > Compare Allegro: > > CL-USER(1): (arglist 'cons) > (EXCL::X EXCL::Y) > T > CL-USER(2): (arglist 'subseq) > (SEQUENCE EXCL::START &OPTIONAL EXCL::END) > T > > This can be fixed either in the Function 2-arg constructor or in the > ARGLIST function itself, by breaking the string into whitespace- > delimited tokens, generating symbols from the tokens (in the EXT > package?) and consing them into a list. > > It would probably minimize overhead to do this in the ARGLIST function. > Once the list is generated, it can be stored back into the function > object to avoid having to generate it again. > > What do you think? So we'd have something like a Cons arglistList; field in Function that would be consulted/filled in by EXT:ARGLIST? Then perhaps arglist should be a LispString (with list syntax) and READ-FROM-STRING could be used to generate arglistList from it. Except that READ-FROM-STRING is defined in Lisp, not Java, so calling it from Java would require spawning a new Interpreter. But maybe EXT:ARGLIST could be defined in Lisp, and then there's no such problem. (I'm just thinking loud.) Or we can just stay on the Java side and use java.util.StringTokenizer and intern (I see an intern method in Lisp.java, but also things like PACKAGE_CL.intern() in the source, which I don't quite understand.) Andras |
From: Peter G. <pe...@ar...> - 2003-12-09 18:11:30
|
On Tue, 9 Dec 2003 at 19:29:45 +0100, Andr=E1s_Simon wrote: > So we'd have something like a > > Cons arglistList; > > field in Function that would be consulted/filled in by EXT:ARGLIST? No. Function.java already has: private LispObject arglist; into which the recently added 2-arg Function constructor is storing a LispString. What I'm suggesting is that when ARGLIST consults the value of this field, it checks to see whether it's a LispString or not. If it's a LispString, then presumably it was set by the Function constructor, so there's a bit of code in ARGLIST that parses out whitespace-delimited tokens from that LispString, interns them in the EXT package (for the sake of argument), conses them into a Lisp list, stores that list back into the same arglist field in the Function object which previously held the LispString, and then returns the freshly-consed-up list as its primary return value. (If ARGLIST finds that the arglist field of the Function object already contains a list, it just returns that list unchanged; if the arglist field contains null, we fail the call.) > Then perhaps arglist should be a LispString (with list syntax) and > READ-FROM-STRING could be used to generate arglistList from it. > Except that READ-FROM-STRING is defined in Lisp, not Java, so calling > it from Java would require spawning a new Interpreter. But maybe > EXT:ARGLIST could be defined in Lisp, and then there's no such > problem. (I'm just thinking loud.) Or we can just stay on the Java > side and use java.util.StringTokenizer and intern (I see an intern > method in Lisp.java, but also things like PACKAGE_CL.intern() in the > source, which I don't quite understand.) I think it's probably easiest to stay on the Java side and use the static method Lisp.readObjectFromString(), which is mainly there for the convenience of the JVM compiler: private static final Primitive1 ARGLIST =3D new Primitive1("arglist", PACKAGE_EXT, true) { public LispObject execute(LispObject arg) throws ConditionThrowab= le { LispThread thread =3D LispThread.currentThread(); Function function =3D coerceToFunction(arg); LispObject arglist =3D function.getArglist(); final LispObject value1, value2; if (arglist instanceof LispString) { String s =3D ((LispString)arglist).getValue(); // Give the string list syntax. s =3D "(" + s + ")"; // Bind *PACKAGE* so we use the EXT package if we need // to intern any symbols. Environment oldDynEnv =3D thread.getDynamicEnvironment();= thread.bindSpecial(_PACKAGE_, PACKAGE_EXT); try { arglist =3D readObjectFromString(s); } finally { thread.setDynamicEnvironment(oldDynEnv); } function.setArglist(arglist); } if (arglist !=3D null) { value1 =3D arglist; value2 =3D T; } else { value1 =3D NIL; value2 =3D NIL; } return thread.setValues(value1, value2); } }; I think that should work, but I haven't actually tested it (or even tried to compile it, if truth be known). -Peter |
From: <as...@ma...> - 2003-12-09 18:31:44
|
On Tue, 9 Dec 2003, Peter Graves wrote: > I think that should work, but I haven't actually tested it (or even > tried to compile it, if truth be known). I tested it, and it works. Cool! Now the only remaining question is whether arglist should add the parens, or should they be there to start with. Andras |
From: Peter G. <pe...@ar...> - 2003-12-09 18:48:50
|
On Tue, 9 Dec 2003 at 20:30:32 +0100, Andr=E1s_Simon wrote: > On Tue, 9 Dec 2003, Peter Graves wrote: > > > I think that should work, but I haven't actually tested it (or even > > tried to compile it, if truth be known). > > I tested it, and it works. Cool! > Now the only remaining question is whether arglist should add the > parens, or should they be there to start with. I don't have a strong opinion about that. Folks will probably be typing the arglist strings into the Java source for functions that aren't in the CL package, so maybe it would be easier in practice for ARGLIST to add the parens. (A really robust ARGLIST implementation would examine the LispString to see if the first and last chars are parens, and add the parens if they're not already there.) Not a big deal. -Peter |
From: <as...@ma...> - 2003-12-09 20:50:04
|
On Tue, 9 Dec 2003, Peter Graves wrote: > On Tue, 9 Dec 2003 at 20:30:32 +0100, Andr=E1s_Simon wrote: > > Now the only remaining question is whether arglist should add the > > parens, or should they be there to start with. > > I don't have a strong opinion about that. > > Folks will probably be typing the arglist strings into the Java source > for functions that aren't in the CL package, so maybe it would be > easier in practice for ARGLIST to add the parens. > > (A really robust ARGLIST implementation would examine the LispString to > see if the first and last chars are parens, and add the parens if > they're not already there.) > > Not a big deal. OK, I committed the parenless version, and your new EXT:ARGLIST. Andras |
From: Peter G. <pe...@ar...> - 2003-12-09 21:33:03
|
On Tue, 9 Dec 2003 at 22:48:51 +0100, Andr=E1s_Simon wrote: > OK, I committed the parenless version, and your new EXT:ARGLIST. Looks good, and the test suite has no complaints (well, no more than usual). Thanks a lot for all your work to make this happen! -Peter |
From: <as...@ma...> - 2003-12-09 18:13:49
|
On Tue, 9 Dec 2003, [X-UNKNOWN] Andr=E1s Simon wrote: > side and use java.util.StringTokenizer and intern (I see an intern > method in Lisp.java, but also things like PACKAGE_CL.intern() in the > source, which I don't quite understand.) I don't know what confused me... It's all perfectly clear. Andras |