----- Original Message -----
From: "Aaron Gray" <[EMAIL PROTECTED]>
To: "Fundamentals of New Computing" <[email protected]>
Sent: Saturday, December 06, 2008 2:53 AM
Subject: Re: [fonc] x86_64...
apparently both this, and my effort, had independently discovered the
idea of having 2 different this/self values (in my case, this was due to
the issue of mixing delegation with class/instance, where I have
delegation methods which accept the self which recieved the original
method call, and normal virtual methods get the self from the object
containing the method). however beyond this I suspect the object systems
differ notably (my system is based mostly on the use of a class/instance
system and interfaces).
There is more about IDC's Lieberman prototype implementation here :-
http://piumarta.com/pepsi/prototypes.html
Aaron
yeah...
I have looked over the project a bit more.
it provides a few interesting ideas, and even points out a few things in the
Win32 API I was not aware of (namely, it is possible to introspect the app's
symbol table and similar without having to load and process the app's
binary, ...).
but, yes, it is a very different sort of project it seems.
most is written in SmallTalk, and seems to be a mostly centralized and
integrated project;
it seems that the implementation written in itself is actually meaningful,
in that the C version of the implementation seems to be largely the compiler
output from an ST->C compiler, which I suspect is also located in the
project.
more so, it has some things merged together which are in my projects several
different subsystems:
apparently it deals with machine code generation, low-level code generation
issues, ... all in a single place.
it is also so clear what separates one thing from another (there does not
appear to be any clear separation between subsystems, ...).
now, in my case, I have different libraries:
BGBASM, which provides the assembler and dynamic linker (also disassembler,
code for managing symbol lookup, ...), accepts data in a textual form
similar to NASM;
VRM, which provides low-level codegen (register allocation, largely
abstracts over processor level register and type handling, ...);
RPNIL, accepts RPN based language for describing the code to be compiled
(granted, the existing RPNIL compiler also includes many things since moved
to VRM);
..
I have not ran a line counter, but I suspect this project is some orders of
magnitude smaller than my project (maybe a 10x or more code-size
difference), or, at least, this project is a little smaller than 250 kloc...
I would suspect the are both advantages and disagvantages to having things
integrated or isolated.
integrated, pros:
there is much less code to work with, and so drastic changes can be done
more readily;
the same task can be accomplished with far less code, and via a potentially
faster process.
integrated, cons:
there is much less abstraction;
can become a horrible and unworkable mess in non-OO languages (such as C);
it is not really possible to reuse components in different contexts, since
the context is integrated with the component;
in this case, it is not possible to utilize alternate capabilities or
implications of a component, because as it so happens many of these
capabilities are not implemented (for example, writing the assembler does
not give one a disassembler almost for free, ...);
..
modular, pros:
components can be replaced with others to give new and different
functionality;
components can be used in a wider variety of contexts;
it may be possible to make use of far more elaborate and complex
transformation processes;
it provides an alternative to code duplication and modification;
it keeps one thing isolated from the inner workings of other things;
it is easy to provide a good number of possible "routes" and thus
drastically different behavior and results, as well as making it more
possible to accomodate alternate components with merged functionality;
..
modular, cons:
much more code may be needed;
often, lots of code is duplicated between modules;
general structures from one subsystem may be mirrored in another, even
though there is no direct interaction between these structures;
a task involving numerous modules and stages may run much slower than one
implemented as a single integrated component;
although the internals of accomplishing a task are kept flexible, and the
whole structure becomes flexible, the way in which the general process is
approached becomes fairly rigid;
the APIs become much like impassible walls;
..
as a result, with a modular system one has to be fairly careful with how
they design their APIs and what they expose and where. this is because,
things hidden well behind the wall can be changed as needed, any
functionality which touches or crosses the wall may become "set in stone"...
so, the design of specific APIs, subsystems, and rules of interaction,
becomes almost as much a central part of the project as the code itself.
one may end up larglely writing their own code for the primary reason that
most existing code does not do the right things in the right way (many
pieces of code don't like seeing themselves as a tiny and rigidly defined
piece of machinery embedded inside a much larger system, or they might do
the right thing in the wrong way, or in some rare cases the wrong thing in
the right way).
..
psychology may relate to all this as well, since apparently I am an ESTJ
(yes... people here can revile in horror...), and this may all relate to how
I approach coding...
BTW: I am considering the thoughts and implications of in my case doing
something similar to 'coke'...
the big hairy issue though is that I would be compiling it to the JVM, which
is slightly different from the normal way languages of this sort operate.
as well, considering ideas for representing a wider variety of data types in
S-Exps (at present, S-Exps force a fairly narrow type model). new syntax
will probably be related to serializing classes and instances, inline XML,
..
#X<foo bar="text">baz...<br/>again...</foo>
in the past, I had not done this, but more because I had usually been using
S-Exps as a convinient way of dumping internal data in a readable form (but
not as much for actual/useful data serialization).
as is, I lack any "capable" data serialization format.
S-Exps work, but only represent a narrow range of types (lists, arrays,
atomic values, symbols, keywords, ...).
XML can be used to implement a data serialization format, but is not in
itself such a format, and it is a pain to make it do so (and efficiently,
since I don't currently have support for SAX, and the use of DOM for data
serialization is slow and expensive).
I have not maintained any of my binary serialization formats (most are
narrow and only serialize the particular kind of data I am looking to
serialize at the time).
..
best bet is still almost to try to hack a much larger syntactic type model
onto S-Exps (as noted above).
as is, it can serialize objects from my older prototype system, but I could
lower these objects from their privledged place in the syntax (especially
since for many uses my newer class/instance system is likely to absorb many
of the use cases of this older system, however the systems are sufficiently
different to where each likely has meaningful use cases).
in particular:
{x: 3 y: 4}
may be downgraded to:
#{x: 3 y: 4}
#C and #O may be added and intended for serialized classes and instances.
#C<classname>{ stuff I have yet to decide on... }
#O<classname>{ key: value}
#O"app/Foo"{x: 3 y: 4}
most likely, I could use special serialization/deserialization handling for
classes and instances, given classes and instances are statically typed in
my framework...
note: classes and instances may also meaningfully absorb many uses of ad-hoc
structural types (which posed a sufficient pain for data serialization and
deserialization that in the past I had generally not bothered with any kind
of generalized data serialization...).
may use the "traditional" syntax for inline references:
'#<num>=' and '#<num>#', even though this syntax is horrid IMO.
in either case, it is uncertain how to efficiently encode references apart
from causing a potentially serious cost to serialization performance
(recursively checking from each compound element if it is used elsewhere
could quickly become an O(n^2) cost).
however, it could be possible by using a separate pass which would keep
track of every non-atom in an array, and transferring any duplicated element
to a separate array (making this essentially a linear complexity).
in this case, for the output pass, only the first occurence is serialized
(checking if it has occured in the table), and for all following occurences
it is referenced.
I am likely to require a strictly linear encoding process (AKA: no forward
references), although forward references could be allowed if a 2-pass
parsing scheme were used (references are initially given "placeholders", and
the correct values are substituted in place via a secondary "un-flattening"
pass).
potentially, I could also split out merged forms and serialize them
beforehand (makes more sense for automatically serialized data, and may
improve readability in many cases, avoiding producing a potentially massive
partial nested graph of objects followed by lots of smaller fragmentary
references).
first form:
{z: 5 _parent: #1={x: 3 y: 4}}
{w: 7 _parent: #1#}
if forward refs were possible:
{z: 5 _parent: #1#}
{w: 7 _parent: #1={x: 3 y: 4}}
if splitting is done, and the table is serialized first:
#;#1={x: 3 y: 4}
{z: 5 _parent: #1#}
{w: 7 _parent: #1#}
this would work because my parser still parses expression comments, but then
discards the results.
for now, I will probably not face the issue of method and function
serialization (it would be both ugly and unproductive to dump out masses of
disassembled functions, and far less certain that any such dumps could be
re-assembled into a working form anyways...). so, any methods which have
been compiled to machine code would probably be serialized as symbolic
references (C-side function name).
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
