On Saturday, 2 March 2013 at 15:12:40 UTC, Iain Buclaw wrote:
On Mar 2, 2013 3:01 PM, "SomeDude" <lovelyd...@mailmetrash.com>
wrote:
On Saturday, 2 March 2013 at 14:47:55 UTC, David Nadlinger
wrote:
On Saturday, 2 March 2013 at 07:16:04 UTC, SomeDude wrote:
On Saturday, 2 March 2013 at 06:50:32 UTC, SomeDude wrote:
Exactly. This fixed subset would be very limited in
comparison to the
full language (I can imagine something looking a bit like a
smaller Go,
there would probably be no templates at all, no CTFE, maybe
even no
exceptions, for instance), but would be orthogonal, completely
stable in
terms of spec, and known to work. It could be defined for other
real world
usages as well, like embedding in small appliances.
It would also make it easy to bootstrap the compiler on new
platforms.
I don't see how this would help with proting to different
platofrms at
all if you have a cross-compiler.
Yes, the DMD frontend currently isn't really built with
cross-compilation in mind (e.g. using the host's floating point
arithmetic
for constant folding/CTFE), but once this has been changed, I
don't see how
the language used would make any difference in re-targetting at
all.
You simply use another host system (e.g. Windows/Linux x86)
until the
new backend/runtime is stable enough for the compiler to
self-host.
David
And what if you *don't* have a cross compiler ? You compile
the D subset
(bootstrapper) in C and off you go (provided you have a
reasonable C
compiler on that platform).
I don't see how using only a subset of the language would have
an effect on
cross compiling or porting of a compiler self hosted in D.
Your argument
is lost on me some dude...
Regards
For the same reason that most embedded languages use C and not
C++. Obviously it is easier to implement a subset of something
than the full set(at the very least, less work). Most embedded
applications don't have the resources to deal with higher level
constructs(since these generally come at a real cost). For
example, a GC is generally an issue on small embedded apps. The D
core language spec would have to be GC agnostic(in fact, I think
the full spec should be).
I actually prefer to use C++ in embedded apps but use static
classes. It just looks better than traditional C because of the
logical separation it creates.
For the core language spec, things like templates, mixins, and
other useful logical language constructs(these are more like
macros than objects) should be included.
One could propose the following: The core language spec is the
specification of the core language elements of D that can run on
any modern processing unit, compiled as is and without "issue".
That is, say you have a model with functions in it. These
functions are just mathematical calculations and should have no
issue running on any cpu. Hence, mark the module as core(core
language spec, no GC, etc) and porting is not an issue. You know
because it is using the core spec that no advanced language specs
are being used that will break the bank.
Every major revision the core spec can be updated to include new
logical language constructs that were added to the previous major
version.
By being able to mark modules one can gain some benfit:
module mymodule : core, gc, ...;
states that mymodule uses the core language spec, the garbage
collector, and whatever else.
You can think of the "core" language spec as being analogous to
purity. It offers similar benefits because it restricts what can
happen to a smaller universe.
