Live data from Hacker News

Deca - a systems language based on modern PL principles

code.google.com

41–50 of 59 posts

Re: Deca - a systems language based on modern PL principles

#41

Earlier quoted context omitted.

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

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.

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.

Re: Deca - a systems language based on modern PL principles

#42

Earlier quoted context omitted.

What about Cyclone?

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

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.

Re: Deca - a systems language based on modern PL principles

#43
post #38

Earlier quoted context omitted.

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 in…

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?

LLVM bytecode does not exist after linking - it turns into usual machine code. It is not even a JIT compiler, talk less of an interpreter.

Re: Deca - a systems language based on modern PL principles

#44
post #19

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/

I'm shamelessly adding my own HNC here :) http://code.google.com/p/inv/ https://github.com/kayuri/HNC/wiki I'm moving to GitHub - so 2 repos. "C++ is an evil language used at early stages of HNC development", so it will go away. See also discussions on reddit (submitted not by me lol) http://www.reddit.com/r/haskell/comments/mldzq/hnspl_a_bette... and here on HN long time ago http://news.ycombinator.com/item?id=2116337 (submitted by me)

Re: Deca - a systems language based on modern PL principles

#45
post #37

Earlier quoted context omitted.

> One of the examples in the repository is an implementation of malloc. Right. And (imho) malloc is quite possibly an "old fashioned" way of looking at things: function malloc(num_bytes: nat): @byte A reference to a byte block obtained from specifying the number of bytes! I would like to see the modern memory manger be type aware, have a very rich memory model, and allow for the propagation of application level seman…

> I would like to see the modern memory manger be type aware Because these are system languages, that would happen when hardware is type aware.

It is not necessary. With software replacement for MMU possible (see Singularity OS), hardly any hardware safety support is a requirement nowadays. TAL is the way to go - AFAIK it is possible to make plain x86 assembly dependently typable by attaching proof witnesses to EXE.

Re: Deca - a systems language based on modern PL principles

#46
post #19

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/

See also Vala, Mercury, Felix and Haxe.

Re: Deca - a systems language based on modern PL principles

#47
post #25

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.

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

Re: Deca - a systems language based on modern PL principles

#48

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-ha…

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.

Re: Deca - a systems language based on modern PL principles

#49
post #32
post #26

Earlier quoted context omitted.

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

Yes I know of Rust and think it's very interesting. For most system level programming it should be an excellent choice. It's great that the dearth of systems capable languages is something that is becoming less of an issue. But when i was making the list I was thinking about if the language could possibly be used in an embed context. C is still king there. Rust I believe, is partially garbage collected in a way that…

Garbage-collected languages can still be fast on microcontrollers. When there isn't a lot of memory it only takes a few milliseconds to run a collection cycle. The problem would be when you need real-time and can't deal with the jitter.
Post reply on HN