[Bug-kawa] Re: [bug #19263] /usr/local/lib/slib/require.scm:139:6: unbound location slib

[Per Bothner]

Aubrey Jaffer wrote:
>  | From: Per Bothner <address@hidden>
>  | Date: Fri, 16 Mar 2007 17:20:31 +0000
>  | 
>  | Update of bug #19263 (project kawa):
>  | 
>  |                   Status:                    None => Need Info
>  | 
>  |     _______________________________________________________
>  | 
>  | Follow-up Comment #1:
>  | 
>  | Hm.  In Kawa require is syntax.  It basically is a compile-time "import
>  | module" statement.
>
> Programs call SLIB REQUIRE with a quoted argument; so that may serve
> to distinguish the cases.

Kawa supports, partly for slib compatibility:
  (require 'symbol)
But there is a table that maps each symbol to a Java class,
and this mapping is done at compile-time.

I can certainly extend this table.  And/or we can provide a mechanism
to extend this mapping depending on the compile-time environment.

>  | However, the other complication is thta Kawa uses a "colon notation" for
>  | various purposes.  Basically:
>  |   foo:bar
>  | -means get the compoent with (literal) name bar if the value of
>  | (evaluating) foo.
>
> Kawa seems to be going it alone on this one.  I don't know of any
> other Scheme using ":" this way; and the nascent R6RS is not doing so.

However, Common Lisp uses ':' for qualified symbols, as does the XML
world.  Kawa's use of ':' is basically a generalization (or at least
compatible with) these existing uses.

Other Scheme implementations support a "dot notation" to name Java
fields, methods, and classes.  That isn't all that different - Kawa's
"colon notation" isn't that different from "dot notation" in
principle - but is more consistent and useful, I think.

> Can you provide some read-time control to make ":" just a normal
> character in symbols?

I should.  I do need to think how to do this - ideally in a general
mechanism.  One option is a general --r5rs option which would
turn off extensions like this.

>  | Kawa does have some "compatibility hacks": If the compiler sees a
>  | defining for the name |foo:bar| (and no definition of the symbol
>  | |foo|) it will then treat foo:bar as referring to the former
>  | definition.
>
> There are many functions in SLIB which are defined both with a prefix
> and without a prefix.  Is it okay if |foo:bar| and bar (as opposed to
> |bar|) are defined?

That should work.  There is not conflict between them - then issue
is foo vs foo:bar.

> We could write a program which creates Kawa copies of all the SLIB
> modules having their ":" symbols wrapped in "|"s.

One possible solution, though I'd prefer some flag that change the
reader.

>  | I'm in the process of trying to clean up top-level declaration, and
>  | specifically the interaction between the run-time environment and
>  | the compile-time top-level scope, so this stuff may change a bit.
>  | In fact, it is possible what you've experienced may be something
>  | that should be fixed.
>  | 
>  | Kawa is focused on compilation.  I've imported a few slib packages
>  | - see gnu/kawa/slib.
>
> I compared "printf.scm"s; nearly all the changes were from the SLIB
> side, mostly character constants.  Only two Kawa declarations were
> added -- I don't think they would make any significant difference.
> The function starting:
>
>   (define-constant (stdio:round-string (str :: <string>) ndigs strip-0s)
>     (let* ((n (- (string-length str) 1))
>       ...
>
> really shouldn't need to declare STR because the first call with
> STRING-LENGTH clearly constrains STR to be a string.

It don't why I did this - it looks like a mistake: I think I
meant to write define-private.

Note if slib functions are shipped with Kawa it may be reasonable
add some optimizations.

Another factor is modularization and namespace management: It is
desirable to keep "module-internal" implementation functions and
variable "private" if such a module system is available.

> As for DEFINE being renamed DEFINE-CONSTANT, that could be done by
> rewriting the files at installation time.  SLIB's functions
> FILE->EXPORTS or FEATURE->EXPORTS can be used to discover which
> functions are exported (is that the relevant distinction?).

Yes.

>  | I'm open to changes to the Kawa system so Kawa can support slib
>
> I have submitted two bugs for the issues gating Kawa/SLIB.

No promises (I'm in job talks, which if it happens will leave
me very busy), but I'll see what I can do.

>  | out-of-the box, ideally without an init file.
>
> Okay.  Would this involve SLIB being part of Kawa.jar?

That is the model I've explored in gnu/kawa/slib - selected
parts of slib are compiled to Java classes in the
gnu.kawa.slib package.  (Though I've some other Scheme modules
in the same package.)

An alternative is a script (or Makefile rule) that would compile Slib
into an slib.jar file.  Kawa applications that use slib would add
slib.jar to their "classpath".

The advantage of a script to build a separate slib.jar is that it
can be updated when slib is updated.  Another is that I'm not
sure everything in slib makes sense for Kawa, at least for as
part of kawa.jar.  For example Kawa has its own pretty-printer
and an implementation of CL-style format; it might be better for
the slib versions on those functions on Kawa to be a wrapper
around the builtin Kawa functions.  Of course that takes some
work, especially if the Kawa versions are missing slib functionality.

> Not anchored in a filesystem

Well, you can load files from the filesystem.  However, it seems
to me that "installing" slib for Kawa should perhaps compile it
to class files or a .jar file.  But not necessarily: One could
find slib by searching the file system.

> and lacking GETENV, finding SLIB from Java is
> difficult.

Getenv is depecated for a numberof years and throws an exception
in JDK 1.4, but Sun finally came to their senses and restored
it (undeprecated) in JDK 1.5.

It can be simulated in JDK 1.4 by running an external program,
but of course that is a bit klunky.

I do think the best way to require a feature under Kawa is
to map a feature to a class name, and then use the Java
CLASSPATH mechanism to find the class in a .jar archive.
But that only works for compiled classes - though one could
write an "slib classloader" that compiles an slib source file
on-the-fly when needed.  But then *something* as to be able
to find the sourcefile.   If you compile slibb at installation
time you avoid that problem - though you have the other
problem of version mismatches between the slib library
and the core kawa classes - unless slib is shipped and
installed with kawa itself.
--
        --Per Bothner
address@hidden   http://per.bothner.com/