Emil Madsen:
> So these sliders are empty - I take it?
I have just lost them a moment behind the table, sorry.
Through Reddit I have found a group of new slides/videos on LLVM ("2010 LLVM
Developers' Meeting"), some of them are interesting:
http://llvm.org/devmtg/2010-11/
Some comments about the PDF slides:
"Implementing Include-What-You-Use using clang": I'd like still D module system
to be more tidy and import only the "foo" name when you write:
import foo;
So you need to use foo.bar and foo.baz.
And to import "bar" and "baz" names and not the "foo" name when you write:
import foo: bar, baz;
And to import all the names from "foo" (but not the "foo" name itself) using
some syntax with * or "all" or something similar. This makes code more readable
and tidy, and makes the work of D analysis tools simpler.
"Polly - Polyhedral optimizations in LLVM" and "Symbolic Crosschecking of
Floating-Point and SIMD Code": they remind me something said by Walter too
recently. It's stupid to use tons of analysis to extract high-level semantics
from low-level C-style code and then compile it again in asm. It's much better
to give programmers a (little or big) language that allows to directly express
the high level semantics of heavy numerical processing code (that often are
some nested loops on arrays and sometimes on trees/graphs). In D this may be
done using something like this:
mixin(Looper!q{
// high-level numerical processing code here
});
That's not a tidy thing, and it asks programmers to learn a special little
language, but it seems better than the alternative (unless you are able to use
languages like Chapel that allow you to express that semantics already). To
implement that in D you need a compile-time compiler that returns a string that
contains asm{...} or even normal D code. To implement this compile-time
compiler you may "just" need to improve D CTFE so it uses memory better, so it
becomes fast enough.
Example: processing.js is a large JavaScript file that essentially parses Java
code and runs it in JavaScript:
http://processingjs.org/
JavaScript today is much faster than D CTFE, but there is more space for
improvements in D CTFE because the CTFE code is statically typed D, that's much
simpler than JavaScript to run efficiently even in an interpreter.
"Creating cling, an interactive interpreter interface for clang": the D
front-end already contains a partial D interpreter. If this interpreter gets
moved (or copied) inside a library that may be used from D code at runtime,
then implementing a D interactive interpreter becomes simple, and enbedding
Lua/Python/etc inside D becomes less necessary. Having a partial interpreter
inside the compiler and not being able to use it at runtime is a wasted
opportunity.
"Hardening LLVM With Random Testing": eventually DMD/D compilers will enjoy
similar random testing, but probably it's too much early now, it's easy still
to find enough bugs manually.
Bye,
bearophile
