
Deca - a systems language based on modern PL principles - nponeccop
http://code.google.com/p/decac/
======
Dn_Ab
I keep a (small) list of active awesome and interesting alternatives to C.
Cyclone has been mentioned already, adding Deca now. the other two I know are:

* ATS <http://www.ats-lang.org/#what_is_ats_good_for>

* Clay <http://claylabs.com/clay/>

~~~
nickik
Dont you know about Rust? If you do why is it not on the list?

~~~
rntz
Rust, while interesting and admirable, isn't quite as low-level as C or Deca.
For example, one of Deca's explicit goals is to not require a garbage
collector or a runtime library. Rust has GC and a light-weight-threading
runtime. So it's not quite a replacement for C, though it's certainly a good
replacement for much of the application-level programming C and C++ are
(unfortunately) widely used for.

~~~
nickik
Ok, thx.

Rust certently has a runtime, cant argue with that.

I thought Rust allows a pretty tight control over allocation with the pointer
hierarchy feature. The GC is designed not to be global and should be pretty
easy ignore. They even have diffrent kinds lambdas to allow the programmer if
the should be allocated on the heap or the stack.

I have not done alot of low level programmig but I want to learn more about
writting Jits and the pretty much need to be rather low level atm there is not
really an alternative then writting them in C (witch sucks).

------
wbhart
It's great to see a language which doesn't ignore 20th and 21st century
programming language theory. It's tremendously boring waiting for the future
to happen.... Anyhow, the type system looks quite interesting.

The choice of LLVM for C interface and performance is also really sensible.

I was surprised to find the language implemented in Scala and Java though.
Perhaps there will be some kind of bootstrap, or maybe the ability to access
the java libraries is intentional.

Without proper documentation it is a bit hard to evaluate this more fully at
this stage. I looked but didn't find many docs yet. Certainly a language to
watch.

~~~
eli_gottlieb
The language is a compiled language, with the JVM being used (originally)
because I wanted a particular parser generator. Deca code can't access Java
libraries because Deca code compiles to LLVM bitcode and thence to machine
code. decac is a compiler, not an interpreter, so it takes the Deca code in
and outputs the LLVM bitcode.

Sorry about the lack of docs. I've been slowly dumping my undergraduate thesis
on this into the wiki, but the language has been evolving and I've been
starting a career. Oy ;-).

~~~
_Y_
Sorry to nag, but how is outputting to LLVM bitcode not interpreting? You are
taking source code and turning it into intermediate form (i.e. LLVM bitcode),
no?

~~~
skrebbel
An interpreter means a program that runs a program, straight from its source
code.

A compiler transforms a program from one format into another. decac does not
execute programs, so it's not an interpreter.

------
eternalban
I greped for "core", "memory manager", "thread", "threading", and "cache", in
the pdf [1]. Am I missing something? I'll probably get flak for this, but this
programmer looks for a modern systems language that directly addresses these
concerns.

 _"The fundamental problems of a systems-programming task or environment are
hard limits on computational resources and a lack of safety protections.
Systems programs have to deal with hardware-imposed limitations on their CPU
time, registers, memory space, storage space on I/O devices, and I/O
bandwidth. They also often have to deal with a lack of the safety features
normally given to most programming environments: garbage-collection of memory,
validation of memory accesses, synchronization primitives, abstracted access
to I/O devices, and transparent multitasking. In fact, the point of systems
programming is usually to create such abstractions and program such
protections."_

Let's take Go, as an example. (Or D). Per above definition, neither is a
"systems programming" language. I know for a fact [2] that Go team would
disagree.

So what is the accepted definition of a "modern" systems programming language?

[1]:
[http://code.google.com/p/decac/downloads/detail?name=Deca%20...](http://code.google.com/p/decac/downloads/detail?name=Deca%20Thesis.pdf&can=2&q=)

[2]:
[http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the...](http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project)

~~~
smosher
I've always taken "systems language" to mean something you might write an OS
in while the Go team takes it to mean something you'd replace Java with.
Whichever way you want to look at it one thing the Go team can't say is that
writing an OS is a "non-systems" problem.

Ideally these would be disjoint sets (in my opinion) but consider this: ASM ->
C -> C++ -> Java -> ... looks like a continuum if you're writing any kind of
Java code, but there's a sharp discontinuity in there if you're writing (say)
a boot loader.

~~~
eternalban
> Whichever way you want to look at it one thing the Go team can't say is that
> writing an OS is a "non-systems" problem.

I do agree with that. (Perhaps it would be helpful to apply the high/low
qualifier to systems languages?)

> Ideally these would be disjoint sets (in my opinion) but consider this: ASM
> -> C -> C++ -> Java -> ... looks like a continuum if you're writing any kind
> of Java code, but there's a sharp discontinuity in there if you're writing
> (say) a boot loader.

Food for thought. I am not arguing for needless complexity (in a language) as
far as the boot up phase is concerned. As far as I understand it, the loader
has its critical, but short lived, life-cycle role to play and then it is out
of the way. Arguably, it is distinct from the OS. Can we not continue to write
them in ASM/C and load operating systems that are written in a more "modern"
language?

~~~
smosher
Personally I'd sooner map the somewhat fuzzier concept of "applications
language" onto that supposed continuum instead. It would put Go in a clearer
category, since it seems to compete with Java and Python better than it does
with C.

I still don't imagine an OS being written in a non-systems application
language, since you've got drivers and performance critical subsystems to
write and things like GC to worry about from the apps-only languages.

~~~
pjmlp
Have a look at Spin or Native Oberon, just to name two operating systems
written in GC enabled languages.

Before C existed, there were already operating systems written in PL/I and
ALGOL, which provide better type safety and memory management as C or C++.

Unix and C success has regressed what meant to be a proper systems programming
language.

There is even a paper from Adele Goldberg about this phenomena, unfortunately
I cannot recall the title now.

------
elehack
Nice to see something actually trying a CLOS-style object system. There are
good ideas in there that don't get enough presence in more recent language
efforts.

~~~
nponeccop
I wonder what happened to SELF-like object systems (slots, prototypes and all
that).

~~~
fanf2
JavaScript

~~~
nponeccop
I mean high-performance implementations. Techniques to (statically) compile
prototypes into efficient code were developed, but they are largely irrelevant
to Javascript. High-performance modern implementations of JS rely on tracing
JIT.

~~~
cyrus_
Pretty sure polymorphic inline caches are standard fare in both Javascript and
other VMs (JVM, CLR, etc.). What other techniques are you referring to?

------
pwpwp
Looks interesting. When I read "modern PL principles" I was afraid to read
about auto-generated getters and setters or something. :P

~~~
nponeccop
Looks like you have never took academia papers seriously :)

