missing support for main.sls files

[GoogleCodeExporter]

What steps will reproduce the problem?
1. install a library with pathname "$SITELIB/srfi/lists/main.sls"
2. try to import the library "(import (srfi lists))"

What is the expected output? What do you see instead?
Ypsilon should find the library even if the pathname is not
"srfi/lists.scm", but it raises an error: attempt to import
undefined library.

What version of the product are you using? On what operating system?
ypsilon-0.6.9.update2, GNU+Linux

Please provide any additional information below.
Other Scheme implementations, like Ikarus and (if I remember correctly)
PLT Scheme support this convention. If Ypsilon adheres to it, it will
be possible to just install libraries and import them without the
need of pathname normalisation.

When trying to import the "(srfi lists)" library, Ikarus searches the
following suffixes of "srfi/lists":

/main.ikarus.sls
/main.ikarus.ss
/main.ikarus.scm
/main.sls
/main.ss
/main.scm
.ikarus.sls
.ikarus.ss
.ikarus.scm
.sls
.ss
.scm

just replace "ikarus" with "ypsilon".

Original issue reported on code.google.com by mrc....@gmail.com on 21 Nov 2008 at 12:54

[GoogleCodeExporter]

Thank very much for your suggestion!
Ypsilon revision 280 searches library files as you suggested. Please try!
--fujita

$ ls foo
main.sls
$ cat foo/main.sls
(library (foo)
  (export)
  (import (rnrs))
  (display "(foo) imported\n"))
$ ypsilon --sitelib=.
Ypsilon 0.9.6-trunk/r281 Copyright (c) 2008 Y.Fujita, LittleWing Company 
Limited.
> (import (foo))
(foo) imported
>

Note: if you need libraries; for example, (foo) and (foo main), you should 
install
files in the following manner to avoid ambiguity.

$(SITELIB)/foo/main.sls       for (foo)
$(SITELIB)/foo/main/main.sls  for (foo main)

or

$(SITELIB)/foo.sls       for (foo)
$(SITELIB)/foo/main.sls  for (foo main)

Original comment by y.fujita...@gmail.com on 22 Nov 2008 at 2:52

• Changed state: Started

[GoogleCodeExporter]

This works. Thanks.

Original comment by mrc....@gmail.com on 23 Nov 2008 at 8:32

[GoogleCodeExporter]

Thank you for your reply. I close this issue :)
-- fujita

Original comment by y.fujita...@gmail.com on 25 Nov 2008 at 3:17

• Changed state: Fixed

[GoogleCodeExporter]

Ikarus's and Ypsilon's implicit "main" library names rules currently differ.  I 
think
a combination of the two's ways will make a better way as well as making them 
more
compatible.  See my latest comment at the bottom of:

  https://bugs.launchpad.net/ikarus/+bug/288003

What do you guys think?  Would there still be issues with the way I propose?  
We need
to figure out a robust no-problems-in-the-future convention.

Original comment by derick.e...@gmail.com on 16 Jan 2009 at 8:48

[GoogleCodeExporter]

Thank you for your message.

Yes, Ypsilon loads libraries by not obvious way. I would like to explain why it 
is.

--------------

First, I tried following rule for Ypsilon.

  (foo)
  "foo/main.ext"
  "foo.ext"

I found it has a problem with following library structure that using no 
implicit main.

  example:

  (power)          : compound library
  "power.ext"

  (power main)     : private library 1
  "power/main.ext"

  (power backup)   : private library 2
  "power/backup.ext"

  "(import (power))" loads "power/main.ext" that implements "(power main)"!

So, I understand why Ikarus and PLT use '_' suffix. However, because '_' looks
somewhat wired for me, I tried alternative search order as follows:

  (foo)
  "foo.ext"
  "foo/main.ext"

  example:

  (power)          : compound library
  "power.ext"

  (power main)     : private library 1
  "power/main.ext"

  (power backup)   : private library 2
  "power/backup.ext"

  "(import (power))" loads "power.ext" as expected.

But, It causes problem with following library structure that using implicit 
mains.

  example:

  (power)          : compound library
  "power/main.ext"

  (power main)     : private library 1
  "power/main/main.ext"

  (power backup)   : private library 2
  "power/main/backup.ext"

  "(import (power))" loads "power/main.ext" as expected.
  "(import (power main))" loads "power/main.ext" that implements "(power)"!

