4 ms·

Is the heredoc syntax for documentation? Or is it syntactic sugar for multiline text? Because that would be very nice.

jashkenas 16y ago
It's syntactic sugar for multiline strings. It lets you write out formatted blocks of text that preserve indentation, allow you to use double-quotes and single-quotes inside without escaping, and because we have ECMA Harmony-style string interpolation -- you can interpolate values into heredocs as well. For example, here's a hypothetical message: email: """ Dear $recipient, You should receive your $product in the mail in $product.eta days. Thanks, $sender """
- endergen 16y ago
  That's really nice, I would love that both for the above use of multiline text to be printed. But especially for client-side html templates. I'm building my own javascript preprocessor language called O. I will definitely have to use that one, I hadn't thought of adding that. Should have considering it's in PHP, Pything, etc. ps. I like the look of coffeescript, and the principle of having everything be an expression. What other kinds of properties does it enforce? Are you going to be adding any more features/property-preservations? I'm trying to shoot for two interesting properties, 1) To be able to compile it back down to C/C++ for server side speed increases(Say in projects like Node.js where you can pretty easily hook in C/C++ modules. 2) To have the property of all code be reversable, and branchable for some interesting use cases. The reversability ties into some Networking/User-Interface Libs I'm making. I'm curious what kind of tricks you used for implementing Coffeescript. Did you use hand made parsers, Parsing Expression Grammars, or base it on any other good projects?
  - jashkenas 16y ago
    Compiling a single language into JavaScript source code as well as C or C++ is going to be one hell of a trick. I think it'll be very difficult to keep the semantics the same, without resorting to running the equivalent of a JavaScript interpreter inside of your C++, but I wish you the best of luck with it. If you'd like to discuss the implementation, feel free to drop by #coffeescript on freenode. But to give you the rough outline -- the compiler is made up of (in order), a Lexer, Rewriter, Parser, and AST of Nodes. The lexer creates the tokens, the rewriter rewrites the stream of tokens, disambiguating parses and allowing for optional syntax, the parser generates the AST of nodes, and then "compile()" is called on the root node, and walks down the tree, compiling the JavaScript string recursively. For the parser, I'm using the excellent Jison parser generator for JavaScript, in LALR(1) mode. The only really unorthodox part of this is the Rewriter. It's not kosher to munge a token stream before parsing it -- but it's removed a ton of complexity from the grammar to not ever have to handle the syntactical edge cases, and to have them resolved in advance. All of the source is annotated, so here's some links: * Jison: http://github.com/zaach/jison http://github.com/zaach/jison * Lexer: http://jashkenas.github.com/coffee-script/documentation/docs/lexer.html http://jashkenas.github.com/coffee-script/documentation/docs... * Rewriter: http://jashkenas.github.com/coffee-script/documentation/docs/rewriter.html http://jashkenas.github.com/coffee-script/documentation/docs... * Grammar: http://jashkenas.github.com/coffee-script/documentation/docs/grammar.html http://jashkenas.github.com/coffee-script/documentation/docs...
    - endergen 16y ago
      You are totally correct about the C/C++ generation not being easy if I go for making the whole language be elegantly compilable. I was thinking more of a subset, where you can mark a module or function(Not sure about the granularity) and it would raise a compile error if it doesn't maintain semantics that work elegantly in both Javascript and C/C++. It's really to allow Javascript programmers to not have to learn C/C++ and be able to accelerate their server side code (For say large image, or file processing. Or just expensive calculations like Pathfinding or Search-Space type stuff.) Of course it only works elegantly for server side, but it would be future proof for say using Native Client on the client side when or if it becomes available. Thanks for the pointers, I remember now finding those implementation details when I leafed through your code a while back. I'll check out the freenode channel when I get a chance.

It's syntactic sugar for multiline strings. It lets you write out formatted blocks of text that preserve indentation, allow you to use double-quotes and single-quotes inside without escaping, and because we have ECMA Harmony-style string interpolation -- you can interpolate values into heredocs as well. For example, here's a hypothetical message: email: """ Dear $recipient, You should receive your $product in the mail in $product.eta days. Thanks, $sender """

endergen 16y ago
That's really nice, I would love that both for the above use of multiline text to be printed. But especially for client-side html templates. I'm building my own javascript preprocessor language called O. I will definitely have to use that one, I hadn't thought of adding that. Should have considering it's in PHP, Pything, etc. ps. I like the look of coffeescript, and the principle of having everything be an expression. What other kinds of properties does it enforce? Are you going to be adding any more features/property-preservations? I'm trying to shoot for two interesting properties, 1) To be able to compile it back down to C/C++ for server side speed increases(Say in projects like Node.js where you can pretty easily hook in C/C++ modules. 2) To have the property of all code be reversable, and branchable for some interesting use cases. The reversability ties into some Networking/User-Interface Libs I'm making. I'm curious what kind of tricks you used for implementing Coffeescript. Did you use hand made parsers, Parsing Expression Grammars, or base it on any other good projects?
- jashkenas 16y ago
  Compiling a single language into JavaScript source code as well as C or C++ is going to be one hell of a trick. I think it'll be very difficult to keep the semantics the same, without resorting to running the equivalent of a JavaScript interpreter inside of your C++, but I wish you the best of luck with it. If you'd like to discuss the implementation, feel free to drop by #coffeescript on freenode. But to give you the rough outline -- the compiler is made up of (in order), a Lexer, Rewriter, Parser, and AST of Nodes. The lexer creates the tokens, the rewriter rewrites the stream of tokens, disambiguating parses and allowing for optional syntax, the parser generates the AST of nodes, and then "compile()" is called on the root node, and walks down the tree, compiling the JavaScript string recursively. For the parser, I'm using the excellent Jison parser generator for JavaScript, in LALR(1) mode. The only really unorthodox part of this is the Rewriter. It's not kosher to munge a token stream before parsing it -- but it's removed a ton of complexity from the grammar to not ever have to handle the syntactical edge cases, and to have them resolved in advance. All of the source is annotated, so here's some links: * Jison: http://github.com/zaach/jison http://github.com/zaach/jison * Lexer: http://jashkenas.github.com/coffee-script/documentation/docs/lexer.html http://jashkenas.github.com/coffee-script/documentation/docs... * Rewriter: http://jashkenas.github.com/coffee-script/documentation/docs/rewriter.html http://jashkenas.github.com/coffee-script/documentation/docs... * Grammar: http://jashkenas.github.com/coffee-script/documentation/docs/grammar.html http://jashkenas.github.com/coffee-script/documentation/docs...
  - endergen 16y ago
    You are totally correct about the C/C++ generation not being easy if I go for making the whole language be elegantly compilable. I was thinking more of a subset, where you can mark a module or function(Not sure about the granularity) and it would raise a compile error if it doesn't maintain semantics that work elegantly in both Javascript and C/C++. It's really to allow Javascript programmers to not have to learn C/C++ and be able to accelerate their server side code (For say large image, or file processing. Or just expensive calculations like Pathfinding or Search-Space type stuff.) Of course it only works elegantly for server side, but it would be future proof for say using Native Client on the client side when or if it becomes available. Thanks for the pointers, I remember now finding those implementation details when I leafed through your code a while back. I'll check out the freenode channel when I get a chance.