On Wed, Oct 5, 2011 at 10:03 AM, Claus Reinke <[email protected]> wrote:
>>>> 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?).
I agree with this 100%. Languages as dynamic as JavaScript and Ruby
are interesting, because as much as the freedoms can allow for more
concise code and a level of expression that can often be difficult to
achieve in more statically typed languages, it can also lead to a
place with almost no constraints or guarantees. Sometimes these
guarantees can be remarkably useful for the coder, the compiler, and
the tooling.
> 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.
I don't think I qualify as a vocal JS coder, though I write a lot of
it, and I have learned a fair amount of Haskell. I'm pretty sure I
even understand monads ;) I find that even though you don't write a
lot of types because of inference, you do think about it a lot more,
especially when they get complicated. Sometimes this can be a good
thing, and sometimes not as much, though I would argue even a JS coder
should be thinking about types - structurally speaking. Types exist
static or not.
> 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?
I think a lot of common patterns, especially in library code that does
a lot of meta-programming would be a lot harder to do with static
types. Good or bad, I think a lot of code would have to change if that
bar got bumped very far. However, seeing as anything added would still
have to backwards compatible for the most part, I think anything done
to the type system which isn't just sugar would have to be optional
for sure, and then that would have to still mix well with the
dynamically typed code.
> 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.
If I had my way, I would probably try to get JavaScript to allow
structural typing as much as possibile. Optional structural types I
guess - with as much type inference as possible. Runtime checks for
guards when not possible statically.
With the notion of freezing and sealing in ES5, we're starting to
approach the ability to make these types of constraints, but because
of the way they are being done imperatively, a lot of those
constraints are a lot harder to use, and certainly much harder to
analyze for tooling, and I imagine the compiler? I guess that is where
I would want things to go - things like the updates to object literal
syntax are a great start.
- Russ
> 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
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
