wrestling type syntax ambiguities

4.6: adda/syntax/
ensuring the 3 uses for colon are unambiguous:

. I had wondered if the labeling used in parameter naming
-- eg f(1,2) = f(p2: 2, p1: 1) --
could be confused with an array's description;
they are both mapping names to values,
but if you pass a named array to a function
are the names for the parameter's parts
or are they for the components of
an array passed to a single parameter?
. all functions are typed as having either one or more arg's,
so this will not be ambiguous,
though maybe not obvious to the casual reader .

. what about goto labels being confused with mappings?
all locals have to be typed explicitly,
and a goto label is a local,  so the type must be specified,
whereas parameter names and component names
will not include a type specification .

.  what about colons after lists as a shorthand:
a,b: type; -- same as (a.type, b.type)?
[..: or rather a,b: .type ]
b: value -- defines b as a constant?
. there could be situations where this could be
confused with component naming;
so, when using that shorthand,
the introduced names need to be dotted at the end,
to make clear that these are locals,
and that the specific type will come from the context .
a. , b. : type; -- same as (a.type, b.type)
[..: or rather a., b.: .type ]
b. : value -- defines b as a constant,
whose type is any that recognizes that value .
4.29:
. a way that might be more user friendly
is to simply check for those situations,
and warn the user when there's an ambiguity .

4.8: adda/syntax/type/
distinguishing types from values after colon:
. if you have a,b: (x,y: int),
this is a pair of point types,
so how to say symbol for const list literal?
make sure the components don't include any type identifiers?
but not all the types use type identifiers:
enums would be a set of symbols
except they are found where a type is expected;
and now you're saying  what comes after a colon
is not necessarily a type, it could be a constant value .
. it might be necessary to include the dot to show it's a type:
a,b: .{enums,,,};
a,b: .(record components,,,) .

4.9: adda/syntax/type/
simplicity without ambiguity:
. the types literals should always have the same syntax,
regardless of whether beside a symbol or after a colon .
. this also makes it easier to tell when a (<) is the beginning of a (< ... > )

4.10: adda/syntax/type/
confusing parameters with locals:
[4.30: mis: ]
. the declaration form (x,y: .type)
can be confused with 2 params;
is there any reason to declare things in a parameter?
[4.30:
. I think I was confusing function declarations with
function application:
within the function declaration,
the declarations in the parenthetical
can only be one thing: parameter declarations .
. then, within a function application,
when applying actual to formal parameters,
then the colon can mean 2 things:
if you find the formal param's the function was expecting,
then the parenthetical is a parameter literal;
if you find unexpected formal parameters,
than expect this an expression that
returns a parameter literal;
the new syntax for declaring the return type of an expression
should make it clear when a function application
has gotten an expression that returns a parameter list,
rather than the parameter list literal .
]
. is there any reason to declare things in a parameter?
yes:
. the declare block can return what the param needs
so then the declare block should be distinguishable,
and, integrating that with the function block,
it is just like a function with no parameter ...
[4.30: obs: ]
[@] adda/syntax/type/return types for function literals and declare blocks
hence (^();;;) is the declare block?
. the function looked like {^(params): f(x)}
because it's a set generator
and any generator is a namespace by convention
a parameter less function is also a namespace .
. a better way is (: ;;;);
that's an abbreviation of {^(): ;;;}
there's 2 features there:  (^(x)) and (:)
and if x is null then the (^(x)) can be skipped .

4.10: adda/syntax/type/
return types for function literals and declare blocks:
. wondering how the declare block can be typed:
(.returnType: ;;;), so then
couldn't you do that with the function literal too?
{(xType).yType:  ;;;}