Embedded systems and transpiling Clojure to Nim

[Alan Moore]

All,

I just ran across Nim (previously Nimrod) which is a garbage collected systems programming language that looks like a suitable target for transpiling Clojure. See:

http://nim-lang.org/

My goal in looking at this is to have Clojure available in native code on real-time embedded systems which is what I work on in my day job. It seemed like targeting LLVM was the way forward with this goal but I have not heard of any progress in this area and it feels large and foreboding. Obviously targeting LLVM gives you a lot beyond just native code but it is limited in the processors it supports. We use Freescale PPC processors which neither LLVM nor most Javascript engines support, or if they do, they do so in a very limited way - e.g. only certain procs, etc.

Having a compiler toolchain that resolves down to C, small executables and no/few dependencies is a huge advantage for using something like Nim.

Is this of interest to anyone else? I'd like to get a proof of concept started. Advice on porting Clojure to other languages would be greatly appreciated :-)

Alan

[Herwig Hochleitner]

I think Nim is pretty cool (conceptionally, haven't used it yet) and full of wonderous features: From the hands down awesome, like the a la carte GC, its AST - based macros and optimizations and effect system to positively weird stuff like its partial case-insensitivity (foo-bar == fooBar == foo_bar == foobar == fOOBAr; wat?) or its method calls (obj.foo(bar) == foo(obj, bar); I don't even). Overall it's appealing to me and certainly seems easier than rust. And, of course, I'm interested in new implementations of clojure.

I'm optimistic about is the possibility to optimize the common case of dynamic features by term-rewriting macros.

However, I have some concerns about it:

- How will nim's static types interact with dynamic features; can enough types for the compiler be generated by inference?

- Could it be that nim is too rich a base as a host language? For the added indirection and complexity: What do we gain over transpiling to C and generating an accurate type map for BoehmGC?

Concerning porting Clojure: I think ClojureScript's experiment of putting protocols/deftypes first in the bootstrapping chain has proven out, so I'd start with figuring out how protocols are best represented (nim's multimethods?). Since nim already has first-class functions, special care has to be taken how they interact with the IFn protocol.

What do you think?

[Gary Trakhman]

Have you guys seen pixie yet?  

It seems like there's overlap for the requirements here.

https://github.com/pixie-lang/pixie

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Herwig Hochleitner]

I have seen it.

PyPy (the platform for pixie) hasn't the reach of even LLVM, let alone plain C, so while there might be overlap in other areas, pixie is a no-starter for non-mainstream hardware.

[Timothy Baldridge]

Well RPython (what pixie is built on) is C...so you get quite a bit of reach there. And I'd be tempted to say that it would be easier to adapt the existing RPython PPC backend to Freescale PPC than it would be to get Nim to play nice with Clojure semantics. 

And let's not forget, RPython can be fast....super fast. Stuff like transducers are slow on non-JIT'ed platforms, work well on JITs like the JVM, and absolutely scream on tracing JITs (like RPython's JITs)
 
Anyway, just some thoughts. 

Timothy

On Fri, May 1, 2015 at 9:10 AM, Herwig Hochleitner <hhochl...@gmail.com> wrote:

I have seen it.

PyPy (the platform for pixie) hasn't the reach of even LLVM, let alone plain C, so while there might be overlap in other areas, pixie is a no-starter for non-mainstream hardware.

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Alan Moore]

You have clearly looked into this more in depth than I have... Thanks for sharing your thoughts. I missed the part about the wonky case insensitivity (truly bizarre and hazard prone IMHO) and have not looked into the type system/inference so I can't comment just yet.

I'm not partial to Nim in particular but I really would like *something* I could use. I wouldn't mind going direct to C if there were some existing GC and immutable DS libraries we could lean on. I think there are enough issues with the transpiling that I wouldn't want to take on those as well.

I too was thinking of following ClojureScript's lead on this but was hoping to have macros available but now that I say it out loud dragging the compiler along for the ride seems like a bad choice given the target environment. Maybe that could be an optional feature for those who have the memory/proc resources.

Let me know how much interest you are likely to have (passing, involved, committed) for this. I appreciate your thoughtful comments - thanks!

Alan

[Alan Moore]

Agreed re: PyPy, Pixie. I got excited when I first saw that project...

As an alternative to straight C I've thought about targeting Lua but also wonder how much that buys you... TBD. I thought I remember reading someone going down that route - anyone?

Alan

[Herwig Hochleitner]

Tim,

