This commit is contained in:
Torsten Rüger 2019-12-01 12:09:24 +02:00
parent 308670b90c
commit 61b6496029
4 changed files with 9 additions and 18 deletions

View File

@ -6,8 +6,8 @@ In essence the slot_language lets us code the slot_machine.
## Problem
The Problem with the current way is that some of the slot_machine instruction are
really quite complex. They are really more function than instructions.
The Problem with the current way is that some of the slot_machine instructions are
really quite complex. They are really more functions than instructions.
This is especially true for everything around the dynamic call. Dynamic call itself
is still ok, but resolve_method is too much. And it even uses method_missing, another
@ -41,10 +41,10 @@ the message.
## Syntax (projection)
Since we are not defining methods, there is no seperate scope. We create objects that
Since we are not defining methods, there is no separate scope. We create objects that
will transform to SlotMachine Instructions _in_ the scope of the current method.
In other words they will have access to the compiler and the callable, when transforming
to SlotMachine (similar to Sol in that way). This means at compile time we have
to SlotMachine (similar to Sol in that way). This means at compile time we
can use the frame type and constants, while we can always assume the Message (and not
much else) at runtime.

View File

@ -1,10 +1,10 @@
module SlotMachine
# The Compiler/Collection for the SlotMachine level is a collection of SlotMachine level Method
# compilers These will transform to Risc MethodCompilers on the way down.
# The Compiler/Collection for the SlotMachine level is a collection of SlotMachine level
# Method compilers These will transform to Risc MethodCompilers on the way down.
#
# As RubyCompiler pools source at the sol level, when several classes are compiled
# from sol to slot, several SlotMachineCompilers get instantiated. They must be merged before
# proceeding with translate. Thus we have a append method.
# from sol to slot, several SlotMachineCompilers get instantiated. They must be merged
# before proceeding with translate. Thus we have a append method.
#
class SlotCollection
attr_reader :method_compilers

View File

@ -18,7 +18,7 @@ module Sol
return SlotMachine::SlotDefinition.new(SlotMachine::LambdaConstant.new(parfait_block(compiler)) , [])
end
# create a block, a compiler for it, comile the bock and add the compiler(code)
# create a block, a compiler for it, compile the block and add the compiler(code)
# to the method compiler for further processing
def compile( compiler )
parfait_block = self.parfait_block(compiler)
@ -26,7 +26,6 @@ module Sol
head = body.to_slot( block_compiler )
block_compiler.add_code(head)
compiler.add_method_compiler(block_compiler)
nil
end
def each(&block)

View File

@ -1,8 +0,0 @@
require_relative "helper"
module SlotLanguage
class TestSlotCompiler < MiniTest::Test
include SlotHelper
end
end