5.18: adda/type/constraint syntax:
. the lang' needs a compact integrated way to
indicate subrange;
eg, i.Z(1...10) -- new Z constrained to 1..10 .
. the parser rule could be that
if the typemark is for a parameterized type
then it expects a parameter;
if it finds an unexpected parameter
(ie, a parenthetical expression)
then it can assume it's a subtype constraint .
. as with functions, (@) can be used for
indicating a symbol returning parenthetical;
eg, i.Z@myConstraint;
eg, i.paramizedType@arg@constraint .
2011-05-31
markup and toc mirroring
5.11: 5.31: adda/markup/integrated markup:
. I had thought of the markup lang' as being
part of the editor -- just as html
is considered to be part a browser --
but in keeping with the one-lang philosophy,
the programming lang should include the
markup lang' -- meta-level lang,
as well as assembly -- low-level lang .
. these levels can have unique syntax
yet share as many qualities as possible .
. by being part of the same standard,
they are all easier to use and remember;
and by not leaving a mode out,
you avoid forcing people to roll their own;
of course, if that's their interest,
good openware should make it easier to do
by providing a reusable kit .]
5.11: adda/markup/toc mirroring:
. there are 2 ways to express nested subtitles:
# containers:
. the markup lang' has container tags:
-- subtitle: [(], [)] --
all titles within the container
are nested within the container's title;
nested titles shows up in the toc as being
indented deeper than their enclosure's title .
# toc's:
. the table of contents (toc) is auto-generated
from what is marked up as being subtitles;
conversely,
if the toc's indentation is changed;
the documents markup will be auto-adjusted
to actively reflect the toc's state,
and auto-generate container markup .
. I had thought of the markup lang' as being
part of the editor -- just as html
is considered to be part a browser --
but in keeping with the one-lang philosophy,
the programming lang should include the
markup lang' -- meta-level lang,
as well as assembly -- low-level lang .
. these levels can have unique syntax
yet share as many qualities as possible .
. by being part of the same standard,
they are all easier to use and remember;
and by not leaving a mode out,
you avoid forcing people to roll their own;
of course, if that's their interest,
good openware should make it easier to do
by providing a reusable kit .]
5.11: adda/markup/toc mirroring:
. there are 2 ways to express nested subtitles:
# containers:
. the markup lang' has container tags:
-- subtitle: [(], [)] --
all titles within the container
are nested within the container's title;
nested titles shows up in the toc as being
indented deeper than their enclosure's title .
# toc's:
. the table of contents (toc) is auto-generated
from what is marked up as being subtitles;
conversely,
if the toc's indentation is changed;
the documents markup will be auto-adjusted
to actively reflect the toc's state,
and auto-generate container markup .
representing meta-values
5.10: adda/enums/the power of zero:
. the system should be interested in
reserving some values for representing
the state of being undefined or out-of-range .
. this though, can be done by system tagging;
ie, every type could inherit from system
to get a bit that indicates whether the var
is in a well-defined state or not .
. generally,
there is no reservable value available:
. most enum'value sequences start with zero
because most value ranges have a value
that is analogous to zero:
you first ask if there is any value,
if not then zero,
else since there is a value,
which one is it ?
eg, {off:0, red:1, yellow:2, green:3};
"(off) is the absence of a color,
so "(off) would be represented by zero;
[5.31: likewise,
some enums have a special purpose for the last value too;
so that can't be reserved either .]
. the system should be interested in
reserving some values for representing
the state of being undefined or out-of-range .
. this though, can be done by system tagging;
ie, every type could inherit from system
to get a bit that indicates whether the var
is in a well-defined state or not .
. generally,
there is no reservable value available:
. most enum'value sequences start with zero
because most value ranges have a value
that is analogous to zero:
you first ask if there is any value,
if not then zero,
else since there is a value,
which one is it ?
eg, {off:0, red:1, yellow:2, green:3};
"(off) is the absence of a color,
so "(off) would be represented by zero;
[5.31: likewise,
some enums have a special purpose for the last value too;
so that can't be reserved either .]
explicitely expressable state
5.10: adda/images for every data value:
5.4: 5.10: 5.30:
. each value may be associated with
# an icon (iconic image):
. optional .
# a symbol (linguistic image):
--[5.31: ada calls this the image]
. all types can be represented as text:
eg, just as enum's have names for each value,
and numbers have a sequence of digits,
graphics have a matrix of color records,
each of which is a list of tagged numbers:
(red:1, green:2, blue:3).
# a digital value (representation);
--[5.31: ada calls this the enum`value
or the structure`representation]
ie, some structure of bit arrays,
where structuring can be done by
pointers or arrays .
[5.31: structures can be equal if they have
the same type, and equal components;
they can also be tested for less-than
with components treated like string characters .]
. a type may choose to hide its implementation;
[@] addx/info'hiding vs blackbox binaries
[5.31: however,
the system can store snapshots of itself,
with each object represented by
a particular string of integers;
which a private type can interpret in various ways .]
5.10: 5.30:
. given the type streetlight.type =
{off:0, red:1, yellow:2, green:3};
the image of red is the text "(red);
and its value is the integer: 1;
. red could have an icon colored red .
5.4: 5.10: 5.30:
. each value may be associated with
# an icon (iconic image):
. optional .
# a symbol (linguistic image):
--[5.31: ada calls this the image]
. all types can be represented as text:
eg, just as enum's have names for each value,
and numbers have a sequence of digits,
graphics have a matrix of color records,
each of which is a list of tagged numbers:
(red:1, green:2, blue:3).
# a digital value (representation);
--[5.31: ada calls this the enum`value
or the structure`representation]
ie, some structure of bit arrays,
where structuring can be done by
pointers or arrays .
[5.31: structures can be equal if they have
the same type, and equal components;
they can also be tested for less-than
with components treated like string characters .]
. a type may choose to hide its implementation;
[@] addx/info'hiding vs blackbox binaries
[5.31: however,
the system can store snapshots of itself,
with each object represented by
a particular string of integers;
which a private type can interpret in various ways .]
5.10: 5.30:
. given the type streetlight.type =
{off:0, red:1, yellow:2, green:3};
the image of red is the text "(red);
and its value is the integer: 1;
. red could have an icon colored red .
control orientations and compound documents
5.6: adda/oop/the orientation space:
--. this article explores how menus
should work in compound documents,
and how they relate to oop (obj'orientation) .
5.6: 5.31: equivalent terminology systems:
(user -- client
, app -- server
, menu -- type
, document -- object
).
5.6: 5.31: control orientations:
# open structure:
. text is an example of an open datatype:
(it's an array of symbols encoded with ascii);
any operation can be applied to this type
as long as it results in the same structure .
# open interface:
. only a particular set of operations can be applied;
but the menu is a public standard;
so, you can know ahead of time
whether something is on the menu or not .
# proprietary:
. neither the document structure nor the menus
are public standards;
so, only a particular app controls the object .
5.4: compound documents:
. support of compound documents means that
selecting multiple objects would result in
a menu consisting of the intersection of
the set of object`menus; 5.6:
every object can tell you the menu it supports
without having to adopt an interface .
5.31:
. if mac.finder were a compound document,
file`info would link not only to the owning'app
but also to that app's select-all menu .
--. this article explores how menus
should work in compound documents,
and how they relate to oop (obj'orientation) .
5.6: 5.31: equivalent terminology systems:
(user -- client
, app -- server
, menu -- type
, document -- object
).
5.6: 5.31: control orientations:
# open structure:
. text is an example of an open datatype:
(it's an array of symbols encoded with ascii);
any operation can be applied to this type
as long as it results in the same structure .
# open interface:
. only a particular set of operations can be applied;
but the menu is a public standard;
so, you can know ahead of time
whether something is on the menu or not .
# proprietary:
. neither the document structure nor the menus
are public standards;
so, only a particular app controls the object .
5.4: compound documents:
. support of compound documents means that
selecting multiple objects would result in
a menu consisting of the intersection of
the set of object`menus; 5.6:
every object can tell you the menu it supports
without having to adopt an interface .
5.31:
. if mac.finder were a compound document,
file`info would link not only to the owning'app
but also to that app's select-all menu .
2011-05-30
standard abi's motivation
5.18: addx/standard abi/motivation:
background:
. the typical example of mistaken expectation
is when an url acts like a script .
. many apps have input limitations
such as when a browser treats certain url's like scripts .
. a commandline could be given what you think is a filename
but because of expectations about filename limitations
a filename can be interpreted as a series of commands .
. this wouldn't happen if unix had
a common abi (app'binary interface);
because, instead of passing the file's name as text
(a form of screen scraping)
it could be passing an obj type-tagged as a filename
and then filename limitations become irrelevant .
4.15?: news.cyb/sec/qubes/Qlipper:
Larry McCay April 15, 2011 2:52 AM`
comment on [The Invisible Things Lab's blog]/
. this is another example of why an abi
is needed:
. what qubes has to do to get vm's communicating
is for each os to support a clipboard
that qubes can translate to a file
that is then sent over the intranet .
. an os's clipboard is understood as
supporting certain data types
with a certain type-tagging convention .
. if qubes has to understand all this anyway
it already does sanitizing by matching types [5.18:
(though it could help by checking for
malformed html and illegal unicodes); ]
but, because os's don't provide a common abi,
they are reduced to supporting only
some common text-based standards
like ascii, unicode, or html [5.18:
whereas, a common abi would also support
a binary version of a complete programming lang',
meaning that instead of just being text,
the code was parsed into a syntax tree;
and native functions were represented by codes
that are read more quickly than text .
. and,
when copying abi code from the pasteboard,
dom0 would be able to read and understand
the implicit capabilities of that code .]
. without an abi, qubes must have
apps communicating via a screen scraper;
but that's ok, because,
the whole point of security by isolation
is that we can never expect to
completely protect app's from being
hung by their own naivety;
what we can do is protect good apps
from being hung by bad ones .
background:
. the typical example of mistaken expectation
is when an url acts like a script .
. many apps have input limitations
such as when a browser treats certain url's like scripts .
. a commandline could be given what you think is a filename
but because of expectations about filename limitations
a filename can be interpreted as a series of commands .
. this wouldn't happen if unix had
a common abi (app'binary interface);
because, instead of passing the file's name as text
(a form of screen scraping)
it could be passing an obj type-tagged as a filename
and then filename limitations become irrelevant .
4.15?: news.cyb/sec/qubes/Qlipper:
Larry McCay April 15, 2011 2:52 AM`
comment on [The Invisible Things Lab's blog]/
A Qlipper app could be introducedJoanna @Larry:
to sanitize and add the appropriate context.
Sanitizing makes sure
what you copied is what you expected
and the context is used to
direct within the target Qubes domains.
. a "sanitizer" must know the limitations of the destination app... .--
. this is another example of why an abi
is needed:
. what qubes has to do to get vm's communicating
is for each os to support a clipboard
that qubes can translate to a file
that is then sent over the intranet .
. an os's clipboard is understood as
supporting certain data types
with a certain type-tagging convention .
. if qubes has to understand all this anyway
it already does sanitizing by matching types [5.18:
(though it could help by checking for
malformed html and illegal unicodes); ]
but, because os's don't provide a common abi,
they are reduced to supporting only
some common text-based standards
like ascii, unicode, or html [5.18:
whereas, a common abi would also support
a binary version of a complete programming lang',
meaning that instead of just being text,
the code was parsed into a syntax tree;
and native functions were represented by codes
that are read more quickly than text .
. and,
when copying abi code from the pasteboard,
dom0 would be able to read and understand
the implicit capabilities of that code .]
. without an abi, qubes must have
apps communicating via a screen scraper;
but that's ok, because,
the whole point of security by isolation
is that we can never expect to
completely protect app's from being
hung by their own naivety;
what we can do is protect good apps
from being hung by bad ones .
info'hiding vs blackbox binaries
5.10: addx/info'hiding vs blackbox binaries:
. info'hiding means being able to reuse a modules
without having access to the module`body;
by accessing only the module`header .
. only the linker needs the bodies of
a program and the modules it uses .
. the bodies are blackboxes:
usable but unviewable,
protecting both trade secrets
and unintended reuse or adaptation .
. addx's intent is simply to warn coders
that the implementation could change;
ie, if you rely on impl'details,
you can't expect easy updates;
instead,
you'd have to rewrite your code
in order for it to work with any new impl'details .
. addx does allow code obfuscation
since you can easily change names to nonsense;
on the other hand,
the user is a new co.maintainer of your code,
and can easily rename them again
to match ongoing understanding of their roles .
. as for binary black boxes,
adda compiles to c, and then to native binary,
but addx should't run a binary unless
either adda compiled it;
or, there's some other way to trust it .
. if there was some secure way to know
that the binary on my machine
was actually generated by
an untampered adda on your machine
then blackbox modules could be consistent with
the addx security model .
. another way to support blackbox binaries
is for addx to know of a secure website
where it could find such adda products .
. that could, however, bring
new complexity to the security problem:
each time you trust a website
that's another time you have to ask:
"(has that site been cracked recently?)
. by staying with the openware model,
you need be trusting only your platform
(the os, and other apps installed).
. some mutually-trusted 3rd party
could accept code and compile it to binaries;
then commercial interests would be assured privacy;
and trusting users would be assured
that this binary was generated by adda,
while non-trusting users
would be free to download pure openware .
5.10: todo.addx/making openware usable:
. an advantage of addx being openware
is that it minimizes trust requirements;
eg, if you're on Apple's mac,
the only thing you have to trust
is Apple's xcode compiler .
. if addx is built by mac's xcode
then xcode should be easy to get;
will it always ship with every new mac?
... in the qt crossplatform ide doc's
they assume xcode will always be
right at your finger tips .
yet, new versions require payment;
and the code base is getting huge;
so, if it's unused by most mac fans
why cut another entire dvd for every unit ?
addx should written in such a way that
the code can be compiled with
easy to get tools .
. for those who want a completely
native mac app,
some of addx will need to be
compiled with xcode .
. therefore,
they will need to download atleast a small binary
or get xcode .
. this small module should allow them
to build extensions;
so then most of their system
is still modifiable by them
yet is native code rather than addm .
xcode's lang is obj'c,
and that provides dynamic linking;
but does it bind gcc binaries ?
gcc itself has obj'c,
but xcode is no longer using gcc;
it uses clang . is clang free ? [..., yes .]
[5.30: anyway,
the plan for now is as was originally:
the source is meant to be compiled all at once,
and subsequent scripting is done with addm .]
5.10: pos.addx/qt on mac decreases security:
. I'm assuming that adda can protect my code
from abusing qt's large library;
and, qt itself reduces bugs by being easy to use .
. it's also a popular code base with a lot of eyes,
but one disadvantage with being popular on Windows
is that it will be worth more to malware writers .
. by requiring the qt codebase,
addx might be adding to a platform's vulnerability .
sharing a runtime:
. another possibility is that
if any other qt app's are run alongside addx,
they may be able to violate addx`privacy
so then addx can't make any privacy claims
to the user in this situation ?
5.20: addx/unix, KDE, and compon tech:
. I was recently baffled by this filename:
"( dims of addx (unix KDE compon tech) );
but, a review of the article put this together:
. when saying unix was a dimension of addx,
I was assuming linux was unix
and unix was the future platform .
. this article was pointing out that
linux domination plans needed dev tools;
and that, KDE was there for even beginners .
. linux's support for components
is a key to healthy competition and evolution .
. info'hiding means being able to reuse a modules
without having access to the module`body;
by accessing only the module`header .
. only the linker needs the bodies of
a program and the modules it uses .
. the bodies are blackboxes:
usable but unviewable,
protecting both trade secrets
and unintended reuse or adaptation .
. addx's intent is simply to warn coders
that the implementation could change;
ie, if you rely on impl'details,
you can't expect easy updates;
instead,
you'd have to rewrite your code
in order for it to work with any new impl'details .
. addx does allow code obfuscation
since you can easily change names to nonsense;
on the other hand,
the user is a new co.maintainer of your code,
and can easily rename them again
to match ongoing understanding of their roles .
. as for binary black boxes,
adda compiles to c, and then to native binary,
but addx should't run a binary unless
either adda compiled it;
or, there's some other way to trust it .
. if there was some secure way to know
that the binary on my machine
was actually generated by
an untampered adda on your machine
then blackbox modules could be consistent with
the addx security model .
. another way to support blackbox binaries
is for addx to know of a secure website
where it could find such adda products .
. that could, however, bring
new complexity to the security problem:
each time you trust a website
that's another time you have to ask:
"(has that site been cracked recently?)
. by staying with the openware model,
you need be trusting only your platform
(the os, and other apps installed).
. some mutually-trusted 3rd party
could accept code and compile it to binaries;
then commercial interests would be assured privacy;
and trusting users would be assured
that this binary was generated by adda,
while non-trusting users
would be free to download pure openware .
5.10: todo.addx/making openware usable:
. an advantage of addx being openware
is that it minimizes trust requirements;
eg, if you're on Apple's mac,
the only thing you have to trust
is Apple's xcode compiler .
. if addx is built by mac's xcode
then xcode should be easy to get;
will it always ship with every new mac?
... in the qt crossplatform ide doc's
they assume xcode will always be
right at your finger tips .
yet, new versions require payment;
and the code base is getting huge;
so, if it's unused by most mac fans
why cut another entire dvd for every unit ?
addx should written in such a way that
the code can be compiled with
easy to get tools .
. for those who want a completely
native mac app,
some of addx will need to be
compiled with xcode .
. therefore,
they will need to download atleast a small binary
or get xcode .
. this small module should allow them
to build extensions;
so then most of their system
is still modifiable by them
yet is native code rather than addm .
xcode's lang is obj'c,
and that provides dynamic linking;
but does it bind gcc binaries ?
gcc itself has obj'c,
but xcode is no longer using gcc;
it uses clang . is clang free ? [..., yes .]
[5.30: anyway,
the plan for now is as was originally:
the source is meant to be compiled all at once,
and subsequent scripting is done with addm .]
5.10: pos.addx/qt on mac decreases security:
. I'm assuming that adda can protect my code
from abusing qt's large library;
and, qt itself reduces bugs by being easy to use .
. it's also a popular code base with a lot of eyes,
but one disadvantage with being popular on Windows
is that it will be worth more to malware writers .
. by requiring the qt codebase,
addx might be adding to a platform's vulnerability .
sharing a runtime:
. another possibility is that
if any other qt app's are run alongside addx,
they may be able to violate addx`privacy
so then addx can't make any privacy claims
to the user in this situation ?
5.20: addx/unix, KDE, and compon tech:
. I was recently baffled by this filename:
"( dims of addx (unix KDE compon tech) );
but, a review of the article put this together:
. when saying unix was a dimension of addx,
I was assuming linux was unix
and unix was the future platform .
. this article was pointing out that
linux domination plans needed dev tools;
and that, KDE was there for even beginners .
. linux's support for components
is a key to healthy competition and evolution .
the state of scripting concurrency
4.19: adda/co/the state of scripting concurrency/intro:
[5.30:
. this excerpt from stackoverflow.com
had me looking at concurrency again:]
[5.30:
. processes are full programs running concurrently:
each process has its own space for
both variables and code;
threads are like processes except that
they share the locals and code
of the process that spawned them .
. threads and processes can be either
native -- implemented by the os,
or green -- impl'd by an app (eg, a scripting interpreter).
Erlang provides a green process(vs thread),
which is much more lightweight than a native process
because it does share (read-only) code space .
. a computer with multiple cores
can be truly concurrent:
doing more than one thing at the same time
by contrast, timeslicing is virtual concurrency:
giving each task a slice of computer time .
. the GIL (Global Interpreter Lock)
is a mutual exclusion lock
that prevents true concurrency:
insuring that app threads are timesliced,
rathering than being mapped to multiple cores .
. it's needed when the the interpreter,
it's libraries, or its plugins
are not thread-safe because of
threads being able to share variables
that aren't protected with atomic access:
ie, being able to complete a read or write
before having being interrupted by the timeslicer .
Ruby's support for concurrency:
. these GIL-free variants of Ruby
. the future of high performance concurrency
python's gil:
Juergen Brendel argues against the GIL;
Guido maintained the GIL is here to stay
. concurrent programming has a bad reputation
for being both buggy and undebuggable,
but it's based on work with threads .
5.30:
. to be efficient and safe,
a language needs to pervasively support
green processes:
a unit of concurrency that does share
read-only mem like a thread does
but does not share variable mem .
. pervasive support means that
not only is the standard library thread safe,
but all reusable modules are also .]
another way threads don't scale:
that are pass-by-copy;
the impl'details involve
read-only pass-by-reference .]
Why don’t we all switch to Erlang?
[5.30:
. this excerpt from stackoverflow.com
had me looking at concurrency again:]
"( If you have programmed expertly ingreen threads and the need for GIL:
Perl Python and in Java for 10 years,
then you'll probably write your program in Perl
because you'll complete the program faster,
the program will have fewer lines of code,
and the language will stay more out of your way.
If you are not an expert in Perl, Python, or Java,
and you have to choose one of those languages,
then I recommend that you choose Python.
... except if threading is important (re: GIL)...)
[5.30:
. processes are full programs running concurrently:
each process has its own space for
both variables and code;
threads are like processes except that
they share the locals and code
of the process that spawned them .
. threads and processes can be either
native -- implemented by the os,
or green -- impl'd by an app (eg, a scripting interpreter).
Erlang provides a green process(vs thread),
which is much more lightweight than a native process
because it does share (read-only) code space .
. a computer with multiple cores
can be truly concurrent:
doing more than one thing at the same time
by contrast, timeslicing is virtual concurrency:
giving each task a slice of computer time .
. the GIL (Global Interpreter Lock)
is a mutual exclusion lock
that prevents true concurrency:
insuring that app threads are timesliced,
rathering than being mapped to multiple cores .
. it's needed when the the interpreter,
it's libraries, or its plugins
are not thread-safe because of
threads being able to share variables
that aren't protected with atomic access:
ie, being able to complete a read or write
before having being interrupted by the timeslicer .
Ruby's support for concurrency:
. IronRuby builds on top of .NET Threads,[5.30:
so they map 1-1 to OS-threads as well;
JRuby does likewise on the JVM .
. these GIL-free variants of Ruby
provide threads without any warranty:. concurrency models supported by Ruby
it's up to you to insure that
all your dependencies are thread safe .
include Threads, Processes and. Ruby needs a standard actor/executor API
Fibers (systems-level coroutines).
. other abstractions to consider include
Coroutines, Actor Models, Petri Nets, Process Algebras
(particularly CSP and the Pi-Calculus),
Software Transactional Memory
and distributed Map/Reduce algorithms
-- see Go, Occam-Pi, Clojure and Erlang;
Ruby could impl' these with current libraries;
eg, EventMachine or RevActor .
-- not platform-specific impl's of actors .
. the future of high performance concurrency
is libdispatch/GCD;]-5.30
for the java/scala folks, there's HawtDispatch:
(JRuby's port of that is at github/jcd).
. HawtDispatch is a thread pooling and
NIO event notification framework API
modeled after the Apple`libdispatch API
that powers Apple's Grand Central Dispatch (GCD).
It allows you to easily develop
multi-threaded applications
without the usual problems .
python's gil:
Juergen Brendel argues against the GIL;
Guido maintained the GIL is here to stay
until someone can prove its removalBob Warfield 2007`analysis of gil:
doesn't slow down single-threaded Python code.
. the language doesn't require the GIL
but, the CPython virtual machine
that has historically been unable to shed it.
it was shown that even on the platform
with the fastest locking primitive (Windows at the time)
it slowed down single-threaded execution
nearly two-fold .
. removing the GIL complicates life for
extension module writers
by precluding the use of global mutable data .
There might also be changes in the Python/C API
necessitated by the need to lock certain objects
for the duration of a sequence of calls.
Guido is Right to Leave the GIL in Python,[5.29:
Not for Multicore but for Utility Computing
considering large scalability issues
in the world of SaaS, Web 2.0,
and utility computing fabrics;
eg, Amazon EC2(elastic computing).
. a concurrency capability based on threads
has done nothing to access multiple machines
-- for that you need socket-connected processes .
. furthermore,
a simple, safe and reliable concurrency language
should be focused on a [green]process model,
not a thread model.
. concurrent programming has a bad reputation
for being both buggy and undebuggable,
but it's based on work with threads .
5.30:
. to be efficient and safe,
a language needs to pervasively support
green processes:
a unit of concurrency that does share
read-only mem like a thread does
but does not share variable mem .
. pervasive support means that
not only is the standard library thread safe,
but all reusable modules are also .]
another way threads don't scale:
The fundamental problem with threads[. it is merely the semantics
is that sharing requires locking
which doesn’t scale (or compose),
and is prone to races and deadlocks .
Erlang features [green]processes
where isolation is enforced by the language
rather than the operating system .
. Erlang is a functional language
with strict copy semantics
and with no pointers or references.
that are pass-by-copy;
the impl'details involve
read-only pass-by-reference .]
Why don’t we all switch to Erlang?
Messages have to be copied.
You can’t deep-copy a large data structure
without some performance degradation,
and not all copying can be optimized away
(it requires behind-the-scenes alias analysis).
so, mainstream languages don’t abandon sharing;
instead, they rely on programmer’s discipline
or try to control aliasing.
2011-05-22
menu systems for compound documents
4.2: adde/menubar`contents:
subdesktops:
. a compound document is one composed of
trees and tables of hyperlinks, text,
graphics, numbers, and any new types
for which there are app's to drive them .
. it's as if there are
many app windows in a single document
just as there are
many app windows on a desktop;
therefore,
a compound document can be thought of
as being desktop within a desktop,
and could thus be called a subdesktop .
. adde can then be called
a subdesktop editor .
review of mac`menubar:
. there are various places to put a menubar:
# the mac`menubar is at the top of the display;
it contains a menu belonging to
whichever app is controling the current window;
# many non-mac systems have, instead,
window-specific menu's:
. the app's menu would be located at
the top bar of each window belonging to that app;
whereas the display's menubar would contain only
system-wide menu's (eg, admin' functions,
app's launchers, and a file finder) .
[5.3:
. the mac`menubar has a list of co.menus
(co.menus are side-by-side,
just as submenus are nested under other menus
).
mac's standard co.menus include:
( (system`name)-- about system, param's, updates;
, (app`name) -- about this app, param's, updates;
, file -- interactions with perm'storage;
, edit,format -- modify the currently open file;
, view -- customze how content is displayed
-- (doesn't modify the content);
, (app-specific menus, ...)
, window -- arrange or select the app's windows;
, help -- for both system-wide, and app-specific .
)
. mac'menu's are expected to be complete
in order to represent what the app does;
5.4: eg,
mac`finder's window has a search box,
but it also has this menu:
finder`menu#file/find .
mac`menu#edit:
[5.8:
. mac uses the edit.menu for
anything related to document modifications,
including select, as well as {copy cut, paste};
and, any service that optionally edits:
eg, find(and perhaps replace),
or spellcheck(and perhaps correct) .
. however, there may be other co.menus
that also provide edits;
eg, mac's textedit has menu#format
which modifies the selection's {font,style,...} .
. another editing co.menu is used by vmware,
(if you think of a virtual machine as a document);
vmware`menu#[virtual machine] is used for
pref's that apply only to the current document .]
[5.3: 5.8: a menu#edit for subdesktops:
. mac provides 2 ways to select data:
# edit#menu/select all
# use the mouse to define a subrange .
. therefore,
because subdesktops are compound doc's,
with a variety of datatypes combined;
there are more ways than [select all]
to select things by menu:
you can also subrange by type .
. whether for simple or compound doc's,
there should be a [select some] item
in which a given truth function can define
a subrange of the {moused, typed} selection .
. in sum, selection subrange provides,
for each type in the current document,
a checkbox and an optional constraint parameter;
eg,
[x] is .txt except [find "(todo)]
[ ] is .jpg except [ null ] .
. this can be integrated with the
[select all] like so:
[select all] brings up the
[select some] dialog,
showing you the list of types
with all possible types selected;
so if no subrange constraints are needed
then just pressing enter
works like [select all].
. if the new user doesn't appreciate a dialog,
the dialog can have a checkbox to
"( map this [select some].dialog
to command-shift-A ).
. the currently moused selection
is mirrored in the menu selection:
if a selection is already made,
the [select some] dialog will
reflect that selection state
by checkmarking only the types
that are currently selected .
]-5.8
[5.4: the dynamic menu:
5.4: 5.9:
. mac`menus can have dynamic content:
ie, they will grey-out any menu items
that aren't applicable to the current selection .
. fully dynamic menus can also
add and remove submenus .
. compound doc's have document-specific
combinations of datatypes;
therefore, fully dynamic menus are required
in order to display all the type-specific menus
of all the datatypes contained in the current doc'.
[5.10:
. if mac`menus weren't fully dynamic
then adde's mac`menu could be for adde-wide operations
and then the edit.menu would have a
[type-specific operations ...] item
that would open an adde-designed menu system
which can then support full dynamism .
[5.4: 5.6: 5.8: merging app menus:
. there are several ways in which
the menus of a doc's datatypes
are merged into a single menu system:
# simple:
. a submenu is named by type,
and selecting that command will then
be applied to components of that type only;
other types will be ignored .
. when on the mac,
these type-specific menus would be expected in
menu#edit, along with [select all] .
# subtype polymorphism:
. an example of this is the supertype: number;
its menu items apply to all numeric subtypes
(int,float, Q,Z,R,C) . [5.10:
. the typical supertype menu
would list any operations affecting all subtypes,
and would then have submenus
representing each subtype, and containing only
subtype-specific operations .
. subtyping is concerned with interfaces
rather than implementations;
so, if a float happens to have an integer value
it retags itself as being an int;
however, since ints are a subset of floats
something constrained to int
will never have a chance to
similarly retag itself to float .]
# representational polymorphism:
. representations include
{ value implementations,
, graphical image,
, and programming language image
( adda-representation text )
} eg,
. when numbers are selected,
I can either bold-format a numeric's text,
or I can add the numeric values . [5.11:
. adde must either detect when types use text,
or types must declare this;
types may want to suggest a preference
that would explain to the user
why the preference exists;
the user can overrule any preference
after oking a purpose alert .]
[5.10:
. if an app is using text to represent its content
then a text styling menu
would apply to that app's datatype
(of course, the other text-modifiers
do not apply because
the text represents a type state
not just strings of characters).
. the user may want to vary the text styling
depending on whether the app's mode is:
# show value's graphical image
(might not use text)
# show value's adda-representation
(might be unavailable*)
# show value's implementation .
*:
. while every datatype must be
implemented in adda;
that type's values are not required to
have a written form (adda-representation);
for example,
streetlight.type = (red, yellow, green);
the intended image of the value red
is an icon that is colored red,
the adda-representation of the value red
is the text "(red);
and the implementation of the value red
is the integer: 1 (assuming the
default encoding of enums starts with 1,
and seeing that red is the first value).]
# generic polymorphism:
. the [all types].submenu shows
what operations of identical name
are recognized by every type in the selection
even if each type's authors had no idea
that they were naming their functions the same . [5.11:
. this would include the case of subtypes
where a supertype's interface is shared;
thus it involves supersets of subtype polymorphism .]
]-5.4: 5.6: 5.8 .
[5.4: the editable menu:
mac`menus are not expected to be user-editable;
but they can launch editable windows .
. in adde's menu-editing mode,
the user has access to 4 menu systems:
# the original menu tree;
# the original keymap;
# the user's version of the menu tree,
# the user's version of the keymap:
. the keymap is a table representing the keyboard
labeled to show each key's function .
left hand . . . . right hand
[][][][high].[] [].[high][][][]
[][][][home].[] [].[home][][][]
[][][][low ].[] [].[low ][][][]
. it's colored to make it graphically obvious
where the home key's row and columns are;
and, users can change the graphics:
the colors, background illustration,
and the nested framing arrangements .
. to stay quick, a text-version is loaded first,
followed by the full graphics .
. after ending adde's menu-editing mode,
only the user's versions are shown .
. in the original keymap, app`authors can show
what they think the most popular functions are
by placing them on the easiest-reached keys .[5.6:
. user's can also have a library of keymaps,
including author's map, current map,
and any other user-designed maps .]
. the style of interaction between {user, keymap}
is user-selectable:
# remindful interaction style:
. when users are in command mode (vs text insert)
typing any key brings the keymap into view,
shows you what you just did, and waits for enter .
# compact interaction style:
. hitting a key fills the command box
with the name of the function you just selected,
and then the command box is waiting for
either {esc, enter} to {stop,launch} the command). [5.6:
. hitting enter on an empty command
would show the keymap .]
]-5.4
. users may want both a menusystem
and a keymap --(before now,
I thought a keymap would be sufficient).
. the keymap title bar has a list of
the types of objects in the current selection; [5.8:
but in the menubar this may be relegated to
a submenu of menu#edit .]
. users may want to place the app`menubar
either in the display`menubar,
or in the current window's menubar .[5.6:
. this will be possible on any system;
because, addx is acting as
a system within a system:
ie, it looks like it's being run by a vm player:
each window into addx represents an addx desktop
within which there are windows into adde documents .
summary of the window nesting:
. mac display ->
mac windows for a mac app named addx ->
addx windows for addx app named adde ->
app windows within an adde document .]
[5.4: hierarchical keymaps:
. the whole point of the keymap
is that it flattens the menu hierarchy
into a table of the user's choice;
however,
the existence of optional co.menus
implies the need for hierarchies of tables:
certain keys can be labeled to
launch new co.menus;
and then each optional co.menu item
is mapped to a cell of the co.menu-specific table .
. there could be room on the main table
in which case
optionality is expressed with grey-outs .
. the purpose of a keymap`title.bar
is indicate which table you selected;
left-arrow brings you to previous one .]
subdesktops:
. a compound document is one composed of
trees and tables of hyperlinks, text,
graphics, numbers, and any new types
for which there are app's to drive them .
. it's as if there are
many app windows in a single document
just as there are
many app windows on a desktop;
therefore,
a compound document can be thought of
as being desktop within a desktop,
and could thus be called a subdesktop .
. adde can then be called
a subdesktop editor .
review of mac`menubar:
. there are various places to put a menubar:
# the mac`menubar is at the top of the display;
it contains a menu belonging to
whichever app is controling the current window;
# many non-mac systems have, instead,
window-specific menu's:
. the app's menu would be located at
the top bar of each window belonging to that app;
whereas the display's menubar would contain only
system-wide menu's (eg, admin' functions,
app's launchers, and a file finder) .
[5.3:
. the mac`menubar has a list of co.menus
(co.menus are side-by-side,
just as submenus are nested under other menus
).
mac's standard co.menus include:
( (system`name)-- about system, param's, updates;
, (app`name) -- about this app, param's, updates;
, file -- interactions with perm'storage;
, edit,format -- modify the currently open file;
, view -- customze how content is displayed
-- (doesn't modify the content);
, (app-specific menus, ...)
, window -- arrange or select the app's windows;
, help -- for both system-wide, and app-specific .
)
. mac'menu's are expected to be complete
in order to represent what the app does;
5.4: eg,
mac`finder's window has a search box,
but it also has this menu:
finder`menu#file/find .
mac`menu#edit:
[5.8:
. mac uses the edit.menu for
anything related to document modifications,
including select, as well as {copy cut, paste};
and, any service that optionally edits:
eg, find(and perhaps replace),
or spellcheck(and perhaps correct) .
. however, there may be other co.menus
that also provide edits;
eg, mac's textedit has menu#format
which modifies the selection's {font,style,...} .
. another editing co.menu is used by vmware,
(if you think of a virtual machine as a document);
vmware`menu#[virtual machine] is used for
pref's that apply only to the current document .]
[5.3: 5.8: a menu#edit for subdesktops:
. mac provides 2 ways to select data:
# edit#menu/select all
# use the mouse to define a subrange .
. therefore,
because subdesktops are compound doc's,
with a variety of datatypes combined;
there are more ways than [select all]
to select things by menu:
you can also subrange by type .
. whether for simple or compound doc's,
there should be a [select some] item
in which a given truth function can define
a subrange of the {moused, typed} selection .
. in sum, selection subrange provides,
for each type in the current document,
a checkbox and an optional constraint parameter;
eg,
[x] is .txt except [find "(todo)]
[ ] is .jpg except [ null ] .
. this can be integrated with the
[select all] like so:
[select all] brings up the
[select some] dialog,
showing you the list of types
with all possible types selected;
so if no subrange constraints are needed
then just pressing enter
works like [select all].
. if the new user doesn't appreciate a dialog,
the dialog can have a checkbox to
"( map this [select some].dialog
to command-shift-A ).
. the currently moused selection
is mirrored in the menu selection:
if a selection is already made,
the [select some] dialog will
reflect that selection state
by checkmarking only the types
that are currently selected .
]-5.8
[5.4: the dynamic menu:
5.4: 5.9:
. mac`menus can have dynamic content:
ie, they will grey-out any menu items
that aren't applicable to the current selection .
. fully dynamic menus can also
add and remove submenus .
. compound doc's have document-specific
combinations of datatypes;
therefore, fully dynamic menus are required
in order to display all the type-specific menus
of all the datatypes contained in the current doc'.
[5.10:
. if mac`menus weren't fully dynamic
then adde's mac`menu could be for adde-wide operations
and then the edit.menu would have a
[type-specific operations ...] item
that would open an adde-designed menu system
which can then support full dynamism .
[5.4: 5.6: 5.8: merging app menus:
. there are several ways in which
the menus of a doc's datatypes
are merged into a single menu system:
# simple:
. a submenu is named by type,
and selecting that command will then
be applied to components of that type only;
other types will be ignored .
. when on the mac,
these type-specific menus would be expected in
menu#edit, along with [select all] .
# subtype polymorphism:
. an example of this is the supertype: number;
its menu items apply to all numeric subtypes
(int,float, Q,Z,R,C) . [5.10:
. the typical supertype menu
would list any operations affecting all subtypes,
and would then have submenus
representing each subtype, and containing only
subtype-specific operations .
. subtyping is concerned with interfaces
rather than implementations;
so, if a float happens to have an integer value
it retags itself as being an int;
however, since ints are a subset of floats
something constrained to int
will never have a chance to
similarly retag itself to float .]
# representational polymorphism:
. representations include
{ value implementations,
, graphical image,
, and programming language image
( adda-representation text )
} eg,
. when numbers are selected,
I can either bold-format a numeric's text,
or I can add the numeric values . [5.11:
. adde must either detect when types use text,
or types must declare this;
types may want to suggest a preference
that would explain to the user
why the preference exists;
the user can overrule any preference
after oking a purpose alert .]
[5.10:
. if an app is using text to represent its content
then a text styling menu
would apply to that app's datatype
(of course, the other text-modifiers
do not apply because
the text represents a type state
not just strings of characters).
. the user may want to vary the text styling
depending on whether the app's mode is:
# show value's graphical image
(might not use text)
# show value's adda-representation
(might be unavailable*)
# show value's implementation .
*:
. while every datatype must be
implemented in adda;
that type's values are not required to
have a written form (adda-representation);
for example,
streetlight.type = (red, yellow, green);
the intended image of the value red
is an icon that is colored red,
the adda-representation of the value red
is the text "(red);
and the implementation of the value red
is the integer: 1 (assuming the
default encoding of enums starts with 1,
and seeing that red is the first value).]
# generic polymorphism:
. the [all types].submenu shows
what operations of identical name
are recognized by every type in the selection
even if each type's authors had no idea
that they were naming their functions the same . [5.11:
. this would include the case of subtypes
where a supertype's interface is shared;
thus it involves supersets of subtype polymorphism .]
]-5.4: 5.6: 5.8 .
[5.4: the editable menu:
mac`menus are not expected to be user-editable;
but they can launch editable windows .
. in adde's menu-editing mode,
the user has access to 4 menu systems:
# the original menu tree;
# the original keymap;
# the user's version of the menu tree,
# the user's version of the keymap:
. the keymap is a table representing the keyboard
labeled to show each key's function .
left hand . . . . right hand
[][][][high].[] [].[high][][][]
[][][][home].[] [].[home][][][]
[][][][low ].[] [].[low ][][][]
. it's colored to make it graphically obvious
where the home key's row and columns are;
and, users can change the graphics:
the colors, background illustration,
and the nested framing arrangements .
. to stay quick, a text-version is loaded first,
followed by the full graphics .
. after ending adde's menu-editing mode,
only the user's versions are shown .
. in the original keymap, app`authors can show
what they think the most popular functions are
by placing them on the easiest-reached keys .[5.6:
. user's can also have a library of keymaps,
including author's map, current map,
and any other user-designed maps .]
. the style of interaction between {user, keymap}
is user-selectable:
# remindful interaction style:
. when users are in command mode (vs text insert)
typing any key brings the keymap into view,
shows you what you just did, and waits for enter .
# compact interaction style:
. hitting a key fills the command box
with the name of the function you just selected,
and then the command box is waiting for
either {esc, enter} to {stop,launch} the command). [5.6:
. hitting enter on an empty command
would show the keymap .]
]-5.4
. users may want both a menusystem
and a keymap --(before now,
I thought a keymap would be sufficient).
. the keymap title bar has a list of
the types of objects in the current selection; [5.8:
but in the menubar this may be relegated to
a submenu of menu#edit .]
. users may want to place the app`menubar
either in the display`menubar,
or in the current window's menubar .[5.6:
. this will be possible on any system;
because, addx is acting as
a system within a system:
ie, it looks like it's being run by a vm player:
each window into addx represents an addx desktop
within which there are windows into adde documents .
summary of the window nesting:
. mac display ->
mac windows for a mac app named addx ->
addx windows for addx app named adde ->
app windows within an adde document .]
[5.4: hierarchical keymaps:
. the whole point of the keymap
is that it flattens the menu hierarchy
into a table of the user's choice;
however,
the existence of optional co.menus
implies the need for hierarchies of tables:
certain keys can be labeled to
launch new co.menus;
and then each optional co.menu item
is mapped to a cell of the co.menu-specific table .
. there could be room on the main table
in which case
optionality is expressed with grey-outs .
. the purpose of a keymap`title.bar
is indicate which table you selected;
left-arrow brings you to previous one .]
freedom from having to trust
4.11: addx/binary extensions:
. the system protects the user from the app coder;
but for more freedom
the app coders perhaps could write extensions
(eg, for directly accessing some hardware [5.11:
and incrementally evolving native code like Python .]
).
. the safety model would be the usual tho':
the user has to ok a warning about
modified systems having no warranty by addx;
ie, the only reason for adding extensions
is to sneak around addx's
safety-minded limitations .
. addx might also ask the user
where they got this extension,
and suggest how they could find
similar functionality elsewhere .
. the safe way to get software
is open source code
written specifically in adda's lang;
which the addx system rewrites into
code it knows is safe;
. extensions don't allow this rewriting;
rather, they are asking the system
to install arbitrary code
which can have full power over your system .
. while such code may be
protecting trade secrets; [5.11:
adda code is guaranteed to protect
your system because the permissions are
per app', not per user (capabilities);
eg, your app can't write to your folders
unless you ok a range of them .
mis:
. this runs into the pc problem tho':
just because we're adults here
doesn't mean were not going to burn;
and then people are using the addx name
to lament how freedom is not idiot-proof;
much better to just take the blue pill
and keep people safe .
. keep in mind freedom vs trust;
the adda code can still do anything;
but only the adda code can be trusted to
tell you every rotten place
it's about to take you to .
"(can I search your folders?
can I use the internet?
do you want to ok what I send out? ...).]
. the system protects the user from the app coder;
but for more freedom
the app coders perhaps could write extensions
(eg, for directly accessing some hardware [5.11:
and incrementally evolving native code like Python .]
).
. the safety model would be the usual tho':
the user has to ok a warning about
modified systems having no warranty by addx;
ie, the only reason for adding extensions
is to sneak around addx's
safety-minded limitations .
. addx might also ask the user
where they got this extension,
and suggest how they could find
similar functionality elsewhere .
. the safe way to get software
is open source code
written specifically in adda's lang;
which the addx system rewrites into
code it knows is safe;
. extensions don't allow this rewriting;
rather, they are asking the system
to install arbitrary code
which can have full power over your system .
. while such code may be
protecting trade secrets; [5.11:
adda code is guaranteed to protect
your system because the permissions are
per app', not per user (capabilities);
eg, your app can't write to your folders
unless you ok a range of them .
mis:
. this runs into the pc problem tho':
just because we're adults here
doesn't mean were not going to burn;
and then people are using the addx name
to lament how freedom is not idiot-proof;
much better to just take the blue pill
and keep people safe .
. keep in mind freedom vs trust;
the adda code can still do anything;
but only the adda code can be trusted to
tell you every rotten place
it's about to take you to .
"(can I search your folders?
can I use the internet?
do you want to ok what I send out? ...).]
amazon-style component distribution
4.15: news.addx/alt's to the spikesource way:
gillmor gang and spikesource:
. spikesource is about selecting and testing
stacks of openwares from the
too-huge number of choices .
. the idea of rss updates were suggested
as a challenge to the spikesource design .
--
. it would take some safe architecture
like addx or ms`.net
for rss to be practically scalable:
anyone could stack any combination of rss feeds
because the architecture was designed to
safely use and mix indie works:
. the architecture would auto'ly accept
only high-level sources that it compiled itself,
and it would auto'ly enforce modularity:
making sure all the plugs & sockets fit each other .
. the spikesource design has to
hand-hold every piece it promotes,
and is not making optimal use of user reviews .
. it should be like amazon, but also sortable by
reviewer reputation or expertise in field .
(that may not be easy to do with volunteers,
but that's where the value is ).
gillmor gang and spikesource:
. spikesource is about selecting and testing
stacks of openwares from the
too-huge number of choices .
. the idea of rss updates were suggested
as a challenge to the spikesource design .
--
. it would take some safe architecture
like addx or ms`.net
for rss to be practically scalable:
anyone could stack any combination of rss feeds
because the architecture was designed to
safely use and mix indie works:
. the architecture would auto'ly accept
only high-level sources that it compiled itself,
and it would auto'ly enforce modularity:
making sure all the plugs & sockets fit each other .
. the spikesource design has to
hand-hold every piece it promotes,
and is not making optimal use of user reviews .
. it should be like amazon, but also sortable by
reviewer reputation or expertise in field .
(that may not be easy to do with volunteers,
but that's where the value is ).
2011-05-02
llvm's role in addx
4.22: addm/llvm's role in addx:
. why can't addm just run llvm code?
isn't elegance a dumb place to put an asm lang?
# c-friendly:
the whole point of addm is to
minimize dependencies;
many systems have no llvm system
but do have a c compiler .
# simplicity = involvement:
. while llvm is all about efficiency,
addx is about making computers accessible .
. just as there can be
cpu's designed for a language,
addm's purpose as a virtual machine
is to match the architecture of adda .
. llvm does fit in as a module:
it would be a tremendous achievement
-- on par with Apple's llvm for obj'c --
to have a way for directly translating
from addm to llvm
rather than the c link used now:
adda -> c -> llvm .
. why can't addm just run llvm code?
isn't elegance a dumb place to put an asm lang?
# c-friendly:
the whole point of addm is to
minimize dependencies;
many systems have no llvm system
but do have a c compiler .
# simplicity = involvement:
. while llvm is all about efficiency,
addx is about making computers accessible .
. just as there can be
cpu's designed for a language,
addm's purpose as a virtual machine
is to match the architecture of adda .
. llvm does fit in as a module:
it would be a tremendous achievement
-- on par with Apple's llvm for obj'c --
to have a way for directly translating
from addm to llvm
rather than the c link used now:
adda -> c -> llvm .
perl(practical extraction & report lang)
4.19: adda/perl/regular expressions:
. if Perl's syntax seems too cryptic
keep in mind the built-in regular expressions .
--
. that degree of terseness should be optional;
adda should have a tool that lets you
write the expression in normal logic;
if you do know perl regex coding,
it should offer to expand that into adda logic
to confirm what was written,
and it should also convert back to regex
for those who want to keep code compact .
illustrations:
-- the comments could also provide
short and long examples of target strings .
. that would be an intuitive but compact reminder
of what the regex code meant .
4.19: adda/lang"perl/compared:
hammerprinciple.com:
Ranked highly in:
# text processing
# good library distribution mechanism.
# too easy to write code in this language
that looks like it does one thing
but actually does something else;
# tends to be terse .
# annoying syntax,
# many features which feel "tacked on".
# for casual scripting of very small projects
eg, write a command-line app
. very flexible .
Ranked low in
# very readable
# built on a small core of orthogonal features
# has a strong static type system
# code is easy to maintain.
# language is minimal
# good for teaching children to write software
# tends to be verbose
guidance from stackoverflow.com:
Coming from C, Perl's syntax is easy;
Perl offers more freedom to
do the "wrong" thing,
It's also prone to ugly code
and "stupid programmer tricks".
also "There's more than one way to
muck it up" .
As for the syntax, Larry Wall (Perl's creator)
has described it as "diagonal"
(in contrast to "orthogonal" languages).
The syntax is designed to mirror the
flexibility and expressiveness of natural language.
. code like (next unless /foo/)
can be slightly jarring at first
but you quickly realize
it flows much more smoothly.
What looks like obscure Perl syntax
is actually a regex pattern
without the (programmer) overhead of
wrapping it in a method call.
But with discipline and coding standards,
you can go far.
(see Perl::critic on CPAN)
. read Conway's "Perl Best Practices"
and Perl Testing
(the Perl community has a VERY strong testing culture).
and check your code with
perl::tidy .
This will help to keep everyone
writing in a similar fashion.
. run a smoke test with Critic on committed code;
Test::Perl::Critic goes in your t/ directory
with all your other tests .
. see the PerlMonks site,
your local Perl user group
and The Perl Review magazine.
. see the great tools & code on CPAN
-- CPAN is the most comprehensive
open source code repository of any language;
most of the code you need to write
has already been written and is available,
searchable and easy to install, from CPAN,
-- you will like how productive
this lang makes you --
Perl is an amazingly good choice when
you are writing a lot of "glue"
that has to talk to a bunch of
disparate systems or work with text.
In many ways,
my favorite platform is CPAN.
Perl just happens to be the language you have to use
to pull together the modules in CPAN.
The ability to just 'get stuff done' is dramatic
when you compare it to even
trying to figure out the API
for an equivalent chunk of code
in a more traditional high level language like Java.
A large part of that power comes from
Perl's initially-strange-seeming
'do what i mean' semantics.
. Perl is the most valuable tool
in any programmer's toolbox.
. "state of the art" modules:
# Moose - a meta object protocol for Perl
it means much of Perl6 OO is available now .
# DBIx::Class
* learning Perl5 now prepares you for Perl6.
- designed to become the lingua franca
of computer languages
Larry Wall has synthesised the best features of
all other programming paradigms
(functional, OO, logic, static, dynamic, concurrency etc)
into one language.
I predict in the next couple of years
Parrot (the Perl6 virtual machine)
and other Perl6 implementations will be released -
. a real Perl programmer has an
understandable, well-documented code base
that is easy to maintain.
. use of Perl as the main development language
has always been a successful business decision
due to the extremely high productivity of a Perl expert
compared to that of a C/C++/Java/C#/Etc expert.
There are IDEs available for Perl.
For Eclipse there is the EPIC plugin.
ActiveState has Komodo.
-- most Perl programmers seem to use
vi or emacs [they are showing their age ?]
. if Perl's syntax seems too cryptic
keep in mind the built-in regular expressions .
--
. that degree of terseness should be optional;
adda should have a tool that lets you
write the expression in normal logic;
if you do know perl regex coding,
it should offer to expand that into adda logic
to confirm what was written,
and it should also convert back to regex
for those who want to keep code compact .
illustrations:
-- the comments could also provide
short and long examples of target strings .
. that would be an intuitive but compact reminder
of what the regex code meant .
4.19: adda/lang"perl/compared:
hammerprinciple.com:
Ranked highly in:
# text processing
# good library distribution mechanism.
# too easy to write code in this language
that looks like it does one thing
but actually does something else;
# tends to be terse .
# annoying syntax,
# many features which feel "tacked on".
# for casual scripting of very small projects
eg, write a command-line app
. very flexible .
Ranked low in
# very readable
# built on a small core of orthogonal features
# has a strong static type system
# code is easy to maintain.
# language is minimal
# good for teaching children to write software
# tends to be verbose
guidance from stackoverflow.com:
Coming from C, Perl's syntax is easy;
Perl offers more freedom to
do the "wrong" thing,
It's also prone to ugly code
and "stupid programmer tricks".
also "There's more than one way to
muck it up" .
As for the syntax, Larry Wall (Perl's creator)
has described it as "diagonal"
(in contrast to "orthogonal" languages).
The syntax is designed to mirror the
flexibility and expressiveness of natural language.
. code like (next unless /foo/)
can be slightly jarring at first
but you quickly realize
it flows much more smoothly.
What looks like obscure Perl syntax
is actually a regex pattern
without the (programmer) overhead of
wrapping it in a method call.
But with discipline and coding standards,
you can go far.
(see Perl::critic on CPAN)
. read Conway's "Perl Best Practices"
and Perl Testing
(the Perl community has a VERY strong testing culture).
and check your code with
perl::tidy .
This will help to keep everyone
writing in a similar fashion.
. run a smoke test with Critic on committed code;
Test::Perl::Critic goes in your t/ directory
with all your other tests .
. see the PerlMonks site,
your local Perl user group
and The Perl Review magazine.
. see the great tools & code on CPAN
-- CPAN is the most comprehensive
open source code repository of any language;
most of the code you need to write
has already been written and is available,
searchable and easy to install, from CPAN,
-- you will like how productive
this lang makes you --
Perl is an amazingly good choice when
you are writing a lot of "glue"
that has to talk to a bunch of
disparate systems or work with text.
In many ways,
my favorite platform is CPAN.
Perl just happens to be the language you have to use
to pull together the modules in CPAN.
The ability to just 'get stuff done' is dramatic
when you compare it to even
trying to figure out the API
for an equivalent chunk of code
in a more traditional high level language like Java.
A large part of that power comes from
Perl's initially-strange-seeming
'do what i mean' semantics.
. Perl is the most valuable tool
in any programmer's toolbox.
. "state of the art" modules:
# Moose - a meta object protocol for Perl
it means much of Perl6 OO is available now .
# DBIx::Class
* learning Perl5 now prepares you for Perl6.
- designed to become the lingua franca
of computer languages
Larry Wall has synthesised the best features of
all other programming paradigms
(functional, OO, logic, static, dynamic, concurrency etc)
into one language.
I predict in the next couple of years
Parrot (the Perl6 virtual machine)
and other Perl6 implementations will be released -
. a real Perl programmer has an
understandable, well-documented code base
that is easy to maintain.
. use of Perl as the main development language
has always been a successful business decision
due to the extremely high productivity of a Perl expert
compared to that of a C/C++/Java/C#/Etc expert.
There are IDEs available for Perl.
For Eclipse there is the EPIC plugin.
ActiveState has Komodo.
-- most Perl programmers seem to use
vi or emacs [they are showing their age ?]
integrating concurrency with oop
4.19: adda/oop/co/integrating concurrency with oop:
. oop was described as msg passing
and then there was said to be a complication
-- inversion of control --
because if you sent a msg
and also expected a response,
then you'd be waiting for a reply to your msg,
meaning that instead of
simply writing a function call,
you were now writing reply handlers for
every use of that function .
. the reason for the handler would be
efficiency:
if your object was getting a lot of requests,
you could be just waiting around
when you could be making more calls
or checking on other replies .
[4.20:
. but, what is there to wait about?
just have the compiler clear a flag
before a remote assignment;
then set it after the remote assignment;
and finally check for the flag
before continuing to use that var .]
. I've long assumed that oop naturally defined
a per-object granularity of concurrency
but now I'm wondering whether that assumption
really holds for my style of oop .
. I like the value-oriented paradigm
(vs the popular address-orientation);
. with value-orientation,
there are still the usual polymorphic functions;
but instead of asking an obj to operate on itself,
the functions can act like they do in
that classic example of polymorphism,
number.type: where {*,/,+,-} are
binary operations over the {N,C,Q,R,Z} subtypes .
. after a var holds a value,
new values seem to come from function assignments;
but, here's what I like about this style:
the functions don't generate garbage;
because,
they use an implicit out-mode parameter, y,
which points at whatever address
the function's result was assigned to .
. all polymorphic vars have expandable
-- but nevertheless localized -- memory
that is dealloc'd in the usual way,
whenever the owning scope retires .
. conversely,
what seems like a self-mutating procedure
is really a like the cooperation between
a function and an assignment stmt .
. the way to view self-mutators like i`+1;
is that they are simply shorthand for i`= i+1;
generally,
y`*(x) means y`= (y)*(x)
and y`f means y`= f(y); each implicitely has
an inout-mode y parameter
rather than the usual implicit out-mode y;
likewise,
to model math's use of y= f(x)
in teaching about functions,
x is the name of a function's
initial activation record,
so the full name of a formal param p,
in a function f, is f`x`p;
or just x`p means self`x`p
where self is the current function
when referring to itself anonymously .
. the interface declares y`f(x) like this:
`f(x.t).proc:
the body implements it as:
f(x.t).proc: ( y`= routine(y, x) ) .
. I also wondered how sequences are preserved;
and, from this brief survey
I discovered the need for a contiguous
(read, Quick-modify, write) critical zone;
now my job is to have it done auto'ly
without involving app developers .
. when concurrent subprograms (cosub's)
are sharing inout access to a var,
the generally required minimal cooperation
is that only one writer has access at a time,
and no reading should be allowed during a write .
. if the compiler can't prove a var is not shared
then it must assume it is,
and provide it with some cooperation scheme .
. oop's message's can serialize concurrent accesses;
but value-oriented oop doesn't require msg-passing .
. the efficient and safe way is a
compiler-administered lock system;
it raises the lock just long eno' to complete
an entire read or write .
. the use must be minimal to protect against
deadlocks and unnecessary waiting .
. another safe use is for an atomic
(read, Qmodify, write) cycle
where Qmodify represents a certain class of procedures
that are guaranteed to be free of deadlock,
because either no dependencies are required
or they have already been procured
before initiating the lock attempt;
and the procedure's loops are proven to terminate .
. when is the (read,Qmodify,write)cycle really needed?
at least for the lock itself:
ie,
redo.loop:(is lock free?
lockit else redo).
-- the generalization of that exists
whenever an externally-aliased object is
# accessed by
both parts of the same conditional
(ie, being read by the guarding expression
# modified by the guarded stmt).
. oop was described as msg passing
and then there was said to be a complication
-- inversion of control --
because if you sent a msg
and also expected a response,
then you'd be waiting for a reply to your msg,
meaning that instead of
simply writing a function call,
you were now writing reply handlers for
every use of that function .
. the reason for the handler would be
efficiency:
if your object was getting a lot of requests,
you could be just waiting around
when you could be making more calls
or checking on other replies .
[4.20:
. but, what is there to wait about?
just have the compiler clear a flag
before a remote assignment;
then set it after the remote assignment;
and finally check for the flag
before continuing to use that var .]
. I've long assumed that oop naturally defined
a per-object granularity of concurrency
but now I'm wondering whether that assumption
really holds for my style of oop .
. I like the value-oriented paradigm
(vs the popular address-orientation);
. with value-orientation,
there are still the usual polymorphic functions;
but instead of asking an obj to operate on itself,
the functions can act like they do in
that classic example of polymorphism,
number.type: where {*,/,+,-} are
binary operations over the {N,C,Q,R,Z} subtypes .
. after a var holds a value,
new values seem to come from function assignments;
but, here's what I like about this style:
the functions don't generate garbage;
because,
they use an implicit out-mode parameter, y,
which points at whatever address
the function's result was assigned to .
. all polymorphic vars have expandable
-- but nevertheless localized -- memory
that is dealloc'd in the usual way,
whenever the owning scope retires .
. conversely,
what seems like a self-mutating procedure
is really a like the cooperation between
a function and an assignment stmt .
. the way to view self-mutators like i`+1;
is that they are simply shorthand for i`= i+1;
generally,
y`*(x) means y`= (y)*(x)
and y`f means y`= f(y); each implicitely has
an inout-mode y parameter
rather than the usual implicit out-mode y;
likewise,
to model math's use of y= f(x)
in teaching about functions,
x is the name of a function's
initial activation record,
so the full name of a formal param p,
in a function f, is f`x`p;
or just x`p means self`x`p
where self is the current function
when referring to itself anonymously .
. the interface declares y`f(x) like this:
`f(x.t).proc:
the body implements it as:
f(x.t).proc: ( y`= routine(y, x) ) .
. I also wondered how sequences are preserved;
and, from this brief survey
I discovered the need for a contiguous
(read, Quick-modify, write) critical zone;
now my job is to have it done auto'ly
without involving app developers .
. when concurrent subprograms (cosub's)
are sharing inout access to a var,
the generally required minimal cooperation
is that only one writer has access at a time,
and no reading should be allowed during a write .
. if the compiler can't prove a var is not shared
then it must assume it is,
and provide it with some cooperation scheme .
. oop's message's can serialize concurrent accesses;
but value-oriented oop doesn't require msg-passing .
. the efficient and safe way is a
compiler-administered lock system;
it raises the lock just long eno' to complete
an entire read or write .
. the use must be minimal to protect against
deadlocks and unnecessary waiting .
. another safe use is for an atomic
(read, Qmodify, write) cycle
where Qmodify represents a certain class of procedures
that are guaranteed to be free of deadlock,
because either no dependencies are required
or they have already been procured
before initiating the lock attempt;
and the procedure's loops are proven to terminate .
. when is the (read,Qmodify,write)cycle really needed?
at least for the lock itself:
ie,
redo.loop:(is lock free?
lockit else redo).
-- the generalization of that exists
whenever an externally-aliased object is
# accessed by
both parts of the same conditional
(ie, being read by the guarding expression
# modified by the guarded stmt).
function notation classes
4.12: adda/cstr/function notation classes:
. how does the type mgt express
parsing particulars?
eg, some infixes can be combined:
a*b*c = *(a,b,c),
whereas, a /b /c = *(a, /b, /c) .
so then (/) is not listable ...
types of declarations:
# unary:
eg, sin(a);
# infix listable:
*(a, ...) -- = a * b * c * ....
--. implies associativity;
ie, (a*b)*c = a*(b*c) = *(a,b,c).
# infix binary:
^(a,b) -- a^b^c = a^(b^c)
-- implies non-associativity;
ie, (a^b)^c =/= a^(b^c);
and, the given rule specifies which way to parse .
--. precedence is indicated by
the order in which operators are declared .
. can also be a prefix .
-- undeclared are assumed to be 2 args of the same type
(ie, the same supertype).
# infix or unary:
/(a=1,b) -- = 1 * /b;
-(a=0,b) -- = 0 + -b
-- /a = 1/a;
# nofix: no arg expected;
eg, pi, e, dimensions,
marks an EOterm
(is also trivially a prefix)
-- declared as having no args: x.t .
# postfix:
(x)!, -- factorial's declaration,
(having multiple parameters but of various types
counts as 1 arg of type record ):
(x.t, x.u)!.v .
[4.30: {postfix, prefix} are treated as separate functions,
like so:
()!, -- postfix
!, !() -- prefix .]
. each type class can overload an operator
as either {unary#prefix, unary#post}
or -- as in the case of Number.type --
{ infix (2 args)
, prefix (other numbers of args)
} . a symbol can be designated as
both pre- and post-fix
but cannot be both post- and in-fix .
. the one place math has a postfix is (x!).
in that case,
it's at the end of a term just like an infix
so the only way to be certain that a postfix
is not the infix found between terms
is by disallowing operators from being
both infix's and postfix's .
. postfix's can, however,
double as prefix's,
as can the infix's;
so, expecting a term and finding (!)
means the (!) is a prefix to that term;
whereas, expecting an infix or EOse
(end of subexpression) and finding (!)
means the (!) is a postfix .
. a subexpression can have multiple terms
separated by infix's;
terms are defined as being either:
nofix's: symbols accepting no args;
or a prefix followed by an arg .
. a subexpression is anything terminated by
an enclosure`end:
ie,
, . ; ) } .> end-of-file ] .
. how does the type mgt express
parsing particulars?
eg, some infixes can be combined:
a*b*c = *(a,b,c),
whereas, a /b /c = *(a, /b, /c) .
so then (/) is not listable ...
types of declarations:
# unary:
eg, sin(a);
# infix listable:
*(a, ...) -- = a * b * c * ....
--. implies associativity;
ie, (a*b)*c = a*(b*c) = *(a,b,c).
# infix binary:
^(a,b) -- a^b^c = a^(b^c)
-- implies non-associativity;
ie, (a^b)^c =/= a^(b^c);
and, the given rule specifies which way to parse .
--. precedence is indicated by
the order in which operators are declared .
. can also be a prefix .
-- undeclared are assumed to be 2 args of the same type
(ie, the same supertype).
# infix or unary:
/(a=1,b) -- = 1 * /b;
-(a=0,b) -- = 0 + -b
-- /a = 1/a;
# nofix: no arg expected;
eg, pi, e, dimensions,
marks an EOterm
(is also trivially a prefix)
-- declared as having no args: x.t .
# postfix:
(x)!, -- factorial's declaration,
(having multiple parameters but of various types
counts as 1 arg of type record ):
(x.t, x.u)!.v .
[4.30: {postfix, prefix} are treated as separate functions,
like so:
()!, -- postfix
!, !() -- prefix .]
. each type class can overload an operator
as either {unary#prefix, unary#post}
or -- as in the case of Number.type --
{ infix (2 args)
, prefix (other numbers of args)
} . a symbol can be designated as
both pre- and post-fix
but cannot be both post- and in-fix .
. the one place math has a postfix is (x!).
in that case,
it's at the end of a term just like an infix
so the only way to be certain that a postfix
is not the infix found between terms
is by disallowing operators from being
both infix's and postfix's .
. postfix's can, however,
double as prefix's,
as can the infix's;
so, expecting a term and finding (!)
means the (!) is a prefix to that term;
whereas, expecting an infix or EOse
(end of subexpression) and finding (!)
means the (!) is a postfix .
. a subexpression can have multiple terms
separated by infix's;
terms are defined as being either:
nofix's: symbols accepting no args;
or a prefix followed by an arg .
. a subexpression is anything terminated by
an enclosure`end:
ie,
, . ; ) } .> end-of-file ] .
2011-05-01
label as comment and method signature keywords
4.27: adda/obj'c/param'labels:
. 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,
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?
# 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 .
. 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 .
Subscribe to:
Posts (Atom)
