On Friday, 13 April 2012 at 09:57:49 UTC, Ary Manzana wrote:
> Having a D compiler available as a library will (at least) give these benefits:
>
>   1. Can be used by an IDE: D is statically typed and so an IDE can benefit a lot from this. The features Descent had, as far as I remember, were:
>     1.1. Outline
>     1.2. Autocompletion
>     1.3. Type Hierarchy
>     1.4. Syntax and semantic errors, showing not only the line number but also column numbers if it makes sense
>     1.5. Automatic import inclusion (say, typing writefln and getting a list of modules that provide that symbol)
>     1.6. Compile-time view: replace auto with the inferred type, insert mixins into scope, rewrite operator overloads and other lowerings (but I'm not sure this point is really useful)
>     1.7. Determine, given a set of versions and flags, which branches of static ifs are used/unused
>     1.8. Open declaration
>     1.9. Show implementations (of an interface, of interface's method or, abstract methods, or method overrides).
>     1.10. Propose to override a method (you type some letters and then hit some key combination and get a list of methods to override)
>     1.11. Get the code of a template when instantiated.
>  2. Can be used to build better doc generators: one that shows known subclasses or interface implementation, shows inherited methods, type hierarchy.
>  3. Can be used for lints and other such tools.
>
> As you can see, a simple lexer/parser built into an IDE, doc generator or lint will just give basic features but will never achieve something exceptionally good if it lacks the full semantic knowledge of the code.
>
> I'll write a list of things I'd like this compiler-as-library to have, but please help me make it bigger :-)
>
>  * Don't use global variables (DMD is just thought to be run once, so when used as a library it can just be used, well, once)
>  * Provide a lexer which gives line numbers and column numbers (beginning, end)
>  * Provide a parser with the same features
>  * The semantic phase should not discard any information found while parsing. For example when DMD resolves a type it recursively resolves aliasing and keeps the last one. An example:
>
>   alias int foo;
>   alias foo* bar;
>
>   bar something() { ... }
>
>   It would be nice if "bar", after semantic analysis is done, carries the information that bar is "foo*" and that "foo" is "int". Also that something's return type is "bar", not "int*".
>  * Provide errors and warnings that have line numbers as well as column numbers.
>  * Allow to parse the top-level definitions of a module. Whit this I mean skipping function bodies. At least Descent first built a the outline of the whole project by doing this. This mode should also allow specifying a location as a target, and if that location falls inside a function body then it's contents are returned (useful when editing a file, so you can get the outline as well as semantic info of the function currently being edited, which will never affect semantic in other parts of the module). This will dramatically speed up the editor.
>  * Don't stop parsing on errors (I think DMD already does this).
>  * Provide a visitor class. If possible, use visitors to implement semantic analysis. The visitor will make it super easy to implement lints and to generate documentation.

By the way, I also started a project called <a href="https://github.com/roman-d-boiko/DCT">The D Compiler Tools (DCT)</a> about a month ago. It is provided under the Boost license, and has the goal to enable building third-party tools with functionality that would include described above. I'm trying to build LLVM-based codegen and also reuse frontend in a separate project with basic IDE functionality for D.

I have never implemented compilers before, and probably should have called my project SDC if only that name had not been taken before ;) Goals are very similar to those of SDC (especially now, after its re-licensing). But I don't commit to ever finish the project, because my free time is very limited :(.

There is SIGNIFICANTLY less functionality implemented at this moment than in SDC. Currently, only primitive lexing is in place (I follow the KISS principle where possible) and parsing of auto declarations (auto i = 3 * (2 + 8), etc.) with stubs for most other cases. (Please note that project Readme file is outdated.) Parser is top-down recursive descent, and it follows specification very closely, except some differences needed to simplify implementation (like using loops to implement left-recursion in specification).

Anyone interested in discussing DCT or participating in development would be welcome!

On 2012-04-19 10:48, Roman D. Boiko wrote:

> Convenience interface on top of low-level core functionality can be
> provided and would suffice for many typical situations.

In that case I think something like this might work:

Foo.renameSymbol("file.d:16:4", "bar");

Where "file.d" is the file in which the symbol is located. ":16:4" would be the row and column number. "bar" would be the new name of the symbol.

-- 
/Jacob Carlborg

On Monday, 16 April 2012 at 11:57:29 UTC, Bernard Helyer wrote:
> Oh god, what did we decide on? Boost?

Imho, MIT is just fine for a compiler. It's not like a line of attribution is much to ask when you are getting an entire compiler fronend for free – in fact, applications should probably mention the compiler frontend they use in the docs anyway in case there are incompatibilities, …

David

"David Nadlinger" <see@klickverbot.at> wrote in message news:voymctvtskltfzhslhkp@forum.dlang.org...
> On Monday, 16 April 2012 at 11:57:29 UTC, Bernard Helyer wrote:
>> Oh god, what did we decide on? Boost?
>
> Imho, MIT is just fine for a compiler. It's not like a line of attribution is much to ask when you are getting an entire compiler fronend for free - in fact, applications should probably mention the compiler frontend they use in the docs anyway in case there are incompatibilities, .
>

There's no attribution in MIT.

