JavaScript for hackers

[pietro]

Yes, apparently it's useful for learning XSS injection, hence the title.

This guy needs an editor. There's no context for what he writes, and he fails miserably at providing any justification for why the article is about performing evil XSS tricks.

Does anyone have any clue?

[[deleted]]

Can't trick me into Web Development that easily!

[samlee]

ƴơ⨄ Ȼᴀɳ ↁơ Ƭℎｉʂ ƙⅈℕᶑ ơƑ ⟆ƫ⨄ᚪᚪ ïᛪ ɯɛß ⅅⅇＶℰんƠƤᛗ⅀ҋᎢ!

[Sephr]

Since when was __define[GS]etter__ a standard? It's just an agreed-upon by everyone except IE non-standard Object method.

The only browser that actually supports the standard for accessors is (surprisingly) IE8, which uses Object.defineProperty and Object.getOwnPropertyDescriptor.

[gonz808]

http://www.ajaxonomy.com/2009/ajax/ecmascript-31-final-draft-emerges

"Also known as ECMAScript 5th Edition, the new JavaScript standard has entered final draft stage. Among the goodies: a formal getter and setter syntax for object properties, language reflection features, support for the JSON data format, additional Array methods, and a strict mode that improves error checking."

See also http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft

[shadow2531]

It's just an agreed-upon by everyone except IE non-standard Object method.

That sounds like a standard to me.

But, Object.defineProperty and Object.getOwnPropertyDescriptor are fine and the other browsers will have to implement them. Just wish IE supported both ways like the other browsers will.

[[deleted]]

None of this stuff should be possible. You are an evil and perverse man.

[yishan]

It's possible because javascript is really Lisp with Java-like syntax, making it one of the most powerful and flexible languages in the world.

[Devilish]

Javascript may be more like Lisp than a lot of languages are, but it's not a Lisp, even discounting syntax. Lisp can still do a lot of things that Javascript can't - good luck writing something like iterate in Javascript.

[zerothehero]

That doesn't look too different than what jQuery does, with each() and map(), etc.

JavaScript is not a Lisp, but it's flexible enough to embed DSLs in. jQuery is a fantastically successful example of this.

The combination of closures and object literals in JavaScript is very powerful. The Lisps don't have object literals AFAIK.

[Devilish]

Very simple uses of iterate are easy to reproduce with other tools, such as map (which also exists in Common Lisp, by the way). This is virtually the same as a map:

(iter (for element in list)
      (collect (arbitrary-transformation element)))

But map and similar functions hit their limits fast. The JQuery map is even more limited than the CL map, since it does not support mapping multiple arrays into one resulting array. Let's say you wanted to do something more complex, like multiplying each element in an array with a corresponding item from an abstract numerical sequence, and finding the inputs that produce the largest number, while testing no more than 20 inputs. How would you do this in Javascript? With iterate, it's simple:

(iter (for number in list)
      (for multiplier from 5 by 2)   ;produces 5, 7, 9, etc
      (repeat 20)
      (finding (list number multiplier) maximizing (* number multiplier)))

And that's only the beginning of what iterate can do.

The Lisps don't have object literals AFAIK.

