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

2013/09/18

Macro system extension

I finally added syntax-rules extensions (srfi:46) to Gauche, that makes Gauche's hygienic macro system compatible to R7RS (except a few known bugs).

The current hygienic macro expander is written in C which is an ugly pile of spaghetti. Originally I planned to ditch the legacy code and to write an explicit-renaming macro expander as the new basis of our hygineic macro system, then to implement syntax-rules on top of it.

I like ER-macro since it's transparent to what it is doing for hygienity. It doesn't necessary to be the easiest one to use--- destructuring the input form, then renaming identifiers explicitly would be cumbersome for day-to-day programming. But those things can be easily alleviated by combining other tools. For example, we can just use util.match matcher to destructure the input form (instead of yet another pattern matcher tied to macro system).

In fact, in er-macro branch in the repo I implemented ER-macro expander to some extent. But it turned out I need some more time to substitute the low-level macro layer completely. A major issue is to keep compatibility between ER-macro, which allows raw symbols inserted by the macro expander to capture symbols in macro calls, and the current syntax-rules implementation which turns all symbols into identifiers. (The same issue is described by mjt here, in Japanese.)

Since I'd like to push out R7RS compatible release sooner, I just went into the legacy code and added some more spaghetti to make it work as srfi:46.

＊ ＊ ＊

I realized this enhancement makes syntax-rules a lot more useful. I also adapted define-values form to R7RS, which allows generic formals, as follows:

(define-values (x y . z) (values 1 2 3 4))

z => (3 4)

With R7RS syntax-rules it's not difficult to distinguish proper list and inproper list (see Gauche:lib/gauche/defvalues.scm).

Tags: macro, r7rs, srfi-46

2013/08/01

.gaucherc

When gosh is started in the interactive REPL mode, it loads ~/.gaucherc if it exists. I suppose it may be handy if the user needs his own local setup, even though I personally haven't used the rc file yet---I guess it's a sort of traditional Unix culture.

Recently I realized this feature interferes with R7RS mode. The .gaucherc file is loaded into #<module user>, but what's visible from the user module differs greatly when gosh is invoked with -r7 option. It'll be quite difficult to write .gaucherc that can work both in traditional Gauche mode and r7rs mode.

(Note: I say r7rs mode and Gauche mode, but it's not that there are two separate modes, except the planned reader compatibility modes. You can load R7RS library from standard Gauche program and load Gauche library from standard R7RS program, no matter whether you start gosh with -r7 option or not. The -r7 option merely specifies which environment you're in at the time interactive REPL starts.)

I considered a few options:

• If -r7 option is given, try to load a different rc file, e.g. ~/.gaucherc-r7. This option is less appealing: It scatters more rc files in the home directory. Besides, I expect things you want to do in rc file are likely to need to access Gauche-specific features (e.g. add-load-path) and you can't do that easily from R7RS environment. You would need to create a separate module, e.g. mysetup.scm for the setup code, then (import (mysetup)) from .gaucherc-r7.
• Let rc file be loaded in a module other than user, say, gauche.user module. Then you can use Gauche features in .gaucherc, regardless of -r7 option. This is clean, but adding a new module just for the rc file seems a bit overkill. Besides, it is incompatible to the current version if a user defines something in .gaucherc and expect it visible from the user module.
• Drop .gaucherc support. This is a tempting solution, for it makes things simpler. But who knows? Sometimes this kind of hook comes handy unexpectedly.

Eventually I settled on somewhat compromised design.

• We load .gaucherc to #<module user>, as we have been doing.
• When gosh is started with -r7 option, the initial module will be #<module r7rs.user>, not #<module user>.

It looks a bit ad-hoc solution, but let's give a shot.

Tags: gosh, r7rs, gaucherc

2013/07/06

It seems working. But typing S-expr in a small keypad is such a pain.

Tag: iOS

2013/05/22

R7RS support

We don't have an official announcement yet, but it seems that R7RS is ratified. Yay! Great thanks to the WG members for long and hard work to realize it.

I couldn't participate in discussions as much as I did for R6RS mainly due to time constraints, but another reason is that I was generally happy about the drafts, unlike what I felt during R6RS development.

I don't hate R6RS; they have some parts I like (e.g. I/O system) and I expect them to be in R7RS-large. I just think R6RS was too ambitious; it tried so hard to plug all the loopholes that some of its parts were introduced prematurely, IMHO. R7RS-small isn't perfect; but it fixes some of the biggest shortcomings of R5RS and "good enough" to move on. I believe, in order to fix the remaining defects, it's better to wait quasi-standard SRFIs that are adopted by most active implementations. The standard can come later, merely to codify the de-facto and proven ways, as R7RS did for some SRFIs.

＊ ＊ ＊

The developlemnt HEAD of Gauche already has some R7RS support. If you invoke gosh as gosh -r7, it starts REPL with R7RS environment. Currently it implicitly imports all the R7RS-small libraries. You can also load files containing define-library form.

(The -r7 option only sets up the default behavior, and it's not that there's a distinct R7RS language mode. You'll be able to use R7RS library from Gauche code, and import Gauche library from R7RS code. Aside from the reader mode described below, the difference between R7RS and Gauche are merely namespaces.)

However, it's not quite ready yet to load portable R7RS libraries. The biggest obstacle is the lexical syntax---the \xNN; style escaping in strings and symbols are not supported yet, because of the backward compatibility problem. Gauche has been using \xNN (two-digits fixed, no semicolon terminator) style. It doesn't generally appear in the source code (the unicode escape, \uNNNN, is preferred), but it appears in datafiles dumped by write. Changing it would break existing datafiles, which would be a disaster.

There are also a few minor reader incompatibilities. For example, Gauche treats single quote as delimiters, so abc'def is parsed as a symbol abc and a list (quote def). In R7RS, this is a reader error.

My plan is to provide a few reader modes:

• Legacy Gauche: Completely backward compatible
• r7rs-compatible: Accepts both format, preferring r7rs when ambiguous
• r7rs-strict: Reject syntax that doesn't comply r7rs

There are also small number of unsupported library functions and syntaxes, which I'm implementing gradually at my spare time. See lib/r7rs.scm to check what aren't supported yet.

The high-level macro also need to be enhanced to comply R7RS. Internal define-syntax is yet to be supported.

＊ ＊ ＊

The R7RS import form works differently from Gauche's import. Gauche's one purely works on on-memory module objects and doesn't involve loading files. R7RS import is rather similar to Gauche's use, which is explained as require and (Gauche's) import.

I pondered a few options for some time: Overload import form with dual functionalities? Change Gauche's import so that it work like R7RS import? Finally I decided to implement completely separate forms. Gauche's import is mostly used in define-module form, which isn't R7RS, so I expect there's not much confusion. We can always rename Gauche's import to something like import-module in future.

Tags: r7rs, import