I went with what I saw on http://pypy.org/features.html "... runs on Intel x86 (IA-32) , x86_64 and ARM platforms, with PPC being stalled ...". Not sure if that's just for the JIT, but if it were, they would list non-JIT platforms separately, no?

I'm aware, that you use RPython directly, but you still reuse a lot of RPython from PyPy, right? Has pixie been tested on any non-x86 platform yet?

​

Alan,

have you seen https://github.com/raph-amiard/clojurescript-lua ?

[Timothy Baldridge]

Yes, I when we finally get around to doing binary releases I plan on shipping x86_64, x86 and ARM7 binaries, as those are the platforms I have access to. 

The other thing that would hinder adoption to other platforms is most likely the stacklet library (lightweight threads), Pixie uses this fairly heavily and it would probably need to be ported to PPC. 

And yes there is a LuaJIT version of Clojure with support for Terra: https://github.com/ohpauleez/cljs-terra

Doesn't look like it's been maintained recently however. 

Timothy

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christopher Small]

Another possibility is https://github.com/takeoutweight/clojure-scheme. It compiles Clojure to Gambit Scheme to C to metal. It's been a couple of years since there was any activity on that project, but it's possible some attention there could get it where you need it.

Nim seems interesting though. I wasn't really aware of it; only the combinatorial game by the same name.

In any case, I think this is an awesome goal. I'd particularly like to see an option for running Clojure of some ilk on Arduino and the like.

Cheers

Chris

[Raoul Duke]

> Another possibility is https://github.com/takeoutweight/clojure-scheme. It
> compiles Clojure to Gambit Scheme to C to metal.

another possibility is to stab oneself in the eye with a sharp stick.

just sayin'.

:-)

[Christopher Small]

Hah; I have no experience with it. Is it that bad?

At least there's another Lisp in there. Lisps all the way down!

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Raoul Duke]

I just would guess that anything other than an embedded JVM would
be... poor r.o.i., to be polite.

[Christopher Small]

Well... Correct me if I'm wrong, but this entire thread is about compiling Clojure to native targets. Are folks here really talking about embedding a JVM?

Has cljs been poor roi? :-)

Chris

[Raoul Duke]

all i'm trying to say is that the more layers of indirection you add,
the more i won't give you any money on kickstarter.

[Christopher Small]

Both Nim and Pixie ultimately compile to C, and would have just as many layers of indirection.

On Fri, May 1, 2015 at 2:37 PM, Raoul Duke <rao...@gmail.com> wrote:

all i'm trying to say is that the more layers of indirection you add,
the more i won't give you any money on kickstarter.

[Ben Wolfson]

I'd assumed that pixie, like other projects using the RPython toolchain, was itself compiled, but ran as an interpreter. Is that not the case?

You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry]

[Alan Moore]

Yeah... well, I do that on a daily basis working in C/C++ so just about anything is better than what I have going on ATM.

Not all of us have the luxury of day jobs in Clojure. The embedded world is sorely lacking when it comes to levels of abstraction and the world is asking more and more from it. Not everything in the IoT is a phone with an expensive processor and lots of memory, well, unless you want to buy a $700 toaster *on contract*. After slogging mutation around for [self edit] years I'll do just about anything to get me some of that Clojure goodness, starting with a REPL!

I really like Clojure and prefer it over Scheme, if nothing more than to get better data structures... kinda half the point of Lisp to begin with and a huge selling point for Clojure IMO.

Aside - I'm bummed that when I was originally introduced to Lisp there were only car, cdr, etc. Really?! What a turn off. Went down the mutation rat hole and am just now coming out... register access acronyms for function names!?!? What *genius* thought up that bright idea? ;-)

Alan

[Raoul Duke]

> Both Nim and Pixie ultimately compile to C, and would have just as many
> layers of indirection.

aaaaaand they are all insane for anything other than learning
themselves at this point, i'd hazard to guess. but i'm a realist, who
knows. i'd rather go for a real jvm e.g. azul's embedded stuff, or
something like that first if at all possible. :-)

[Raoul Duke]

My goodness, there are other things than Clojure in the universe.
People have been making "native" software with "real" languages for
ages. There's probably even some that are fpish or heck go get an
actual lisp that's been used for ever (franz, allegro, ecl, gambit,
chicken, clozure, tinyscheme, etc.). Or an async or sync dataflow
langauge. Or just lua. etc. etc. etc. :-)

[Christopher Small]

I hear you Alan.

