typed enclosures

4.29: mis.adda/syntax/typed enclosures:
. adda currently reserves the square brackets
as a way to allow more freedom in identifier spellings:
. the space and all printable characters are allowed
as long as every use of square brackets is paired,
because then the ending bracket is well-defined;
eg, [*thi{ i$ ()ne [eg@l iden]ifier] .
. one way to allow multiple uses for square brackets
is to reserve typed brackets: eg,
[this is a single symbol] --. no typing syntax .
[.M(2,3): ...] --. this is typed as being a 2x3 matrix .
{.R: [a,b)} -- a <= x < b for x in reals .
mis:
. this seems too arbitrary, with no compelling use cases ...
sci:
. however, look at the angle brackets:
while the type is .< ... >
the other use is as a value:
<. ... > or <.type: ...>
and of course the 3rd use is as the less-than,
without any dots nearby .

pre- and post-conditions

4.18: adda/cstr/function/pre- and post-conditions:
. we need a syntax that extends a function's type expression
to include the function's pre- and post-conditions
which are predicates that reduce the function's space
by testing both the input and output for certain conditions .
. math syntax sometimes uses the (|) operator for such work .
. perhaps the new syntax for a function type literal could be:
(x.t).t | (pre-condition; post-condition) .

unifying generators with function literals? [revised]

4.17: adda/syntax/
unifying generators with function literals?:
(this is a revision of 3.11)

{parameterized, variant} records

adda/type/{parameterized, variant} records:

4.15: adda/dstr/variant vs parameterized records:
. a parameterized type is not the same thing
as a variant record;
the parameter of a parameterized record type
works like a function, representing a set of subtypes;
eg, it might determine the max length of an array,
or the type of a list's items .
. the variant record, on the other hand
-- which is what is expressed by
.(x? #1: v.t1; #2: v.t2; #3: v.t3 #.)  --
is not requiring a parameter to express its discriminant;
the discriminant can be changed dynamically,
and must be changed in order to mirror
any changes in the way the variant is used .
. conversely, if the discriminant is changed,
then the current variant it represented must be erased,
as the new variant is initialized .

multi-inheritance

4.14: adda/oop/multi-inheritance/
works with single-inheritance:
. how does the support for multi-inheritance
differ from that for single-inheritance?

defining returns out of declare blocks

4.10: adda/cstr/declare blocks/defining returns:
. ideas for what declare blocks can do to return:
idea#1:
. it has its own return y so if it wants the parent to return,
it has to do a (parent `return).
idea#2:
. it can't use the return stmt for itself,
instead the return is the final stmt's return .
[4.30:
. later I had the idea of using (be ...)
as the declare block's return statement .]

[::] as a context clarifier

4.9: adda/syntax/type/[::] as a context clarifier:
. confusing having syntax"(type`value) when
(`) already has a specific meaning: (x`f);
so, maybe a good idea to use (::) as a
context specifier (type::value) ?
t.type: .< .(fields), .{values}, f(x).t, `method.t >
-- so then (x.t) lets me call { x`method, f(x) }
but if (`) was the context operator,
then we have { t::f, t::method }.

implicit declare block complication

4.6: adda/cstr/declare block/
complication of being implicit:
. the problem with not needing a
special symbol for declare block,
is that if I happen to be in a parenthetical
but I was declaring a var meant to belong to the enclosing body,
then under the current system,
the fact that I've made a var declaration in a parenthetical
has converted that a declare .
. the way out of this is to use a path name
to show where the declaration is being made:
( ../belongsToEnvirons.t;  ).
4.29:
. there was also the idea of typing the parenthetical
in order to declare it to be a namespace,
so then untyped parentheticals would not be
deallocating what was declared within them .

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 .

an array is not a function!

adda/dstr/syntax/is an array a set or a list?:
4.29: summary:
. an array should be seen as a special case of record,
where the component types are all the same .
. while a component selection has the same functionality
as applying an argument to a function,
and a function can be implemented with an array,
only a read-only array is equivalent to a function .
. the following is what I wrote on the way to
clearing this up in my mind .

when to type an object as pointer

4.1: 4.2: adda/dstr/pointer/when to type object as pointer:
implicit conversions:
. in designing syntax, it's been assumed that explicit is good,
hence we encourage the explicit use of pointers;
but that idea is at tension with trying to avoid
unnecessary implementation details .