Copy risc compiler stuff to mom
Start to separate the layers. wip, just checkin in to see the following changes better
This commit is contained in:
@ -3,10 +3,10 @@ module Parfait
|
||||
# A Block is a callable object, much like a CallableMethod.
|
||||
# Surprisingly similar in fact, as the block is really only missing the name.
|
||||
#
|
||||
# The difference lies mostly in the way they are compiled
|
||||
# The difference lies mostly in the way they are compiled (scope and return)
|
||||
#
|
||||
# Also both have a list of blocks defined in their scope. But this is
|
||||
# notimplemented for blocks yet
|
||||
# not implemented for blocks yet
|
||||
#
|
||||
class Block < Callable
|
||||
|
||||
|
@ -1,14 +1,15 @@
|
||||
module Parfait
|
||||
|
||||
# An Object is really a hash like structure. It is dynamic and
|
||||
# An Object is conceptually a hash like structure. It is dynamic and
|
||||
# you want to store values by name (instance variable names).
|
||||
#
|
||||
# One could (like mri), store the names in each object, but that is wasteful in both time and space.
|
||||
# Instead we store only the values, and access them by index.
|
||||
# One could (like mri), store the names in each object, but that is wasteful in both
|
||||
# time and space.
|
||||
# Instead we store only the values, and access them by index (bit like c++).
|
||||
# The Type allows the mapping of names to index.
|
||||
|
||||
# The Type of an object describes the memory layout of the object. In a c analogy, it is the
|
||||
# information defined in a struct.
|
||||
# The Type of an object describes the memory layout of the object. In a c analogy,
|
||||
# it is the information defined in a struct.
|
||||
# The Type is a list of the names of instance variables, and their value types (int etc).
|
||||
#
|
||||
# Every object has a Type to describe it, so it's *first* instance variable is **always**
|
||||
@ -21,14 +22,13 @@ module Parfait
|
||||
# But Objects must also be able to carry methods themselves (ruby calls singleton_methods)
|
||||
# and those too are stored in the Type (both type and class include behaviour)
|
||||
|
||||
# The object is an List of values of length n
|
||||
|
||||
# The Type is a list of n names and n types that describe the values stored in an actual object.
|
||||
|
||||
# The object is an "List" (memory location) of values of length n
|
||||
# The Type is a list of n names and n types that describe the values stored in an
|
||||
# actual object.
|
||||
# Together they turn the object into a hash like structure
|
||||
|
||||
# For types to be a useful concept, they have to be unique and immutable. Any "change", like adding
|
||||
# a name/type pair, will result in a new instance.
|
||||
# For types to be a useful concept, they have to be unique and immutable. Any "change",
|
||||
# like adding a name/type pair, will result in a new type instance.
|
||||
|
||||
# The Type class carries a hash of types of the systems, which is used to ensure that
|
||||
# there is only one instance of every type. Hash and equality are defined on type
|
||||
|
@ -5,7 +5,7 @@ module Parfait
|
||||
# Type objects are already created for args and locals, but the main attribute
|
||||
# is the source, which is a Vool::Statement
|
||||
#
|
||||
# Classes store VoolMethods, while Types store CallableMethod
|
||||
# Classes store VoolMethods, while Types store Risc::CallableMethod
|
||||
# A Type referes to a Class , but a Class (interface) is implemented by many types
|
||||
# as it changes during the course of it's life. Types do not change. Objects have
|
||||
# type, and so only indirectly a class.
|
||||
|
Reference in New Issue
Block a user