I'm really interested in writing my own converter. I know C++/Python/Objective-C/Swift and a little Haskell.
There are website like objectivec2swift and iswift.org, which can convert OC to Swift online.
I have a strong interest in making my own parser and compiler, but I don't know what should I do to get start with this converter task. It seems like making an Source to Source Compile
I really want to try doing this and I hope to get help. Thanks.
This is a pretty big task. But then again, so are most things worth doing in programming. We start by breaking it down into smaller and smaller tasks until we get them down to the level of a problem we know how to solve.
You're right in that your overall task is a source-to-source compiler, and that you need to start with a parser. Unfortunately, C (and by extension any superset of the language, such as Objective-C) is difficult to parse. From the vocabulary you're using, you may already know a few things about parsing theory and the Chomsky hierarchy. If not, read up on it. It defines four levels of language complexity from 0 (very difficult to parse) to 3 (very easy to parse.) Most modern programming languages are level 2, context-free languages, because it's difficult to create a useful language without a recursive grammar, which is what differentiates level 2 from level 3. C and Objective-C are level 1, context-sensitive languages, because of the way typedefs work: the same string of code can parse in two different ways, with two different meanings, depending on whether or not the symbol it's reading is a type. This makes creating a proper parser for them much more difficult. Until you've got a lot of experience with compiler work, you'd be better off finding an existing parser than trying to build your own.
Once you have a parser, a lot of the hard work is done, but there's still plenty of interesting challenge ahead for you. You can run your parser over Objective-C code and get an Abstract Syntax Tree (AST) out. Hopefully you have a strong grasp of trees and recursion, because compiler work uses them everywhere. I'm not kidding.
Once you have your AST, the next step is semantic analysis. This is a formal way of saying "take this AST and figure out what its meaning is." Exactly how you perform semantic analysis depends a lot on the specifics of how your AST works and what you're trying to do. In this specific case, what you're trying to determine is the proper semantics for the code in question to be mappable to to Swift semantics. (This will, of course, require a deep knowledge of how both Swift and Objective-C work.) Your semantic analysis should either produce a new AST or annotate the AST from the parser in some way, and when you're done, you have a semantic tree.
The final phase is code generation. This is where you walk the semantic tree, inspect the semantics of the tree, and produce code in the target language.
On the Swift side, there's some good news and some bad news. The good news is, Apple has open-sourced the Swift language, so you can borrow their official AST, including a class called ASTPrinter that appears to take a swift AST and generate Swift code from it. (This means that your semantic analysis phase can be turning your Objective-C AST into an equivalent Swift AST, and your code generation phase is already taken care of.) The bad news, if you want to go this route, is that Apple's code is in C++, which is a really horrible language to work in. But at the very least, you can use their AST code for inspiration.
Anyway, that's a very high-level overview of how to write a source-to-source compiler. I didn't go into too many details, because details differ a lot depending on the specifics of what you're doing, but I hope it's helpful, at least for giving you an idea of what you need to do.
