Harmony as a Compilation Target of my Dreams
-1. I do not like the inline textual annotation style for attributing original source position. Much better IMO is the tack taken by Java < blog.csdn.net/dollyn/archive/2009/09/01/4506156.aspx#sourcemapfile>,
Caja, and ClosureCompiler of generating separate source mapping tables that map from generated text position back to original text position. That way, one's debugging view can be easily switched between different levels of abstraction by switching or omitting such mapping info.
And I find HOBD's use of "#" much more valuable. I do not think we should have both uses of "#" coexist in one language.
On Tue, Feb 8, 2011 at 1:39 PM, Mark S. Miller <erights at google.com> wrote:
Much better IMO is the tack taken by Java blog.csdn.net/dollyn/archive/2009/09/01/4506156.aspx#sourcemapfile, Caja, and ClosureCompiler of generating separate source mapping tables that map from generated text position back to original text position. And I find HOBD's use of "#" much more valuable. I do not think we should have both uses of "#" coexist in one language.
Ah. With these givens, I agree.
Kris Kowal
On Feb 8, 2011, at 1:39 PM, Mark S. Miller wrote:
-1. I do not like the inline textual annotation style for attributing original source position. Much better IMO is the tack taken by Java blog.csdn.net/dollyn/archive/2009/09/01/4506156.aspx#sourcemapfile, Caja, and ClosureCompiler of generating separate source mapping tables that map from generated text position back to original text position. That way, one's debugging view can be easily switched between different levels of abstraction by switching or omitting such mapping info.
Cool, this is like the solution we're aiming to implement in future Firefox for CoffeeScript source debugging, btw.
On 11:59 AM, Kris Kowal wrote:
This is a half-baked idea. Harmony of Brendan's Dreams makes extensive use of new octothorp syntax. There is perhaps another use for octothorp prefixes: to annotate generated JavaScript with line numbers from the source.
Don't make me have to come after you with the half-baked thing again. We have already have an abundance of half-baked ideas. What we need are proven ideas.
Our greatest scarcity is ASCII special characters. We only have three left. Brendan has proposed some uses for # and they seem like a good tradeoff to me. Before going crazy with overload it, we should consider other representations.
This is a half-baked idea. Harmony of Brendan's Dreams makes extensive use of new octothorp syntax. There is perhaps another use for octothorp prefixes: to annotate generated JavaScript with line numbers from the source.
source.cs: number -= 42 if opposite square = (x) -> x * x
target.js:
This would require some form of annotation to connect the line numbers with the corresponding source code. The connection could be inferred easily given the tacit strawman for Module(text, fileName, lineNo) and I imagine that some similar annotation would be possible on or around a module keyword.
It might even be useful to implicitly increment the annotation line number on line breaks to reduce the verbosity so that minifiers can provide similar annotation at little cost.
A third use-case would be annotating the sources of statically bundled "Simple Modules" or whatever succeeds them. I imagine that there would be a need for tools that transform load directives into inline modules, so it would be handy to annotate sources for debugging in that case too.
Kris Kowal
This is a half-baked idea. Harmony of Brendan's Dreams makes extensive use of new octothorp syntax. There is perhaps another use for octothorp prefixes: to annotate generated JavaScript with line numbers from the source. source.cs: number -= 42 if opposite square = (x) -> x * x target.js: var opposite, number, square; #1 if (opposite) { number -= 42; } #2 square = function (x) { return x * x; } This would require some form of annotation to connect the line numbers with the corresponding source code. The connection could be inferred easily given the tacit strawman for Module(text, fileName, lineNo) and I imagine that some similar annotation would be possible on or around a module keyword. It might even be useful to implicitly increment the annotation line number on line breaks to reduce the verbosity so that minifiers can provide similar annotation at little cost. A third use-case would be annotating the sources of statically bundled "Simple Modules" or whatever succeeds them. I imagine that there would be a need for tools that transform load directives into inline modules, so it would be handy to annotate sources for debugging in that case too. Kris Kowal