StopIteration and undefined

Good to know:

StopIteration and undefined are mutable globals by Dave Herman: "Luckily, there's generally some reliable way to generate such a value without having to hope that no one has reassigned a global variable."

Declaring Object Structures

There are different ways of creating object structure.
One is declaring a structure:

Declerative programming emphasises on the principle of concentrating on WHAT is the result and not HOW it that result achieved.

SQL is for example a declerative query language. As a consequence there are lots of implementation variations and they can be improved without the changing the user code.

There is a good language for everything, look how we can declare object structures for example a HTML DOM structure:

• Computational Construction
  
  This involves calling an API, and create instances directly with function calls. It is thus not delerative at all:
  
  

  
  var body = document.getElementByTag('body')[0];
    var div = document.createElement('div'); body.appendChild(div); div.setAttribute("class","c1 c2");
       var p = document.createElement('p'); div.appendChild(p);
         var bla = document.createTextNode("bla bla"); p.appendChild(bla);
  

  
  
  This a very verbose way to build object structures.
  We are using functions to declare a structure by 'computing' it, altough there is not much computing going on, more wiring structures together over and over again.
  Each each library of functions creates a sort of new 'language'. But as it are functions the emphasis is still on computation. The disadvantage is that there is so much freedom in ordering and verbose calling going on, that we can not capture the relevant information at once: What is really going on? Compare this to the next code resulting in the same structure:
  
  

  
  var bla = document.createTextNode("bla bla");
  var body = document.getElementByTag('body')[0], div = document.createElement('div');
  var p = document.createElement('p'); p.appendChild(bla);
  body.appendChild(div);div.appendChild(p);
  div.setAttribute("class","c1 c2");
  

  
  The focus on HOW we build it, hides the knowledge about WHAT we build.
  



• Representive Data Declaration
  
  In this case we define the final oject structure, what we want, by using representive data structure:
  
  

  
  var html = [{ body : [{}, {div:[{ class: "c1 c2" }, {p: [{},"bla bla"]} ]} ]}
  }]
  

  
  
  We then need extra functional code wich translates the object structure into the final object structure: funtion get_node(description,document){ .... return 'the node';}, which can hide all sort of implementation details.
  
  With this pure data based approach, we are forced to use the elements and semantics provided by the base language. Here we use for eample javascript object literals to express html literals. As javascript has other semantics then html mark up it is not so good at it. It makes it more verbose. See how we have to express that importance of ordering of html child nodes by using arrays, and how we allow multiple object with the same name by using objects with a single attribute. That is why we get these repeating ':[{' ']}' and kind of brackets.
  
  A small advantage is that the parser checks some of the brackets, but as the correctnes depends on a certain combination, the correct 'html' syntax can be checked only at runtime.
  
  Another advantage is that you only need to learn javascript to be able to 'read' html, and not an extra language. On the other side to 'understand' it, you still have to learn the html concepts. And the verbose non suitable notation is not very helpfull.
  
  Ext uses this approach combined with the computational construction.
  
  Other examples of this approach and its limits can be seen when using XML based template languages or even XSLT. Very often XSLT contains computational elements like 'if' 'then' 'else'.
  Expressing this in a declerative language that was not designed to be computational becomes very verbose and besides it then is a sort of 'XML' it does not provide any advantage. We use a lanaguage for what it was not designed, and therefore is not good at. The interpunctation is not optimized. For example XML only knows nested brackets, we can not express directly an expression with 3 elements 'if C then A else B' directly, but have to encode it: 'AB' or simular. To make it simple we then put functional code like javascript in the string attributes or text nodes.
  That is mostly often exactly what template languages do.
  



• Decleration with Function Language
  
  Here we use function calls with objects as parameters in a mixed way, as builders to create the object structure:
  

  
  var body_node = body()
    .div({class:"c1 c2"})
      .p("bla bla").end() 
    .end()
  .end().toString(document);
  

  
  
  This allows a short flexible notation mixing calls and parameter objects.
  
  Note how this approach goes step further in using functions as interpunctation elements. The meaning changes depending on the context. Here a own block/bracket structuring language is developed by using javascript function names.
  Because we are allowed to introduce new function names with n paramters we can change the set of available language elements.
  
  The syntactical correctnes is not controlled by the language parser, but could be at runtime. Throwing a missing end() call exception for example.
  
  This is thus creating a new language using a an other language. We thus can use the programmatic API calls mixed with object strcuters as function parameters as an implementation of the function language deceleration.
  
  jQuery also uses this approach.
  
  





