Re: GSOC | Extending Common Lisp support

[Jamison Hope <jrh at theptrgroup dot com>]

On May 5, 2012, at 4:28 PM, Charles Turner wrote:

> Sorry for the slow response, exams are getting in the way of more
> interesting things, and the situation is only going to worsen for the
> next 3 weeks until they all end. :-(

No worries! The S in GSOC means this is supposed to be a summer project,
so while you still have school work to do, that must take top priority.

> The refactoring is progressing slowly, mostly due to difficulties I'm
> having in reasoning about the possible regressions I might cause with
> some of these changes (and exams). To be honest, I've had to resort to
> trusting the test suite coverage for some of this stuff (that's not
> overly optimistic, right?)

That's the test suite's raison d'être, no? If you inadvertently break
something, then the test suite is supposed to catch it. Naturally, the
tests don't cover every possibility (I wonder if Gödel's theorems imply
that this is inevitable..), but that's OK. We can always add more tests
to fill in the gaps. For the moment, as long as the existing tests pass
and it doesn't break Scheme in some obvious-but-untested way, we can
declare it good enough for now and come back to it later if we find
subtle flaws.

> I think most of the types in Scheme#getTypeMap are of interest to all
> Lisps, barring of couple that I consider specific to scheme (boolean
> and the various vector types). I moved this into LispLanguage. The
> gist of the type changes in Scheme.java are:
>
> public synchronized HashMap<String, Type> getTypeMap ()
>  {
>    if (types == null)
>    {
>      types = new HashMap<String, Type>();
>      booleanType = new LangPrimType(Type.booleanType,  
> Scheme.getInstance());
>      types.put("boolean", booleanType);
>      for (int i = uniformVectorTags.length; --i >= 0;)
>      {
>        String tag = uniformVectorTags[i];
>        String cname = "gnu.lists." + tag.toUpperCase() + "Vector";
>        types.put(tag + "vector", ClassType.make(cname));
>      }
>
>    }
>    return types;
>  }
>
> (where types is now a private field of Scheme, also note, this method
> is no longer static)
>
>  public Type getNamedType (String name)
>  {
>    Type type;
>    type = LispLanguage.getLispTypeMap().get(name);
>    if (type == null) {
>      type = getTypeMap().get(name);
>    }
>    return type;
>  }

Looks good to me. You could probably make that a method of LispLanguage
along with an abstract declaration of getTypeMap(), and then each
LispLanguage subclass can implement its own additional type mapping.

The existing provision for specifying a type from a different language
(i.e. the 'name.startsWith("elisp:") || name.startsWith("clisp:")' stuff
doesn't appear to be used much, but could be handy. So perhaps make
getNamedType() something like:

public Type getNamedType (String name)
{
  Type type;
  type = LispLanguage.getLispTypeMap().get(name);
  if (type == null) {
    int colon = name.indexOf(':');
    Language language = this;
    if (colon > 0) {
      String lang = name.substring(0,colon);
      name = name.substring(colon+1);
      language = Language.getInstance(lang);
      if (language == null) throw new RuntimeException(...);
    }
    type = language.getTypeMap().get(name);
  }
  return type;
}


I just typed that into this mail window, so it's probably full of errors
but you get the idea. I'm imagining a situation in which you're writing
a library in one language but want to call a function written in  
another,
or want to write a wrapper function conveniently callable from another
language. Maybe I've got some Scheme code that works with u32vectors and
I'd like to call it from CL. Then if I do something like:

(defun foo ()
  (let ((v (some-function-defined-in-scheme-code)))
    (declare (scheme:u32vector v))
    ...))

it'll do the right thing. Thoughts? Will that conflict with Common Lisp
package syntax? Maybe we need a host-language-specific delimiter which
can be ':' in Scheme but is something else in Common Lisp? Or maybe
the various Languages are treated as packages in CL.

(We can revisit this later, I think it's outside the scope of your  
project
for this year.)

> I also discovered quantities today, they're übercool, but currently
> specific to Scheme. I don't see any reason for this, is it OK to make
> them available to all Lisps?  This would make the refactoring of
> SchemeCompilation#checkDefaultBinding a little nicer.

It's fine with me. Any objections, Per?

> I am actively applying the advice of not getting too hung up on this
> stuff, it's just this particular refactoring is tightly coupled to a
> few others, so it's taking a little longer than I expected.

We're still in the Community Bonding Period, so I think you're still a
little ahead of schedule. Relax, study for your exams, go see Avengers
if you haven't yet.

> Charles.


Jamie

--
Jamison Hope
The PTR Group
www.theptrgroup.com