Hello Jiri,
Requirements:
- strong static typing, compiled to native code
- ability to statically prove absence of invalid dereferences,
integer overflows, out of bounds array accesses... any condition
that would cause
the program to misbehave
- similar to C (superficially, and in simplicity)
- minimal requirements for runtime support
- programs without dynamic memory must be possible
- ability to call functions written in assembly/C
- ability to write assembly inline and do check it (i.e. not just "put
this string in the generated code")
- builtin support for asynchronous code (fibrils) and tools to
provably avoid races in SMP environment
These requirements seem rather reasonable.
Maybe except the last point which is perhaps too high-level for the core
of the language -- the fibrils specifically, which we only have as a
pure user space concept. The kernel uses regular preemptible threads and
I don't think that the core of the language should really prefer any
specific scheduling paradigm.
However, I can imagine that the core of the language might support (a)
some primitives and intrinsics (e.g. atomics, test-and-set, etc.), and
(b) advanced stack manipulation (e.g. coroutines) that you can use to
implement any scheduling paradigm.
Extending from above (mostly my preferences):
- arbitrary ranges instead of fixed machine types; the compiler will
check that the range can't overflow (as in Ada)
Yes. Although fixed machine types can also come handy, especially if you
can really specify them precisely (e.g. uint32_aligned_little_endian_t).
- owned, borrowed and managed pointers (as in Rust)
- statement-based syntax, packages (as in Go)
- parser plugins for machine code
- contracts (preconditions, postconditions, invariants)
- statically verified (on a function level - a method call is
specified by its interface, no inlining)
- integration with exchangable SMT solver (SMT-LIB 2.0 provides
suitable interface)
- (for an example see Dafny)
- no classes, statically bound methods, type-tagged interface pointers
to provide dynamic binding (as in Go)
- dynamic stack size, unless the maximum can be determined statically
(also Go)
- compiled (at least) to ANSI C
Oh, this would be Christmas :-D But when speaking of the contracts, what
kind of properties do you have on your mind (ownership, safety,
temporal)? What kind of logic?
A few additional ideas of my own:
- some kind of safe meta-programming (something more sane than both the
C preprocessor and C++ templates), at least for the implementation of
the most useful polymorphic functions (e.g. max())
- some basic support for more advanced programming concepts, preferably
implemented only as optional syntactic sugar without a heavy run-time
(foreach loops, iterators, operator overloading, yield [coroutines])
- precise control for type alignment and array/structure packing (with
the possibility to use thr C alignment and packing rules)
- type system with support for physical dimensions (e.g. m*s^-2, bytes,
pages = bytes/PAGE_SIZE, etc.), ideally with safety assignment checks
or explicit conversion functions
- (goes with the previous one) preferably no hard-wired implicit value
and type conversions, implicit conversions only using explicitly
defined conversion functions
- contracts with object ownership and life-cycle notion (as in VCC)
- possibility to easily inline binary blobs as data (not that
necessary, but still a handy feature)
If you don't stop me, I might generate similar ideas for a long time :-)
But, of course, you have the liberty to reject all of them as your own
list is already good for a dissertation or two :-)
Also have a look on Sysel [1]. Granted, the goals and starting points
are quite different, but you might find some inspiration there.
A discussion between Jiri S. and Jiri Z. about designing the perfect
programming language might be rather .. interesting :-)
[1] http://trac.helenos.org/wiki/Sysel
Based on my current idea about syntax and functionality, I am about
halfway done with a basic interpreter (alas with none of the static
checking).
Fantastic. I am definitively looking forward to the result.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
