Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Comments: Projects' status & task list #3
added a commit
Jun 29, 2015
Basically, Flame.Loyc is an F# library that converts Loyc syntax trees into Flame's (in-memory) IR.
Flame.Loyc's feature support is pretty basic at this point (no exciting stuff like generics, lambdas and events), but it can compile simple "hello, world"-like programs, such as this.
I'd love to hear your thoughts on this. Cheers!
Wow, this Flame thing is really something else! Where's the documentation
On Fri, Aug 21, 2015 at 3:27 PM, Jonathan Van der Cruysse <
Well, yeah. Flame is kind of similar to Loyc. They're both managed, high-level compiler-ish frameworks.
My goal with Flame is to do for high-level languages what LLVM does for low-level languages. Unlike LLVM, which seems almost eager to discard non-essential information as soon as possible, Flame does not lower high-level constructs such as
Which brings us to the awkward issue of the currently nonexistent D# docs. D#'s basically a dialect of C# that started off as a subset of C#, which then slowly expanded its syntax and semantics until it was a subset no more - though it does retain a lot of similarity to C#. I know I should get around to documenting D# someday, but I feel that's a pretty daunting task which will take up a lot of time that would be better spent squashing bugs and improving Flame's middle-end. Maybe I should write a short tutorial or comparison with C# that covers the relevant bits instead?
It sounds like our goals are pretty much the same. Most of the Loyc code is currently focused on syntax because I guess I kind of felt like that was the "beginning", and I like to start things at the beginning. I haven't been able to find funding or other developers to help, so I haven't been able to flesh out other ideas. You're only the second person to contact me about Loyc - the first one wants to help, but has a full time job and little time to spare.
As you can see on the home page, I have a rudimentary plan for the semantic parts - a Standard Imperative Language (not yet designed), a Multi-Language Standard Library (not yet started).... and Enhanced C# which sounds a lot like D# - EC# is a superset of C#, but like D# it diverges quite a bit from C#, and it breaks backward compatibility in small ways.
I am unusual in that I tend to write my documentation before I write the implementation. Thus I've written multiple articles and documents about EC#, I just haven't published them "formally" yet. In particular, have a look at my "EC# for language pundits.txt" (download raw, since GitHub won't word wrap). The rules of EC# have changed slightly since I wrote the document... remind me to review it sometime. And since none of the compiler has been written except LeMP, most of EC# is subject to change. Even LeMP isn't really complete: I need a solid plan for allowing multiple macros to affect the same construct at the same time, e.g. imagine two attributes attached to a method that cause macros to insert different things into the method body. LeMP doesn't currently support that.
BTW I recently finished a pattern-matching macro for Loyc trees, which you'll probably find useful. See the unit tests for examples. I also made a macro for constructing a sort of "object-oriented" algebraic data type (examples in unit tests). How did you find out about Loyc? The first LeMP article?
Anyway, perhaps there is some way we could join forces? Could EC# and D# be combined into one language? Without good documentation of D# (and Flame), I can't guess. So I hope you'll read my unpublished article about EC#, then compare & contrast them for me.
BTW a lot of the things "EC# for language pundits" says about macros are wrong, e.g. the syntax for defining macros has changed, there is not currently any macro hygiene system, it's called
I've read up on EC# as you suggested. The way D# has diverged from C# mostly seems like a small subset of the features EC# has added. I'll try to break down the relevant points of convergence and divergence between D# and EC# here.
A (maybe not so) brief comparison between D# and EC
Things that D# and EC# agree on:
D#-specific stuff that C#/EC# don't do:
C#/EC# stuff that D# doesn't have:
Things that D# and C#/EC# do differently:
I'll elaborate on this because it's more of a philosophical topic to me.
Expanding templates is easy, but I would much rather tackle the few remaining template expansion use-cases with generics and hidden delegate parameters. This may sound like a performance killer, but that need not be the case if the generated code is sufficiently optimized.
For example, consider this D# snippet:
Compiling this with
Obviously, that's a major performance killer. Now. let's try compiling with the (albeit experimental and maybe even dangerous)
Same source code, different set of optimization passes.
which would then be lowered to:
And the optimizer would make calling this "performance disaster" a breeze.
Now, I don't think "the compiler will take care of it for me" a lot when I write code. I do, however, believe that this is one of those rare situations where the compiler itself can at first generate suboptimal code because it knows for sure that specific instantiations of said code sequence will be optimized in the release build.
D# and EC# seem highly similar to me, especially if the right macros are used. Unifying them doesn't look all that hard to me, really. I do wonder, though, if we wouldn't be better off considering how features such as non-nullable references will fit in first. Last time I checked, the Roslyn folks were still arguing over how to add those to C# without breaking the
In response to your question: actually, I stumbled upon Loyc in a Google search results page, though I can't quite recall the specifics of my search query.
I'm also actively interested in developing a cross-platform standard library which can then be linked (and LTO'ed) with a platform-specific "primops" library. However, I don't see that happening any time soon without some intermediate format - not quite unlike SIL, though I would require said format to have an efficient, easy-to-parse binary representation: parsing source code has always proven to be prohibitively expensive in my experience.
Also, this comment ended up being way longer than I intended. Sorry about that.
I'm reconsidering the reassignment of LoycCore to core.ecsharp.net. Although LoycCore is the core libraries for EC#, it seems like it's just as appropriate to name it after "Loyc", it's has been published on NuGet as LoycCore for a couple of years, and I don't have an alternate name in mind ... maybe I should switch back to core.loyc.net after all. Any thoughts @jonathanvdc?
I've never operated an actual website myself, so I'm not sure if I'm qualified to comment on these matters. That being said, from a user's perspective: I don't think the exact URL matters that much, as long as it's consistent. I don't think switching back to core.loyc.net will hurt right now. But bear in mind that broken links are a pain. So if you're going to change Loyc's domain name, then I recommend you do it sooner rather than later.
By the way, I've recently created a Flame.Front NuGet package. I couldn't find any Loyc.Ecs and LeMP packages, so I just included the Loyc libs in the Flame.Front package. Right now, I'm using my own Loyc fork (which includes BLT) to build those libs, which complicates things a bit. I reckon I could just move the BLT format to a different repository if you were to create a Loyc.Ecs package, though.
Oh, and I'm using AppVeyor CI to build and publish NuGet packages automatically whenever I push a git tag. Perhaps that makes sense for Loyc as well. I could help you with writing an