curimit / SugarCpp

SugarCpp is a language which can compile to C++11.
135 stars 13 forks source link

take some inspiration from rust - match, trait-objects etc? #32

Open dobkeratops opened 9 years ago

dobkeratops commented 9 years ago

Is this project still active, its' interesting;

some of the syntax here is reminiscent of rust, although a lot is different. I'm working on something with similar goals compiling to LLVM (I will upload to github soon) which is essentially C++ + features inspired by Rust,

Here is my project, https://github.com/dobkeratops/compiler

would you be interested in absorbing features inspired by the Rust language:- [1] 2way type inference (may require a more advanced compiler, more semantically aware) [2] expression-based syntax [3] 'match' -pattern matching, similar to switch but more advanced,interacting with tagged-unions (my plan is to make it use equivalent of C++ 'dynamic_cast' [4] 'trait-objects' - decoupling interfaces from data by passing (vtable ptr, data ptr) around [5] 'impl' blocks

UFCS is the other huge feature I'm interested in. I'm also insterested in a lot of the syntactic sugar from scala , especially default constructors. I would like to absorb a lot of what I see here, e.g. "where", "?" (my idea was to invent an operator A?:B analogous to A?A:B). I'm also doing a "for...{ }else{}" which should work nicely with expression syntax but I don't have break yet

ozra commented 9 years ago

Please upload your idea too. I've coded cpp, perl, JS transpilers etc. since 1999, in-house and hack-state use only (for use in in-house projects). But I'm getting more and more interested in something more serious that could be used net widespread, as coffeescript has become for JS. All options popping up are good, later on a "perfect" transpiler/compiler could unfold.. The pro of making a transpiler instead of a compiler is the fact that there are maaany C++ compilers with good optimizations, and so they would be gotten for free for the language, and the fact that one can link / co-compile with straight C++-libs.

2014-12-05 20:50 GMT+01:00 dobkeratops notifications@github.com:

Is this project still active, its' interesting;

some of the syntax here is reminiscent of rust, although a lot is different. I'm working on something with similar goals compiling to LLVM (I will upload to github soon) which is essentially C++ + features inspired by Rust,

would you be interested in absorbing features inspired by the Rust language:- [1] 2way type inference (may require a more advanced compiler, more semantically aware) [2] expression-based syntax [3] 'match' -pattern matching, similar to switch but more advanced,interacting with tagged-unions (my plan is to make it use equivalent of C++ 'dynamic_cast' [4] 'trait-objects' - decoupling interfaces from data by passing (vtable ptr, data ptr) around [5] 'impl' blocks

UFCS is the other huge feature I'm interested in. I'm also insterested in a lot of the syntactic sugar from scala , especially default constructors

— Reply to this email directly or view it on GitHub https://github.com/curimit/SugarCpp/issues/32.

dobkeratops commented 9 years ago

ok - I still want to cleanup a little before i make my code public, i should be able to upload within a day or two. I actually wish I just did a transpiler to C as progress would be faster, as you correctly say all that work is already done - but typically people don't seem to take this as seriously as a 'real compiler'. LLVM also gives you the same optimisation as C++, and it seems to be becoming established as a universal back end for native-code. co-compile/link with C++ libs is still possible infact i'm just using clang itself to compile LLVM from text. Indeed see how in the JVM world scala/java can interoperate, and how Apple have objC/swift.

I was inspired to start this after seeing "jonathan blow's" videos, I'd been looking into Rust for about a year... most of it is amazing but I've become dissatisfied with some choices in it and I think it still diverges from C++ a little too much.

The key part of my own experiment is merging C++ style adhoc overloads+templates with Rust style 2-way inference. (rust makes traits AKA C++'concepts' compulsory, I'd prefer them optional). I think adhoc overload is superior for maths, but beyond that I want something where you can stick to writing independent free-functions (or completely open 'impl' blocks of extention methods) and 'gather' them into an interface - maybe using any parameter as 'this', aswell as providing UFCS- without any syntax changes or 'up-front' choices, e.g. transparently switch between 'sort by type' / 'sort by function' . I might be interested in multi methods too, but thats not a high priority.

Rust also had some awesome sugar for internal iterators - 'do notation' , but they removed it; I want it for data-parallel work. e.g. do par_foreach(items) |x|{...} ... it made passing a lambda to an internal iterator look more like inbuilt syntax. .. I've stuck with Rusts' |x| syntax, it can be quite nice, but would probably prefer (x){...} Local functions are another great thing rust has, and I think I would be good to generalise them to always capture locals - thats' something jonathan blow talks about.

I can see the real problem here is consensus; getting a language going doesn't seem so hard - but making it user-friendly and getting all the surrounding tooling is a big task e.g: IDE autocomplete support, debugger integration. One of the biggest reasons I keep going back to C++ over Rust is IDEs; and of course I will have the same problem with my own language. Most of what I want looks like syntactically legal Rust, its just outside of its' semantics.

As soon as we veer from C++ we all diverge. So I've personally figured trying to stay close to Rust's syntax at least gives me a chance to appeal to fans of that language. On the other hand I'm not so keen on some of their renaming "this=self", "=new", "=box".

whilst we all diverge, out of millions of programmers on this planet it must be possible to find some community with near identical preferences... if just 0.01% of a million people agree on something .. thats still 100 potential user-contributors

I see this specific project is in C# which I haven't tried (and I use linux/mac most of the time); my own compiler is coded in C++, my intent is translating its own source to make it self-host; I'm still missing vtables amongst other things, but I have closures with captures working fine. I've experimented with a limited hack for disambiguating < .. > that would handle a subset of cases without needing a full on GLR parser, I'm wondering if I can roll a limited C++ parser for my own source base - if a language could still directly import some C++ headers directly that would be incredibly useful

my C++ usage tends to be a bit messy, ranging from C to C++14, I'm writing this in the first place because I'm not a fan of idiomatic C++ at all. Originally I started out trying to avoid templates altogether to make the transition to self-hosting easier- but I gave in, so thats' one area where I might do a major cleanup one way or the other .. I'm still not sure which way.. I'm sure most programers will be repulsed by C like link lists, but a compiler doesn't need to free anything and I'm not fussed about performance yet.

I like the idea of adding haskell style currying but worry a little about how this would interact with overloading; one idea here is to actually leverage the OOP syntax: Imagine if A::foo(b) could be curried foo(b)== |x|{x.foo(b)}, and a.foo == |x|{a.foo(x)}. If 'extention methods' were completely open I'd probably lose my fear of them and use them more universally.

There is interest in the Rust community in C++ <-> Rust trans-piling, but you can't represent all of C++ since Rust declares a lot of what C++ is as 'misfeatures'. No overloads, no default params.. I definitely want a path to non-destructively trans-pile C++ <-> [custom language]

Significant whitespace is intriguing , I prefer it on paper but my brain has been conditioned to curly braces; I like what go & rust do omitting the parens around conditions at least - and I like Rusts' "significant semicolon" making the last expression a return value - so the semicolons are less pure noise.

I wonder if a compiler could switch between the two styles easily - I think it would be interesting for a parser to warn if you have incorrect indentation for example

dobkeratops commented 9 years ago

Ok - here is my compiler project, uploaded to github. https://github.com/dobkeratops/compiler

your project appears more polished and our starting points are quite different, but maybe there is scope for convergence, I am open to changing syntax and so on; and I certainly want to absorb way more syntax sugar -however targeting LLVM I have more work to do on the basics.

I guess you have a more solid way of doing similar things by adding loads of specific sugar for various cases whereas i'm trying to re-invent C++'s general purpose template engine around better inference, inspired by rust.

ozra commented 9 years ago

The way I see it, C++ is as good, or better actually, an intermediary language as LLVM IR, or any other representation, for many reason. I'll elaborate in a ticket on your project.

dobkeratops commented 9 years ago

I'm interested to hear any further opinions/info;

Alternate 'back ends' are part of what I want - but my time is limited. I am currently cleaning up 'codegen' with the intent of swapping in alternatives, decoupling ::compile methods from the implementation of CodeGen:: & CgValue, there's still some residual mess. (and of course even if sticking with LLVM I want to use its library, not text intermediate.)

I know C has an interesting #line feature for sane debug info when transpiling