Maybe he could have adapted an existing one, but I think the main issue was that parsers traditionally just quite when they find an error, language.js has some error recovery feature (naughty or) to proceed with parsing.

It's back up now.

Not sure this is the place for it (maybe ask on the google group?) But there's two ways:

screen root() { mydiv@<div/> script { mydiv.someplugin(); } }

mydiv will be bound to a JQuery object representing the div. You can also just do this:

screen root() { script { $("#div").someplugin(); } }

So generally your answer is: put it in a script { ... } block.

Generate your mobile web application using mobl. Then wrap it as a PhoneGap native app. They're complementary.

Did anyone try this; seems like a cool option?

I experimented with it. Works fine. There's an ongoing effort to also wrap the PhoneGap-specific APIs (such as camera, contacts) as mobl libraries: https://github.com/mobl/mobl-lib/tree/master/phonegap

I think many people missed my main point. Here's another shot at explaining it better: http://zef.me/3753/planning-ahead-the-async-javascript-probl...

State of the art in parsing is SGLR (http://strategoxt.org/Sdf/SGLR) and GLL parsing

See also Adam Megacz' SBP ("Scannerless Boolean Parser") (http://research.cs.berkeley.edu/project/sbp/). Boolean grammars are a superset of context-free grammars that can do some interesting things. For example, one can write a scannerless grammar for Python that handles the significant indentation in the grammar.

Thanks a lot for the link, I'll look through it.

I also found the GLL paper at p. 113 [123] of http://ldta.info/2009/ldta2009proceedings.pdf

The SGLR parser in Strtego/XT is not state of the art, at least not for production use. It only supports pure seven bit ASCII, it is a throwback to the 1970ies.

That's what I use. But Douglas Crockford suggests using a different way of building object hierarchies which he uses. I could ignore this, but Crockford kinda is one of _the_ Javascript guys, who, supposedly knows what he's talking about: http://javascript.crockford.com/prototypal.html

Eh, I give Crockford all the respect in the world as one of thee js guys, but I've always found that object function downright disgusting. I am still trying to understand what advantages his prototypal toolbox has over his classical one.

Alright. So now I want to iterate over all original keys, how do I do that (i.e. their original values, not the stringified version)?

Plus, a random object (that doesn't have a meaningful toString method) will probably result in something like "[object]" as a key, which would break when you use more objects like that as keys.

Yeah agreed. The edit was intended to concede that your statement about only being able to use strings was technically correct and mine about using objects was misguided :)

One good use case for objects as keys in hashes is functions. When you use a function as a key it is reliably converted to its definition, cross-browser. Doesn't make your point any less valid though.

> So now I want to iterate over all original keys, how do I do that

for(var key in obj) { if(obj.hasOwnProperty(key)) val = obj[key]; }

Or did I misunderstand the question?

The key is now effectively '1,2,3' in the case [1,2,3] . You can iterate using that string and even pass in the array using bracket notation. But when you iterate using for..in the key will be a string not the original array, and you lose that data. The string is now indistinguishable from the subset of strings with comma delimkted data. May that is inconsequential in your app but for some apps it dampens the effectiveness of the construct.

Ain't JavaScript a riot? [I just found an excuse to use snowclone in an HN comment. Pats self on back]

Functions on the other hand work very well because the key is the function definition (call toString on a function). There is no reason for two functions to have the exact same definition in JavaScript.

In my post I link to JSAN, which is exactly that: http://openjsan.org

It has its own module system.

At the time I created that library, JSAN was a dead site. There were rumors that it would be revived some day, but it hadn't happened.

Maybe I wasn't clear enough in my post, but I said this:

> and the good thing is that it does not require any changes in the Javascript language itself, nor its browser support.

As far as I'm concerned it would be fine with a standard library in a file (std.js, or base.js), that I would just include on every page, it does not have to be implemented in the browser at all. Maybe on the long term, for efficiency, but necessarily. Indeed, the nice thing about Javascript is that it is flexible enough to do this "ourselves". So I would say the "but what about IE" discussion is kind of irrelevant, unless there's some core Javascript features it doesn't support that we absolutely need.

Let me briefly tell you where I'm coming from. A month or two ago I started working on an O/R mapper for Javascript, built on top of the HTML5 SQL store (http://github.com/zefhemel/persistencejs). I wanted this library to be useable from any Javascript framework and supply an as "native" a Javascript API as possible. There were two problems that I came across:

1) What is the proper way to do OO? I read "JS: The Good Parts", but it discusses like 3 or 4 ways of implementing OO and variations on inheritance, each having different advantages and disadvantages, either using the new keyword or not etc. Personally I'm open to any OO style, just tell me which on to use. There was no obvious answer. There's a bunch of frameworks that offer utility objects to do inheritance "properly", do mixins etc., but I didn't want to buy into any framework in particular. So eventually I went with the constructor function (function MyObj() { }, new MyObj()) approach, manually solving inheritance problems as I went along.

If there would be a style, possibly with some utilities of doing OOP in Javascript that "everybody" would agree on, I wouldn't have had this problem. I'd just say "ok, let's rely on this std.js/base.js and it's obvious how to do it". Everybody would understand my code, because they'd use the same style as well. Sure, it's a very powerful thing that we can do inheritance in 4 different ways, but it doesn't simplify communicating the fact that we're trying to implement inheritance, or how to use a particular constructor function (should I call new Bla() or just Bla()?).

2) I needed to implement the observable pattern, I need to respond to changes in objects. Some JS frameworks contain an implementation of the observable pattern, but I don't want to rely on any framework in particular, so what should I do? I ended up implementing a lightweight one myself, which is included in the library. A bit of a waste of effort, plus of code size when somebody uses persistence.js together with another framework that also contains an observable pattern implementation.

The observable pattern is another example of a construct that's common enough to be in such a standard library. If we decide on a particular implementation, we can all utilize it without being too dependent on larger frameworks. We only have a dependency on the small standard library.

I'm currently working on a larger HTML/Javascript problem and there the modularization problem popped up. I want to declare module dependency and have them automatically be loaded. Again, Google Closure, Dojo and YUI provide ways to implement this, but I have been using jQuery so far, should I switch or add Dojo/Closure/YUI to my project, just to get the modularization features? That seems a bit excessive.

If we would have agreed upon modularization features in a standard library that all the frameworks used, I wouldn't have this problem.