------
andrewflnr
I see that "lispy macros" will not be supported, but one of the things that
bugs me about C (in my brief experience) is the verbosity and repititiousness.
Good generics will help, but I'd still like to see a better macro system than
the C preprocessor.

One possible feature that stands out would be macros local to a scope. I
actually did this, defined a macro right in the middle of a function to
automate some error-handling junk. It felt nasty, but not quite as nasty as
copy-pasting or retyping the code, as long as I don't try to re-use the name.
It would be nice if my language handled stuff like this.

This is obviously not a huge issue. The language looks awesome.

~~~
obtu
Macros can be band-aid to overly verbose languages, but plenty of languages
are concise without (whereas C is particularly bad). Higher order functions
and an expressive type system (features it shares with OCaml, Oz, etc) are
where the magic is.

------
zem
ltu discussion: lambda-the-ultimate.org/deca

------
agumonkey
Finally a successor to the now frozen bitc

~~~
nponeccop
What about Cyclone?

~~~
agumonkey
I'm not sure I've even heard the name once. Looks interesting , gradually
safer than C, I like that.

~~~
nponeccop
Well, BitC is not too popular either. Another interesting experiment is
Sing#/Singularity, which is a successful attempt to get IO performance of
FreeBSD despite designing whole OS in modified dependently-typed C# with usual
JIT and garbage collection. The question whether GC is applicable in memory-
constrained environments is still open - I couldn't find a single research in
this direction.

------
mvzink
Looks awesome, especially the type system.

Check out
[http://code.google.com/p/decac/source/browse/examples/list.d...](http://code.google.com/p/decac/source/browse/examples/list.dca)

I'd love to see some discussions on possible/practical shortcomings.

~~~
nponeccop
The type system looks novel, but it doesn't provide controlled effects or
safety as the system for Disciple language described in the "Type inference
and optimization in impure world" paper. So it doesn't qualify as 'awesome'
IMO

~~~
eli_gottlieb
The docs are out of date. I read the Disciple papers about a month after
finishing the thesis, and immediately began working out how to add "back"
(regions were always intended) regions and effects.

~~~
nponeccop
Yeah, I have the same story. I have long wanted a "mutable" type system for my
HNC project ( <https://github.com/kayuri/HNC/wiki>,
<http://code.google.com/p/inv/> ) - it was here on HackerNews about 1 year ago
but got little to no interest. I asked on cstheory.stackexchange.com but got
no useful answers. And then someone pointed my attention to DDC. I knew about
it but I thought it was just an eager revamping of Haskell, just like many
other eager haskells (speculative execution etc) out there.

------
andrewcooke
how do you combine first class functions (and so closures) with no garbage
collection? don't you end up with possibly multiple references to memory and
no way of knowing who owns it?

~~~
nponeccop
If you read the dissertation, it turns out that variables are captured by
value. But even if they are captured by reference - solutions are possible
such as the one in C++11. The decac doesn't provide more memory safety than C,
so there are no problems :) Yet another solution is to inline all higher-order
functions so no closures exist at runtime.

~~~
eli_gottlieb
Actually, this issue is what spurred a major evolution in the language. I
hadn't had a real region or effect system before, and now I do. Why? I needed
some way to register what pointers (regions) are getting captured by an
existential package (aka: a lexical closure). Since regions are now registered
as part of an existential package, the regions captured by a package can be
constrained to suit the region of the stack up to which a package is being
returned.

In short, closures now remember what pointers they capture, and you won't be
allowed to return a closure over a pointer further up the stack than safe.
Other than that, closures capture by value, copying the captured variable into
an environment structure.

------
olliesaunders
Isn’t the name of the language Decac?

~~~
nponeccop
The dissertation says it's Deca. DecaC stands for Deca Compiler.

------
tom626
They should have used more C-like syntax.

~~~
skucherenko
<http://bikeshed.com/>

