Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Newsgroups: comp.lang.javascript
Subject: Re: Why is it so convoluted to import a .js file in javascript?
Date: Sat, 29 Mar 2014 18:57:08 +0100
Organization: PointedEars Software (PES)
Lines: 158
Message-ID: <1658884.GDCoxO0Dda@PointedEars.de>
References: <d1050ce2-5b06-4bb8-9d69-18cc325b30c0@googlegroups.com> <include-20140327003813@ram.dialup.fu-berlin.de> <ce8b01e4-3142-4b81-b103-aab2a92c0b39@googlegroups.com> <270320141145170829%timstreater@greenbee.net> <d9854441-f57a-4b17-bf72-a934836819f2@googlegroups.com> <XnsA2FDC97BC475Beejj99@194.109.133.133> <e96817ba-43dd-412e-ac44-617254e21546@googlegroups.com> <XnsA2FEBA5B9A273eejj99@194.109.133.133> <00d68cb0-4463-426a-859d-125781cd2f56@googlegroups.com> <power-20140328185800@ram.dialup.fu-berlin.de> <eval-20140329180710@ram.dialup.fu-berlin.de>
Reply-To: Thomas 'PointedEars' Lahn <usenet@PointedEars.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
X-Trace: solani.org 1396115833 16345 eJwFwYEBwCAIA7CXVKB15wDS/09YEoaNpiPgoVDlCfNudVGyGue0BnuEQZLHHm2t7+C+vPgBQKARzQ== (29 Mar 2014 17:57:13 GMT)
X-Complaints-To: abuse@news.solani.org
NNTP-Posting-Date: Sat, 29 Mar 2014 17:57:13 +0000 (UTC)
User-Agent: KNode/4.11.5
X-User-ID: eJwFwQcBACAIBMBKiDwjjqz+EbzD1aNlolDBYh3OcNeCnDsRuc3vSre94ZOexqgwMNebSiknKBFF13QtfUGnFZY=
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXTxa4RFk5dUWANED8PFEfy7+MGBiW+n3ZNF/QuAAACaElEQVQ4jVXUwVOcMBQG8Dc7Rc4PUntdWV2uxjDpGaGeozOp1woar4jd5t/v9wLstMwsA/ntlxdCAgUc1hjTc9/JCZfGoo3wG3HdmdAWrIJRHe7GM/TmpY5VFefuVcAkkPbLIaN8rmPmjloyZxgyR3GuJ4K0AGtJ2htz8o7yqikm759fldQXaMpbDzjKAG+8v+AugVTOPO5DOjLvGtUYQwh0CPjnVMyGd+8/GfUB5nLKJDD2aLDh5HYyMDJGDwQIo2ZmZcKbowNmAdB/AzyFhrmF2MHRb0QJJfaAnwGB6orZhoykLzJtGwF/xpYxI1dswomiUj3gTuAIqCn/4C7cULwGNBtwMTk3Y4LfKB5YUaOKBKYtpplm7u0vip8tU1NWWyI/7XdcSuIDoMt6rVHMWT0DbjHPGqDqZVSa6zleLcUTcIKLoMv3ueJluALtAo9B302zPPlrtiVScRdCjXvVh3e3JpYa/jjkuC9N+LrBMlz/eAN4eQijX2EdLo6c5tGGHwLyHFtXk89dDGHwCVhG9T0S/j55AhRZgkMCmUQXJ49TnS1wnQDvw0eAh9ICeMmEFbCnPMFzjAvsWoEWEFdYEx+S0MoUZ1gT1wId8+AF3Bl2OoEu906AUHx5VLw/gXYg/x84loOah/2UYNrgiwSwGO7RfUzVBbx/kgpckumGOi6QirtD6gkLTitbnxNol47S2jVc2vsN5kPqaAHT8uUdAJM4v/DanjYOwmUjWznGfwB7sGtAtor5BgofDuzaRj4kSQAqDakTsKORa3Q3xKi3gE1fhl71KRMqrdZ2AWNNg/YOhQyrVBnb+i+nEg4bsDA+egAAAABJRU5ErkJggg==
X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&.<b';Md8`dH6iqhT)6C^.Px|[=M@7=Ik[_w<%n1Up"LPQNu2m8|L!/3iby{-]A+#YE}Kl{Cw$\U!kD%K}\2jz"QQP6Uqr],./"?;=4v
Cancel-Lock: sha1:sxg7RqrMZ328i7pA8X0CJSVprRE=
X-NNTP-Posting-Host: eJwFwYEBwDAEBMCVCI+O0+D3HyF3sNDo9EA4CGo15VPgYG9Oj5HGHaGrlab0Abo37l9R4AMiXBFo
Xref: csiph.com comp.lang.javascript:23741

