In JavaScript we have estree which is the AST definition evolving from Mozilla's implementation. But nowadays if you build an AST transformer in JS of a JS AST, you probably use this structure. Do we have anything like this for Swift, of the Swift AST?
I see we have a grammar, but what about an AST? I guess I can make one from that, but still.
If nothing standard, do we have any AST examples?
The Swift project offers SwiftSyntax as a package for working with Swift source code, in Swift. Under the hood, it's powered by the compiler's own libSyntax, written in C++.
Note that this currently isn't the representation that the Swift compiler proper uses for actually compiling Swift code — libSyntax focuses on source code itself for rewriting, formatting, transformations, etc., but is largely void of the semantic information that you may find in a compiler AST necessary for transforming the source into machine code. If you're just looking to operate on the AST without those semantics, this may be sufficient for your use case.
The repo README should have some info to get you started, an example, and some real-world use cases showing concrete usage of the library.
Related
I've started a project to transpile a subset of Swift into Kotlin (for sharing business logic between iOS and Android apps) and am using the Abstract Syntax Tree output of the Swift compiler (i.e. as produced by the -dump-ast option) as a starting point.
I was wondering if anyone knew of an "official" grammar and/or lexer for the AST output itself. It's not that complicated and I've created one myself for now, but I'd feel more comfortable if I was relying on something supported.
I was doing some research of how to solve this question. However, I am wondering if I can start learning how the function works, or how they pass the argument into the local scope by reading the source code of scala.
I know the source code of scala is hosted in Github, my question is how to locate the definition of def.
Or more generally, how to locate the source code of certain built in functions, operators?
The source code for everything in the Scala standard library is under https://github.com/scala/scala/tree/2.11.x/src/library/scala.
Also, the Scaladoc for the standard library includes links to the source code. So e.g. if you're interested in scala.Option and you're looking at http://www.scala-lang.org/api/2.11.7/#scala.Option, notice that page has "Source: Option.scala" where "Option.scala" is hyperlinked to the source code.
For something like def, which is not part of the standard library, but part of the language, well... there is no single place where def itself is defined. The compiler has 25 phases (you can list them by running scalac -Xshow-phases) and basically every phase participates in the job of making def mean what it means.
If you want to understand def, you'd probably be better off reading the Scala Language Specification; it's highly technical, but still much more approachable than the source code for the compiler.
The part of the spec that addresses your question about named and default arguments is SLS 6.6.1.
Recently I have started to use Google Closure Tools for my javascript development. Until now, I have used to write my code in CoffeeScript, however, the javascript generated by CoffeeScript seems to be incompatible with Google Closure Compiler's advanced mode.
Is there any extension to the CoffeeScript compiler adding Google Closure support?
There are various tools that aiming to make CoffeeScript usable with Google Closure Tools. I will describe three of them:
Bolinfest's CoffeeScript fork
Features:
Fixed function binding, loops, comprehensions, in operator and various other incompatibilities
Fixed classes syntax for Google Closure
Automatic generation of #constructor and #extends annotations
Automatically inserts goog.provide statement for each class declared
Python's like include namespace as alias support translated to goog.require and goog.scope
Drawbacks:
Constructor has to be the very first statement in the class
Cannot use short aliases for classes inside the class (i.e. class My.Long.Named.Car cannot be refered as Car in class definition as pure CoffeeScript allows)
User written JsDoc comments don't get merged with compiler generated ones
Missing provide equivalent for include
No support for type casting, this can be done only by inserting pure javascript code inside backticks "`"
Based on outdated CoffeeScript 1.0
Read more at http://bolinfest.com/coffee/
My CoffeeScript fork
Disclaimer: I am the author of this solution
This solution is inspired by the Bolinfest's work and extends it in these ways:
Constructor can be placed anywhere inside the class
Short aliases for classes work using goog.scope
User written JsDoc comments get merged with compiler generated, user written #constructor and #extends annotations are replaced by generated
Each namespace is provided or included mostly once, namespace, that is provided is never included. You can provide namespace by keyword provide
Support for typecasting using cast<typeToCastTo>(valueToBeCast) syntax
Based on CoffeeScript 1.6
Read more at https://github.com/hleumas/coffee-script/wiki
Steida's Coffee2Closure
Unlike the two solutions above, Steida's Coffee2Closure is postprocessor of javascript code generated by upstream nontweaked CoffeeScript. This approach has a one major advantage, that it will need no or only slight updates with continued development of CoffeeScript and still be actual. However, by the very nature of this approach, some of the features cannot be delivered. Currently it fixes only classes and bindings, loops, in operator and few other incompatibilities. It has no support for automatic annotation generation, type casting or custom keywords.
https://github.com/Steida/coffee2closure
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.
Given a Scala AST, is there a way to generate Scala source code?
I'm looking into ways to autogenerate Scala source by parsing/analyzing other Scala source. Any tips would be appreciated!
I have been successfully using Scala-Refactoring by Mirko Stocker for this task.
For synthetically constructing ASTs, it relies strongly on the existing Tree DSL of Scala's NSC.
Although the code is a bit messy, you can find an example usage in my project ScalaCollider-UGens.
I have also come across a very useful class by Johannes Rudolph.
See our DMS Software Reengineering Toolkit.
DMS provides a complete ecosystem for parsing/analyzing/optimizing/transforming source code in many languages. It achieves this by provide generic machinery for these tasks as its core capabilities, and specializing those according to explicitly supplied language definitions ("front ends"). DMS has front ends for many languages (C, C++, C#, Java, COBOL, ...) that have been used in anger, and a process for defining others very quickly.
We work on expanding the language set more or less continuously. DMS already has parts of a Scala front end implemented, and we know how to finish it based on the other 30+ front ends we have built, with special emphasis on knowledge of Java.