2014/07/20

Oops - gauche-package regression

Alert for those who start writing new extention package with Gauche 0.9.4. When you create the skeleton files by gauche-package generate, you need to tweak the generated files to make them work.

Before going into details, I just describe what to do:

After generating skeleton files, edit configure script to add the following stuff right after ;; Output line:

(use gauche.package)
(let1 gpd-file #"~(cf$ 'PACKAGE_NAME).gpd"
  (with-output-to-file gpd-file
    (cut write-gauche-package-description
      (make <gauche-package-description>
        :name (cf$ 'PACKAGE_NAME)
        :version (cf$ 'PACKAGE_VERSION)
        :configure (string-join (command-line))))))

And in Makefile.in, remove configure from the rule of maintainer-clean target, as shown in this patch.

  maintainer-clean : clean
-       rm -rf $(CONFIG_GENERATED) configure VERSION
+       rm -rf $(CONFIG_GENERATED) VERSION

Now, the explanation.

0.9.4 is shipped with new gauche.configure module, which attempts to replace autoconf-based configuration to build Gauche extensions.

Autoconf is well-built system, but it makes great effort to make configure scripts work on a minimal environment. In order to do so, it requires an extra step for developers to generate configure script from configure.ac etc. It is reasonable for distributing basic tools to the destination platform that lacks them.

However, when installing Gauche extensions, we know for sure that the destination platform already have Gauche installed, so the configure script doesn't need to be restricted in the minimal shell features. In fact, we can write configure script itself as a Gauche script, eliminating the step for developers to generate configure script from other files.

Nowadays more and more projects don't bother to create distribution tarballs and ask users to just pull from repository. Making configure script a source, not something to be generated, has advantage for not requiring users to run autoconf.

So I migrated the default skeleton files to use new configure features. But I forgot to cover a couple of points, as shown above.

The .gpd file is to keep metadata of the extension package. In the old skeleton configure.ac file, it is generated by calling gauche-package make-gpd. My plan is to provide an easier API in gauche.configure, which will be in the next version of Gauche.

And of course, we no longer need to remove configure in maintainer-clean!

Autoconf has comprehensive feature tests gauche.configure can't match. If you need advanced feature tests, you may still want to use autoconf-based configuration. Just give --autoconf option to gauche-package generate, and it gives you configure.ac.

gauche-package generate --autoconf YOUR-PACKAGE-NAME

Tags: 0.9.4, Extension, gauche-package

2014/07/20

0.9.4 is out!

Thanks for those who tested release candidates.

Tarball:

• http://prdownloads.sourceforge.net/gauche/Gauche-0.9.4.tgz
• http://prdownloads.sourceforge.net/gauche/Gauche-0.9.4.tgz.asc (signature)

Windows installer (including Gauche-gl):

• http://prdownloads.sourceforge.net/gauche/Gauche-mingw-0.9.4.msi
• http://prdownloads.sourceforge.net/gauche/Gauche-mingw-0.9.4.msi.asc (signature)

Release notes:

• English: http://practical-scheme.net/gauche/gmemo/?Release%200.9.4
• Japanese: http://practical-scheme.net/gauche/gmemo/?%A5%EA%A5%EA%A1%BC%A5%B9%200.9.4

Tags: Gauche, r7rs

2014/05/03

Keyword-symbol integration

Aargh, Already May?　Unbelievable. Final stretch turned out to be a long marathon.

If you monitor github repo https://github.com/shirok/Gauche you know it's actively developed, though most changes are minor fixes. I cleared the items on the table I listed last time for 0.9.4 release, but I realized I left out one major item: Keywords.

Gauche has a keyword type, disjoint from other types. I think I inherited it from STk. I also speak Common Lisp and having :keyword is so natural that I tend to forget that treating keywords specially actually conflicts RnRS spec. In RnRS, they must be symbols.

In fact, it became an issue when we adopted srfi:42, in which symbols beginning with : is used. Alex Shinn employed a clever trick during macro expansion to work around the issue.

Now, with more R7RS libraries coming out, I expect this design would be a bigger obstacle.

Some implementations that have keywords avoid this conflict by adopting a syntax different from symbols, e.g. #:keyword. In fact, my original plan was to make the keyword syntax customizable, :keyword, #:keyword or even keyword: (DSSSL style; anybody remember?). That's why we don't have the colon in keyword's name slot. However, mixing these syntax is just confusing, and I strongly prefer :keyword anyway. #:keyword has a merit of not conflicting with symbols, but they are visually too intrusive, and it has been used as uninterned symbols in CL and Gauche.

Technically we don't need to make keywords separate from symbols; indeed, in CL, keywords are just symbols in the keyword package. We can just do the same:

• We can make <keyword> a subtype of <symbol>. Identifiers beginning with ':' are read as an instance of <keyword>, but they're also symbols. So keyword? still works, but keywords also return #t for symbol?.
• We can have gauche.keyword module, that acts as if it has constant bindings of every possible keywords, bound to itself. In reality, we create such bindings on the fly as keywords are read.
• Then the gauche module can inherit gauche.keyword, so that existing usage of Gauche keywords will be preserved. They are symbols, but evaluate to themselves. It also allows programmers to rebind keywords (locally or at the toplevel of their modules) but the effect stays local, and those who conduct such an act should know what they are doing.
• The r7rs module does not inherit gauche.keyword, hence symbols starting with : are just ordinary symbols. All portable R7RS code should run.
• If one wish to use Gauche features and import gauche.core, the bindings of those keywords come with it, so you can call Gauche procedures with keyword arguments just like you're using Gauche.

This looks reasonable to me. There are a couple of catches, but I think they are minor and easily worked around:

• If you import some of Gauche's procedures into R7RS code by (import (only (gauche core) foo ...)), keywords are not imported, so you should call it something like (foo ':bar b ...) i.e. quoting keywords.
• If you import both an R7RS library that exports bindings of symbols that begins with : and gauche.core into R7RS code, whichever comes later would shadow the former. Generally you need to import gauche.core first.

However, this change needs to break the backward compatibility of certain cases, and it turned out it's a bit complicated. I'll describe it later.

Tags: r7rs, keyword

2014/02/07

Almost there?

Just committed changes to cover R7RS-small support.

• Exact complex numbers are not in yet. In next version, I hope.
• Problems have been reported regarding hygienic macro-defining macros (Macros that expands to let-syntax). It's a long-standing issue, but I'm going to give one more try before releasing 0.9.4. If it turns out a lot of work to fix, though, I'll postpone it to the next version.
• Currently, toplevel import is Gauche's by default, which is different from R7RS import. So you need -r7 option for gosh to run R7RS scripts. However, as R7RS gets adopted more widely, users would expect R7RS code just works on Gauche, so requiring -r7 option may confuse them.
  I can't change Gauche's import semantics for the backward compatibility, and I don't want to extend Gauche's import to support R7RS semantics, since those two have different functions (R7RS import ≒ Gauche's use ＝ require + Gauche's import).
  However, I had another idea. The import issue only arises when a Scheme script uses it on toplevel. When a Scheme script is given, gosh start evaluating it in user module. So we can provide the third import form in user module, which checks its arguments and dispatch to either R7RS import or Gauche import.
• And of course, I need to go through documents to update for R7RS.

Tags: r7rs, 0.9.4

2013/11/12

Getting closer

Just added r7rs test suite (taken from ChibiScheme) to the repo.

About two dozens of tests fail, because of the following:

• Lack of exact complex number support. Most of test failures, including number writer tests, are due to this. This isn't required in r7rs, but I plan to implement it anyway just for my satisfaction. (If I don't have time, though, I may put it off).
• Behavior of 'write'---currently it works like write-circular. I'm rewriting the writer submodule and that will address this. (In the current HEAD, you may sporadically see a test failure in gauche.threads, telling assertion failure in the writer submodule. It'll be also fixed in this rewrite.)
• Behavior of 'equal?' (this isn't tested in r7rs test suite.) --- Gauche's current implementation doesn't conform r7rs since it diverges on circular structures.
• Feature 'r7rs' ---- I'll turn this on when above issues are addressed.

This is all I'm aware of to support r7rs. Once done, I'll call it 0.9.4.

My work project is in crunch time, though, so I can't guarantee when it'll be done.

Tag: r7rs