#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 .

converting messy data formats

adde/universal conversion via screen scraping
adde/convert clonespy links
adde/browser/filename cleaner

mixing strings and numbers

7.17: adda/type/mixing strings and numbers:
. suppose the (+)-opererator can be used for
both addition and concatenation;
if we have to eval (string + number),
then the coercion should be to string,
since every number has a string image,
but not every string can eval to a number;
therefore, we should have it so that

(x as type) conversion syntax

3.23: adda/type/syntax/conversion:
. adda conversions should be like python:
val(type);
because try doing it the other way:
type(val):
if the type needs param's,
then it's not obvious whether this is a param'd type
or a type converting a value .

3.14: adda/syntax/conversions look like dimensions:
. in some situations, we may need to
specify the literal's datatype
with a conversion syntax;
conversion should work like dimensions,
as factors: a value is followed by its dimension .

[8.1:
. I'm wondering if that starts to look messy
for general expressions vs literals ...
we'll have a full expression
and then be expecting either a
terminator or a binary operator,
so then finding a typemark means a
conversion of the previous subexpression
(an atom, or a parenthetical).
. does ( f(x) type ) apply to f or x?
. maybe just as there is (x: type)
there could be (x:: type -- conversion)?
but that is counter to most popular uses of [::].
. ada may have had the best idea:
typemark( ... ) would tell you
that typemark was converting (...) .
. a compromise might be ( x(typemark) )
but that could be confused with
function application
-- and the same applies to ada's syntax
since we may want a conversion by
a parameterized type:
typemark(arg)(thing to convert)
-- lots for a reader to remember .
. the keyword "(as) would be memorable:
x as typemark
-- although people coming from Visual Basic
might be confused .
. using english is literally too wordy,
but conversions are mostly automatic,
and shouldn't be seen too often .]

 3.23: adda/type/syntax/context specification:
. perhaps the best syntax for specifying a value's type
(in contrast to converting a value to some type)
is to use the possessive syntax:
type`x,
where x can be any symbol defined by the type,
or be an parenthetical expression that is
returning a value of that type .