dobkeratops / compiler Goto Github PK

Your ideas about the language awoke my curiousity about some ideas:

As you know, I'm intrigued by the SugarCpp project, syntactically. I've been in the web/nodejs business for a couple of years now, coding LiveScript. I've also attended a bunch of meetups with one of the founders of Erlang, one of the first external (outside of Ericsson LM AB) Erlang users, now a devote Haskell coder, where a lot of focus has been on Haskell. And, I'm since a few months back in to C++-coding. It's basically like writing pseudo code, changing a few characters here and there, and you're good to go.. Well, that's some background, which might hint to my perspectives.

I really like your ideas about two way type inference - not having to template manually for trivial cases, UFCS - perhaps 'both ways' (using a method as a function), matching capabilites, the for..else is such a clever idea - so natural for so many (imperative) cases.

Significant ws + voluntary curlies

• Would you consider significant whitespace? I really do think it makes for much clearer, readable code, and when it's needed, voluntary block braces would really be a heaven sent. If someone wants to dabble with the language and get started, braces can be used through out if wanted, like in C/C++/D/E/JS/Java, well - the bracy ones..
• Would you consider, in that perspective, "newline indented to same level as expression start line" = expression termination. That is as soon as a new line arrives that is not indented, the expression is closed, unless ofcourse it's still in an open parantheses.
  C++ terminates with semicolons. Rust, Pascal etc. separates with semicolons. I must say that unfortunately I do not find the Rust model intuitive - utilizing an empty statement in order to return void! Why clutter up all source for being able to not make an empty statement last in the block? I think then it would even be better to specifically use return, or always return last, and specifically write void in the end instead of ;. There are many other parts of Rust I like a lot, just not the shallow, on the surface, part of semis and braces, in my eyes they obscure.

C++11 as "assembly" / "object code" language

• Also, I believe strongly in using C++11 as intermediary language. The strength of a language for high performant systems coding - in my eyes - is not whether it compiles directly to CPU-specific assembly, through LLVM IR or whatever. No. It's simply that it is more productive, safer, and gets the job done!
  An LLVM code producer could simply be added at a later stage when the language itself has gone through the experimental developing phases, matured and stabilized.
  Developing the language with such an easily readable and recognizable target helps speed up the development process. And I don't think there is any case that can't be covered with C++ as target "object code" since it has all low level capabilities (which is what we want, with added ruggedness).
  For instance open multi methods could be aided with https://github.com/jll63/yomm11, generalized delegates/closures can be implemented so that they compile to two assembly instructions per call. I've got a need for speed, and I don't want to give up clarity for it.
  It would be much easier to make plugins for IDE's, because one can always use the C-code behind the scenes for symbol lookups / search etc. to aid auto completion etc. Any language that could replace C++ "raw syntax" for me, I would make plugins and tools around for.

What I personally would enjoy to see

• compatibility with existing high performant libraries in the de facto fastest system language (C++)
  • This way you can use headers directly, you can benefit from link time optimizations, and even compile time cross unit optimizations based on inlining and templating from a huge existing base.
• readability, clarity of intent (you write a line once, you look at it thousands of times)
• ease of adoption (hence good "how to"-guides for a coders from different languages - with C++ this is dead simple when the output is C++, dabblers can easily use an online compiler to learn for instance.
• tools support (editors, building, meddling with the source in any way
• there are far more CPU targets (embedded etc.) reached through C++ than with LLVM alone.
• with a bit of will, it could be rewritten to support Java, C# or even JavaScript with perhaps some limits in functionality..
• when users know that it "bascially is C++", but better, they'll easier adopt it, because they can back out, by simply generating C++ and continue in that, this makes room for people to dare take the step faster. This is what we've seen in the coffeescript scene - javascript is basically just seen as "the object code of the web" (there's actually a project aiming at defining a subset of javascript so that it can be used specifically as "assembly" without breaking compat - but that's a another story)

When it comes to syntax, I believe keeping the mind open to, as scientifically as possible, identify the absolutely clearest most readable syntax one can come up with for the code that is most commonly written to get the most stable results.

Now, this is all ideas and wishful thinking, in any event, I'm really happy to see your project! New languages are always cool! :-)

It saddens me that I don't have the time required to implement a language from scratch in my current life situation, but I'd be happy to collaborate and contribute on one, and I'd be happy to start using one in practical projects soon.

System: Arch Linux
Clang version: 5.0.1

I tested building test_hack test project and it fails with:

prog.ll:42:25: error: expected comma after load's type
        %r11 = load void(i32)**@_Z10anon_fn_40i.ptr

After searching for the error online, I see that it works with previous versions of LLVM (MLton/mlton#138).
Shouldn't LLVM api be used instead to ensure compatibility?

Sorry if I'm intruding this space with possibly OT but..

I thought I'd get your input on an idea:
I was thinking of another way of typing:

do-stuff(par_a = int, par_b = double 0.7) -> int =
    foo = double par_a * par_b
    bar = par_a * 2
    mut baz = int
    baz = bar / 3
    round a * b

• You get the picture:

ID "=" ( TYPE EXPR | TYPE | EXPR )

Do you see anything that could conflict with such a syntax? It seems to me to be very intuitive. Think about objs of classes..

C++ stylee

SomeClass foo = SomeClass(47, "Stuff");

vs.

foo = SomeClass 47, "Stuff"

This is basically, C++ with the auto keyword implicitly entered (except it would ofc. work in classes too), and then ofcourse with LiveScript call syntax assumed (ID ID, ID ==> ID(ID, ID) - if you get what I mean.)

Thoughts?

Hey! Couldn't find a way to send a message in github - not possible?
Just wanted to check if you've tried out Nim? Looks really promising to me.