. adda conversions should be like python:
because try doing it the other way:
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 .
. 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
-- 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:
where x can be any symbol defined by the type,
or be an parenthetical expression that is
returning a value of that type .