. obj'c has non-ada formal param's:
[perform selector](SEL, withObject: x1.ID, withObject: x2.ID)
. in ada the param names must be unique
but not in obj'c .
. in ada there is both named and
positional param association;
but in obj'c there is only positional;
so it doesn't matter if the
method signature keywords aren't unique .
. adda can mirror what obj'c is doing by
using label declarations:
. if the label has no type specified,
then it's a comment,
and doesn't have to be unique; ...
4.29: adda/obj'c/method signature keywords vs param'names:
mis:
. if obj'c param'names
don't have to be unique,
then how is the body distinguishing them?
web:
for each param,
it has both a param'name,
and a method signature keyword .
. the first keyword, of course,
includes the function's verb .
. the name of the function includes
all of the method signature keywords:
( my.SEL`= @selector(setWidth:height:);
str.nsString`= "(setWidth:height:);
my`= NSSelectorFromString(str)
).
basically just a signature id:
. the fact that the msk's
(method signature keywords)
can seemingly be used for named association
is completely secondary to their function as
uniquely stating the function's name;
ie, if the function is instantiated,
then the identification occurs through the
arg`record`type;
but if the arg's aren't mentioned
then the identification can still occur
through the (now not optional)
method signature keywords .
4.22: adda/cstr/labels need no type declaration:
. the colon operator's meaning is the same as
its most frequent use in english and c:
labeling things . in that capacity,
it's not only declaring constants
(eg, x.t: value -- initializing a constant,
vs: x.t`= value -- initializing a variable .
); but also,
defining points in maps:
# a case stmt:
-- var? # val1: act1, # ...; --
a map from var`values to actions;
# named associations:
-- (param1: val1, ...) ---
-- (component1: val1, ...) --
a map from agg'components to instantiations .[4.28:
# method signature keywords:
. in order to mirror what obj'c is doing, 4.29:
each param has a 2nd label consisting of
its method signature keyword;
like so:
f(x1.t, my2ndarg: x2.t, my3rdarg: x3.t)
so,
the params and function have the usual names;
but then there is labeling for expressing
the entire signature:
(f:my2ndarg:my3rdarg:)
. if this is a unique form of overloading
then it may need a unique type id:
perhaps .sig (signature keyword)
used like this:
f( x1.t
, my2ndarg.sig: x2.t
, my3rdarg.sig: x3.t) .]
. in situations where labels can be
both declared for use as a comment
(with no declared type)
and also used for named association,
there needs to be some way of
distinguishing between the two;
because, any unexpected label should be
interpreted as either a spelling error
or a shortcut for declaring a label .
. an unambiguous way to declare a label
is to use the type`dot without mentioning the type:
(label.: );
the label is then local to the current scope block;
and, the label renames a following symbol;
or, the label names a following control structure .
[5.1:
if there's no use of a declared label,
that tells the compiler it's simply a comment ...
unless some use involved a misspelling .]
4.19: adda/type/generics:
. if you write just (var. )
ie, without a specific type
adde will complete it with an interface literal
and the interface is determined by
whatever is applied locally
(ie, it's a generic;
the system won't know until run-time testing
whether the object handles those functions .)
. notice that aggregates (arrays and records)
are using labels like a map does,
but are not sets like maps are . [ 4.29:
. mapping usually refers to a set of points;
but here, "(map) includes ada's named
associations for agg'components and parameters.
(param'lists are a form of agg':
call instantiation records).]
. you might be able to identify an agg'literal
by the thing it's being assigned to;
but you also want to support
generic agg' literals;
[5.1: that would be something like lisp
where you can send trees of symbols
which then represents a situation .]
. labels for goto's need to
define themselves as loops or exits,
eg,
myway.loop:otherwise,
b?? myway
else thedoor;
thedoor.exit .
they are assumed to be part of
some pre-existing map`domain .
. if there is no dot with the label,
and the label doesn't match an expected map point
then adde might ask beginners
what they meant:
# a full-featured goto address?
(eg, spaghetti4.<<>>: ...) # a loop name (enterable only from within loop)?# an exit (a special non-looping goto address)? .
other ideas about labels:
4.22: adda/naming/freedom and efficiency:
. one reason for not allowing
special characters in names
`~!@#$%^&*()_+-={|\}[],./:;'"
-- besides the unreadability of it --
is that the compiler would be slowed down
by every other use of a special char:
having to stop and ask:
is that in one of the current names?
or is that the start of a new symbol ??
. by optionally enclosing a name in brackets,
[`~!@#$%^&*()_+-={|\}[],./:;'"]
one can have nearly complete naming freedom
(barring only the use of
unbalanced brackets within a name)
while also keeping the compiler efficient:
the compiler just looks for the end of enclosure
without having to check through current names
just to know whether a name
continues past a special char .
. as for readability,
the adde editor allows for smart name replacements,
taking your renaming suggestions
by showing all the names in the current scope block
so it's easy to tell what will be a unique name .
other uses for the colon operator:
4.24: web.adda/standard ml's [::]-operator:
. part of pattern matching
http://en.wikipedia.org/wiki/Standard_ML
an arg with formal name of (a::b)
has declared that input will be divided in 2
and given names {a(for the first part)
b (for the 2nd part)}.
4.9: news.adda/operator-::/context definition:
. some at bigresource.com
http://mac.bigresource.com/OS-X-Leopard-Leopard-bug-that-can-cause-data-loss-hqic9R96w.html
are using :: for the context operator:
eg, (in the case of hardware version x, y is happening;)
would be stated as x :: y .
4.27: mis.adda/double colon as comment:
. the problem of confusing comments
[@] adda/obj'c/param'labels
with a map's expected keys
gave me the idea of using a [comment]:: syntax
to unambiguously use labels as comments .
. it would be similar to the other styles of comment:
--[], and ##[] .
4.28:
. however,
this use has no precident,
and would be unintuitive;
furthermore, there is no ambiguity problem;
[@] adda/cstr/labels need no type declaration
therefore any label with the usual syntax
can already serve as a comment .
No comments:
Post a Comment