On Thursday, 19 April 2012 at 09:58:52 UTC, Nick Sabalausky wrote:
> "David Nadlinger" <see@klickverbot.at> wrote in message
> news:voymctvtskltfzhslhkp@forum.dlang.org...
>> On Monday, 16 April 2012 at 11:57:29 UTC, Bernard Helyer wrote:
>>> Oh god, what did we decide on? Boost?
>>
>> Imho, MIT is just fine for a compiler. It's not like a line of attribution is much to ask when you are getting an entire compiler fronend for free - in fact, applications should probably mention the compiler frontend they use in the docs anyway in case there are incompatibilities, .
>>
>
> There's no attribution in MIT.

Yes, there is no attribution: https://github.com/roman-d-boiko/SDC/blob/master/LICENCE. It is very similar to Boost. Actually, I prefer Boost only because it is slightly more popular and because the D standard library uses it. I'm perfectly happy with MIT, though, and already cloned SDC :)

Just interested about motivation behind choosing MIT.

On Thursday, 19 April 2012 at 09:24:23 UTC, Roman D. Boiko wrote:
> On Friday, 13 April 2012 at 09:57:49 UTC, Ary Manzana wrote:
>> Having a D compiler available as a library will (at least) give these benefits:
>>

What about joining forces with sdc then?

On Thursday, 19 April 2012 at 10:28:08 UTC, Tobias Pankrath wrote:
> On Thursday, 19 April 2012 at 09:24:23 UTC, Roman D. Boiko wrote:
>> On Friday, 13 April 2012 at 09:57:49 UTC, Ary Manzana wrote:
>>> Having a D compiler available as a library will (at least) give these benefits:
>>>
>
> What about joining forces with sdc then?

I think I will use some code from SDC and contibute back to it now that it is liberally licensed. It wasn't an option when it was under GNU, because I generally prefer possibility for commercial usage.

However, I believe that the project I'm working on (DCT) has a good potential and the D community will better benefit from two alternatives. There are several design differences, and will be more. This also gives me additional flexibility and more learning opportunities.

I will dual-license (Boost+MIT) any part of my code if somebody would like to incorporate such part in SDC. My question about motivation for MIT licence was caused in particular by desire to minimize possible overhead of dealing with two licenses for me.

On Thursday, 19 April 2012 at 10:15:36 UTC, Roman D. Boiko wrote:
> On Thursday, 19 April 2012 at 09:58:52 UTC, Nick Sabalausky wrote:
>> "David Nadlinger" <see@klickverbot.at> wrote in message
>> news:voymctvtskltfzhslhkp@forum.dlang.org...
>>> On Monday, 16 April 2012 at 11:57:29 UTC, Bernard Helyer wrote:
>>>> Oh god, what did we decide on? Boost?
>>>
>>> Imho, MIT is just fine for a compiler. It's not like a line of attribution is much to ask when you are getting an entire compiler fronend for free - in fact, applications should probably mention the compiler frontend they use in the docs anyway in case there are incompatibilities, .
>>>
>>
>> There's no attribution in MIT.
>
> Yes, there is no attribution: https://github.com/roman-d-boiko/SDC/blob/master/LICENCE. It is very similar to Boost. Actually, I prefer Boost only because it is slightly more popular and because the D standard library uses it. I'm perfectly happy with MIT, though, and already cloned SDC :)
>
> Just interested about motivation behind choosing MIT.

Motivation for Boost would be reducing the number of licenses that the code author must know. Also, here are some differences between these licenses, which I consider as Boost advantages:

"The Boost Software License is based upon the MIT license, but differs from the MIT license in that it:

(i) makes clear that licenses can be granted to organizations as well as individuals;

(ii) does not require that the license appear with executables or other binary uses of the library;

(iii) expressly disclaims -- on behalf of the author and copyright holders of the software only -- the warranty of title (a warranty that, under the Uniform Commercial Code, is separate from the warranty of non-infringement)

(iv) does not extend the disclaimer of warranties to licensees, so that they may, if they choose, undertake such warranties (e.g., in exchange for payment)."

http://ideas.opensource.org/ticket/45

Le 16/04/2012 13:58, Bernard Helyer a écrit :
> 
> I recall mentioning it via IRC. Which is hardly going to stand up in a court. :V
> 
And given the ongoing Oracle-Google suit over the Java API license, this has to be taken seriously, I'm affraid....

On 4/19/12 12:48 AM, Jacob Carlborg wrote:
> On 2012-04-18 14:49, Marco Leise wrote:
>
>> I want refactoring to be as simple as Foo.renameSymbol("std.path.sep",
>> "std.path.dirSeperator"); if the connection between module- and
>> filename allows "std.path" to be traced back to the original file.
>
> I'm not sure but I don't think that is enough. In Clang you do something
> like this:
>
> 1. Get cursor of source location
> 2. Get a unique global ID of the cursor the corresponds to the symbol
> (unified symbol resolution)
> 3. Walk the AST to find all matches of this ID
> 4. Get the source location of the cursors which match
> 5. Rename the symbol at the source location
>

Unfortunately rename can't be perfect in D because you can't apply it inside templates.