Stefan Ram wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>I just wrote the following evaluator that can evaluate
>>expressions like »6+3*2^3+1«. All its errors and features
>>gaps are meant to be an exercise for the reader.
> 
>   The new version
> 
>       - now correctly treats 2^3^2 right-associatively,
>       - has additional operators "/" and binary "-", and
>       - can deal with multi-digit numerals.
> 
> <!DOCTYPE HTML><html><head><title>Main</title>
> <meta charset="UTF-8"></head><body><pre><code><script>

Your code style, although apparently consistent, still is only barely 
readable.  Your code is very inefficient and error-prone.

The part of the code that does not depend on output belongs in the “head” 
element.
 
> function Scanner( source ){ this.source = source; this.pos = 0; };
> Scanner.prototype =
> { check: function( pattern )
>   { var next = this.source.substring( this.pos, this.pos + 1 );

  var next = this.source.charAt(this.pos);

or in some implementations (especially those of ES5+)

  var next = this.source[this.pos];

<http://PointedEars.de/es-matrix/?filter=string\[>

>     if( pattern.exec( next )){ ++this.pos; return next }
>     else return false; },

It does not make any sense to use regular expressions and at the same time 
to not use the resulting matches.

>   numeral: function()
>   { var next = /[0-9]+/.exec( this.source.substring( this.pos ));
>     this.pos += next[ 0 ].length; return next[ 0 ]; }, };
> 
> var ex = Object.create( null );
> ex[ "^" ]= Math.pow;
> ex[ "*" ]= function( a, b ){ return a * b };
> ex[ "/" ]= function( a, b ){ return a / b };
> ex[ "+" ]= function( a, b ){ return a*1 + b*1 };
> ex[ "-" ]= function( a, b ){ return a - b };

This can be compacted and optimized into

  var ex = Object.create(null, {
    "^": {value: Math.pow},
    "*": {value: function (a, b) { return a * b; }},
    "/": {value: function (a, b) { return a / b; }},
    "+": {value: function (a, b) { return (+a) + (+b); }},
    "-": {value: function (a, b) { return a - b; }}
  });

An important difference to the above is that these properties are read-only 
and not enumerable.  Otherwise the code begs the question why a simple, more 
compatible, Object initialiser would not suffice:

  var ex = {
    // …
  };
 
> var left_associative = Object.create( null );
> left_associative[ "^" ]= false;
> left_associative[ "*" ]= true;
> left_associative[ "/" ]= true;
> left_associative[ "+" ]= true;
> left_associative[ "-" ]= true;

Same here.  In fact, it might be more efficient, and certainly makes more 
sense data-wise, to have the associativity of an operator as the property of 
an operator, not some unrelated object:

  var operators = {
    "…": {
      call: function () { … },
      leftAssociative: …
    },

    /∕ …
  };
 
> function Parser( source ){ this.scanner = new Scanner( source ); };
> Parser.prototype =

As you have been told before, this overwrites the prototype property, 
setting the value of the  “constructor” property of Instance to a reference 
to the value of the “constructor” property of the RHS value.

> { numeral:  function( me ){ return me.scanner.numeral(); },
>   parse: function( me, op, next )
>   { var result = next( me ); var sym;
>     while( sym = me.scanner.check( op ))
>     result = ex[ sym ]( result,
>       ( left_associative[ sym ]? next( me ): me.parse( me, op, next )));
>     return result; },

Completely unmaintainable.  Kids, don't try this at home.

>   power:   function( me ){ return me.parse( me, /[\^]/,  me.numeral ); },
>   product: function( me ){ return me.parse( me, /[*\/]/, me.power   ); },
>   sum:     function( me ){ return me.parse( me, /[+-]/,  me.product ); },
>   start:   function(){     return this.sum( this ); }};

It is pointless and less efficient to pass the “this” value to a function 
called as a method of the “this” value.

  ({
    foo: function (me) {
      return me;
    },

    bar: function () {
      this.foo(this);
    }
  }).bar();

is semantically equivalent to

  ({
    foo: function () {
      return this;
    },

    bar: function () {
      this.foo();
    }
  }).bar();

[“this” has nothing to do with scope.  That it had is a common beginner’s 
misconception.]
 
> function evl( x ){ var parser = new Parser( x ); return parser.start(); }
> 
> function check( x, y )
> { var e = evl( x ); var r = e == y*1;

Because we are dealing with floating-point values, converting to Number 
explicitly with unary “+” is probably more efficient than converting 
implicitly by multiplying by 1.  It is also less likely to be upwards-
incompatible (should there in be an implementation in the future
that overloads “*” as string repetition operator in the future [1]).


[1] cf. <http://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.repeat>
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.