disnet · HackerTrans

disnet

no profile record

comments

12 tahun yang laludiscuss

> I'm starting to wonder whether readtables would also allow all of TypeScript to be compiled with sweetjs.

I haven't tried yet but I think all the syntax forms in TypeScript can be handled with just plain sweet.js macros, no need for the readtable. Actually handling the types in TypeScript via macros should also be eventually possible (Typed Racket [1] does typing via macros) once we have a bit more feature parity with Racket's macro system.

[1] http://docs.racket-lang.org/ts-guide/index.html?q=typed

13 tahun yang laludiscuss

We're working on integrating macros and modules to address this. Once it's implemented you'll be able to do something like `import { m } from "macros.js"`.

13 tahun yang laludiscuss

Actually sweet.js just landed infix macros [1] so you can match on syntax that comes before the macro name. This just happened last week so we haven't updated the docs or made an official release just yet.

[1] https://github.com/mozilla/sweet.js/pull/162

13 tahun yang laludiscuss

Yes indeed. Sweet.js already uses syntax objects internally so the groundwork is there for syntax-case. We "just" need to implement and surface the API :)

14 tahun yang laludiscuss

> The macro syntax is definitely not simple, and it could possibly get really complex for more elaborate syntactic definitions, thus rendering the source much less readable.

True, but the same can be said of any API. Reading the definitions can help but for both complex macros and complex APIs built today out of just functions and objects you need to document your abstractions. Macros don't change this, they just give you another abstraction axis (syntactic) to work with.

As with most things it just depends on how you use it. Sure you can abuse macros to make tons of crazy, undocumented, hard to understand syntactic extensions that destroy readability. But you can already do that today. Used wisely macros can increase readability, used poorly they can decrease it.

> And does the effort to integrate macros into the browser mean that it'll be possible to evaluate macros "runtime"?

Not sure what you mean here. By definition macros are expanded at compile time (well, parse time really). The browser doesn't change this.

14 tahun yang laludiscuss

Thanks for taking the time to write these up! I'm tracking them here [1]. The first two should be fixed and I should have the third ready soon.

[1] https://github.com/mozilla/sweet.js/issues/18

14 tahun yang laludiscuss

> OK, either your description page doesn't get your point across at all, or you're missing a definition somewhere.

The description page (like the rest of the project at them moment) is definitely a work in process. Sorry about the confusion!

> 'Wish the function keyword in JavaScript wasn't so long? What if you could define functions with def instead?'

> Erh, no? Why in the lord's name would I ? Is that your big selling point? 'I don't like function() because it's too long?'

This is just a really basic example of what you can do. Obviously you could have the same effect with sed but we need something simple to shows what basic macro definitions look like.

> 'Want a better way to make "classy" objects?'

> <provides example that looks like php vomited on Javascript after mating with ruby>

I'm assuming you refer to the macro definition with $ and whatnot. If you have ideas for better syntax please contribute! The notation is by no means final. That said I think it's pretty good for what it needs to do, matching syntax patterns and transforming them into new bits of syntax. Certainly more readable than a full parser/compiler.

> Am I the only one that doesnt understand the use case of this? Or is it just another lexer/parser?

The idea is to provide a middle way between no syntax extensions and writing your own full compile-to-js language languages like CoffeeScript which allow you to add any kind of syntax you want, but at the expense of being able to compose extensions. If you like the class notation of CS you must buy into all the syntax choices of CS whereas macros allow you to add just the syntax you want.

Whether you want new syntax is of course a different question. Other languages like scheme and closjure have found macros useful so sweet.js is an experiment to find out if the same syntactic extensibility that they provide is useful in JavaScript.

Hope that helps!

14 tahun yang laludiscuss

Yeah there are certainly a few bugs remaining in the reader :)

It actually does the right thing if the function is named:

    a = function foo() {}
    /5/
    7

correctly translates to:

    a = function foo() {
    } / 42 / 7;

But clearly I missed the unnamed case. You mentioned finding a few other bugs? Would you mind submitting a bug report on github? I would love to fix those too!

15 tahun yang laludiscuss

