Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #17420

Re: form field/spreadsheet question

Followups directed to: comp.lang.javascript

Show all headers | View raw

Wally W.  wrote:
^^^^^^^^
Please fix that.

> On Sun, 02 Dec 2012 19:06:27 +0100, Thomas 'PointedEars' Lahn wrote:
>> Wally W.  wrote:
>>> On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote:
>>>> On 02-12-2012 05:22, Jon wrote:
>>>>> Where can I find an editor/..../.... for Javascript?
>>>>
>>>> Notepad.exe, or any other text-editor....
>>>>
>>>>> Where can I find an ..../compiler/.... for Javascript?
>>>>
>>>> There is no compiler for Javascript,
>>> 
>>> That is an oversight in the IT world.
>>
>> Strictly speaking, what was stated is correct,
> 
> As was my statement.

Most certainly not.
 
>> because there is no "Javascript" language to begin with:
>> <http://PointedEars.de/es-matrix>
> 
> Your link highlights in incompatibilities between script engines.

I am comparing the language features supported by different ECMAScript 
implementations there.
 
> A script I develop for my own use in my preferred browser may be
> useless in someone else's preferred browser.

Correct.  This is why it is important to know where implementations differ 
and where not, so that appropriate measures can be taken by the Web 
developer.  I am currently focusing on ECMAScript implementations;
DOM implementations are another matter altogether (and I will probably 
investigate them more thoroughly later).

> With web pages and javascript so prevalent,

There are no "web pages" and there is no "javascript".  As soon as you can 
accept that, and stop talking like you want to sell something, understanding 
can begin.

> it is an oversight that there is no generally available program to
> "compile" the pages with *some* version of javascript

Different ECMAScript implementations are not versions of one imagined 
universally implemented and uniform "javascript" language; they are separate 
programming languages in their own right (with a common root, most of which 
is standardized in ECMAScript).

> to a browser-independent EXE file.

You have overlooked the existence of such programs.  However, such a program 
would not be overly useful with regard to browsers, because ECMAScript 
implementations are scripting languages, which "[are] programming 
language[s] that [are] used to manipulate, customise, and automate the 
facilities of an existing system." (ECMAScript Language Specification, 5.1 
Edition, p. 2).  As such, they are primarily interfacing languages, and APIs 
differ among browsers.  You cannot avoid that; browser vendors will not let 
you.  And if you are honest, you would not want to: this competition is 
*basically* a Good Thing.

>> Loosely speaking it is wrong, though, because ECMAScript source code in
>> Web browsers and elsewhere is JIT-compiled and _not_ interpreted
>> verbatim. 
>> Most of the script engines of ECMAScript implementations compile source
>> code to bytecode, executed by a Virtual Machine (this applies to
>> Netscape/Mozilla JavaScript and Microsoft JScript).  Google V8 even JIT-
>> compiles source code to native machine code, which part of why it is so
>> fast by comparison.
> 
> Which is of no help to one who wants to convert their web page,
> complete with javascript, to a browser-independent EXE file.

Those people should learn to know what they are doing before they are doing 
it, and then might be interested in
<https://developer.mozilla.org/en/docs/GRE> pp.

But that has nothing to do with "web pages" (read: HTML documents) as such.

>>> Spreadsheets are also "interpreted."
>> Spreadsheets are not a programming language.
> 
> Missing the point for the semantics.

I am not sure yet, are you trolling or are you just completely clueless?
 
> Functions in spreadsheet cells are, in a practical sense which may not
> meet a purist's definition, "interpreted."

Yes, but that is a different thing.  Functions in spreadsheet cells are a 
part of an API, which is used with programming languages.

> Javascript operating on forms in a web page can behave similarly to
> simple, or not-so-simple, spreadsheets.

While that is partially true, you still have no clue what you are talking 
about.  There are programming languages, and there are APIs that can be used 
with programming languages.  That is no different with ECMAScript 
implementations and the DOM API.

>>> That didn't stop someone from
>>> writing a compiler:
>>> http://en.wikipedia.org/wiki/As_Easy_As
>>
>> ISTM you are confusing things.
>> 
>>> How many would like a compliable web page that has:
>>> 1. Embedded javascript
>>
>> Meaning what exactly?
> 
> For example, this web page could be converted to a stand-alone EXE
> file with all the functionality of its scripting fully implemented:
> http://www.pmel.org/unitconv.htm