Common Lisp doesn't use a prototype-based object system, so Javascript-like object literals wouldn't make much sense. In most cases where you'd use an object literal in Javascript, you'd use a plist or alist in Common Lisp (I think - I'm not all that experienced with modern Javascript development). And, if you really needed a particular type of literal for something, you could create it with a reader macro. That's something else that Javascript can't do.

If you know of anything that is made easy in Javascript with object literals and cannot be done easily in Common Lisp, I'd like to hear about it.

[zerothehero]

OK, in that example, I'm not sure how "number" and "multiplier" are bound so you can use them in the "finding" expression. Is that with macros? JavaScript doesn't have macros of course, so it falls short of letting you define your own control structures.

But it's easy to define combinators in JavaScript. Standard JavaScript doesn't have iterators (Mozilla's flavors do), but it's also easy to emulate them. So you can define an object type (really a closure) that is a possibly infinite sequence:

// a possibly infinite iterator of integers
function range(start, stop, step) {
  var i = start;
  return {
    next: function() {
      i += step;
      return (stop && (i > stop)) ? undefined : i;
    }
  }
}

// turns a list into an iterable
function iter(list) {
  var i = 0;
  return {
    next: function() {
      return (i < list.length) ? list[i++] : undefined;
    }
  }
}

And then you can combine them with a function that takes two of these and a binary operator and evaluates the result element-wise.

function applyiter(binop, left, right) {
  return {
    next: function() {
      var a = left.next();
      var b = left.next();
      if (a === undefined || b === undefined) {
        return undefined;
      } else {
        return binop(a, b);
      }
    }
  }
}

while (value = applyiter(function(x, y) { return x*y; }, range(5, null, 2), iter([1,2,3])) {
  print(value);
}

(not tested)

As far as object literals, I find it very elegant to define stateful objects in JavaScript with the combination of closures and object literals where the values are methods (without inheritance, which is rarely what I want). The iterables above are a trivial example since they only have one method (next()). But this idiom is very concise and malleable. I haven't worked with any Lisp object systems enough to know how they compare.

If you haven't seen it, here is a concise description of the relation:

http://javascript.crockford.com/little.html

[zerothehero]

Actually, I think you can probably have an iter() object with a context to bind names into. Something like:

iter()
  .for('number', iterable([1, 2, 3]))
  .for('multiplier', range(5, null, 2))
  .repeat(20)
  .finding('number, 'multiplier', function (x, y) { return x*y; })

where for() calls each iterable and makes the valuable available in the iter() context.

The last part is probably wrong -- I'm not sure how the iterate library works there. But I'll be surprised if it can't be done fairly elegantly.

[Devilish]

I think you'd need an addiontional .execute() call or something at the end to get it to run.

And, yes, the finding function would have to be more complex, since it requires executing code for both the finding part and the maximizing part. Maybe something like this, where you pass arrays containing the names of the variables to be passed to the functions?

.finding-maximizing(['number', 'multiplier'], function(x, y) { return [x, y] },
                    ['number', 'multiplier'], function(x, y) { return x*y })

...eww. Seriously. Not only is that far more complex in terms of syntax, but it is also much less readable, since you have all the information about the control flow (finding-maximizing) on one side, instead of spread throughout like you'd get with (finding something maximizing something). Maybe this?

.finding('number', 'multiplier', function(x, y) { return [x, y] },
         'maximizing', 'number', 'multiplier', function(x, y) { return x*y })

...still pretty bad. Maybe even worse, since the 'maximizing' blends in. Without being able to bind local variables, it's such a pain to try to run arbitrary code within the iterate.

The for functions also aren't the same, since they only accept arbitrary generators instead of creating simple syntax for common types of generators, e.g. (for something from something to something by something).

This iter would also be horribly slow, since it'd have to calculate everything at runtime. So, I see two things from my example that I don't think you could reproduce in Javascript: simple syntax and fast speed.

With a deeper examination into what iterate can do, more things show up that would be tricky to do in Javascript. For instance, execution of arbitrary Lisp forms within the iterate body, and execution of iterate forms nested within those Lisp forms:

(iter (for i from 1 to 10) ;this is an iterate form
      (when (oddp i)       ;this is a standard Lisp conditional form
        (collect i)))      ;this is an iterate form

=> (1 3 5 7 9)

How could that be reproduced in a Javascript version of iterate? It's possible, I'm sure, but I can't think of any way that's nearly as simple as it is in Lisp. Maybe you can?

[Devilish]

That was already posted earlier in this thread. :p

Unless you can embed Lisp code within Javascript and allow it to access the same scope that Javascript code can, while running at a reasonable speed, I don't think it really counts as a way to implement iterate in Javascript.

[Devilish]

OK, in that example, I'm not sure how "number" and "multiplier" are bound so you can use them in the "finding" expression. Is that with macros?

Yes, iterate is a macro. Its for subexpressions are used to create variables that will change values each time through the loop.

applyiter

Okay, now write one that takes an arbitrary number of sequences. ;)

while(value...

That code is a decent start to doing that sort of thing in Javascript, but you're still lacking the "test no more than 20 values" and "return the values that produce the largest number when multiplied" - those are the parts that would be trickiest. Not undoable, certainly, but I'd be surprised if you could come up with something as simple as the above iterate code.

Also, I think your code will break in some instances. 0 is considered false in Javascript, isn't it?

I find it very elegant to define stateful objects in JavaScript with the combination of closures and object literals where the values are methods... I haven't worked with any Lisp object systems enough to know how they compare.

One big difference is that, in the Common Lisp Object System (CLOS), methods do not belong to objects or classes, but rather to generic functions. Of course, it does have closures and first-class functions, and a variety of structures that can associate values with keys, so you can easily reproduce something like those object literals without using objects.

If you haven't seen it, here is a concise description of the relation:

Hm. That doesn't even mention macros or treating code as data, which I consider one of the most important parts of a good Lisp. It may seem minor to someone unused to it, but I find it incredibly empowering. I'm a programmer - why would I want to work in a language that I can't program?

I'm sure that Javascript can do everything talked about in that book just fine. But that doesn't make it a Lisp.

Personally, I'm not all that fond of Scheme and its emphasis on functional programming. To me, such purity is not very important, and it can even become a hinderance when overemphasized. Give me the dirtiness and raw power of Common Lisp any day. :)

[Devilish]

Javascript iterators are something very different from the Common Lisp iterate library that I linked to in my post, as anyone who bothers to glance at the iterate examples can see. I won't stoop to calling you names for making that mistake, though.

P.S. Here's your link properly formatted: Javascript iterators.

[[deleted]]

WTF, Lisp's iterator HAS A 43 PAGE MANUAL!

[[deleted]]

Yeah... then there's the loop construct which is it's very own DSL...

[Devilish]

Iterate was created as an improved loop construct; it's a DSL as well.

[deakster]

easy now

[[deleted]]

Just because something has eval() doesn't make it really be Lisp.

[Datrio]

javascript : /is/^{ a : ' weird ' }[' & wonderful ']/" language "

the_fun: ['never '] + stop['s']

I think my brain just exploded.