I'm just a hardware hobbyist, but I've been working on a Clojure library for abstracting away some of the differences between different boards (Raspberry Pi, BeagleBone Black, etc): https://github.com/clj-bots/pin-ctrl. Currently, my best bet for Arduino is to use Firmata, but I would love to be able to provide native compilation targets, since that would open up a whole lot.

I'd love to have you join the group, if only to provide feedback (which given your professional experience would be invaluable). We have a chat here: https://gitter.im/clj-bots/chat.

Cheers

Chris

PS Gave a talk about this at ClojureWest, if you're interested: https://www.youtube.com/watch?v=0EQMrpZb7-Y. Most of the talk is actually about the automatic chicken coop door I set up, but a good chunk of it is introduction of pin-ctrl and call to arms for hardware developers as well.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Alan Moore]

In my world the JVM is a non-starter. I don't care if it fits in a ring (http://www.javaworld.com/article/2076641/learn-java/an-introduction-to-the-java-ring.html), culturally it just won't fly. Even Forth has a better chance of making it than the JVM.

Re: Zulu embedded - "Intel/AMD x86. Please contact us for availability of ARM, SPARC or other support packages." doesn't work for us.

Re: Lua, and other lisps, sure we could go that route. We already have Lua in our devices. <shrug> I have a very specific use case in mind that I think Clojure would be especially well suited for that Lua just doesn't help me in the same way. YMMV.

I'm sorry you don't like this question. I can assure you that I'm not some naive wild eyed Clojure fanboy as your responses suggest. I'm simply asking if anyone else is interested in making this possible, I'll put you down in the "no" and "hell no" columns. ;-)

I'm sure Rich got a lot of "aren't there already enough actual Lisps that have been used forever" when he started Clojure. I'm glad they did not deter him.

Take care.

Alan

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- 
"Whatever you can do, or dream you can do, begin it. Boldness has genius, power, and magic in it. Begin it now." - Goethe

[Alan Moore]

Chris,

I'll watch the video and then head on over - talk to you soon.

Alan

[gvim]

I've looked around intermittently for something Clojure-esque to fill
the scripting/sysadmin void and Pixie is the only thing I've come across
which inspires hope. The only remaining issue for me is whether it can
tap into existing (Python) libraries as that's what tends to swing the
vote for scripting languages. With more languages fragmenting the
landscape building a community and sizeable selection of libraries is
that much harder but I hope Pixie rises above the legions of
Lisp-in-language-X exercises one finds on Hacker News by the dozen.

gvim

> <mailto:clo...@googlegroups.com>

> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com

> <mailto:clojure%2Bunsu...@googlegroups.com>

> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to clojure+u...@googlegroups.com

> <mailto:clojure+u...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@googlegroups.com

> <mailto:clojure+u...@googlegroups.com>.

[Fluid Dynamics]

Hear, hear. After cdring down a language-path that long you'll be lucky to get anything more sensible out the other end than "hexapodia is the key insight". ;)

[Kimmo Koskinen]

Hi,

Wanted to mention two more languages, that might be interesting:

Hy: http://docs.hylang.org/en/latest/ (Lisp that targets Python's AST, has Clojure flavoured syntax)

newLISP: http://www.newlisp.org/ (at least FFI seems simple: http://www.newlisp.org/newlisp_manual.html#import)

- Kimmo

[Fergal Byrne]

Hi Alan,

Don't be deterred - it's a great question... Some people are just having a separate conversation in the one thread ;)

I think there is a threshold in your domain, which gives a different answer on each side. 

The easy side is for something RaspberryPi or Arduino-sized (or bigger), where you can - as Chris' wonderful talk demonstrates - simply run a big fat JVM on your hardware. This might be a bit wasteful, but Moore's Law has given us this and we can happily concentrate on the domain (improving life for your chickens) and ignore the hardware.

It's likely you're really asking about the hard side of that boundary, where I guess most of us big-iron software people have little expertise. On this side, you're talking about development in a language which assumes a VM, but you've to execute in a world without it. You've two main choices: a) compile all the way down to metal or b) mimic the VM very thinly.

For a) the Clojure to Gambit Scheme to C route is not insane. All compilers use lots of intermediate representations (DSLs) and compile from one to the next in stages. It's likely that this exact pathway is not optimal, so perhaps we'll need a better one for real embedded Clojure. 

For b) something like Nim might be a fit. It looks to me like combining Clojurescript's Cljs-in-Cljs (or similar in Elixir's) design with an "emitter" for Nim (and using Nim mutable data structures instead of Java's) might work.

You could consider b) as a) in Nim's clothing, by the way.