No, it could not.  The functionality of "the scripting" to be cross-browser 
would be lost to begin with.

>>> 2. A 'save as" capability to write all contents, including entered
>>> values, to a disk file?
>> That capability exists already.
> 
> Where?

In all script-capable Web browsers.

>>> 3. An "open file" capability to resume work on or print values in a
>>> file placed on disk with the "save as" feature mentioned above?
>> That too.
> 
> Where?

Same.

>>> I know I would like such a compiler.
>> I do not think you know what a compiler is or where you are posting to,
>> though.
> 
> I suppose the software to produce CHM ("compiled HTML") files would
> not meet your definition of "compiler."

That is correct.  Those files need an executable (HTMLHelp.exe & friends) to 
be displayed, which in turn uses a runtime library, MSHTML.dll.  In short, 
the browser core.  That library supports JScript, Microsoft's ECMAScript 
implementation (through JScript*.dll), and so does Internet Explorer, for 
example, because it is based on MSHTML.dll (which is why I am talking about 
JScript and the MSHTML DOM and not "javascript in Internet Explorer").
.CHM files are not executables themselves, and HTML Help certainly is not a 
programming language.

<http://msdn.microsoft.com/en-
us/library/windows/desktop/ms524402(v=vs.85).aspx>

> The "compiler" I would like for web pages with embedded javascript
> would be similar, but with more features.

Such as?

> My mention of "embedded javascript" recognizes that web pages do *not*
> necessarily need to contain javascript. The ideas seems to be anathema
> to some webmasters, but it is true.

ACK, but your argumentation is inconsistent nevertheless.  You cannot have 
"embedded javascript" without having "javascript".


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

form field/spreadsheet question "Jon" <no-reply@no-reply.com> - 2012-12-01 23:22 -0500
  Re: form field/spreadsheet question Luuk <luuk@invalid.lan> - 2012-12-02 13:55 +0100
    Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 12:19 -0500
      Re: form field/spreadsheet question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 19:06 +0100
        Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 14:29 -0500
          Re: form field/spreadsheet question Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-02 20:10 +0000
            Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 17:18 -0500
          Re: form field/spreadsheet question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 21:22 +0100
            Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 17:15 -0500
              Re: form field/spreadsheet question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-03 00:29 +0100
                Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 19:55 -0500
                Re: form field/spreadsheet question Dr J R Stockton <reply1249@merlyn.demon.co.uk.invalid> - 2012-12-03 18:30 +0000
                Re: form field/spreadsheet question Andrew Poulos <ap_prog@hotmail.com> - 2012-12-04 11:26 +1100
            Re: form field/spreadsheet question John G Harris <john@nospam.demon.co.uk> - 2012-12-03 20:18 +0000
              Re: form field/spreadsheet question Andrew Poulos <ap_prog@hotmail.com> - 2012-12-04 07:43 +1100
                Re: form field/spreadsheet question John G Harris <john@nospam.demon.co.uk> - 2012-12-04 09:10 +0000
                Re: form field/spreadsheet question Andrew Poulos <ap_prog@hotmail.com> - 2012-12-04 20:31 +1100
                Re: form field/spreadsheet question Scott Sauyet <scott.sauyet@gmail.com> - 2012-12-04 06:15 -0800
                Re: form field/spreadsheet question John G Harris <john@nospam.demon.co.uk> - 2012-12-04 14:34 +0000
  Re: form field/spreadsheet question Martin Leese <please@see.Web.for.e-mail.INVALID> - 2012-12-02 11:27 -0700
    Re: form field/spreadsheet question "Jon" <no-reply@no-reply.com> - 2012-12-02 19:01 -0500
      spreadsheet-to-Javascript translator "Jon" <no-reply@no-reply.com> - 2012-12-02 20:06 -0500
        Re: spreadsheet-to-Javascript translator Patricia Shanahan <pats@acm.org> - 2012-12-03 10:26 -0800
    Re: form field/spreadsheet question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-03 02:42 +0000

csiph-web