On Thursday, 22 June 2017 at 09:45:09 UTC, Russel Winder wrote:
I think the term "systems programming language" contains no
actual data, so needs to be retired. In this situation it
provides no reason for conservative garbage collection.
It means the intent of language designer to let you write
operating system with his language, wich implies certain building
blocks available to you. Whether it actually allows it or not is
another question.
Why should any language allow anything outside the type system.
Everything the language allows to compile is allowed by it's type
system, or is a bug in the compiler.
Strong typing means strong typing
Define strong typing then. Pointer is part of the type system,
all casts and operations on it are too. If you pass wrongly-typed
pointer, it won't compile.
Maybe then the fault is having a weak type system, as any
language is that allows ints to be pointers and vice versa.
What's wrong with pointers in a language? You're not forced to
use them, you know? But some tasks force you. If you seek
compile-time verifyability, use different coding patterns \
languages, designed around this intent.
Maybe type systems should be strong and all FFI be by value
with no references to memory allowed?
No, they definetly should not.
Why can't GC use staticaly available type info (all
pointer\reference variables and fields are visible in program
text, why not just scan only them)? I don't know, probably it's
harder, since it requires more cooperation between compiler and
runtime, and increases GC signature (you have to store a huge
list of pointers to all pointers on all stacks (and probably heap
too), and compiler should generate code to populate this list on
every function call). At this point you would be better off with
RAII, wich will be more efficient and explicit and do exactly
what you tell it to do.
