I was going to complain that I could find no mention of TameJS (from which the await and defer keywords/features clearly originated). Then I noticed that the IcedCoffeeScript author is also the author of TameJS.
IcedCoffeeScript
31–40 of 63 posts
Re: IcedCoffeeScript
#32Re: IcedCoffeeScript
#33This fork brings some up deep issues, perhaps intractable, around about the development of syntax-y languages. Useful source transformations require marginalized forks of the compiler and all the development burden and risks that entails. In some sense CoffeeScript inherits the actual problem with JavaScript - a select few determine the introduction of language features. Perhaps these language features are best shipp…
What language exists in which this is not the case? Language by committee sounds terrible.
Re: IcedCoffeeScript
#34I'm wanting in CoffeeScript knowledge and/or intelligence, so could someone explain the above please? (In the examples, defer seems to specify the variable that gets the result of await.)
Re: IcedCoffeeScript
#35This fork brings some up deep issues, perhaps intractable, around about the development of syntax-y languages. Useful source transformations require marginalized forks of the compiler and all the development burden and risks that entails. In some sense CoffeeScript inherits the actual problem with JavaScript - a select few determine the introduction of language features. Perhaps these language features are best shipp…
> the actual problem with JavaScript - a select few determine the introduction of language features. What language exists in which this is not the case? Language by committee sounds terrible.
Re: IcedCoffeeScript
#361. The floating title looks cool esp with greying out above it, but it page-down/space moves down more than a page (in effect), so it skips some text. I didn't realize I was missing some text for a while.
2. In the Animal example, the "Run" button doesn't work (though "run" works from the "load" overlay for it). I'm uising Firefox 9.0.1 on Ubuntu 10.04
Re: IcedCoffeeScript
#37Looking at first parallelSearch example, it could be like that (in regular CoffeeScript):
parallelSearch = (keywords, cb) ->
searches = [search k for k in keywords]
$.when.apply(searches, null).then cb
Although seems like it can't really cover all Iced's use cases. Hopefully the fork will continue to be maintained!Re: IcedCoffeeScript
#38When a language has dialects, you kno you are doing something right... go coffee-script!
http://disnetdev.com/contracts.coffee/
It's a great way to write defensive code for those of us who find writing regular unit tests a little onerous even (if they are often necessary). I'm planning on using it in all my CoffeeScript, up to -- but not including -- generated production Javascript.
Re: IcedCoffeeScript
#39> The function defer returns a callback, and a callee in an await block can fulfill a deferral by simply calling the callback it was given. I'm wanting in CoffeeScript knowledge and/or intelligence, so could someone explain the above please? (In the examples, defer seems to specify the variable that gets the result of await .)
defer is a function which returns another function. When that returned function is called, we get out of the await block.
So, to take the same example:
await
for k,i in keywords
search k, defer out[i]
Here, defer(out[i]) returns a function. We pass this function to search.Search is like this:
search = (keyword, callback) ->
# do some search
callback(some_result)
And here, by calling callback, which is the function returned by defer, it will end the await block.Here's a trivial example:
await
some_function = (fn) -> fn(1234)
some_function(defer(x))
console.log(x)
defer(x) returns a callback, it's given to some_function. And some_function calls it, which ends the await block.Re: IcedCoffeeScript
#40> The function defer returns a callback, and a callee in an await block can fulfill a deferral by simply calling the callback it was given. I'm wanting in CoffeeScript knowledge and/or intelligence, so could someone explain the above please? (In the examples, defer seems to specify the variable that gets the result of await .)
I tried to formulate very differently so you can see that as another point of view. Sorry for the lack of formality. defer is a function which returns another function. When that returned function is called, we get out of the await block. So, to take the same example: await for k,i in keywords search k, defer out[i] Here, defer(out[i]) returns a function. We pass this function to search. Search is like this: search =…
await $.getJSON url, defer json
Is the following right? Syntactically, "defer json" is an argument to the function "$.getJSON". So you could write it like this: await $.getJSON( url, defer(json) )
The code we are waiting for is the "$.getJSON" call. That code indicates that it is finished by calling the function returned by defer.But what does the function returned by defer do? It looks like it (somehow) sets its argument to the result... so in the above example, "json" (somehow) gets the result of the call; in your example, "x" (somehow) gets a value. I'm guessing it's some convenient compiler magic that ICS does, and not an issue of CoffeeScript syntax.
An upshot of this is you can't give defer any old argument (e.g. a numerical value) - it has to be a variable that is capable of being set.
Also, who is the "callee"? A "callee" is a function that is called... Oh, does it mean (eg) "$.getJSON" is a callee, and it calls the callback function given to it (in the jQuery docs, it's notated as "success(data, textStatus, jqXHR)"; here, that success function is the function returned by defer). I guess, given the purpose of ICS, there will always be a callee in the block - but it seems to me that, syntactically, you could just directly call the function returned by defer. Ah... but (I bet) part of the compiler magic is that you are only allowed to call the function returned by defer from within another function - this is because the result of that other function is needed in order to set the argument of defer to it. Whew.
One last thing: the description talks about "deferrals" begin "fulfilled", but it doesn't say where these defarrals come from. Now, I think they are created by calling defer.
Hmmm.... it's probably better for me to think about this in terms of lisp macros, instead of C calls, as macros allow you to do weird source code transformations, like setting the value of a variable given as an "argument". i.e. ICS is a macro.