• Dedicated Language
  
  
  This seams to be the shortest and clearest way to declare a structure. Use a dedicated optimzed language, suited to the purpose.
  
  

  
  var body = '<body><div class="c1 c2"><p>bla bla</p></div></body>';
  

  
  
  Note how the function language decleration approach may serve as an implementationof a parser/compiler/runtime system for such a language.
  
  In a first attemp, a pre processor could translate the above code in a appropiate function calls:
  
  

  
  var body_node = body().div({class:"c1 c2"}).p("bla bla").end().end().end().toString(document);
  

  
  
  While many people resist when developers want to define a new language, because things become 'complicated' then this is just part of the truth. Above examples show that without a dedicated language, things do not get clearer. While not learning something 'new', that standard code is very 'hard' to understand so what costs more? The problem is that it is not easy to design a good language and often you would need to extend it, adapt it to changes. You must spreak a fashionable language, you need to find enough developers. You need good debugging capabilities etc. This makes it as hard just like the framework programming where you start depending completly on the framework/compiler developer.
  
  A big part of the problem is that the dedicated language gives you the feeling of being locked in the 'every thing must be expressed in this language/framework' trap. And things start to become even more problematic if in an attempt to 'escape' these limits complete external languages are mixed in with there own different semantics but then need to communicate with each other using API calls, then all sort of adapters libraries, translations are needed and then at the interfaces all sorts of conversion errors and mismatches occur. You are in a trap.
  Just see what happend to the HTML Javascript, java, flash mixing.
  
  A requirement to make a language work is to be able really to hide the implementation for 95% of the cases to developers and allow a simple debugging. This 'all or nothing' requirement is what makes a dedicated language not suitable for single projects. There are how ever some things that can done to embed a dedicated language, and not suprisingly they are the same as for developing a library:
  
  
  
  
  • Take a primary full supported language with debugger libraries as starting point. And embed your stuff in it. Not the other way round.
    First design a good library of you add ons.
    
  
  
  
  • Make the use of the language extension optional. The old framework idea don't call us, we call you approach is causing the locked in the trap. It makes you reacting like a fool, never knowing when you are getting called and why. Debugging is a pain. The developer of the user code must be in control when he calls what. Most developers even SQL programmers simply think in HOW things are done and must be able to programm, test and debug that way.
    
  
  
  
  • Keep the language small and simple. If you can not hide the inner working 100% make them obvious, provide source and allow debugging. C++ startet as a simple preprocessor. The resulting C code could still be debugged and was understandable. Lateron when it became popular debuggers/compilers made it an own language.
    
  
  
  
  • If you are not able to put it a good concise library then you are not able to make it a good language.
    
  
  
  
  
  
  
  

Rendering, HTML/XML to JSON, JSON to HTML/XML

Why? you could ask. Both XML and JSON have strengths and different origins. XML unstructured texts with some markup, and JSON from describing javascript data structures.

HTML is our 'Rendering Engine Language'
Is it not HTML as mixture of incorrect XML with javascript hooks, CSS linkage the main javascript GUI 'rendering' engine?

Well assume we simply wnat to describe HTML within javascript. Why learn different languages HTML/CSS/Javascript if one would be good enough? Using just javascript could remove the artificial break between the active javascript and the declerative XML.

Well there has been some mapping posts:

• Converting between XML and JSONby Stefan Goessner
  
• xml2json.js by Thomas Frank who say you should better use
  
• terracoderby Sam Tsvilik

Stefan Goesner brought up some good points:

• JSON has and ordered list of values: arrays, objects as name/value pairs, with unique names. Each value can be an object an array or a literal string, number etc.


• XML elements have a single set of non named attributes with string values, and has an ordered list of childnodes, wich can be text nodes, and other named child elements.
  

While the set of attributes could easily be directly mapped to some name/value pairs in JSON, this is not the case with the child nodes. They have an order and a name.
The correct way woud thus be an array to preserve order and within the array we then could put text or object with a name value pair:

<p class="c1 c2 c3" style="border: 3px coral solid;font-size:1.5em">
  bla bla
  <ul><li>one</li><li>two</li></ul>
  bla bla
  <input type="button" onclick="alert('click');"/>
</p>

How could we map this to JSON/Javascript like syntax?, we propose using an array where the [0] index contains the attributes, this makes the notation somewhat shorter: Note that XML path uses sets beginning with index 1. So this could maybe justify this decision.

