Skip to content

WIP: Switch to markdown and fix code blocks #49

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Prev Previous commit
Next Next commit
replace @ with backticks in fin.textile
  • Loading branch information
BuonOmo committed Apr 17, 2021
commit dfd40588a54d46f20880f8253007a9819e763c05
54 changes: 27 additions & 27 deletions fin.textile
Original file line number Diff line number Diff line change
@@ -6,11 +6,11 @@ h1. Final Chapter: Ruby's future

h2. Issues to be addressed

@ruby@ isn't 'completely finished' software. It's still being developed,
`ruby` isn't 'completely finished' software. It's still being developed,
there are still a lot of issues. Firstly, we want to try removing
inherent problems in the current interpreter.

The order of the topics is mostly in the same order as the chapters of
The order of the topics is mostly in the same order as the chapters of
this book.


@@ -43,41 +43,41 @@ there might be the necessity to consider Incremental GC.

h3. Implementation of parser

As we saw in Part 2, the implementation of @ruby@ parser has already utilized
@yacc@'s ability to almost its limit, thus I can't think it can endure further
As we saw in Part 2, the implementation of `ruby` parser has already utilized
`yacc`'s ability to almost its limit, thus I can't think it can endure further
expansions. It's all right if there's nothing planned to expand,
but a big name "keyword argument" is planned next
and it's sad if we could not express another demanded grammar because of the
limitation of @yacc@.
limitation of `yacc`.


h3. Reuse of parser

Ruby's parser is very complex. In particular, dealing with around @lex_state@
Ruby's parser is very complex. In particular, dealing with around `lex_state`
seriously is very hard. Due to this, embedding a Ruby program or creating a
program to deal with a Ruby program itself is quite difficult.

For example, I'm developing a tool named @racc@,
which is prefixed with R because it is a Ruby-version @yacc@.
With @racc@, the syntax of grammar files are almost the same as @yacc@
For example, I'm developing a tool named `racc`,
which is prefixed with R because it is a Ruby-version `yacc`.
With `racc`, the syntax of grammar files are almost the same as `yacc`
but we can write actions in Ruby.
To do so, it could not determine the end of an action without parsing Ruby code
properly, but "properly" is very difficult. Since there's no other choice,
currently I've compromised at the level that it can parse "almost all".

As another example which requires analyzing Ruby program,
I can enumerate some tools like @indent@ and @lint@,
I can enumerate some tools like `indent` and `lint`,
but creating such tool also requires a lot efforts.
It would be desperate if it is something complex like a refactoring tool.

Then, what can we do? If we can't recreate the same thing,
what if @ruby@'s original parser can be used as a component?
what if `ruby`'s original parser can be used as a component?
In other words, making the parser itself a library.
This is a feature we want by all means.

However, what becomes problem here is, as long as @yacc@ is used,
However, what becomes problem here is, as long as `yacc` is used,
we cannot make parser reentrant.
It means, say, we cannot call @yyparse()@ recursively,
It means, say, we cannot call `yyparse()` recursively,
and we cannot call it from multiple threads.
Therefore, it should be implemented in the way of not returning control to Ruby
while parsing.
@@ -86,33 +86,33 @@ while parsing.

h3. Hiding Code

With current @ruby@, it does not work without the source code of the program to
With current `ruby`, it does not work without the source code of the program to
run. Thus, people who don't want others to read their source code might have
trouble.


h3. Interpretor Object

Currently each process cannot have multiple @ruby@ interpretors,
Currently each process cannot have multiple `ruby` interpretors,
this was discussed in Chapter 13.
If having multiple interpretors is practically possible, it seems better,
but is it possible to implement such thing?


h3. The structure of evaluator

Current @eval.c@ is, above all, too complex.
Current `eval.c` is, above all, too complex.
Embedding Ruby's stack frames to machine stack could occasionally become the
source of trouble, using @setjmp() longjmp()@ aggressively makes it less easy to
source of trouble, using `setjmp() longjmp()` aggressively makes it less easy to
understand and slows down its speed.
Particularly with RISC machine, which has many registers, using @setjmp()@
aggressively can easily cause slowing down because @setjmp()@ set aside all
Particularly with RISC machine, which has many registers, using `setjmp()`
aggressively can easily cause slowing down because `setjmp()` set aside all
things in registers.


h3. The performance of evaluator

@ruby@ is already enough fast for ordinary use.
`ruby` is already enough fast for ordinary use.
But aside from it, regarding a language processor,
definitely the faster is the better.
To achieve better performance, in other words to optimize,
@@ -136,17 +136,17 @@ So I profiled.

This is a profile when running some application but
this is approximately the profile of a general Ruby program.
@rb_eval()@ appeared in the overwhelming percentage being at the top,
`rb_eval()` appeared in the overwhelming percentage being at the top,
after that, in addition to functions of GC, evaluator core,
functions that are specific to the program are mixed.
For example, in the case of this application,
it takes a lot of time for regular expression match (@ruby_re_match@).
it takes a lot of time for regular expression match (`ruby_re_match`).

However, even if we understood this, the question is how to improve it.
To think simply, it can be archived by making @rb_eval()@ faster.
That said, but as for @ruby@ core, there are almost not any room which can be
easily optimized. For instance, apparently "tail recursive -> @goto@ conversion"
used in the place of @NODE_IF@ and others has already applied almost all
To think simply, it can be archived by making `rb_eval()` faster.
That said, but as for `ruby` core, there are almost not any room which can be
easily optimized. For instance, apparently "tail recursive -> `goto` conversion"
used in the place of `NODE_IF` and others has already applied almost all
possible places it can be applied.
In other words, without changing the way of thinking fundamentally,
there's no room to improve.
@@ -156,7 +156,7 @@ h3. The implementation of thread

This was also discussed in Chapter 19. There are really a lot of issues about
the implementation of the current ruby's thread. Particularly, it cannot mix
with native threads so badly. The two great advantages of @ruby@'s thread,
with native threads so badly. The two great advantages of `ruby`'s thread,
(1) high portability (2) the same behavior everywhere,
are definitely incomparable, but probably that implementation is something we
cannot continue to use eternally, isn't it?