FAQ Topic - What is a function statement? (2010-05-24)
in [JavaScript]
|
From: Dmitry A. Soshnikov on 25 May 2010 05:14 On 25.05.2010 13:11, Ry Nohryb wrote: > On May 25, 9:51 am, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com> > wrote: >> (...) If it would obviously >> defined in the spec (even without mentioning a separate function type), >> but saying some small note e.g. "if FD appears a statement position, >> then it is created during the code execution". And that's all (...) > > No that's not all: saying that would not be correct. Just skip it, it was an abstract small note (no more). I know that it's not all. But it doesn't matter in the case. What _is_ essential, is my phrase to Asen, that if it would _somehow_ (do you see this word? somehow -- that means -- we concentrate on something else, this "somehow" isn't essential at the moment) standardized, then maybe it wouldn't be something strange for him ;) Dmitry.
From: Ry Nohryb on 25 May 2010 06:12 On May 24, 8:18 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > You have communicated well enough that you don't understand what you're > arguing about. Aha, so you still don't get it. (unbelievable) > The problem is not a (just) matter of English; yours is barely > comprehensible. No, the problem is that you disrupt discussions with > your misunderstanding and irrelevant quips in a childish way. It is a > deficit to the discussion and a waste of time. No matter how much more fluent your English is nor how much better your manners are for your rather limited comprehension ability drives you invariably to botched conclusions, e.g. the statements in this FAQ entry. > New killfile, entry #1: Jorge Chamorro Oh, Smith, you are breaking my heart. I think someday I'm going to publish another, different, up-to-date, much improved *official* cljs FAQ, one that you can't screw up. With daily and weekly posts here and all. Yeah. Open to edit for ~anyone with a clue, except you, of course, because of the "with a clue" clause. -- Jorge.
From: Ry Nohryb on 25 May 2010 06:17 On May 25, 11:14 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > On 25.05.2010 13:11, Ry Nohryb wrote: > > > No that's not all: saying that would not be correct. > > Just skip it, it was an abstract small note (no more). I know that it's > not all. But it doesn't matter in the case. What _is_ essential, is my > phrase to Asen, that if it would _somehow_ (do you see this word? > somehow -- that means -- we concentrate on something else, this > "somehow" isn't essential at the moment) standardized, then maybe it > wouldn't be something strange for him ;) Ok. Sorry. -- Jorge.
From: Richard Cornford on 25 May 2010 07:40 On May 24, 6:28 pm, Dmitry A. Soshnikov wrote: > On 24.05.2010 19:31, Richard Cornford wrote: >> On May 24, 3:44 pm, Dmitry A. Soshnikov wrote: >>> On 24.05.2010 18:07, Richard Cornford wrote: >>>> On May 24, 2:35 pm, Dmitry A. Soshnikov wrote: <snip> >>>>> That strange phrase from the spec /"ExpressionStatement cannot >>>>> start with the *function* keyword because that might make it >>>>> ambiguous with a FunctionDeclaration"/ is really strange -- >>>>> because how then Mozilla distinguishes FD from FS? Easy I >>>>> guess, by the context of the source code position. For what >>>>> to write it in the spec (including 5th edition), if it is easy >>>>> to distinguish? > >>>> Have you noticed that section 5.1.1 (3rd Ed.) is entitle >>>> "Context-Free Grammars"? It is quite a change to switch from >>>> context-free to context dependent. > >>> Yes, of course, I understand. So, the Mozilla just extended >>> their parser for that. > >> Many of the compiling optimisations that are possible are very >> context related so it is very likely that most (of not all) >> production javascript compliers are context sensitive in >> reality, even if the language's specification does not >> require that. > > To say precisely we have to analyze the source codes of the > implementation; Looking at implementat6ion source code is always an option, but the odds are you will end up finding out that one does one thing and another does another, so there aren't many generalisations to be made from that source. > although, it also seems to me logical if some implementation > makes optimizations based even on parsing stage. Yes, I didn't mean to imply that only compilation would be context sensitive. >>> From the other hand, today I see (e.g. in some Node.js files) >>> that some always use function expressions to define a function >>> (even, if it isn't required) > >> It is a gathering trend, and one I have commented on from time to >> time. Generally I don't approve of that trend. I think that if a >> function can be a function declaration then it should be (and the >> cases when it cannot be one are the special cases), but that >> probably is a matter of style/taste. > > Yes, moreover, the most general purpose of a function expression > to be used in an expression, e.g. as an functional argument for > some higher-order function (relating e.g to the lambda calculus), > and _do not pollute the outer variable object/environment record_. > In contrast a function declaration from this position -- is just > a casual subroutine for a code reuse and encapsulating/abstracting > some actions. But seems, some once have seen that "coolness" can > use FE everywhere. Well, they are free to do that, that their > choice. The only thing I want, that they understand why do they > use it and whether it is really needed to use exactly a function > expression. Where the test for understanding would be their ability to explain why the 'choices' were made (which pre-supposes that there was a choice and that the code observed is no just the result of reproducing the code of others without (fully) understanding it). <snip> >> There was a proposal to do the new (then ES4) spec in ML; to >> have the whole ECMAScript language fully defined in the form >> of ML code. That could have included a parser and so not be >> so bound by how ECMAScript is currently defined. > > Yeah, I've heard something about it. Recent mailings also > provides some spec described in alternative syntax (lambda JS > if I remember correctly). There was a proposal to take (strict mode) JS as defined in ES5 and use that to define anything added in later specs. That avoids the circular problem of needing to understand JS before being able to study the spec in order to understand JS. >> I didn't think that was such a great plan as it >> would have rendered the spec even more esoteric than it already is > > Depends, we have to see. I am fairly sure we will not be seeing an ECMAScript specification expressed in terms of ML (in my lifetime at least). > The idea to describe a spec on the language itself at least > deserves attention. Although, it is a bit odd -- we don't know > yet a language (we're reading a spec), but already see this > language in algorithm descriptions. Yes, that is the circular problem I mentioned above. > In general, yes, an abstract algorithmic language (or even just > abstract algorithms) is enough for the technical spec for > implementers. Which brings us back to the context free grammars, which work for specifications but do impose limitations on how things can be expressed and so do make introducing a FunctionStatement a lot more complex then simply handling a FunctionDeclaration differently depending on context. >> (and I wasn't buying the argument that those who could not >> understand the spec could then learn the language from books, >> given how very bad most javascript books are), but it would >> have been interesting to see the outcome. > > Recently in ML (that would be a 'mailing list' ML, not a 'metalanguage' ML <URL: http://en.wikipedia.org/wiki/ML_(programming_language) >) > Douglas Crockford was arguing that a spec should be > described that every JS programmer can understand it. That is one of the things that worried me about the proposal to do the spec in ML; that learning another programming language as a prerequisite for understanding the spec is a little much to ask of the average (and especially javascript) programmer. > That's a noble idea of course, but seems he forgets that a > technical spec -- is a technical spec (i.e. a requirements > specification), but isn't an interesting literary reading. It shouldn't be too difficult for someone capable of (reasonably) logical thought processes (which is pretty much necessary for an effective programmer) and sufficiently familiar with the language in which the text is written to eventually understand a technical specification in detail. However, there are lots of things that could be done (at minimum in terms of additional text explanation (of the algorithms and their implications)) that could speed that process up. Previous ECMA 262 versions have not been that easy to approach for a newcomer, so there is plenty of room for improvement without asking the result to come anywhere near 'an interesting literary read'. Of course if there were any really decent (and in depth) books on javascript then it may not be necessary for those seeking understanding to go to the specification, and so much less need for an understandable spec. > Although, some (including me) provides the alternative spec > description in more human view ... <snip> Javascript learning form the web suffers from two things; 1. There is a mass of bogus information and very poor advice available on the web (as there is less standing in the way of its publication than standing in the way of bad books on the subject). 2. Almost any (Google, etc.) search on the subject of javascript will be swamped in hits from pages that contain NOSCRIPT elements declaring that "this page works best with javascript enabled" (or the like). It is nice that there are good resources available, but newcomers are going to be hard pressed to tell the good from the bad. > The most parts of the spec help to understand how does something > work (again -- just an exact algorithm). But at the same time > the ECMAScript provides its own abstraction level, and exactly > ECMAScript programmers are not required to think about > _implementations details_. It could be easier to say them that > there is something called as a "variable hoisting" (a thinking > out simplified concept to understand the things), rather than, > "the handling of the execution context code is divided on two > stages: the entering the context and the code execution, and all > data (vars, FD, formal parameters) are created at the first stage -- > that's why they are available before the definition in the source > code position". The name of the thing ("variable hoisting" in this case) is of limited use without knowing what that thing does (or how it works), so the explanation still needs to be somewhere. > Yes, it will be interesting to see the outcome, although, we > already can see some implementation on JS -- Narcissus -- there > all that algorithms are described very interesting on JavaScript. Javascript implementations written in javascript raise some interesting questions. Narcissus uses javascript regular expressions to implement its regular expressions. Take that to its extreme and Narcissus stops existing, and you run the code it would be executing in Narcissus is the javascript engine that would otherwise be running Narcissus. Go the other way and insist that Narcissus provide an implementation for everything (regular expressions, primitives, representations of IEEE double precision numbers, math operations on those reprehensions, etc., etc.) and you are asking more of that implementation than of any other. Richard.
From: Richard Cornford on 25 May 2010 07:40
On May 24, 8:35 pm, kangax wrote: > On 5/24/10 10:07 AM, Richard Cornford wrote: >> On May 24, 2:35 pm, Dmitry A. Soshnikov wrote: >[...] >>> And I think for some it would be convenient to >>> define functions in the declaration view. >> <snip> > >> How much difference in 'convenience' would there be? You >> can evaluate a function expression conditionally and assign >> the result to a variable, so whatever the job is it can be >> done with existing syntax. So the difference in convenience >> is that between writing - x = function(n){ ... }; - and >> - function x(n){ ... } -, which doesn't seem that much. > > The difference in convenience becomes more apparent once we > "zoom out" from `x = function(){}` vs `function x(){}` > comparison. > > Take a look at something like `addListener` abstraction, and > one of the possible ways to implement it. As you're well aware > of, forking function definition based on certain condition is > an extremely common scenario when it comes to cross-browser > scripting: > > var addListener, docEl = document.documentElement; > if (isHostMethod(docEl, 'addEvenListener')) { > addListener = function () { > /* ... */ > };} > > else if (isHostMethod(docEl, 'attachEvent')) { > addListener = function (){ > /* ... */ > }; > > } > > Specifics aside, what we're dealing with here is this: > > var addListener; > if (/* ... */) { > addListener = function () { };} > > else if (/* ... */) { > addListener = function () { }; > > } So at this point the possibilities are that - addListener - is either undefined or it is a native function. > The inconvenience in this case is that we need to first > define `addListener` variable before assigning function > object to it. Don't actually need to if the destination of - addListener - is as a property of the global object as an assignment to an undeclared Identifier is going to do that. But it is still a good idea to declare it. > Knowing how variable declaration works in ECMAScript (i.e. > that `addListener` is "hoisted"), we could shorten this > version like this: > > if (/* ... */) { > var addListener = function () { };} > > else if (/* ... */) { > addListener = function () { }; > > } > > - but this just has too much chance of looking like a > mistake (or confuse reader of the code), Yes, let's not do that. > and is a pattern I would rather stay away from. > > The benefit of function statements becomes even more apparent > once we bring the subject of function identifiers into a > picture. To aid in debugging/profiling (IIRC, you found this > argument bogus last time I've heard :)), > `addListener` could be given an identifier like so: > > var addListener; > if (/* ... */) { > addListener = function addListener() { };} > > else if (/* ... */) { > addListener = function addListener() { }; > > } > > I personally know libraries that follow such pattern (their > authors are also well aware of NFE bugs in IE). Now the possible values for - addListener - are undefined or a native function, except in JScript, where the undefined option no longer exists. (Granted that won't matter much in this case as presumably one branch of a listener attaching method will use IE's available facilities, but I mention it as a comment on the 'pattern' (and the understanding NFE bugs claimed by those employing it; the results are now environment dependent. > Note that some of the NFE issues are "worked around" here by > using same identifiers for variable (to assign function to) > and actual function. Some perhaps, but not all. > Now, if we were to utilize function statements in a previous > example, the snippet becomes rather elegant: I am always suspicious of "elegant" as a justification for code authoring style. > if (/* ... */) { > function addListener() { }} > > else if (/* ... */) { > function addListener() { } > > } Now at this point the possibilities are that - addListener - is a native function, or it has never been declared. This modifies the possibilities for verifying the viability of adding listeners in the environment. The undefined or native function discrimination can be made in several ways, the simplest of which is type-conversion to boolean. The 'never declared' or native function discrimination is going to require of - typeof - test or a try-catch to avoid the exception that would be thrown at an attempt to read the undeclared Identifier's value. > I've seen another pattern, like this: > > function addListener() { /* ... */} > if (/* ... */) { > addListener = function () { /* ... */ } > > } > > - but it only solves the identifiers problem partially. It also disregards the possibility that the environment odes not provide either of the possible options, denying the possibility of planned clean degradation. > And on a related note, implementations that extend function objects with > "name" property (such as Mozilla) usually populate that property with > identifier of a function during its declaration. > > var f = function g(){}; > f.name; // "g" > > function h(){} > h.name; // "h" > > In those implementations there's an added cost of not having > "proper" `name` value (if that matters, for whatever reason) > when using expressions instead of declarations. As function - name - properties are non-standard and not universally supported that could only be a consideration for specialised contexts. > All in all, I don't particularly find function statements to > be an amazing boon, but I can see how they are useful; I don't mind whether they exist or not. > I would > take them any day if not for complete uselessness in context > of general web, where backwards compatibility issues Backwards compatibility? Isn't the behaviour in 'current' browser inconsistent enough to introduce 'issues'? > would probably render them to be more of a danger than a > convenience. Yes, they are not of general use at the moment, and will probably stay like that for some time to come. > I'm curious how committee is going to handle these issues, > as "block functions" appear to be scheduled for ES harmony, > and are already on the list of proposals (not just in > strawman section) :) > <http://wiki.ecmascript.org/doku.php?id=harmony:proposals> It will be interesting to see. While claiming JavaScript(tm) compatibility, environments that did implement Function Statements have tended to switched to handling their declarations more in the way JScript does (presumably out of expedience) so going back the other way may not be popular (even without considering Microsoft's influence on the question). Ricahrd. |