Does a Interpretation-Engine fit in phobos ?

[ZombineDev via Digitalmars-d]

On Thursday, 30 June 2016 at 14:14:41 UTC, Wyatt wrote:
> On Thursday, 30 June 2016 at 10:36:44 UTC, qznc wrote:
>> Ok, seriously, it sounds like an awesome feat, but I don't 
>> think it is necessary to put it into Phobos. First, a dub 
>> package, please.
>
> Agree.  Does Java even have something like that?

I'm afraid you couldn't be more wrong. Both Java and .NET have 
many provide ways for generating and executing byte code at 
run-time. Sometimes this the only way to implement something 
efficiently when runtime reflection is needed. See for example:
https://msdn.microsoft.com/en-us/library/mt654263.aspx,
https://msdn.microsoft.com/en-us/library/mt654267.aspx,
http://openjdk.java.net/groups/compiler/doc/package-overview/index.html,
http://asm.ow2.org/,
https://commons.apache.org/proper/commons-bcel/manual.html,
https://github.com/cglib/cglib,
http://jboss-javassist.github.io/javassist/,
https://www.jetbrains.com/mps/index.html,
https://docs.microsoft.com/en-us/dotnet/core/api/system.reflection.emit and
https://www.postsharp.net/features

Also almost every dynamic language has some sort of eval function 
can be used to evaluate arbitrary code at run-time. This has it's 
security and maintainability challenges, but without any doubt 
there are situations where this is very helpful.

> That's sort of the exemplar for "hopelessly overdone standard 
> library".

LOL, I have never heard about a user complaining that a product 
has too many features, as long as they don't get in the way. 
Instead users complain when something is **not available**, 
because that prevents them from getting their job done. What's 
wrong with having a module in the standard library that you 
personally won't use, but others will find helpful?

There are many ways in which code-generation can interact with 
the language runtime. By including it in the standard library, we 
can ensure that it is thoroughly tested on all supported 
platforms. Of course the other benefit is that it can be used 
from other modules in the standard library for implementing 
various optimizations (e.g. optimizing regex, linear algebra, 
data base queries, etc.) Such functionality has been a huge 
success for .NET. E.g. they enabled some advanced LINQ features 
which are used under the hood of almost every .NET project.

>> Off-topic: Is it possible/feasible/desirable to let dmd use 
>> dub packages?
>
> DMD shouldn't have to download things from the public internet 
> to do its job.

I don't think you understood the question. The question is how 
should DMD's code base be structured / modularized. Of course 
after the DMD is compiled it shouldn't need to use the internet, 
but that's not the point. The question is if it's a good idea to 
split the project in small safe-contained reusable packages. For 
example, that would allow linters to leverage the compiler lexer 
and parser instead of implementing their own, which often can't 
handle all language features.

Another huge area is compiler plugins which are quite popular in 
Rust and .NET
https://doc.rust-lang.org/book/compiler-plugins.html
https://github.com/dotnet/roslyn/wiki/Roslyn%20Overview

About compiler plugins in Rust:
> In a nutshell Rust plugin's let you write normal imperative 
> run-time type-checked Rust code that is executed at 
> compile-time on the AST and they let you do absolutely anything 
> (File/Network I/O, launching threads, ...) including rewriting 
> the AST. People use it to extend the language "as a library": 
> implement coroutines, plain-Rust-to-GLSL libraries that allow 
> you to write shaders in Rust, GPGPU language extensions, and 
> also to write very powerful libraries: regex engines, 
> serialization libraries, database libraries that connect at 
> compile-time to the data-base to validate your SQL queries and 
> give you compile-time errors if they are invalid... EDSLs... 
> All in normal, imperative, run-time Rust code, without shadow 
> worlds (except for the AST API).
- some guy on reddit

.NET Compiler Platform ("Roslyn"): Analyzers and the Rise of 
Code-Aware Libraries:
https://www.youtube.com/watch?v=Ip6wrpYFHhE

>> I guess it would make sense to extract parts of dmd into dub 
>> packages. As a next step, dmd could use those packages instead 
>> of duplicating code.
>
> Does it?  Which parts?  I'm afraid I don't see the benefit.
>
> -Wyatt

LOL x2