Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IcedCoffeeScript

maxtaco.github.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: IcedCoffeeScript

#51

Post by xpaulbettsx »

crazygringo wrote: post #18
equark wrote: post #17

Why is defer needed? Why can't I follow C# and do: result = await search("test") Is this just so that it plays nicely with non-standard callback APIs? I'd prefer to introduce Promises (i.e., q) and have await interact with that. I guess this is not the NodeJS way though.

search("test") is not an asynchronous call, in your example, because there's no callback function. (In JavaScript) defer() is needed because it becomes the placeholder for the callback function, and lets Iced know how many functions it needs to wait to call back.

In other words, JavaScript doesn't return a Promise/Future/Task, so the defer syntax is necessary. You could get rid of it by simply capturing the callback params and returning them as a value, though your code would end up having a lot of `[0]`'s in them, since most callbacks are of the form (thing, err)

Re: IcedCoffeeScript

#53

Post by danbmil99 »

samdk wrote: post #5
russianbandit wrote: post #4

Why didn't the "iced" feature just get added to CoffeeScript? Why have two separate packages?

I haven't looked at this implementation specifically, but the issue with many similar proposals/implementations is that the generated JavaScript is ugly. One of the nice things about CoffeeScript is that there's no magic--it's very easy to figure out what the generated JavaScript is doing, and there's a straightforward CS JS mapping. jashkenas (CoffeeScript's author) has been reluctant to change that.

I did some simple tests, and frankly the generated code is ugly, certainly by comparison to vanilla CS. Gone is the "oh I see how it did that, it's just a Javascript version of my Coffee!" It's now more like what C++ used to look like when compiled to C (remember cfront? probably not. Be glad you don't).

As someone else said, if you avoid await/defer entirely, it seems to back off to exactly what Coffeescript does, so there is a nice progression path.

code: https://github.com/danx0r/testiced#readme

Re: IcedCoffeeScript

#54

Post by jarek-foksa »

If I understand correctly, everything after "await ..., defer" block will be executed only after the asynchronous operations from the await block are completed.

Does it mean that it's impossible to return any value from a function that contains await block?

  module = 
    dataPath: "http://search.twitter.com/search.json?q=blah&callback=?"

    init: () ->
      # Fetch data and do some stuff with it
      await 
        $.getJSON @dataPath, defer @data
  
      # Return yourself (this won't work)
      return @

Re: IcedCoffeeScript

#55

Post by timruffles »

jarek-foksa wrote: post #54

If I understand correctly, everything after "await ..., defer" block will be executed only after the asynchronous operations from the await block are completed. Does it mean that it's impossible to return any value from a function that contains await block? module = dataPath: "http://search.twitter.com/search.json?q=blah&callback=?" init: () -> # Fetch data and do some stuff with it await $.getJSON @dataPath, defer @…

There is a way around it. Here, everything after the await is transformed into a callback for the await magic:

    waity = (forFn) ->
      await forFn defer r1, r2
      console.log "values of defer variables", r1, r2
      return "this only returns from the result callback, not waity"

    syncReturn = waity (cb) ->
      setTimeout ->
        cb "r1 val", "r2 val"

    console.log "waity's synchronous return value:", syncReturn
So our output is:

    waity's synchronous return value: undefined
    values of defer variables r1 val r2 val
To return, you can simply write:

    waity = (forFn) ->
       setTimeout -> 
         await ...
       return "works as normal"

Re: IcedCoffeeScript

#56

Post by masklinn »

btipling wrote: post #33
swannodette wrote: post #29

This 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.

> What language exists in which this is not the case?

Languages which have very little "own shape" (syntax) and let you transform it easily (via macros) or provide high flexibility.

Mostly concatenative languages and Lisps, but e.g. Smalltalk or IO can probably be fit in that category as well, they have a minuscule syntactic core and that core is used to build abstractions and structures putting both the language's designers and the language's users on a level ground.

Of course that creates other issues, where every developer or organization has its own lingo and structures, making even going from one codebase to the next more expensive. It's a tradeoff.

Still, realizing that you have pretty much the same power as the language builders themselves when it comes to creating abstractions and datastructures and control flows... is an enjoyable feeling.

> Language by committee sounds terrible.

Can end horribly, and can end pretty well. Haskell was designed by a committee over ~10 years (FPCA '87 to the release of "The Haskell 98 Report" in 1997).

It does generally end baldy.

Re: IcedCoffeeScript

#57

Post by olegp »

If you're only using CoffeeScript on the server, then you should check out node-fibers to achieve the same effect.

Here's an example of using my Common Node library (that implements a number of sync APIs using fibers - http://olegp.github.com/common-node/) with CoffeeScript: https://gist.github.com/1447709

Re: IcedCoffeeScript

#58

Post by apgwoz »

swannodette wrote: post #29

This 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…

IcedCoffeeScript works through a CPS transformation, not sure how you could do that as a library in CoffeeScript...?

Re: IcedCoffeeScript

#59

Post by swannodette »

btipling wrote: post #33
swannodette wrote: post #29

This 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.

I'm not talking about language design by committee. For example, ClojureScript is far more restrictive in its design than either JavaScript or CoffeeScript. I'm simply questioning where the line is drawn concerning what constitutes language extension and what is perhaps best served as a library.

Re: IcedCoffeeScript

#60

Post by phzbOx »

6ren wrote: post #47
phzbOx wrote: post #44

Earlier quoted context omitted.

Note that I haven't tested ICS so it's only based on my understanding of the examples/docs. "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) )" Yes, exactly. "'m guessing it's some convenient compiler magic that ICS does" Yes, exactly. When you say "defer(x)", it basically returns a callback like this: f…

Thanks a second time, I'm getting there! I realized one can look at the transformed javascript output, to see just what it does. The setting of the variable in the defer becomes: $.getJSON(url, __iced_deferrals.defer({ assign_fn: (function() { return function() { return json = arguments[0]; }; })(), lineno: 6 })); Presumably, when the function that __iced_deferrals.defer returns is called by the code in .getJSON that…

About the function which is called automatically, it's a common pattern in javascript. It's used to create a new namespace/modules as block are defined per function instead of {}.

And, you are right that we're not assigning the return value of $.getJSON. Basically, once $.getJSON has finished with the request, it will call a function with the result. This result is set to the variable passed to defer. It's a bit of a brain teaser but that's the whole point of the await/defer thingy. Instead of using a callback to retrieve the result as an argument, you just write a variable after defer and you receive it.

Post reply on HN