On the other hand, there is huge effort going into the Javascript engines for embedded systems. Plain Clojurescript could be used here. In terms of how much effort we have to put in, this route might be the one.

By the way, the Erlang people have projects [1, 2] to dig up their ancient, tiny BEAM designs for use in embedded systems and the new massively multicore chips like Parallela. It's not Clojure, but Elixir is a love-child of Clojure and Erlang which might be worth looking at.

Regards,

Fergal

[1] http://www.erlang-embedded.com/about/

[2] https://www.youtube.com/watch?v=tCg1LakJF3g

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Fergal Byrne, Brenter IT

http://inbits.com - Better Living through Thoughtful Technology

http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne

Founder of Clortex: HTM in Clojure - https://github.com/nupic-community/clortex

Author, Real Machine Intelligence with Clortex and NuPIC 

Read for free or buy the book at https://leanpub.com/realsmartmachines

Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014: http://euroclojure.com/2014/

and at LambdaJam Chicago, July 2014: http://www.lambdajam.com

e:fergalby...@gmail.com t:+353 83 4214179

Join the quest for Machine Intelligence at http://numenta.org

Formerly of Adnet edi...@adnet.ie http://www.adnet.ie

[Herwig Hochleitner]

Tim,

I agree that porting enough of rpython to run pixie seems like the best way to get started on a given bare-metal platform. Not least because pypy's contributors would certainly be sympathetic to that effort.

Still, a piece that I'd really love to see is, what I call rclojure: That is, tools for working with an allocation-free subset of clojure (think asm.js); optimizing it based on inference and/or profiling; transpiling it into various various bytecodes that lack a built-in gc; finally a code transformer that can map code with deterministic stack usage into that subset.

That would be useful not only for native code generators, but also for talking to APIs that let you define data formats that you pass, like OpenGL vertex buffers.

[adrians]

Alan, have you looked at Clasp? I'm not sure if CL is something you like, but maybe it has potential for your application.

https://github.com/drmeister/clasp

[Alan Moore]

All,

Looks like I have some more research to do... A year or so ago I looked into going the Python/PyPy route but it's PPC support had previously stalled. I was intrigued by it's interpreter/tracing JIT structure.

It seems to me that there would be a huge win, similar to the Clojure/JVM, ClojureScript/Javascript bump, for targeting Python. This would allow Clojure to integrate with many libraries for devops, big data, scientific and non-traditional IT communities. Pixie looks pretty nice - maybe that will work. TBD.

I think I'd prefer to stay with the Clojure dialect rather than CL/others, partly because I am used to Clojure and partly because one of my use cases requires the same exact code running in an embedded system and in the browser, e.g. don't want to maintain separate versions of key algorithms.

Herwig - I like your suggestion re: rclojure. That seems like a harder but more fruitful approach than other porting options. Do you have any references to this kind of approach in other languages?

Fergal - I agree, many IoT projects are targeting Javascript which could obviously use ClojureScript. I've been looking at the duktape javascript library (supported by the AllSeen Alliance) but have yet to try it out on our target or running ClojureScript generated code. I will also look at Elixir.

Thanks for the feedback everyone. If anyone is interested in taking this topic offline so as not to spam this group with our corner case, let's use Chris' chat as a point of contact (if he doesn't mind):

For those who missed his link, here it is:

https://gitter.im/clj-bots/chat

See you over there.

Alan

On Mon, May 4, 2015 at 1:25 AM, adrians <nma...@gmail.com> wrote:

Alan, have you looked at Clasp? I'm not sure if CL is something you like, but maybe it has potential for your application.

https://github.com/drmeister/clasp

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Christopher Small]

Using clj-bots/chat is fine with me. If there ends up being much noise with respect to this specific native compilation thread vs the project as a whole, we can set up another gitter channel.

Cheers

[Herwig Hochleitner]

2015-05-05 2:04 GMT+02:00 Alan Moore <kahun...@coopsource.org>:

Herwig - I like your suggestion re: rclojure. That seems like a harder but more fruitful approach than other porting options. Do you have any references to this kind of approach in other languages?

It could be argued, that compilers doing escape analysis (which includes Hotspot), have that subset of their input language hidden in them. However, I'm not aware of a dynamic vm that takes that subset and uses it to provide e.g. allocation-free transducers over homogeneous arrays (The latter being, what i estimate as a minimal useful example of an allocation-free language subset). Even rpython assumes a gc for all code, though it certainly tries to eliminate many allocations.

Graal talks about it, so that could mean they might provide infrastructure: https://wiki.openjdk.java.net/display/Graal/Graal+Partial+Escape+Analysis