I've found the path of least resistance is to not change the default keybindings of the various emacs packages. Use the vi bindings for text manipulation and when you need to invoke a package function it's back to the ctr/meta chords. It's the text manipulation that's burned into my brain so as long as vimpulse takes care of that I'm mostly happy.

It's true though that if you're heavily invested in vim plugins there's fair time sink in getting up to speed on the emacs equivalents. Everything's a tradeoff.

15 tahun yang laludiscuss

Yep, but I managed with viper and vimpulse [1] which give vim bindings in emacs. You can have your cake and eat it too :)

[1] http://www.emacswiki.org/emacs-es/Vimpulse

15 tahun yang laludiscuss

Not sure if const/private are a good fit for contracts but things like "account balance is always positive" can be done right now with contracts.coffee using object invariants. For example, verifying the invariants of a binary search tree hold [1].

[1] http://disnetdev.com/contracts.coffee/#duck

15 tahun yang laludiscuss

MozRepl can give you a JS repl in emacs tied into the browser...no refresh required: https://github.com/bard/mozrepl/wiki

15 tahun yang laludiscuss

I haven't done any benchmarks yet so not sure. In addition to the guards I think the use of Proxies will cause some slowdown. But you're right the JIT should be able to optimize most of those guards away (maybe even someday use the guards to help in their optimizing/tracing...just speculating here, I'm not a compiler/JIT guy).

If you compile with "coffee -c" (compile, no contracts) instead of "coffee -cC" (compile, with contracts) you get pure JavaScript, no contracts and no runtime checks. Exactly what vanilla CoffeeScript would have given you.

15 tahun yang laludiscuss

> Indeed it would be. That said, CoffeeScript is a compiler of sorts.

The fact that we have a compiler doesn't give us all that much. Adding types to a dynamic language (where things can be monkey patched, evaled, and just generally mutated willy-nilly) is a hard problem (not impossible but definitely research [1 and 2 to start, but much more]).

>> And we'd like to do it in a more elegant way than constantly writing "if(argument === ...) then ... else ..."

> This doesn't really seem to solve that problem.

It solves the problem of elegance :)

> It just throws consistent errors if the types don't match. Your code would likely throw its own error if you didn't check the type manually. In my experience, native js errors are as easy or easier to track down that throwing errors yourself.

Key word there is likely. Like I mentioned, there are some errors that don't result in a run-time error and we might like to check for those too. As a silly example, consider a binary search tree [3] that you want to keep balanced. If you get the balance wrong, there's no immediate fault (no TypeError/NPE).

> Ah, ok. That makes more sense. They're like python decorators, only single purpose.

I guess you could say that. If we had an expressive enough decorator-like system for CoffeeScript we could probably implement contracts with it. CS doesn't have one of course so path of least resistance is to add the contract language extension directly.

[1] http://ecee.colorado.edu/~siek/blame-forall-2011.pdf

[2] http://dl.acm.org/citation.cfm?id=1863561

[3] https://github.com/disnet/contracts.coffee/blob/master/test/...

15 tahun yang laludiscuss

Well, CoffeeScript/JavaScript doesn't have a static type system. And to add one would be...hard.

But we would still like to express and enforce some invariants about our code. And we'd like to do it in a more elegant way than constantly writing "if(argument === ...) then ... else ..."

Contracts also allow us to check invariants that might not result in a run-time exception but could lead to the code just being subtly wrong.

15 tahun yang laludiscuss

I'm not sure that the relationship between types and contracts is all that tenuous.

They both work to enforce program invariants and there's a large overlap in the invariants they can express. Usually contracts are checked dynamically (as in contracts.coffee) but this is not a hard requirement (for example .net's code contracts can be statically checked [1]).

http://msdn.microsoft.com/en-us/devlabs/dd491992

15 tahun yang laludiscuss

It's a fork of CoffeeScript so it replaces your "coffee" executable. If you don't want to overwrite your normal CoffeeScript compiler just run the contracts.coffee "coffee" executable from its own directory.

I mention this briefly towards the end of the quick start section of the doc: http://disnetdev.com/contracts.coffee/#quickstart

17 tahun yang laludiscuss

Well, the wave people have already said they're stopping development for IE and will just be forcing the chrome frame: http://googlewavedev.blogspot.com/2009/09/google-wave-in-int...

As long as wave takes off it'll drive adoption.