Just walk the object graph starting from the root object and let the
set of all reachable symbols be A.
Load jQuery
Walk the object graph again letting the set of all reachable symbols be
B.
The public API of jQuery is then (B - A).
That's works fine under 2 conditions:
1. You're willing to execute code instead of statically analyze it
2. You're capable of executing that code in isolation.
This should be true for most libraries out there.
It obviously doesn't hold for user code and definitely not for all
code in an IDE since IDE's have to deal with code during editing.
One standard way around this dilemma is to execute such code
abstractly (known as "abstract interpretation"). What that means is
that the code is run through an alternative engine that does not
execute the code in full detail, but only as far as necessary in order
to infer some interesting properties.
In particular, one wants the abstract interpretation not to have
side-effects (like network or file system operations) and one wants
it to terminate (quickly; so branches and recursion tend to be
approximated).
Unfortunately, interesting properties tend to be undecidable, ie,
they cannot be extracted from arbitrary code while guaranteeing
termination (oversimplifying: you have to run such code in full
to find out what it does..).
There is no magic cure for this, but it is possible to design
languages and programs in such a way that a practically
relevant subset of the properties of interest becomes decidable.
Doing that requires thought and a lot of work (and open minds
to begin with), but the benefits tend to be worth it.
Without support from language and program designers, it does
not matter how many companies throw how much money at tool
development (no magic bullets). Unless you want to find out how
much money they are willing or able to throw before they start
throwing towels.
Support is not so much about syntax as it is about statically
recognizable programming patterns (so that one can distinguish
code with arbitrary effects from code that just adds properties to
a class of objects, or export items to a module; and so that one
can extract useful program properties without having to run the
code in full).
The reason syntax tends to be mentioned is because syntax frozen
in the language spec tends to be less flexible than general code
implementing the same feature in the language. So it looks easier
to analyze, and cannot be re-defined (in current JS).
But adding this kind of special-case syntax makes a language
more complex, by adding lots of constructs that -by design- do
not support the full expressiveness of the language. Other
languages have demonstrated that one can fix programming
patterns sufficiently to permit analysis, without fixing syntax
(added bonus: less syntax, less complexity -easier for coders
and tools to read/analyze- and more general usage patterns
through homogeneous syntax with few special cases).
For this particular problem (improving analysis support), syntax
is the wrong level to work at, but in order to see that, one would
have to make an effort to work with modern type systems - why
they work, and how that interacts with language and program
design. To begin with, one can think of a type system as an
abstract interpretation engine with enhanced information flow,
and of types as program properties.
Also, if coders can express their intentions (do they really mean
an object, or a record, or a map, or an array, ..?), it tends to be
easier to check whether an implementation matches those
intentions (within the limits of decidability, so one is usually
looking at guaranteeing invariants) than to guess what those
intentions were in the first place (is this a function or a method
and should we give it dynamic super or not? are objects from
this constructor expected to retain a certain set of properties
or can they change arbitrarily? is this function going to spider
the web, or will it just add a few methods to an object? can
we rely on function F to be the one in the spec, or could it
have been overwritten?).
It would be great if vocal JS coders with strongly expressed
opinions ("often in error, never in doubt") could try a language
like Haskell for a mini project. Don't worry about advanced
features, just convince yourself that a static type system does
not have to get in the way as often as one might expect.
Then, for your second project, start thinking about what you
and the language have to do to make better use of types,
rather than just get your code to compile: where do you have
to change your coding patterns, compared to what you would
do in JS, and how does that help the type system?
After taking these two steps (*), you will be ready to think
about the pros and cons of syntax or types for helping JS tools
with code analysis. And then about how this should affect JS
language design. The basics don't require a big effort, but one
should allow that type/analysis research has not been idle in
the last 30 years - there are reasons why languages and type
systems need to evolve together.
Similar real-code experiments might help with discussions of
"short syntax", where the point is not to save n characters when
defining a handful of functions, but to make functional abstraction
so lightweight that it can be used as pervasively as one uses
strings and numbers now. And another such experiment might
help to convince that language-level threads and event loops
are not mutually exclusive (though that information could also
be found on the ecmascript wiki) and that such threads can be
made so cheap that they can be used pervasively. And so on..
Sorry about this side-line. I'm not picking on anyone in particular,
but I find it distressing how strongly expressed opinions do not
always match with good information. And since those with good
information tend to be silent while considering ramifications or
writing code, JS discussions (outside this list) are all too often
driven by strong opinions. The more JS coders have their own
practical experience with these topics, the fewer of them will be
tempted easily. Readers of this list tend to make an effort to be
informed, so can set good examples in other forums.
(if there wasn't so much JS activity to cover, some JS events
might consider guest talks, to borrow experience from users
of "nearby" languages)
Claus
http://clausreinke.github.com/
(*) Coming from a group of dynamically typed coders that
used to collect code examples that could not be typed
statically, I found it enlightening to actually develop some
project in Haskell and find types much less of a problem
than I expected (making good use of types takes a little
longer). I also found as many static type zealots as
dynamic type ones, and a depressing amount of
misinformation on both sides.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
