> 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.
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"`.
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.
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 :)
> 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.
> 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.
Okay, Now that's a story that makes me understand what this is about, thanks!
How about a more clear description like above on your page with some readups into macro's, and some more complicated examples that tell me as a programmer: "Yes, I dó need macro's!" and I can use them for these and these cases?
Also, don't underestimate how smart your audience is going to be by giving them just 3-line examples. I always find it more clear when there's some actual use cases on the wiki pages. How about a proper class, or a todoMVC style demo, so that people can actually imagine what kind of possibilities this would unlock?
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!
Sorry, was distracted by the other conversation with dherman, and really shouldn't be spending any time on this anyway, but I've verified your operator associativity is wrong.
To start with some example code:
for (var a = 7 in /7/ in 9 in b);
If I run that in node I get:
TypeError: Cannot use 'in' operator to search for '/7/' in 9
As this code is vaguely equivalent to:
var a = 7; for (a in ((/7/ in 9) in b));
However, it gets converted by sjs to:
for (var a = 7 in (/7/ in (9 in b)));
That's obviously different, and gives this error instead:
ReferenceError: b is not defined
(I really should get back to actually doing my job now, though; if dherman responds again I'll totally notice and follow up: that conversation is really interesting to me.)
I'm a die-hard vim user, who's used vim for many years.
I tried emacs with viper and vimpulse recently, and found that while they did make emacs a lot less painful, they were a far cry from making a long-time vim user comfortable in emacs.
The biggest problem is that in order to configure emacs and bind functions to keys you have to invest a lot of time in reading documentation and finding out about emacs.
If you have that sort of time to invest, great. But I didn't, especially since I already know vim very well and feel completely comfortable using and configuring it. Switching to emacs just didn't seem worth the time investment in my particular case.
I have heard that evil was a better vim emulation mode for emacs, and I've been meaning to give it a try, but haven't gotten around to it yet -- and I'm still skeptical of it addressing my main concern, which is that to really use emacs effectively (even in vim emulation mode) you'd have to invest a lot of time in learning the emacsy parts.
There is one other major issue that none of emacs' vim emulation modes address, which is the thousands of vim plugins available on www.vim.org. You might, in the best case, get all the standard vim keybindings for emacs, but you'd still be forced to use emacs scripts and plugins, instead of the vim scripts and plugins you like and are used to. Learning and transitioning to those is yet another big time sink right there.
One of the main reasons that I switched to emacs was to use SLIME to interface with Common Lisp. But SLIME is a huge program, and learning to use it and configure viper/vimpulse to bind keyboard shortcuts to its functions requires spending a lot of time learning about and understanding SLIME. It's just so much simpler to one of the less feature-rich vim plugins to develop code in CL. Yes, you'd miss out on some great SLIME features, but you would also not have to spend a ton of time learning SLIME and configuring viper/vimpulse to work with it.
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.
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].
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