This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSOC | Extending Common Lisp support


> That's what I was expecting, too. Charles, when you say you are "manually"
> adding the symbol names to the packages, what do you mean? It would make

Something like this which is called from initLisp

private void populateStandardPackages ()
  {
    LispPackage cl = LispPackage.CLNamespace;
    cl.primExport("CAR");
    cl.primExport("CDR");
    ...
  }

where primExport trivially make the symbol and adds it to the packages
external symbol table.

> Â Â Âpackage = common_lisp_package; // like (in-package "COMMON-LISP")
>
> Â Â ÂdefProcStFld(); // now this symbol ends up in that package
> Â Â Â...

And IIUC, we'd override defProcStFld (or maybe
StaticFieldLocation#define) to do the package munging in CommonLisp?

> Yeah, that makes sense. Make a list of the changes at a logical level,
> and come up with a dependency ordering. Any small fixes that are self
> contained can go first, and stuff that requires those to be in place
> can go next, etc.

That's a good plan. I posted a change file for the types, which
actually might have contained some small fixes, but I didn't notice
them whilst reading through it.

> Also, what's your preferred way to fix Lisp2's getNamespaceOf for
> syntax declarations? You had suggested something like
> getFlag(Declaration.PROCEDURE|Declaration.IS_SYNTAX) but the
> former flag is not public. So I'm sitting on a change that looks like
>
> $ svn diff gnu/commonlisp/lang/Lisp2.java
> Index: gnu/commonlisp/lang/Lisp2.java
> ===================================================================
> --- gnu/commonlisp/lang/Lisp2.java   Â(revision 7259)
>
> +++ gnu/commonlisp/lang/Lisp2.java   Â(working copy)
> @@ -61,7 +61,9 @@
> Â Â Â// function and variable position.
> Â Â Âif (decl.isAlias())
> Â Â Â Âreturn FUNCTION_NAMESPACE+VALUE_NAMESPACE;
> - Â Âreturn decl.isProcedureDecl() ? FUNCTION_NAMESPACE : VALUE_NAMESPACE;
> + Â Âreturn (decl.isProcedureDecl() ||
> + Â Â Â Â Â Âdecl.getFlag(Declaration.IS_SYNTAX)) ?
> + Â Â ÂFUNCTION_NAMESPACE : VALUE_NAMESPACE;
> Â Â}
>
> Â Â/** Get a symbol for a given (interned) Java string. */
>
> which works but is ugly. Methinks we need either an isSyntaxDecl() method,
> or we need Declaration.PROCEDURE to be public, for better consistency.

Yeah, I'm using the following to fix that

Index: gnu/expr/Declaration.java
===================================================================
--- gnu/expr/Declaration.java	(revision 7259)
+++ gnu/expr/Declaration.java	(working copy)
@@ -230,7 +230,7 @@
   public final void setSyntax ()
   {
     setSimple(false);
-    setFlag(IS_CONSTANT|IS_SYNTAX|EARLY_INIT);
+    setFlag(IS_CONSTANT|IS_SYNTAX|EARLY_INIT|PROCEDURE);
   }

   /** Return the ScopeExp that contains (declares) this Declaration. */
@@ -501,7 +501,7 @@

   /** True if in the function namespace, for languages that distinguishes them.
    * I.e. a function definition or macro definition. */
-  static final int PROCEDURE = 0x80;
+  public static final int PROCEDURE = 0x80;

   public static final int IS_ALIAS = 0x100;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]