It seems that this problem appears only when library have "main" for last 
component.
So, I flip search order only if last component is "main", as follows:

  (foo bar)          : usual
  "foo/bar.ext"      : A
  "foo/bar/main.ext" : B

  (foo main)         : exceptional for last "main"
  "foo/main/main.ext": B
  "foo/main.ext"     : A

Now, it seems to work for both implicit mains and no implicit mains, but there 
is
drawback that library file layout may restricted if library that have "main" 
for last
component exists.

  example1:

  (power)          : existing compound library --implicit main
  "power/main.ext"

  (power main)     : new private library to add
  *** Must use "power/main/main.ext" because "power/main.ext" conflict with (power).

  example2:

  (power main)     : existing private library, --no implicit main
  "power/main.ext"

  (power)          : new compound library to add
  *** Must use "power.ext" because "power/main.ext" conflict with (power main).

--------------

> We need to figure out a robust no-problems-in-the-future convention.
I agree with you. I am expecting simple and easy to understand solution for 
this issue. 
Hopefully, without using '_'. :)

Regarding your proposal at [1],
I think its default precedence does not work on my first example.

--fujita

[1] https://bugs.launchpad.net/ikarus/+bug/288003

Original comment by y.fujita...@gmail.com on 26 Jan 2009 at 3:03

[GoogleCodeExporter]

On Mon, 2009-01-26 at 03:04 +0000, codesite-noreply@google.com wrote:
Comment #5 on issue 57 by y.fujita.lwp: missing support for main.sls
files
> http://code.google.com/p/ypsilon/issues/detail?id=57
> 
> Thank you for your message.

Thank you for helping figure this out.

> > We need to figure out a robust no-problems-in-the-future convention.
> I agree with you. I am expecting simple and easy to understand
solution for  
> this issue.
> Hopefully, without using '_'. :)
> 
> Regarding your proposal at [1],
> I think its default precedence does not work on my first example.

You are correct.  I retract that proposal.

Now I'm thinking this rule solves all the problems:

  (foo)
  "foo/^main^.ext"
  "foo.ext"

The key to it is it uses "^" in the file names for implicit mains.  This
character will never occur in the result of mapping library name
components to file name components because "^" will always be encoded,
thus conflicts can never happen, which I think solves all the problems.
Any encoded character in any position, as long as there's at least one,
would work.  This was mentioned in the middle part of [1].  It might
look wired but I think it needs to be wired because I think any
implicitly added file name component that uses all non-encoded
characters has the potential for some type of conflict which either
requires exceptional rules and/or restricts the set of what will work
together, and a wired name visually stands out as "for implicit" which I
like.  I chose "/^main^.ext" because it does not conflict with shell
input use and its only conflict is "^"s need to be escaped for regular
expressions; see Michael D. Adams overview of various possible
characters at [1].  I'm totally open to suggestions for what encoded
character(s) work/look best and where.

  example1:

    (power)          ; existing compound library, implicit main
    "power/^main^.ext"

    (power main)     ; new private library to add
    "power/main.ext" OR
    "power/main/^main^.ext"

  example2:

    (power main)     ; existing private library, no implicit main
    "power/main.ext"

    (power)          ; new compound library to add
    "power.ext" OR
    "power/^main^.ext"

  example rules:

    (foo)
    "foo/^main^.ext"
    "foo.ext"

    (foo main)
    "foo/main/^main^.ext"
    "foo/main.ext"

    (foo ^main^)
    "foo/%5emain%5e/^main^.ext"
    "foo/%5emain%5e.ext"

I think ".ext" could precede "/^main^.ext" without making a
difference?  And with this scheme, I think reverse mapping file names
to library names is always unambiguous?

As is now being discussed at [2], we need a coherent specification for
mapping libraries to files that implementors can refer to, probably in
the form of an SRFI.  I want it to include encoding of characters,
selecting implementation-specific libraries, and implicit
final-component file names.

[1] https://bugs.launchpad.net/ikarus/+bug/288003
[2]
http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/2a6a7636f5f
69573

Best,

-- 
: Derick
----------------------------------------------------------------

Original comment by derick.e...@gmail.com on 27 Jan 2009 at 2:58