var c1={},c2={},c3={}
json = {p:[{class:[c1,c2,c3],style:{border:[{px:3},'coral','solid'],font:{size:{pt:12}}},
   "bla bla",
   {ul:[,{li:[,"one"]},{li:[,"two"]} ]},
   "bla bla",
   {input:[{type:'button'},{onclick: function(){alert('click');}}]}
]}

Is this much sorter or cleaner then XML itself? I'am not convinced. It still looks ike we misused JSON
But what becomes obvious is that HTML is not that clean as XML. Just look at the class attribute and the style stuff. A language within a language encoded in a string.
I just played a bit around and translated the multi value class attribute to an array, and the style css syntax also to a json like syntax.
Look at the java script code linked to the click event, here it is a real function not just a text.

The advantage could be that HTML/CSS/Eventhandling could all be defined and processed in a single language.

Stefan Goessner and others also wantet to keep accessing elements easy. He even used an non bidrectional XML to JSON mapping to keep access easy. p.ul.li.text could deliver 'one'. While this is a nice idea it is hard to keep it that simple if there is a bidrectional general mapping needed. In our mapping we can access both list items:

p[1].ul[1].li[1] = 'one';
p[1].ul[2].li[1] = 'two';

As always with hierachical structures an processsing whe soon have the desire to
access sets of nodes them using query language like XPATH or JSONP or CSS selectors.
Designers are so used to CSS Selectors jQuery was designed around this.

But back to our language description. In the end its all about language and we just introduced a new 'data' language. More on that in the next post.

Why not using this?

p @ class{ c1, c2, c3} , style{ border{ px:3, coral, solid } , font:size:pt:12 
  { bla bla,
    ul { li:one, li:two }
    bla bla
    button@onclick:alert('click');
  }

A little precompiler could transform this to javascript

JXML	maps to JSON
X1..Xn	"X1..Xn"
X@A1,..,An{E1,..,En}	X:[{{A1,..,{An}},{E1},..,{En}]
X:Y:Z	X:{Y:Z}

Oh yes now we again left the one language approach :-)

Code Challenge....

Hi Steven Levithan proposed a "Code Challenge " on his Blog:

function makeChange (money) {
   var i, num,
       output = [],
       coins  = [
           [100, "dollar",  "dollars" ],
           [25,  "quarter", "quarters"],
           [10,  "dime",    "dimes"   ],
           [5,   "nickel",  "nickels" ],
           [1,   "penny",   "pennies" ]
       ];
   money = money * 100; // avoid float precision issues
   for (i = 0; i < num i < coins.length; i++) {
        num = Math.floor(money / coins[i][0]);
        money -= num * coins[i][0];
        if (num) {
            output.push(num + " " + coins[i][num > 1 ? 2 : 1]);
        }
   }
   return output.join(", ");
}

makeChange(0.37); // "1 quarter, 1 dime, 2 pennies"

How would you improve this code to make it shorter, faster, or otherwise better?

My proposal:

function makeChange2 (m) {
   // make it pennies and substract as many dollars as possible, then quarters etc.
   var /*pennies*/p = m*100; 
   function x( /*name*/n, /*factor*/f ) { var /*coins*/c = Math.floor(p/f); p-=c*f; return (c>0? ', '+c+' '+n+ (c>1?'s':'') : ''); };
   return (x('dollar',100)+x('quarter',25)+x('dime',10)+x('nickel',5)+(p>0?', '+p+' penn'+(p>1?'ies':'y'):'')).substr(2);
};

Why is this better?

• Why creating a data structure, if you can express everything in function calls? Seperating both, results in extra data structures and code which handles this data structure and maintainers must understand all that extra just for ... nothing?
  


• Having long variable names doesn't make code always more readable, compare:
  

  
  var c=Math.floor(p/f); p-=c*f; return c>0? ', '+c+' '+n+ (c>1?'s':'') : ''; 
  

  
  to
  

  
  var coins=Math.floor(pennies/factor); pennies-=coins*factor; return coins>0? ', '+coins+' '+name+ (coins>1?'s':'') : ''; 
  

  
  Using comments we can explain the abbreviated names once:

  c/*coins*/

  .
  Sometimes long variables names are just too verbose, looking like COBOL programms, saying nothing with lots of glyphs.
  Short names within a certain scope make things clearer. With long names the focus is not more on the operations but is blurred with the names. You have to search for the important operations.
  


• It is also not always clear if multi-line formatting really helps that much, better type one line of usefull text explaining the *concept*. Human language is much more expressive then all this formatting stuff. Computers don't need formatting anyway.
  And scrolling through less code text is much more fun.
  If you are interested in the implementation you can read the line, learn the variable names and dive into the implementation.
  
  Look here, do you think this is so much better? I don't think so
  
  

  
  function makeChange2 (m) {
  
     var /*pennies*/p = m*100, 
  
     /*exchange*/x = function( /*name*/n, /*factor*/f ) {
        var /*coins*/c = Math.floor(p/f);  
        p-=c*f; 
        return (c>0? ', '+c+' '+n+ (c>1?'s':'') : '');  
     };
  
     return (x('dollar',100)
            +x('quarter',25)
            +x('dime',10)
            +x('nickel',5)
            +(p>0?', '+p+' penn'+(p>1?'ies':'y'):'')
            ).substr(2); // remove prefix ' ,'
  };
  

  
  

Oh yes i know join() should be faster
...

HTML Parsing, Ensure and UFrame

Well not to related but wanted just to dump these links in here

well this is from Omar Al Zabir a pageflakes co founder... UFrame , to embed external html in normal div elements and Ensure wich was mentioned on ajaxian to dynamically load stuf just before u use it the first time.

This way I found the
pure javascript html parser from John Resig, the jQuery man

Parser JS/CC and Code Mirror combined

Well I was thinking about making a nice edit area for a wiki, with a markup with a real defined context free grammar parsed by a
LALR.

Why? well you will have nested bracket structures even in text....
Mediawiki fails here, it seams to be just some regular expressions matching.. :-(

Ok I found this nice parser JS/CC by Jan Max Meyer,
a great tool beacuse:

• its completly done in javascript, so you can parse at the client like on the server
• has a flexible template mechanism
  

an this great Code Editor: CodeMirror by Marijn Haverbeke.
I liked it more that all the others because:

• It uses a parser, and you can extend it with your own parser.
  
• It supports long documents, as each line brack has a own copy of the parser state (a continuation sort of. So for the next line simply take the parser an continue parsing.
• It supports undo/redo
• You can earn a lot of programming techniques by looking at the code :-)
  

Well so why not combine JS/CC and CodeMirror ?

I created an js/cc driver_editor.js_ template which can be used to create a parser that fits right into the CodeMirror editor ...anybody interested? Send an email to me :-)





-

Javascript Continuations

Continuation support may have some advantages to make programming easier.
Imagine simpy having the complete state encoded in the
request and then a call to the server simply continues a function in the
same state where it stopped before.
No need to worries about any back buttons :-)

We know this from cocoons flowscript, but what does exist in pure javascript?

Here you can find a nice intro Continuation-Passing Style by Marijn Haverbeke, the creator of CodeMirror.

An an older post by Steve Yen, the creator of Trimpath Junction, about 'poor man' continuations: continuations-in-mozilla

What do we have to integrate it in javascript?
Well I found Narrative Javascript From Neil Mix
and Kirs Zip forked it to make add co-routines and co-threading possible
Strands, you know the "yield" thing :-) and also see jwacs by James Wright.

