#adda initialization

adda/initialization:
2015.1.2: image and string inputs:
. user-definable literal types reminded me of
user-programmable compilers
(what are the security implications of that?!)
but, the compiler doesn't need to be modifiable,
as the literals come as some composition of
just 5 literal types:
list, number, symbol enumeration, string, image .
. the type mgt's declaration of it's literal type
has nothing to do with the internal representation
of the type mgt's object's value;
so, for example, the string-initialized object
is not necessarily holding the string;
rather, just like the enum is converted to a number;
the type's mgt has its own parser
that converts the string into some data structure .
. the type's literal can be an image;
assuming the user's editor can display images,
the user can see the image or icon
instead of the image's hex representation .

2014.10.26:
. each interface definition can include
a value literal definition,
which describes the expressions that can be
fed to the assignment operation
(which includes parameter passing).
. the assignment procedure is expecting that
the value being assigned will have
the same datatype as the target's type;
so, each type mgt needs to define a function
that will convert literals into
an object of the expected type .
. for example, this is done implicitely
via enum definition (each symbol in the enumeration
can be assigned an integer,
or its position number will be its value,
and then anything expecting an enum
is expected to be implemented by an integer).
. generally though a literal could be
any tree (list of list of any standard literals)
and the type mgt could define a function
value( literal ).type
that repacks the literal into the object's
hidden internal type .
[1.2: value() could have a default input
for specifying the default initialization .]
. value(), aside from converting the literal
could also be used for init'-specific tasks .

. another way to handle literals
is to overload the assignment operation:
(theType)`= (theType)
(theType)`= (literal)
(theType)`= (inheritedType, extended values, ...).

. the literal assignments would simply
convert their input to theType
and then call the normal assignment
(theType)`= (theType).
which sees how large its incoming object is
and will possibly deallocate unneeded memory
or reallocate additional memory .

. besides defining value literals,
the interface can also define various functions
that can pack other types of lists
into the object's hidden internal tuple .
. for instance, to support an inherited type
a function could accept (supertype`obj, other inputs).

. the compiler checks that all variables
are initialized by either the user
or the type mgt's default .
. some of the assignment procedures
don't know whether they are doing an init or not,
which means their target may or may not be defined;
so, the compiler offers an automatic init'
that nullifies every new obj's trailer pointer .
[11.2: todo:
need to review about type tag expectations .]