4.28: bk.adda/ada05`oop/why is dot notation needed?:
. didn't ada have a problem with needing oop's x.f
to avoid a redundancy problem with f(x) ?
. 05's rationale for oop syntax changes
is not compelling in adda's context:
. they noted that x.f can look a lot neater than f(x);
esp'ly in math formulae;
but, adda allows f x * ...
which means the same as f(x) * ... .
. they liked the fact that components and primitives
could be accessed with the same syntax .
. what should adda say x`f means?
the possessive character (`)
was supposed to remind one that
some modifications could be happening;
and, to offer a c.lang convenience like (x+= b)
-- which means x= x+b --
adda offers x`+ b .
2010-04-30
parse pref's for stack-based eval's
4.26: adda/oop/parse pref's for stack-based eval's:
. whenever the type T has a lot of operations
(vs functions, ie, having a form like:
T->T, or TxT->T,
where all the arg's and returns
are all of the same type.class),
then it should be more efficient to
send it all as one call:
numstacker(output/.c, input#.c, opcode#.s) .
-- the arrays are constant,
so the call's parameter activation record
is just 3 ptr's
no matter how large the expression .
. there may also be a compiler advice function
that tells how to transform an etree
(expression tree)
to be most precisely eval'd;
but this might depend on current values?
. the type'mgt supplies a function:
parse(tree).tree
which the compiler uses to get advice of
special precedence or other type-specific rules .
. once the parse advice has been taken
the compiler stacks the etree:
ie, it loads an array
with the pointers to the arg's .
. whenever the type T has a lot of operations
(vs functions, ie, having a form like:
T->T, or TxT->T,
where all the arg's and returns
are all of the same type.class),
then it should be more efficient to
send it all as one call:
numstacker(output/.c, input#.c, opcode#.s) .
-- the arrays are constant,
so the call's parameter activation record
is just 3 ptr's
no matter how large the expression .
. there may also be a compiler advice function
that tells how to transform an etree
(expression tree)
to be most precisely eval'd;
but this might depend on current values?
. the type'mgt supplies a function:
parse(tree).tree
which the compiler uses to get advice of
special precedence or other type-specific rules .
. once the parse advice has been taken
the compiler stacks the etree:
ie, it loads an array
with the pointers to the arg's .
binary operator support for evolvers
4.25: adda/oop/biop'support for evolvers:
. unlike polymorphs such as type"number,
when an evolver gets a biop (binary operation),
it doesn't have a type'mgt that knows
who all its subtypes are,
so it doesn't know how to do conversions,
and can't delegate a biop call
to a particular subtype .
. one approach, though not generalizable,
is to have all biop methods be defined by
the root type,
and defined in terms of unary operations .
. all evolutions of that root type
would then inherit a working biop,
even if they had defined their own unary op's .
. the unary op's should provide code too,
just to be consistent?
ie, evolver subtyping involves complete impl'inheritance ?
[4.30:
. it should be up to the individual root.type
as to whether or not it chooses to
share a given method;
but if it wants the biop's to work
the way they do for polymorphs,
then it will provide the methods for all biop's .]
. a dynamic scripting approach,
like one might expect from a lisp system,
would be where all evolutions or subclasses
are allowed to read and modify
a supertype's biop-managing script .
. a subtype would register itself
and complete a table:
subclass x subclass x biops;
or, do whatever other rescripting was needed
in order handle the various combinations of subclasses
that are sent a biop message .
. a strategy for how to design evolvers
is to keep in mind why inheritance is good here:
it offers a form of type-checking
along with interface-based programming .
--[4.29: it offers nominal in addition to
structural subtype polymorphism (generics).]
. generics is when any type will do
if it supports the same interface
(I call these typeless obj's "(generals)).
. nominal type checking includes
the given type'name and all its descendants .
1130:
. the type'tag points to type'mgt
which is a node in a tree (or lattice);
that node has ptr's to all sources of inheritance .
. the 2 arg's of a biop must share
one or more supertypes,
and one of the supertypes must support that biop .
. if more than one?
[4.29: as when using multiple ada`packages,
the biop could be qualified to indicate
which node in the type.class lattice
the operation should be executed by .]
[4.30: qualifying an infix operator
could look rather confusing;
another option is raising an exception when
multi-inheritance is getting ambiguous .
. Ada05 allows multi-inheritance only with
interfaces (methods are not inherited,
and there's no concept of a biop).]
4.29: adda/oop/evolvers supporting biop's:
. what if an evolver wanted to inherit from a polymorph?
as long as adda promotes generics or interfaces .
[4.30:
. inheritance that expresses a
nominal subtype polymorphism
may not be good for contract-based prog'ing:
. types that support the same interface
could be modeling very different things;
so there should be a distinction made between
whether the model or the interface is supported .
eg, when I say the formal is a number,
I probably don't mean
the assigned obj'should do clock arithmetic
-- even if the interfaces are the same .]
. how does it support biop's ?
it needs to ask both arg's who their type'mgt is,
and see if they have a common superclass,
then see if any of them have a method for that biop .
but, num is a closed type, (not an evolver):
the biop it supports is not tolerating any
unrecognized subtype names .
. similar to the idea that there are
separate inheritances for interface and impl',
not every interface inheritance
has to imply the type is compatable with
the one it inherited from .
. just as polymorphs have some way of cooperating
in order do binary operations on various subtypes,
the evolvers need some universal way of describing value:
ie, the one job of the root.type
is having a way to define the supported values
in terms of some composition of public types;
[4.30: ie,
a subtype doesn't have to reveal how it stores a value,
but it does need to support exporting of a value
in some public form,
similar to offering a printed version
but instead of exporting as text,
it would be an efficient binary form .]
. for example,
number could describe its polymorphs
as an evolver would:
instead of subtypes knowing each other
and providing conversion routines,
the root.type, number,
could define a record of integers
(or a pointer to symbol in one case)
that describes all the parts of any number:
( mant'int#, [irrational]/ -- mantissa
, mant'frac'numerator#
, mant'frac'denominator#
, exp'int#, exp'frac# -- exponent
, sign'int#, sign'frac# -- large for complex numbers .
); [4.30:
. for types that are not numeric,
the root.type could express itself as
some tree of certain classes of symbols,
like the way english can be described,
with a grammar and a vocab' .]
. is that idea useful for the problem of
integrating popular notions of oop with biop's?
. the obj'c oop is assuming privacy from
even subclassers, not just clients;
therefore, any biop's must be defined in terms of
the superclass's unary op's .
. as shown by class"numbers,
there will be situations where only a
universal value format will be useful:
the biop will ask both arg's
to convert themselves to universal,
and then after working on a pair of univerals,
the biop can ask the receiver
to convert the universal to the type prefered;
[4.30: ie, within an evolver class,
one of the subtype's assignment functions
is expected to accept a universal-formatted value .]
. unlike polymorphs such as type"number,
when an evolver gets a biop (binary operation),
it doesn't have a type'mgt that knows
who all its subtypes are,
so it doesn't know how to do conversions,
and can't delegate a biop call
to a particular subtype .
. one approach, though not generalizable,
is to have all biop methods be defined by
the root type,
and defined in terms of unary operations .
. all evolutions of that root type
would then inherit a working biop,
even if they had defined their own unary op's .
. the unary op's should provide code too,
just to be consistent?
ie, evolver subtyping involves complete impl'inheritance ?
[4.30:
. it should be up to the individual root.type
as to whether or not it chooses to
share a given method;
but if it wants the biop's to work
the way they do for polymorphs,
then it will provide the methods for all biop's .]
. a dynamic scripting approach,
like one might expect from a lisp system,
would be where all evolutions or subclasses
are allowed to read and modify
a supertype's biop-managing script .
. a subtype would register itself
and complete a table:
subclass x subclass x biops;
or, do whatever other rescripting was needed
in order handle the various combinations of subclasses
that are sent a biop message .
. a strategy for how to design evolvers
is to keep in mind why inheritance is good here:
it offers a form of type-checking
along with interface-based programming .
--[4.29: it offers nominal in addition to
structural subtype polymorphism (generics).]
. generics is when any type will do
if it supports the same interface
(I call these typeless obj's "(generals)).
. nominal type checking includes
the given type'name and all its descendants .
1130:
. the type'tag points to type'mgt
which is a node in a tree (or lattice);
that node has ptr's to all sources of inheritance .
. the 2 arg's of a biop must share
one or more supertypes,
and one of the supertypes must support that biop .
. if more than one?
[4.29: as when using multiple ada`packages,
the biop could be qualified to indicate
which node in the type.class lattice
the operation should be executed by .]
[4.30: qualifying an infix operator
could look rather confusing;
another option is raising an exception when
multi-inheritance is getting ambiguous .
. Ada05 allows multi-inheritance only with
interfaces (methods are not inherited,
and there's no concept of a biop).]
4.29: adda/oop/evolvers supporting biop's:
. what if an evolver wanted to inherit from a polymorph?
as long as adda promotes generics or interfaces .
[4.30:
. inheritance that expresses a
nominal subtype polymorphism
may not be good for contract-based prog'ing:
. types that support the same interface
could be modeling very different things;
so there should be a distinction made between
whether the model or the interface is supported .
eg, when I say the formal is a number,
I probably don't mean
the assigned obj'should do clock arithmetic
-- even if the interfaces are the same .]
. how does it support biop's ?
it needs to ask both arg's who their type'mgt is,
and see if they have a common superclass,
then see if any of them have a method for that biop .
but, num is a closed type, (not an evolver):
the biop it supports is not tolerating any
unrecognized subtype names .
. similar to the idea that there are
separate inheritances for interface and impl',
not every interface inheritance
has to imply the type is compatable with
the one it inherited from .
. just as polymorphs have some way of cooperating
in order do binary operations on various subtypes,
the evolvers need some universal way of describing value:
ie, the one job of the root.type
is having a way to define the supported values
in terms of some composition of public types;
[4.30: ie,
a subtype doesn't have to reveal how it stores a value,
but it does need to support exporting of a value
in some public form,
similar to offering a printed version
but instead of exporting as text,
it would be an efficient binary form .]
. for example,
number could describe its polymorphs
as an evolver would:
instead of subtypes knowing each other
and providing conversion routines,
the root.type, number,
could define a record of integers
(or a pointer to symbol in one case)
that describes all the parts of any number:
( mant'int#, [irrational]/ -- mantissa
, mant'frac'numerator#
, mant'frac'denominator#
, exp'int#, exp'frac# -- exponent
, sign'int#, sign'frac# -- large for complex numbers .
); [4.30:
. for types that are not numeric,
the root.type could express itself as
some tree of certain classes of symbols,
like the way english can be described,
with a grammar and a vocab' .]
. is that idea useful for the problem of
integrating popular notions of oop with biop's?
. the obj'c oop is assuming privacy from
even subclassers, not just clients;
therefore, any biop's must be defined in terms of
the superclass's unary op's .
. as shown by class"numbers,
there will be situations where only a
universal value format will be useful:
the biop will ask both arg's
to convert themselves to universal,
and then after working on a pair of univerals,
the biop can ask the receiver
to convert the universal to the type prefered;
[4.30: ie, within an evolver class,
one of the subtype's assignment functions
is expected to accept a universal-formatted value .]
live obj's have a guest.tag
4.25: adda/{oop, concurrency}/live obj's have a guest.tag:
. type.tags could be shorter than a ptr
by being a node-specific typeId#,
where the term "(node)
is supposed to conjure up the idea of networking
as being a collection of communicating modules .
. a node-based library is specific to
either a computer or a user account .
. if a live object is passed between nodes
then how is the typeId associated with
an implementation of a type'mgt?
[4.29:
. a live obj' is sent from a guest node
to a host node;
the guest-host handshake starts by
associating a type'name with the
type'mgt's body of code,
and after that,
the host can then refer to that type
using a pair of both the guest#,
and the obj's typeid# .
. the handshake ends with the host
telling the guest or the messaging system
what the guest's guestID# is .
. after that,
all obj's come in from a guestID#,
and all obj's contain a type.tag that's
understood within the context of a given guest .]
. type.tags could be shorter than a ptr
by being a node-specific typeId#,
where the term "(node)
is supposed to conjure up the idea of networking
as being a collection of communicating modules .
. a node-based library is specific to
either a computer or a user account .
. if a live object is passed between nodes
then how is the typeId associated with
an implementation of a type'mgt?
[4.29:
. a live obj' is sent from a guest node
to a host node;
the guest-host handshake starts by
associating a type'name with the
type'mgt's body of code,
and after that,
the host can then refer to that type
using a pair of both the guest#,
and the obj's typeid# .
. the handshake ends with the host
telling the guest or the messaging system
what the guest's guestID# is .
. after that,
all obj's come in from a guestID#,
and all obj's contain a type.tag that's
understood within the context of a given guest .]
structural subtype polymorphism
4.25: adda/oop/structural subtype polymorphism:
. in addition to polymorphs and evolvers
there are generals, where type is not named;
instead,
the given obj' must support the same operations
as expected by the formal symbol
that the obj' was assigned to;
and, in order to show
where it's getting this support from,
the obj' must carry a type.tag;
this would be in addition to
a possible subtype tag that the type'mgt would use
to discriminate between a polymorph's subtypes .
. in addition to polymorphs and evolvers
there are generals, where type is not named;
instead,
the given obj' must support the same operations
as expected by the formal symbol
that the obj' was assigned to;
and, in order to show
where it's getting this support from,
the obj' must carry a type.tag;
this would be in addition to
a possible subtype tag that the type'mgt would use
to discriminate between a polymorph's subtypes .
polymorphic vs evolutionary subtyping
4.23: adda/oop/polymorphic vs evolutionary subtyping:
. the crux of subtyping is being
compatable with multiple types;
structural subtyping is allowing compatability between
any interfaces that share operations having
the same name and parameters;
nominal subtyping is where compatability is declared:
a subtype is compatible with its supertype
because it defined itself as supporting that supertype .
. the 2 types of nominal subtyping
are tentatively named here:
polymorphic subtyping, and
evolutionary subtyping .
. the term polymorphic refers to a single genome
that results in individuals of varying form;
eg, drones, queen, workers .
. evolution is about extending the capabilities
that were inherited .
. when considering the design of syntax for oop,
I noticed a difference between
{polymorphic subtyping (polymorphs)
, evolutionary subtyping (evolvers)
} that would cause their syntax to differ:
. the polymorphs are exemplified by the numbers,
which include the subtypes {Q,R,N,Z,C,...}.
. an obj' of type"number needs to recognize
all the binary operations (biop's)
that are recognized by any of its subtypes; [1]
this implies that a subtype's set of biop's
can never be an extension of
its supertype's biop set
-- it must instead be a subset .
. this is in stark contrast to evolvers
where a subclass's set of operations
come from not only inheriting those of superclass's
but also by declaration of new operations .
1:
proving (using number as an example)
the supertype of a polymorph needs to recognize
the union of all its subtypes' operations:
. any time a binary operation occurs on
on an arbitrary pair of subtypes of number,
the most general response must be
to ask the supertype how to handle
any combination of subtyping in
{Q,R,N,Z,C,...}x{Q,R,N,Z,C,...} .
. even though there may be biop's
that only one subtype can perform,
in the general case
-- with dynamically changing subtypes
and user-defined polymorphs --
the only modular approach
is to leave it up to the supertype
to decide on whether a pair of subtypes
can legally be used by a given biop .
. the alternative to modularity
is to reprogram the compiler
to know what the supertype's job is,
so that it can supply that code implicitely .
. that might make sense for numbers,
but can compilers be changed in the general case?
(eg, with plugins); otherwise,
polymorphs need to put that code
in their supertype's body .
. the compiler should be able to use
the supertype's body, in a high-level way,
for optimizing code;
eg, if every twin pair (M,M) results in
delegating the implementation to M's method,
then in-line code could include
a run-time check for whether a pair were twins .
. the crux of subtyping is being
compatable with multiple types;
structural subtyping is allowing compatability between
any interfaces that share operations having
the same name and parameters;
nominal subtyping is where compatability is declared:
a subtype is compatible with its supertype
because it defined itself as supporting that supertype .
. the 2 types of nominal subtyping
are tentatively named here:
polymorphic subtyping, and
evolutionary subtyping .
. the term polymorphic refers to a single genome
that results in individuals of varying form;
eg, drones, queen, workers .
. evolution is about extending the capabilities
that were inherited .
. when considering the design of syntax for oop,
I noticed a difference between
{polymorphic subtyping (polymorphs)
, evolutionary subtyping (evolvers)
} that would cause their syntax to differ:
. the polymorphs are exemplified by the numbers,
which include the subtypes {Q,R,N,Z,C,...}.
. an obj' of type"number needs to recognize
all the binary operations (biop's)
that are recognized by any of its subtypes; [1]
this implies that a subtype's set of biop's
can never be an extension of
its supertype's biop set
-- it must instead be a subset .
. this is in stark contrast to evolvers
where a subclass's set of operations
come from not only inheriting those of superclass's
but also by declaration of new operations .
1:
proving (using number as an example)
the supertype of a polymorph needs to recognize
the union of all its subtypes' operations:
. any time a binary operation occurs on
on an arbitrary pair of subtypes of number,
the most general response must be
to ask the supertype how to handle
any combination of subtyping in
{Q,R,N,Z,C,...}x{Q,R,N,Z,C,...} .
. even though there may be biop's
that only one subtype can perform,
in the general case
-- with dynamically changing subtypes
and user-defined polymorphs --
the only modular approach
is to leave it up to the supertype
to decide on whether a pair of subtypes
can legally be used by a given biop .
. the alternative to modularity
is to reprogram the compiler
to know what the supertype's job is,
so that it can supply that code implicitely .
. that might make sense for numbers,
but can compilers be changed in the general case?
(eg, with plugins); otherwise,
polymorphs need to put that code
in their supertype's body .
. the compiler should be able to use
the supertype's body, in a high-level way,
for optimizing code;
eg, if every twin pair (M,M) results in
delegating the implementation to M's method,
then in-line code could include
a run-time check for whether a pair were twins .
subtype polymorphism replacing polymorphic records
4.22: adda/oop/subtype polymorphism replacing polymorphic records:
. the example in [cocoa patterns].book/hierarchy
of using a graphics tree to express subgraphics
reminded me of how expressions use trees:
. generic trees are intuitively implemented as
variant records, (I'm not sure why these aren't called
polymorphic records ...)
and, this had me realizing how oop subclasses
are using their subclass tag
as a variant record discriminant:
[4.28: for example,
an expression tree has an eval operation
for both the branch and leaf variants
of its variant record structure;
therefore, it's a candidate for replacement by
an oop structure:
the branch subclass's eval
has to eval all args's
then apply the given operation;
the leaf subclass's eval
has to return its immediate value .]
. in both the case of oop and of variant record,
the low-level implementation could involve
a tagged record:
a record where one of the fields
is a code indicating which variant or subclass
the current state belongs to .
. to see a record as an ADT (abstract datatype),
imagine its list of components rephrased as
the operations that come with those components .
. show how oop's subtype polymorphism can save space
the way a variant rec's polymorphism can .
[4.28: variant rec's assume
that the size of all variants
is known at compile time;
and if all the sizes are known to be
approx'ly the same,
then the implementation might use
an immediate placement
rather than a pointer .
. among oop cases, it's true for polymorphs (eg, numbers)
that the size of all variants is known at compile time;
but not generally true for evolvers
(because they can evolve after compile time)
so then, polymorphs can benefit from a
tag system that can indicate
whether the obj's placement is immediate
or found by a pointer .
. on the other hand, oop's polymorphism can be
a time waster:
if half the instances
implement an operation as null,
then it would be more efficient to
case the tag
and make the call only when the instance
supports that operation;
that, in fact,
is why oop allows both styles:
oop can do anything a variant record can
by allowing a client to ask an obj'
what subclass or variant
it currently belongs to .
. summary of variant discrimination
vs subclass polymorphism:
. every node visit can either case the tag
in order to decide on operations to apply;
or a visit can simply
use those operations that are
supported by every subclass .
so, when you ask an oop obj' to do an act,
you're asking a subtype
to do its version of the act .]
. the example in [cocoa patterns].book/hierarchy
of using a graphics tree to express subgraphics
reminded me of how expressions use trees:
. generic trees are intuitively implemented as
variant records, (I'm not sure why these aren't called
polymorphic records ...)
and, this had me realizing how oop subclasses
are using their subclass tag
as a variant record discriminant:
[4.28: for example,
an expression tree has an eval operation
for both the branch and leaf variants
of its variant record structure;
therefore, it's a candidate for replacement by
an oop structure:
the branch subclass's eval
has to eval all args's
then apply the given operation;
the leaf subclass's eval
has to return its immediate value .]
. in both the case of oop and of variant record,
the low-level implementation could involve
a tagged record:
a record where one of the fields
is a code indicating which variant or subclass
the current state belongs to .
. to see a record as an ADT (abstract datatype),
imagine its list of components rephrased as
the operations that come with those components .
. show how oop's subtype polymorphism can save space
the way a variant rec's polymorphism can .
[4.28: variant rec's assume
that the size of all variants
is known at compile time;
and if all the sizes are known to be
approx'ly the same,
then the implementation might use
an immediate placement
rather than a pointer .
. among oop cases, it's true for polymorphs (eg, numbers)
that the size of all variants is known at compile time;
but not generally true for evolvers
(because they can evolve after compile time)
so then, polymorphs can benefit from a
tag system that can indicate
whether the obj's placement is immediate
or found by a pointer .
. on the other hand, oop's polymorphism can be
a time waster:
if half the instances
implement an operation as null,
then it would be more efficient to
case the tag
and make the call only when the instance
supports that operation;
that, in fact,
is why oop allows both styles:
oop can do anything a variant record can
by allowing a client to ask an obj'
what subclass or variant
it currently belongs to .
. summary of variant discrimination
vs subclass polymorphism:
. every node visit can either case the tag
in order to decide on operations to apply;
or a visit can simply
use those operations that are
supported by every subclass .
so, when you ask an oop obj' to do an act,
you're asking a subtype
to do its version of the act .]
read-only subtypes
4.22: adda/oop/read only:
. the interface view of "(readonly)
is that the usual obj' has accessors
that allow both read and write .
[4.28:
. generally though, the obj's body defines
when operations are allowed to do modifications
so an instance needs a tag that indicates
whether this obj' should be changing,
and then methods that normally do any mod's
need to check this bit .]
. also,
the need for read-only subtyping is common;
so, for syntax,
something compact is needed, like the (!)
but that's still unresolved
since that clutters the (/) pointer symbol;
ie, you want it compact like c,
but you don't want c's reputation of looking like
math's full-blown greek .
[4.28:
. it could be changed by an editor preference,
where type T read-only was displayed either as
(T!) or (T-ROM) .]
. the interface view of "(readonly)
is that the usual obj' has accessors
that allow both read and write .
[4.28:
. generally though, the obj's body defines
when operations are allowed to do modifications
so an instance needs a tag that indicates
whether this obj' should be changing,
and then methods that normally do any mod's
need to check this bit .]
. also,
the need for read-only subtyping is common;
so, for syntax,
something compact is needed, like the (!)
but that's still unresolved
since that clutters the (/) pointer symbol;
ie, you want it compact like c,
but you don't want c's reputation of looking like
math's full-blown greek .
[4.28:
. it could be changed by an editor preference,
where type T read-only was displayed either as
(T!) or (T-ROM) .]
cross-platform means a deep binding
4.11: news.adda/cross-platform means a deep binding:
summary:
. Apple is disallowing the use of code
that uses an intermediary translation
or compatibility layer .
. the important thing is that when intelligently done,
intermediary translations are no different than
people translating pseudocode to the target language .
. you'll know when it's intelligent
because they won't be able to enforce it .
rationale:
. this rule is just being fair to
dev's that spend the extra time
to get their code designed for efficiency;
Apple is acknowledging how important it is
to be first to market with an idea,
and if people are creating virtual machines
this will make it easy to be first to market
but at the expense of keeping the app' efficient .
. the xcode system will generate code that follows certain rules,
and it would not be easy to quality-check the app'
unless the code is following those rules .
rationale @ daringfireball.net
co.android alerts dev's to Apple's major change .
daringfireball.net 8 April 2010
Unity3d's CEO:
. if Unity3D is disallowed,
at least they are ahead with a source-to-source tool;
now all they have to do is make it a deep binding:
convert their graphics library functions calls
directly into cocoa graphics calls .
4.29:
. the mac#iphone expects code to follow the idioms,
and this is achieved by very intelligent transforms:
adda code -> mac idioms .
. each platform needs its own adda backend;
adda's oop system should not be concerned with
having a shallow binding to various other oop systems .
. adda's front end should turn human ideas into
expression trees that can be analyzed by computer,
rather than using the idioms of a given platform;
and then,
adda's backend for the mac#iphone
should be able to translate human ideas to
iphone`particulars
-- the same way a programmer does
(this is the sort of work lisp was invented for).
4.30: my response after reviewing the issue:
Ludd·ite:
Pronunciation: \App'll\
Function: noun
Etymology: perhaps from Ned Ludd, 18th century Leicestershire workman
who destroyed a knitting frame
Date: 1811
. one of a group of early 19th century English workmen
destroying laborsaving machinery as a protest;
broadly : one who is opposed to especially technological change .
— Luddite adjective .
summary:
. Apple is disallowing the use of code
that uses an intermediary translation
or compatibility layer .
. the important thing is that when intelligently done,
intermediary translations are no different than
people translating pseudocode to the target language .
. you'll know when it's intelligent
because they won't be able to enforce it .
rationale:
. this rule is just being fair to
dev's that spend the extra time
to get their code designed for efficiency;
Apple is acknowledging how important it is
to be first to market with an idea,
and if people are creating virtual machines
this will make it easy to be first to market
but at the expense of keeping the app' efficient .
. the xcode system will generate code that follows certain rules,
and it would not be easy to quality-check the app'
unless the code is following those rules .
rationale @ daringfireball.net
. what Apple does not want
is for some other company to establish a
de facto standard software platform
on top of Cocoa Touch.
Consider a world where some other company’s
cross-platform toolkit proved wildly popular.
Then Apple releases major new features to iPhone OS,
and that other company’s toolkit is slow to adopt them.
At that point, it’s the other company
that controls when third-party apps
can make use of these features.
co.android alerts dev's to Apple's major change .
daringfireball.net 8 April 2010
. section 3.3.1 of the iPhone Developer Program License Agreement:Steve Jobs explains:
Applications may only use Documented APIs
in the manner prescribed by Apple
and must not use or call any private APIs.
. the 4.0 SDK beta now adds:
Applications must be originally written in
Objective-C, C, C++, or JavaScript (iPhone OS WebKit engine)
and only code written in C, C++, and Objective-C
may compile and directly link against the Documented APIs
(e.g., Applications that link to Documented APIs
through an intermediary translation
or compatibility layer or tool
are prohibited).
“intermediate layers between platform and dev'a response:
ultimately produces sub-standard app's
and hinders the progress of the platform.”
. it doesn’t make sense to limit--
source-to-source conversion tools like Unity3D
unity3d creates a complete XCode project that just works!--
. using iPhone Remote,
you can use an actual iPhone or iPod Touch device
to view and test your game live,
right from the Unity Editor. [using javascript on the web]
Unity3d's CEO:
. In the ancient days of the App Store (July 2008),my response:
Apple very late changed the kernel to disallow
JIT (just-in-time) compilation.
What we did instead was spend several months
changing Mono to compile scripts
AOT (ahead of time) instead
(this is why some dynamic constructs in our JavaScript
doesn’t work on the iPhone).
. if Unity3D is disallowed,
at least they are ahead with a source-to-source tool;
now all they have to do is make it a deep binding:
convert their graphics library functions calls
directly into cocoa graphics calls .
4.29:
. the mac#iphone expects code to follow the idioms,
and this is achieved by very intelligent transforms:
adda code -> mac idioms .
. each platform needs its own adda backend;
adda's oop system should not be concerned with
having a shallow binding to various other oop systems .
. adda's front end should turn human ideas into
expression trees that can be analyzed by computer,
rather than using the idioms of a given platform;
and then,
adda's backend for the mac#iphone
should be able to translate human ideas to
iphone`particulars
-- the same way a programmer does
(this is the sort of work lisp was invented for).
4.30: my response after reviewing the issue:
Ludd·ite:
Pronunciation: \App'll\
Function: noun
Etymology: perhaps from Ned Ludd, 18th century Leicestershire workman
who destroyed a knitting frame
Date: 1811
. one of a group of early 19th century English workmen
destroying laborsaving machinery as a protest;
broadly : one who is opposed to especially technological change .
— Luddite adjective .
Air Vehicle c coding standards compete with Ada
4.8: news.adda/av c++ coding standards:
stn vol3#1 p36/c can be safe too!
. while Ada is the technically superior
and more robust language compared to C,
-- where anything can be type-cast into anything,
type-casting was a problem with
hiring college students for Ada coding:
it was seen as an unmarketable experience base .
. reliability issues with C
have been due only to
the way in which it was used;
however,
another possible problem with C
comes at the time of inspection,
when some code reviewers may find Ada
to be more self-documenting .
. the auto industry had a safe-subset standard for c;
and the F-22 used static code analyzer (SCA) tools
to enforce restriction to a safe-subset of Ada 83 .
. with the same idea in mind,
the F-35 Joint Strike Fighter found a safe subset
of both C and C++ for the safety critical systems
developed by the team of Lockheed Martin Aeronautics,
Northrop Grumman Aerospace, BAE Systems
and the F-35 supplier team.
. the F-16 had safety-critical software
that was all assembly coded,
and some of their team helped the F-35 team with
deploying a safe subset of c
-- both c and asm are similarly low-level lang's .
. an SCA tool's analyzer is like an observer
in a pair programming operation:
a much faster way of getting up to speed
than learning a new language like Ada .
--. after reading that,
I wondered how many C cowboys from college
were still banging their head on restricted C ?
(either the 216 new rules in the form of compiler spit,
or a 140 more pages of manual ...).
air vehicle c++ coding standards (doc) (google's cache)
. unit testing with full structural coverage
is typically done only at the source level
for non-critical code .
. but since compilation to object code
will result in some structural changes
as high-level control structures
are translated to a maze of goto's,
safety-critical code is also
unit-tested at the object level .
. that precaution has even found
some compiler bugs!
. it may seem more efficient to do Ada's practice
of validating one compiler per platform,
rather than unit-testing every translation;
in fact,
Ada compiler validation
has been for language enforcement only:
any safety-critical code for
military, aviation, [or medical?]
is routinely unit-tested at the object level
regardless of what language (Ada, C, ...)
the compiler was translating .
. from seeing how things went on the F-35 project,
the F-22 maint crew, when switching to new cpu's,
decided to convert their code base from Ada 83 to C .
soon-to-be-Dr. Robb at lockheedmartin.com
--. watch the F-35 do its first vertical landing(video) .
stn vol3#1 p36/c can be safe too!
. while Ada is the technically superior
and more robust language compared to C,
-- where anything can be type-cast into anything,
type-casting was a problem with
hiring college students for Ada coding:
it was seen as an unmarketable experience base .
. reliability issues with C
have been due only to
the way in which it was used;
however,
another possible problem with C
comes at the time of inspection,
when some code reviewers may find Ada
to be more self-documenting .
. the auto industry had a safe-subset standard for c;
and the F-22 used static code analyzer (SCA) tools
to enforce restriction to a safe-subset of Ada 83 .
. with the same idea in mind,
the F-35 Joint Strike Fighter found a safe subset
of both C and C++ for the safety critical systems
developed by the team of Lockheed Martin Aeronautics,
Northrop Grumman Aerospace, BAE Systems
and the F-35 supplier team.
. the F-16 had safety-critical software
that was all assembly coded,
and some of their team helped the F-35 team with
deploying a safe subset of c
-- both c and asm are similarly low-level lang's .
. an SCA tool's analyzer is like an observer
in a pair programming operation:
a much faster way of getting up to speed
than learning a new language like Ada .
--. after reading that,
I wondered how many C cowboys from college
were still banging their head on restricted C ?
(either the 216 new rules in the form of compiler spit,
or a 140 more pages of manual ...).
air vehicle c++ coding standards (doc) (google's cache)
. less-critical portions of Air Vehicle (AV) code
will be developed in C++
(safety-critical portions are to be in C);
the air vehicle c++ coding standards
provide safe, reliable, testable, and maintainable
C++ programming .
. these rules are required for all
Air Vehicle C++ development
and recommended for any
non-Air Vehicle C++ development.
Vehicle Systems Safety Critical Coding Standards for C,
is based on:
MISRA Guidelines (Motor Industry Software Reliability Assoc)
For The Use Of The C Language In Vehicle Based Software,
but is providing a more comprehensive set
of language restrictions
applied more uniformly across
all Vehicle Systems safety critical applications.
. AV Coding Standards build on the
Vehicle Systems Safety Critical Coding Standards for C,
by including:
C++ language-specific guidelines and standards.
. unit testing with full structural coverage
is typically done only at the source level
for non-critical code .
. but since compilation to object code
will result in some structural changes
as high-level control structures
are translated to a maze of goto's,
safety-critical code is also
unit-tested at the object level .
. that precaution has even found
some compiler bugs!
. it may seem more efficient to do Ada's practice
of validating one compiler per platform,
rather than unit-testing every translation;
in fact,
Ada compiler validation
has been for language enforcement only:
any safety-critical code for
military, aviation, [or medical?]
is routinely unit-tested at the object level
regardless of what language (Ada, C, ...)
the compiler was translating .
. from seeing how things went on the F-35 project,
the F-22 maint crew, when switching to new cpu's,
decided to convert their code base from Ada 83 to C .
soon-to-be-Dr. Robb at lockheedmartin.com
--. watch the F-35 do its first vertical landing(video) .
2010-04-01
battery-saving architecture
3.27: addx/batt'saving architecture:
notifications:
. without notification systems or hardware interrupts
ipc (interprocess communication) requires
a polling loop which uses power all the time
just checking for whether anything needs power!
. notifications work by having service agents
tell the os what they are checking for,
and then the os will call them back when it happens .
power-saving mode:
. another needed control system is batt'savings mode;
because, agents can provide
higher levels of service if they know
whether the user has nearby access to more batt's .
. services can vary their levels of service by
putting optional services in a separate thread,
and then marking that thread as optional
which then affects its scheduling priority .
. the user can indicate how much to conserve,
and then the system sets a power.conserve.flag .
. the scheduler can use that flag
to adjust the way it schedules the optionals .
. put all optional work on a todo,
else if it's now-or-never,
tell the user what's not being done
while on min drain mode .
. another option while employing a user agent
is letting the agent handle the annoying,
repetitive questions from a service .
. the os uses the average recent rates of cpu useage
to estimate relative batt'life or work levels .
. the os also considers batt's charge age:
if the batt' is near the end of life,
then optional services should be cut anyway
since being in that state worsens the amount of
batt'drain per work done .
. if the system is working more than minimally,
it can then ask the user
whether they'd rather have more batt'life .
. it could do this with an alert
or an on-going notification (animated icons)
for both work intensity and remaining energy;
but, on some systems,
the remaining energy is not easy to measure .
notifications:
. without notification systems or hardware interrupts
ipc (interprocess communication) requires
a polling loop which uses power all the time
just checking for whether anything needs power!
. notifications work by having service agents
tell the os what they are checking for,
and then the os will call them back when it happens .
power-saving mode:
. another needed control system is batt'savings mode;
because, agents can provide
higher levels of service if they know
whether the user has nearby access to more batt's .
. services can vary their levels of service by
putting optional services in a separate thread,
and then marking that thread as optional
which then affects its scheduling priority .
. the user can indicate how much to conserve,
and then the system sets a power.conserve.flag .
. the scheduler can use that flag
to adjust the way it schedules the optionals .
. put all optional work on a todo,
else if it's now-or-never,
tell the user what's not being done
while on min drain mode .
. another option while employing a user agent
is letting the agent handle the annoying,
repetitive questions from a service .
. the os uses the average recent rates of cpu useage
to estimate relative batt'life or work levels .
. the os also considers batt's charge age:
if the batt' is near the end of life,
then optional services should be cut anyway
since being in that state worsens the amount of
batt'drain per work done .
. if the system is working more than minimally,
it can then ask the user
whether they'd rather have more batt'life .
. it could do this with an alert
or an on-going notification (animated icons)
for both work intensity and remaining energy;
but, on some systems,
the remaining energy is not easy to measure .
Subscribe to:
Posts (Atom)