In this new post by Steve Continuations For JavaScript, Reloaded he points to Haili Wiki by Kevembuangga and its usage of continuations in a script continuation.js, modififing the function code on the fly..hmmm

The javascript FAQ Closures

to really understand closures read this from the fabulous javascript

FAQ Notes
Thank you Richard Cornford and other contributors!

oh and here ist the FAQ it self
Thank you Jim Ley from jibbering.com :-)

Hello Javascript Programmers

While i was thinking about the next generation development environment,
i came to the conclusion that javascript will play an important role.

Why? It is available almost everywhere in most web browsers , Adobe AIR, Google Gears, iPhone and many mobile devices. Not only on the client side you can create form based user interfaces with ExtJS, but also on the server side for example with Jaxer.

The language is easy, well documented, powerfull because it has functions as objects, and *because* it has prototypes and ...its for free :-)

With the javascript subset JSON data transfer is a simple as XML and you can even easily transfer code ond use it on the fly. Perfect for synchronizing local and remote code like Trimpath Junction shows.

So we only need javascript and no PHP, C++, Java, Ruby + Javascript + HTML + XML and framework combo mombo anymore. Keep it simple !!!

Probably we will have some different javascript frameworks around but hey nothing is perfect....

So no please don't tell me all those: its not a 'real' language, has no strong typing, has no OOP classes etc. simply forget the brainwashing an thin what do we really need and what is there? If there is something missing it is a lack of standard libraries.

Happy hacking.

BTW: Do we really need this SQL stuff anymore ?!?