Re: complexity tax
Well, most languages have better support for libraries than C or C++. But there are things that even C has and JS2 doesn't: * #include * a linker * a somewhat standard manner of distributing these libraries (.a or .so) * arguably, a [not necessarily hacker-proof] mechanism for sharing symbols between several components without exposing them to the client. Note that I'm not attempting to advocate the merits of #include, which I find rather ugly. I also have no idea whether the linker is part of the spec or not -- but then, I wasn't discussing specs, more developer experience, and linkers have been part of the standard package for as long as I've been programming. Now, with JS2, to get something linke #include + linking (or Java's import), you need to use somewhat more convoluted methods. In addition, all the techniques I have seen require some hard-wiring inside the document, which may be good for small webpages, but looks like a rather bad practice when you're talking about whole applications: essentially, this is equivalent to putting all your #includes inside the UI code. Finally, while the methods may work in a webpage, not all of them apply well to non-web JS -- I'm thinking about off-line extensions, XPCOM or server-side JS. This strikes me as a good reason to improve library management in JS. Which was the case last time I looked at ES4, although I may have missed a few developments on that front. Cheers, David On Thu, 2008-03-27 at 10:30 -0400, Mike Shaver wrote: I don't quite understand this -- could you give an example of a language that has better support for libraries as part of its language specification? I don't think the C specification includes linking (or even the ABI, though C++ grew an ABI specification later), so it seems to be about at the same point of get your code into scope somehow. Browsers use script for that, and many an AJAX toolkit has added new capabilities to the environment through just that means. Mike -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: complexity tax
On Wed, 2008-03-26 at 08:23 -0700, Douglas Crockford wrote: The difficulties we have had in the development community since 1999 were not due to over-minimization. They were due to features that did not work as expected or reliably over the various brands and versions. In my experience, the main problem with JS was the impossibility of extending it. That is, no notion of libraries and no built-in pre-processor (although reflexivity could be used for similar purposes). A consequence was that any extension deemed important by the developers of a browser had to be bolted-on in non-specified manners. Now, all the features I see en ES4 are nice (my favorite being the hybrid type system, although type inference is going to be a heck to design and implement) and I can see myself using most of them, but I would have been content with just the addition of libraries and pre-processor. Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: complexity tax - mobile devices - Microsoft + Adobe tools + future browsers
On Wed, 2008-03-26 at 14:56 -0700, ToolmakerSteve98 wrote: I am putting together a toolset that bridges .NET Silverlight development tools with Adobe's tools. I've decided to do a proof-of-concept for a given scope of language, specifically using type-inference technology in F# to provide a statically-type-bound compilation of a subset of ES4. Do I understand correctly that you're compiling your subset of ES4 to F# ? Sounds interesting. Do you keep a blog on that ? Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: performance of OO dispatch in inner loops
On Fri, 2008-03-21 at 13:45 -0700, Brendan Eich wrote: You really should read the papers, and Andreas Gal's blog. Probably. I'm not an expert in [dynamic] optimisations, my line of work is mostly related to static analysis. Do you suggest any specific papers other than the blog ? Runtime types are only one of many kinds of information available to runtime optimizers. Tracing loops allows hoisting and even allocation elimination, using escape analysis. Common sub-expression elimination can consider trace-invariant expressions. One can guard all sorts of on-trace assumptions and compensate to the interpretr, re-tracing other hot paths. It's not just about types. I'm quite aware that there's more to optimisation than removing dynamic type checks consolidating dynamic method dispatch. I was just answering that particular point. Having written this, there are open issues with tree folding to avoid proliferation of paths in the trace tree. Again, see http:// andreasgal.com/ for more. Thanks for the reference. Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft LAST CALL: Map
I have a question related to collections in general. I have the impression that ES4 will someday accept some kind of high-level concurrency, possibly Erlang-style. If so, we will probably need the ability to perform some kind of (destructive) pattern-matching/switch-type on the contents of a collection. Now, maybe this kind of pattern-matching will only needed for some concurrency-specific data structure, say a dynamically-typed Mailbox (à la Erlang) or a statically-typed Channel (à la Concurrent ML) or perhaps something higher-level (à la JoCaml). With the current definition of Map and collections, this form of pattern-matching may probably be hand-coded using an iterator and intrinsic::remove, although the process is relatively unfriendly and the thread-safety will remain uncertain until there's a concurrency model for ES4. Now, on to my question: should we add a method for finding some data in a collection from destructive pattern-matching or should this be left for later ? Cheers, David Quoting Lars Hansen [EMAIL PROTECTED]: Last call for comments. Minor changes since previous drafts (and some comments at the beginning to address changes that are known to come). --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: performance of OO dispatch in inner loops
I'm not sure about necessary but for useful, see for instance _Practical Soft Typing_, by Andrew Wright. Performance analysis for softly typed Scheme show that, on the benchmark, 20% to 50% of the time of the execution was spent performing run-time checks which may be automatically removed. Cheers, David Quoting ToolmakerSteve98 [EMAIL PROTECTED]: was [Re: Any discussion of compact subset for mobile devices?] Brendan Eich wrote: Why do you believe static typing is necessary for performance? Just curious. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Dylan 'nullable' types [Was: Close review of Language Overview whitepaper]
I guess it's one of these things we may try and static-analyze-away. Cheers, David P.S.: Should I mention OCaml's option types or Haskell's maybes at this point ? On Thu, 2007-11-15 at 14:06 -0800, Graydon Hoare wrote: P T Withington wrote: I must say, coming from Dylan, es3's undefined _and_ null seem like overkill... but we're stuck with them now! I think they feel like overkill to everyone, but yeah. Backward compatibility! -Graydon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Opaque / abstract types ?
Hi list, After reading the Outline document, I find myself wondering if there's a way to provide a type without any method for the user to manually create an inhabitant of that type ? This is a technique commonly used in functional programming (and sometimes used in Java/C#, too, I believe) to provide type-checked safety / security, e.g. you can only call function read_from_file with an argument of type FileOpenedForReading, which itself may only be obtained from function open_file and cannot be forged. Of course, this example applies to files, but could just as well apply to any kind of credential. From the Outline, operator as and reflexivity make me think it's not possible. Am I wrong ? Cheers, David -- David Teller -- Security of Distributed Systems --- Project JStify: Static Analysis for JavaScript 2 - -- http://www.univ-orleans.fr/lifo/Members/David.Teller - Laboratoire d'Informatique Fondamentale d'Orleans ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Rule 317
Ok, I think I'm now understanding something that I had completely missed about that syntax: it's LR(1). I was assuming it was something much more complicated with unlimited backtracking. Dumping my code and restarting the parser with lighter tools... Thanks and cheers, David On Tue, 2007-10-23 at 19:20 +0200, liorean wrote: On 23/10/2007, David Teller [EMAIL PROTECTED] wrote: So I guess this could just be handled by making this rule have a lowest priority ? Not really. In statement context, a function without a name should be a syntax error -- David Teller -- Security of Distributed Systems --- Project JStify: Static Analysis for JavaScript 2 - -- http://www.univ-orleans.fr/lifo/Members/David.Teller - Laboratoire d'Informatique Fondamentale d'Orleans ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Rule 317
Hello list,
I'm still fighting the syntax of JS2. Attempting to feed it into a
parser generator (menhir, for the moment), has already allowed me to
find a few typoes in the spec and a few useless variables in the
reference implementation, which is all I have to show for the moment.
That and the fact that all XML* productions seem absent from the RI.
At the moment, though, I'm being puzzled by rule 317:
ExpressionStatement
| ListExpression (allowColon, allowIn)
[if lookahead not in { function, let, { }]
Besides the fact that this rule is annoying to implement, does it
actually mean what it intends ? In addition to blocks, it also prevents
an assignment to an object pattern from starting the ListExpression. Is
that desired ?
Thanks,
David
P.S.:
I forgot where I found that version of the grammar, it's dated
14/10/2007, so I assume it's the latest. Where are they to be found, in
general ?
--
David Teller --
Security of Distributed Systems ---
Project JStify: Static Analysis for JavaScript 2 -
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
- Laboratoire d'Informatique Fondamentale d'Orleans
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Rule 317
On Tue, 2007-10-23 at 14:58 +0200, liorean wrote:
It's there to prevent the grammar from being ambiguous. function,
let and { have different meaning in statement context from
expression context. If the ExpressionStatement construct allowed them,
then they would be ambigous in statement context, they could have
either the statement or the expression semantics. So, in order to
prevent this ambiguity, they are not allowed in ExpressionStatement.
So I guess this could just be handled by making this rule have a lowest
priority ?
Cheers,
David
--
David Teller --
Security of Distributed Systems ---
Project JStify: Static Analysis for JavaScript 2 -
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
- Laboratoire d'Informatique Fondamentale d'Orleans
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: 'switch' operator improvement
Pattern-matching with views [1,2], anyone ?
Cheers,
David
[1] http://martin.jambon.free.fr/micmatch-manual.html#htoc10
[2] http://blogs.msdn.com/dsyme/archive/2006/08/16/ActivePatterns.aspx
On Tue, 2007-10-16 at 20:11 +0200, liorean wrote:
On 16/10/2007, Peter Hall [EMAIL PROTECTED] wrote:
already you can do something like this:
var str;
switch(true){
case /a/.test(str):
alert('a');
break;
case /b/.test(str):
alert('b');
break;
}
I can only imagine that solution being preferable to chained
if..else-statements in one case, and that would be if you actually
used the fall through mechanism. If you don't fall through, it's just
bloat without any gain.
--
David Teller --
Security of Distributed Systems ---
Project JStify: Static Analysis for JavaScript 2 -
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
- Laboratoire d'Informatique Fondamentale d'Orleans
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Yacc ?
Just a simple question about the reference implementation: why is the parser hard-coded rather than written with ml-yacc ? I admit that I'm somewhat tired about converting this parser manually to OCaml with bunches of regexps + human proofreading, so I'm wondering if I shouldn't skip this and go directly to Yacc or equivalent. Thanks, David -- David Teller -- Security of Distributed Systems --- -- http://www.univ-orleans.fr/lifo/Members/David.Teller - Laboratoire d'Informatique Fondamentale d'Orleans ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Type Annotations ?
Hi everyone, I'm still working on my static analysis tool for ES4. This tool will make use of custom type (or type-like) annotations. I wonder if there are already syntax guidelines for this kind of things. I assume I should put them somewhere in comments. Should I use something like Java's @annotation tag ? Thanks, David -- David Teller -- Security of Distributed Systems --- -- http://www.univ-orleans.fr/lifo/Members/David.Teller - Laboratoire d'Informatique Fondamentale d'Orleans ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Type Annotations ?
The type annotations I have in mind would be related to side effects.
So, should I go for something like
function write_to_file(f : String /*file_name*/): void /*write f*/ {
...
}
?
Cheers,
David
On Wed, 2007-10-03 at 07:44 -0700, Lars T Hansen wrote:
The ES4 syntax for type annotations is invariably a postfix : type
phrase: put it on variable bindings, parameters, functions (following
the parameter list).
--
David Teller --
Security of Distributed Systems ---
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
- Laboratoire d'Informatique Fondamentale d'Orleans
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: URI Proposal
Just one quick word: be careful when designing a URI class that it should be able to deal with URNs, too. Cheers, David On Fri, 2007-09-07 at 14:29 -0700, Garrett Smith wrote: I've decided to propose a URI class to deal with the handling of URIs that is so prevalent in Ajax apps and also in Flash and to a lesser extent, Adobe Reader. I propose this idea here because noticed that there are other places besides the web that can use it (Flash, Reader). A URI class could be implemented in ES to cover all these needs. I have a proposal page at http://www.dhtmlkitchen.com/rec/URI.html I won't copy paste the entire thing here. It prints on 3 pages if you set margin to 0 and scale to 70%. Is this the appropriate way to make a proposal? Garrett -- David Teller -- Security of Distributed Systems --- -- http://www.univ-orleans.fr/lifo/Members/David.Teller - Laboratoire d'Informatique Fondamentale d'Orleans ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
