On Tuesday, 4 February 2014 at 12:46:58 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 4 February 2014 at 11:57:25 UTC, Paulo Pinto wrote:
On Tuesday, 4 February 2014 at 11:13:03 UTC, Don wrote:
Yeah, I dunno what "systems language" means really.
For me it means you can write an OS with it, even if some tiny
parts require the use of Assembly glue.
Pretty close to my definition, but I would add:
- you should be able to write a performant OS with it
- you should be able to use all core language features when
doing so
- the mapping to hardware should be obvious
- thus the runtime should be transparent/easy to grasp
Basically I think a system level language should provide a
minimal library and runtime that you can extend to a OS-level
library that you use for implementing all services on your OS.
I think GC+Phobos should be an extension of such a minimal set
up.
---
I don't think ARC is needed for D, because I think you use RC
only when needed when writing latency sensitive code and use
primarily other strategies (unique pointers, embedded objects
etc).
I do think that interop with C++ is a good strategy. Language
level support for C++11 pointer types would be a good addition
now that they are being used quite extensively. Interop with
C++ is more important than Objective-C.
Having a system library core that is GC free would be nice. I
think this should be done on the name space level. I.e. having
one optimized "core" section that is 100% GC free and one more
extensive "std" section that requires GC to be available.
I don't think it is realistic to have all libraries being
non-GC. It is better to have useful libraries that are somewhat
inefficient than not having them due to complexity issue.
It is better to have a very easy to use and extensible to XML
DOM library than to have a more obfuscated and less extensible
XML DOM library without GC. But the XML parser library should
be GC free.
In Oberon and Modula-3's control over GC tends to be a bit
easier than D's current design, because of a few points:
- No implicit allocations outside NEW
- No closures
- You can use untraced pointers in unsafe modules.
However it would be nice to know if anyone here has real life
experience with Lisp Machines and how was their performance.
--
Paulo
