Calypso and the future of D

[Walter Bright via Digitalmars-d]

On 1/25/2015 7:16 AM, Elie Morisse wrote:
> On Sunday, 25 January 2015 at 10:18:34 UTC, Walter Bright wrote:
>> Next, in the README example, it says:
>>
>>   $ clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o
>>   $ ar rcs libshowcase.a showcase.cpp.o
>>   $ ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d
>>
>> Where's Calypso in that?
>
> On Sunday, 25 January 2015 at 11:12:50 UTC, Kelly wrote:
>> Calypso is part ldc2 and, as far as I understand it, is invoked via the
>> "-cpp-args" command line arg.
>
> -cpp-args is only to pass arguments to Clang while generating the precompiled
> header.

You see, nobody understands where Calypso is! Is it part of clang, part of ldc, 
a standalone tool?

I feel like Noah:

https://www.youtube.com/watch?v=bputeFGXEjA 1:44


> Calypso registers itself as a "language plugin", and when parse.c encounters

parse.c is not part of my project. Where is parse.c?

> « import (ABC) xxx.yyy; » it asks the registered plugins if one of them handles
> the "ABC" language id. If that's the case it lets the plugin create the Import
> symbol by itself, for instance Calypso creates a cpp::Import which derives from
> Import and has a completely different load() method, which won't look for
> modules in .d files but inside the PCH generated by Clang.

A language plugin plugging into where?


> Here's the LangPlugin interface:
>
> class LangPlugin
> {
> public:
>      // returns -1 if said lang isn't handled by this plugin, or its id number
>      // to be passed to createImport otherwise
>      virtual int doesHandleModmap(const utf8_t *lang) = 0;
>
>      virtual Modmap *createModmap(int langId,
>          Loc loc, Expression *arg) = 0;
>
>      // returns -1 if said tree isn't handled by this plugin, or its id number
>      // to be passed to createImport otherwise
>      virtual int doesHandleImport(const utf8_t *tree) = 0;
>
>      virtual Import *createImport(int treeId,
>          Loc loc, Identifiers *packages, Identifier *id,
>          Identifier *aliasId, int isstatic) = 0;
>
>      // ===== - - - - - ===== //
>
>      virtual Expression *getRightThis(Loc loc, Scope *sc, AggregateDeclaration *ad,
>          Expression *e1, Declaration *var, int flag = 0) = 0;
>
>      // ===== - - - - - ===== //
>
>      virtual FuncDeclaration *buildDtor(AggregateDeclaration *ad, Scope *sc) = 0;
>      virtual FuncDeclaration *buildCpCtor(StructDeclaration *sd, Scope *sc) = 0;
>
>      // ===== - - - - - ===== //
>
>       virtual CodeGen *codegen() = 0;
> };
>
> getRightThis, buildDtor and buildCpCtor are needed because they "override" the
> global functions with the same name.
>
> About Andrei's query about a general plugin system I don't know how one could be
> architectured. The hooks created for Calypso are specific to C++, so the help I
> could get is simply to be open to those hooks (which aren't really intrusive and
> don't uglify the code except for one or two that could probably be done
> differently:
> https://github.com/Syniurge/Calypso/commit/debd83f49363bf6805573d141a62b25d068d8a14)
>
>
> The problem with arbitrarily limiting where the hooks could occur is that it
> might force the plugins to copy and paste redundantly the base functions, which
> is bad especially for big semantic() functions.
>
> This probably deserves more thought, maybe there's a more elegant way waiting to
> be found.