I have a relatively large Scala code base that does not use named parameters for any function/class calls. Rather than going in and manually entering it, which would be a very tedious process, I was looking at a formatter to do the job. The best I found is scalariform, but I'm not sure whether I can even write a rule for something so complex.
I'm curious if anyone has ran into a similar problem and found a powerful formatter.
The Scala Refactoring library might be something you could use. You will need some knowledge of Scala's Abstract Syntax Tree representation.
Why do you want to use named parameters throughout your code base? I like IntelliJ's default which is to suggest to name boolean arguments (only).
Related
Macro contexts in Scala come with two handy methods: reifyType and reifyTree which essentially generate code that, when executed at runtime, will return the Type or Tree being reified.
I wonder if there is some way to achieve something similar with Symbols - some kind of reifySymbol method?
We didn't implement reifySymbol yet, but it might be decently emulated by wrapping a symbol in an Ident and then reifying the resulting tree. Pull requests are welcome as well :)
I'd really like to use case classes' copy feature in my project, but unfortunately I also need inheritance, which doesn't work well with case classes. So, I'm wondering if it's possible to write a macro which will generate a method for creating copy-with-changes object for an arbitrary class. What stops me there at the moment is the fact that AFAIK macros don't support named parameters. Has anyone found a way around that or, alternatively, can suggest other way for easy creating of copies which use inheritance?
That will be possible with type macros and/or annotation macros. The current macros do not support this.
Do look at lenses work, though. There's quite a few macro-based versions around, such as Shapeless.
You could also take a look at https://github.com/dicarlo2/ScalaEquals
The only ways I am aware of, aren't "direct":
converting to ANTLR format and using its own visualizer
VISUALLANGLAB, which it seems to require an entire mouse-clicks "rewrite"
implementing a converter by myself (which would be funny, but time-consuming)
second link below
Related:
comparison
wrapper
a 3rd party attempt
The second link suggests to debug adding an implicitly method to the parsers:
implicit def toLogged(name:String) = new {
def !! = log(p)(name)
}
May be an AST would be more feasible/usefull; but the question remains similar.
I might have misunderstood your question.
Scala parser combinators are used to parse strings to instances of types that you can use (either custom or built-in). The result is a structure of Scala instances that you decide, this could be anything.
You could create a parser that parses your arbitrary string into instances of a well known java structure for example ECore.
Without a usecase it's hard to suggest the best road for your problem. Maybe Xtext can help you: http://www.eclipse.org/Xtext/. Xtext has quite a few built-in features, however it's an Eclipse plugin and you might need something else.
I have a build chain setup that will convert a file from coffeescript to typescript to javascript. My question is: what is the most minimally intrusive way to add type signatures to a coffeescript function?
coffeescript supports raw javascript through backticks. However, that means coffeescript no longer understands the backtick snippet.
Coffeescript rejects these:
f = (`a:String`) -> a + 2
f = (a`:String`) -> a + 2
I can write this above the function:
`var f = (String) => any`
It compiles, but does not do the type-checking. I think this is because Coffeescript already declared the variable.
The only way I could figure out how to make it work requires a lot of boilerplate
f = (a) ->
`return (function(a:String){`
a + 2;
`})(a)`
Backticks do not seem to work properly in the new Coffeescript Redux compiler:
https://github.com/michaelficarra/CoffeeScriptRedux/issues/71
I am well aware that this is a dubious endeavor, it is just an experiement right now. I currently use contracts.coffee, but I am looking for actual types.
Here's my project which transpiles CoffeeScript into TypeScript and then merges it with a d.ts file containing types. Then reports compilation errors, if any.
Its called Compiled-Coffee.
If you want to write CoffeeScript, it is best to write CoffeeScript and compile to JavaScript.
The benefit of TypeScript is mostly design-time benefit and better tooling, so using it in the middle of CoffeeScript and JavaScript adds very little benefit as you will get design time and tooling based on your CoffeeScript code.
You can consume the libraries you write in CoffeeScript in TypeScript and vice-versa, so you can maintain your CoffeeScript libraries in CoffeeScript and consume them in your new TypeScript files while you decide which way to go.
Update: I'm not sure how there can be such a wide misinterpretation of this answer - I'm going to assume that I haven't explained this well (rather than assuming it is merely straw-man argument or hyper-sensitivity to language comparison).
TypeScript is indeed a type system for JavaScript. Static types are more use to you as a programmer earlier in the workflow. Having design-time warnings in your IDE means rapid correction of common errors like mis-typed variable names, incorrect parameters, invalid operations and a whole lot more. Having code underlined and annotated with an error means instant feedback. Having this at compile-time is good, but your feedback loop is longer. I won't even talk about run-time given that all types are erased by this point when using TypeScript.
As to all the "TypeScript vs CoffeeScript" comments - this question is not about that at all. The question is about compiling from CoffeeScript to TypeScript and then to JavaScript. Let's look at why this might not be ideal:
You will only get type feedback at compile time
You won't get auto-completion
Your CoffeeScript code will no longer be compact - it will have type annotations
Your CoffeeScript code will no longer be valid without your intermediate compiler
You will have to use an additional compiler and it will need to be in-step with CoffeeScript version x and TypeScript version y
Your IDE won't understand your CoffeeScript code
I think what I came up with is the best I can do. Things are harder in the new Coffeescript Redux compiler: it would actually be easier to try to hack the current coffeescript compiler to make this work.
The way of making this look less hacky is:
`var f : (a:Number) => Number = originalF`
However, typescript's weak type inference doesn't do that well with this form.
This gets proper type analysis:
f = (a) ->
`var a : Number = a`
a + 2
However, I am still not sure how to specify a return value with this form.
Typescript is a strong type javascript.
Coffee-script provides a more comfortable way of writing and reading.
I do not treat coffee-script as a language.
It's just a way, a style that can be attached to any language: Coffee Style Smart Computer Language should be the future
It's very ugly and stupid through backtick to 'support' the such strong type.
The correct way to implement the coffee-script with strong type:
Modify the CoffeeScriptRedux source to add the strong type supported
the TypedCoffeeScript has already done.
Modify the Typescript parser source to use coffee-script syntax.
It seems nobody do this.
I have just finished the first version of a Java 6 compiler plugin, that automatically generates wrappers (proxy, adapter, delegate, call it what you like) based on an annotation.
Since I am doing mixed Java/Scala projects, I would like to be able to use the same annotation inside my Scala code, and get the same generated code (except of course in Scala). That basically means starting from scratch.
What I would like to do, and for which I haven't found an example yet, is how do I generate the code inside a Scala compiler plugin in the same way as in the Java compiler plugin. That is, I match/find where my annotation is used, get the AST for the annotated interface, and then ask the API to give me a Stream/Writer in which I output the generated Scala source code, using String manipulation.
That last part is what I could not find. So how do I tell the API to create a new Scala source file, and give me a Stream/Writer/File/Handle, so I can just write in it, and when I'm done, the Scala compiler compiles it, within the same run in which the plugin was invoked?
Why would I want to do that? Firstly, because than both plugins have the same structure, so maintenance is easy. Secondly, I want to open source it, and there is just no way to support every option that anyone would want, so I expect potential users to want to extend the generation with their own code. This will be a lot easier for them if they just have to do some printf(), instead of learning the AST API (this also applies to me).
Short answer:
It can't be done
Long answer:
You could conceivably generate your source file and push that through a parser instance within your plugin. But not in any way that's likely to be of any use to you, because you'd now have a bigger problem to contend with:
In order to grab all the type/name information for generating the delagate/proxy, you'll have to pick up the annotated type's AST after it has run through both the namer and typer phases (which are inseperable). The catch is that any attempts to call your generated code will already have failed typechecking, the compiler will have thrown an error, and any further bets are off.
Method synthesis is possible in limited cases, so long as you can somehow fool the typechecker for just long enough to get your code generated, which is the trick I pulled with my Autoproxy 'lite' plugin. Even then, you're far better off working with TreeDSL to generate code instead of pumping out raw source.
Kevin is entirely correct, but just for completeness it's worth mentioning that there is another alternative - write a compiler plugin that generates source. This is the approach that I've adopted in Borachio. It's not a very satisfactory solution, but it can be made to work.
Edit - I just reread your question and realised that you're actually asking about generating source anyway
So there is no support for this directly, but it's basically just a question of opening a file and writing the relevant "print" statements. There's no way to invoke the compiler "inside" a plugin AFAIK, but I've written an sbt plugin which hides most of the complexity of invoking the compiler twice.