Regarding the modern RacketVM

[Abhinav Sharma]

Hello racket-dev team :)

I've been reading the source code for racket and learning more about the internals via inside racket seminars etc, it has made me really curious about what gives racket this amount of extensibility!

I've found other scheme implementations intriguing as well, so I'll ask my question with a context

a. There's ChezScheme with a smaller core, nanopass compiler and without the VM and bytecode - with a neat C codebase.

b. There's GuileVM with a RacketVM like concept about a functional bytecode ( as opposed to the .net or java bytecode), with a reversible functional assembly-code https://www.gnu.org/software/guile/manual/html_node/Assembly.html#Assembly

c. There's RacketVM which is clearly moving towards nanopass compiler too ( could you please update me about that? ).

d. Does racket has a Gambit or Chicken like C transpiler option?

My questions are,

1. Is it possible to use any racket lib written in other dialects like hackett or rosette in racket - directly or byte-code compiled?

2. Which files are undergoing a change from *.c to *.rkt extension? Apart from the Leif Andersen's repo is there any other resources that'd help me understand the proposed changes better?

3. What does the team feel about the C-codebase and about plans to modernize it - what's the roadmap?

Thank you,

Abhinav

[Matthew Flatt]

Hi Abhinav,

At Sat, 11 Feb 2017 16:32:47 +0530, Abhinav Sharma wrote:
> 1. Is it possible to use any racket lib written in other dialects like
> hackett or rosette in racket - directly or byte-code compiled?

When you run from source, it is compiled internally to bytecode, so
using the library source or in bytecode form should be the same.

> 2. Which files are undergoing a change from *.c to *.rkt extension? Apart
> from the Leif Andersen's repo is there any other resources that'd help me
> understand the proposed changes better?

See the "linklet" branch of the "mflatt/racket" repo on GitHub:

https://github.com/mflatt/racket/tree/linklet

The "pkgs" directory has new subdirectories:

* "expander" --- an essentially complete rewrite of the macro
expander, module system, and reader

* "regexp" --- an essentially complete rewrite of the regexp matcher

* "path" --- a barely started rewrite of path operations

* "port" --- a barely started rewrite of input and output ports

Next on my list is the thread and events subsystem, and so on. The goal
is to replace nearly all of the C code with Racket implementations.

> 3. What does the team feel about the C-codebase and about plans to
> modernize it - what's the roadmap?

I hope it's ok if I defer this question for a little while (a couple of
weeks at most), since I should be able to give a better answer soon.


Matthew

[Abhinav Sharma]

Sure, I understand that there are a lot of moving parts.

Please do keep me posted, I'm looking for opportunities to contribute, as per my skills)

On Feb 11, 2017 6:07 PM, "Matthew Flatt" <mfl...@cs.utah.edu> wrote:

Hi Abhinav,

At Sat, 11 Feb 2017 16:32:47 +0530, Abhinav Sharma wrote:

> 1. Is it possible to use any racket lib written in other dialects like
> hackett or rosette in racket - directly or byte-code compiled?

When you run from source, it is compiled internally to bytecode, so
using the library source or in bytecode form should be the same.

> 2. Which files are undergoing a change from *.c to *.rkt extension? Apart
> from the Leif Andersen's repo is there any other resources that'd help me
> understand the proposed changes better?

See the "linklet" branch of the "mflatt/racket" repo on GitHub:

  https://github.com/mflatt/racket/tree/linklet

The "pkgs" directory has new subdirectories:

 * "expander" --- an essentially complete rewrite of the macro
   expander, module system, and reader

 * "regexp" --- an essentially complete rewrite of the regexp matcher

 * "path" --- a barely started rewrite of path operations

 * "port" --- a barely started rewrite of input and output ports

Next on my list is the thread and events subsystem, and so on. The goal
is to replace nearly all of the C code with Racket implementations.

> 3. What does the team feel about the C-codebase and about plans to
> modernize it - what's the roadmap?