Merge with shymega/guile-rs

[shymega]

As we've discussed over email and over IRC on Mozilla/#guile-rs, this issue is to track the progress of merging this project with my guile-rs repository.

I have reached out to contributors of my guile-rs repository to get their permission for their contributions to be included into the new merged project of Rust bindings to GNU Guile.

[shymega]

I've heard back from the two other contributors to my version of guile-rs, who have given their permission for their code to be relicensed.

That has been approved, so in terms of code licensing, there are no issues with contributions.

[Javyre]

Sounds great! Ill add you as a contributor, you can create a new branch for the merge. Ill be glad to help out.

(mentioning @CherryMan for the licensing...) (edit: you should have write permissions to the repo now)

[shymega]

@Javyre Sure, I've got the invitation, accepted it.

I can create a branch, I'm not too sure how to begin the merging, and I don't know how you and @CherryMan wanted it to be structured. What should we begin with?

Cheers.

[cherryman]

There are some structures that are shared between both projects (namely the Guile[VM] and Scm types) which seem to be very similar, so they could easily be merged.

API changes

Guile

The following could be used from @shymega's branch

• shell method from GuileVM
• undefined_variable from GuileVM (up for discussion)

The define and define_subr1 calls are being implemented as macros in this repository, which allows for any number of arguments as well as optional arguments.

Scm

Many methods have already been implemented. There are some missing, which could be useful

• force_cast
• is_unsigned_integer and is_signed_integer (Would probably be done using Scm<Integer>

Encode/Decode

The remaining methods for the Scm type are check_type and case, which use the Encode/Decode system. @Javyre expressed a strong interest in it. Merging would require changing the way this branch does type conversion and use the Encoder system instead, which IMO is much nicer. There aren't too many methods for conversion, and some of them have been done already.

For example, see the string conversions in this branch in src/scm/string.rs and in @shymega's branch see src/repr.rs. I find that having a separate repr module is better since a separate module is used to define conversions between rust and guile types, however this is up for discussion.

Organisation

We could either track the changes here, since there aren't many, or make a milestone with multiple sub-issues. Since the merging isn't too complex, and will take place in a separate branch, I don't think we'll need an extra milestone.

For the merging itself, I don't have many ideas. One is to import as a git submodule and incrementally move over relevant sections. I'm sure there have been similar moves in the past by other projects, so if we find something similar then we could potentially use it as inspiration.

And finally, the biggest problem: what do we name the branch used for merging?

(@Javyre edited: minor corrections)

[shymega]

Sorry, just got back to taking a look at this issue.

Just wondering, what Rust channel are we targeting? Nightly? Stable?

I've created a branch on this project for me to work on. We also need to think about how to redirect people from my guile-rs repo to your one. I think it makes more sense to be associated with your project. I suppose a warning in the README would suffice!

[shymega]

Oh, also: I see a lot of build-deps for your version of guile-rs. Could we lose any dependencies? Probably not a bad idea to keep things simple :-)

[Javyre]

I'm always open to minimize dependencies But I'd to preserve current functionality as well...

IIRC, most of the dependencies come from the build script.. we could pre-generate the code to minimize these deps

We are targetting the stable channel.

I've been pretty busy with school myself (as well as @CherryMan ), I should be back on task in about a month on this project