And value types as planned for a future jdk will certainly help java programmers eliminating allocations.

[Paul deGrandis]

I'm just going to echo a few things -

Timothy and I have talked at length about Clojure-like languages on other platforms.  His ideas and general approach have led to some very promising work (Pixie), and I can personally vouch for RPython as a platform.  My ideas led me to Terra ( http://terralang.org ) - which supports LLVM-based compilation (AOT and JIT), dynamic typing/programming via LuaJit integration, macros and AST manipulation, etc.  Based on this and some needs I was trying to fill, I produced cljs-terra ( https://github.com/ohpauleez/cljs-terra ).  The trade-off is the that library support is a mix of Lua and C libs all intertwined.

There is also the option of ClojureScript on top of Node.js (which I recently used for an IoT system) - which has an ecosystem of libraries.

All of that aside, I still tend to do my low-level work in C and C++14, with some Lua and Terra occasionally.  I also recently used Oracle's Embedded JVM with great success (producing a custom JRE for exactly what I needed).

Cheers,
Paul

[Alan Moore]

Paul,

I'm quite impressed with what you and Timothy have done. I'm taking a third look at Pixie and cljs-terra. Is there any chance that cljs-terra could run on generic lua instead of terra/luajit?

The main problem I'm having is that anything that isn't interpreted (or that generates C/C++ I can cross-compile) is generally not going to support all of the processors in our various hardware products. My use case is functionality that is in common code so it needs to support the lesser brethren in our product lines. Two of our products have a modern SOC (Freescale P1022) which has some support in LLVM.

The faster javascript engines (V8) do not support anything beyond x86/ARM. I've been following Andrew Low's port of V8 to PPC but given the many kinds of PPC, from PS3s to AIX boxen, most are 64bit and so I can't tell if all of our procs are supported. The github page has the 32-bit build failing ATM. There is recent progress as indicated by this issue:

https://github.com/andrewlow/v8ppc/issues/119

I may be able to live with an interpreter since this portion of the code operates at human time scales and is not performance critical. Duktape (single file javascript engine written in C) is looking especially interesting as ClojureScript should "just work". Also, simplicity (especially fewer build/runtime dependencies) is more important than performance.

Obviously it would be great to have a JVM so I'm curious to hear more about your custom JRE, how you cross-compiled it, etc. Do you have any links to share? Unfortunately, this is only of personal interest as the group in charge of our custom platform support/bsp (and available libraries) is dead-set against anything JVM related, sad but true. I pick my battles carefully these days.

Thanks for your feedback - it is very helpful to see what others are doing.

Take care.

Alan

[John Gabriele]

Alan, there was an attempt at compiling Clojure to C, https://github.com/schani/clojurec , but it hasn't been updated in a while.


On Thursday, April 30, 2015 at 11:00:02 PM UTC-4, Alan Moore wrote:

All,

I just ran across Nim (previously Nimrod) which is a garbage collected systems programming language that looks like a suitable target for transpiling Clojure. See:

http://nim-lang.org/

My goal in looking at this is to have Clojure available in native code on real-time embedded systems which is what I work on in my day job. It seemed like targeting LLVM was the way forward with this goal but I have not heard of any progress in this area and it feels large and foreboding. Obviously targeting LLVM gives you a lot beyond just native code but it is limited in the processors it supports. We use Freescale PPC processors which neither LLVM nor most Javascript engines support, or if they do, they do so in a very limited way - e.g. only certain procs, etc.

Having a compiler toolchain that resolves down to C, small executables and no/few dependencies is a huge advantage for using something like Nim.

Is this of interest to anyone else? I'd like to get a proof of concept started. Advice on porting Clojure to other languages would be greatly appreciated :-)

Alan

[Paul deGrandis]

Hi Alan,

Yep, you can cross compile the output from Terra - you can even set it up to output compilations dynamically for any platform you want.  Replacing LuaJIT with Lua would just be a matter of changing the library that you link when building Terra itself.  As Timothy pointed out, Pixie is just going to be C, so you should be able to cross-compile the base for whatever platform you need (someone recently blogged about putting Pixie on the Raspberry Pi).

Cheers,
Paul

[Tyler Anderson]

I really like nim from just tinkering here and there. If i was looking to do what you are i'd go with nim or ocaml. 

Since i'm not exactly the most helpful person here i'd suggest you contact Dennis Felsing his blog is http://hookrace.net/

and his github is https://github.com/def-   he'd be able to tell you just how viable this path is.