Re: [Kawa-commonlisp-dev] [PATCH] Type refactoring.

[Charles Turner]

On 22 September 2012 01:24, Per Bothner <address@hidden> wrote:
> My biggest concern is the various uses of Scheme.getInstance().xxx()
> It seem like these should be plain xxx() or (in the case of the
> subclasses of Compilation) getLanguage.xxx().  Any reason why not?

I don't think so. I've updated XQuery and ELisp to remove their
dependence on Scheme, only these files now call
Scheme.getInstance().xxx():

gnu/xquery/lang/XQResolveNames.java:350:  type =
Scheme.getInstance().string2Type(sym.getName());

I'd like for this not to be the case, but I get testsuite failures if
I instead call the method from Language.getCurrent() (or
XQuery.getInstance(), which should be equivalent in this case). There
seems to be a dependence on Scheme's boolean type, I don't know enough
about XQuery to decide if that's necessary, or whether we can give
XQuery its own boolean type (or if this is even the problem!).
XDataType seems to just use Type.booleanType.

gnu/kawa/servlet/ReplSession.java:112:
this(kawa.standard.Scheme.getInstance());

Seems benign.

> It might also be help to add some comments - for example what is
> the difference between getNamedType and string2Type.

At first I thought I could manually inline getNamedType into
string2Type, and be rid of getNamedType, but that turned out not to be
true, and I'm struggling to see why.

In SchemeCompilation,:291, if the line is this:

Type type = getLanguage().getNamedType(cname);

All is OK, if it's this:

Type type = getLanguage().string2Type(cname);

I get this when doing a fresh make:
(compiling srfi69.scm)
srfi69.scm:29:25: 'hash-table?' exported but never defined
srfi69.scm:31:40: 'hash-table-set!' exported but never defined
srfi69.scm:32:2: 'hash-table-delete!' exported but never defined
srfi69.scm:32:21: 'hash-table-exists?' exported but never defined
srfi69.scm:34:2: 'hash-table-size' exported but never defined

Just going off the names (hash-table? etc), I can't see how
string2Type differs in its execution path to what getNamedType would
do... I'll paste the two method below:

  public Type getNamedType (String name)
  {
    Type type = getTypeMap().get(name); // Initialise the type map if necessary.
    return (type != null) ? type : getPackageStyleType(name);
  }

  @Override
  public Type string2Type (String name)
  {
    Type t;
    if (name.endsWith("[]")) // clearly fails on the names above
    {
      t = string2Type(name.substring(0, name.length() - 2));
      if (t != null)
        t = ArrayType.make(t);
    }
    else
    {
      // This fails even if you inline getNamedType below...
      t = getNamedType(name);
    }
    if (t != null)
      return t;
    // hash-table? etc aren't valid java type names, so this branch
can not be taken
    else if (Type.isValidJavaTypeName(name)) {
      t = Type.getType(name);
    }
    return t;
  }



------ In other news:
I'm not sure if this is a bug, or just a case of getting what I
deserved, the reasoning behind it was that I'd changed some code and
wanted a decent compilation test (I've had cases in the past were the
build process signaled a bug, but the testsuite didn't) on the Scheme
files in Kawa:

(assume kawa has already been made, then do this)
$ find . -name "*.scm" | xargs touch
$ make
...
(compiling StreamsDerived.scm to gnu.kawa.slib.StreamsDerived)
StreamsDerived.scm:83:18: unknown type name 'stream-type'
... lots more times


Charles.