There is Gambit Scheme, MIT Scheme, PLT Scheme, Chicken Scheme, Bigloo, Larceny, ...; then there are all the lisps.
Yet, there's not (to my knowledge) a single popular scheme/lisp on LLVM, even though LLVM provides lots of nice things like:
easier to generate code than x86
easy to make C FFI calls
...
So why is it that there isn't a good scheme/lisp on LLVM?
LLVM provides a lot, but it's still only a small part of the runtime a functional language needs. And C FFI calls are uncomplicated because LLVM leaves memory management to be handled by someone else. Interacting the Garbage Collector is what makes FFI calls difficult in languages such as Scheme.
You might be interested in HLVM, but it's still more than experimental at this point.
For CL: Clasp is a Common Lisp implementation on LLVM, and mocl implements a subset of Common Lisp on LLVM.
For Scheme: there's a self-hosting Scheme->LLVM demo and a prototype LLVM backend for Bigloo Scheme.
For Clojure: there's Rhine, which is a Clojure-inspired lisp.
There's a very small and apparently unoptimised Scheme compiler here:
http://www.ida.liu.se/~tobnu/scheme2llvm/
Taking your question literally,
Writing compilers is hard.
A poor implementation like the one linked above can block new implementations. People going to the LLVM page see that there's a Scheme already, and don't bother writing one.
There's a limited number of people who write and use Scheme (I'm one, not a hater, btw).
There are lots of existing Scheme intepreters and compilers and there's not a screaming need to have a new one.
There's not an immediate, clear benefit to writing a new interpreter using LLVM. Would it be faster, easier, more flexible, better in some way than the other dozens of Scheme implementations?
The LLVM project went with another language (C) to demo their technology, and haven't seen a need to implement a lot of others.
I think that it could be a lot of fun for someone to build an LLVM-based Scheme compiler. The Scheme compilers in SICP and PAIP are both good examples.
Maybe I'm completely misunderstanding the question or context, but I believe that you could use ECL, which is a Common Lisp that compiles down to C, and use the Clang compiler to target LLVM (instead of GCC).
I'm not sure what (if any) benefit this would give you, but it would give you a Lisp running on LLVM =].
One thing to keep in mind is that many of these implementations have C FFIs and native-code compilers that significantly predate LLVM.
CL-LLVM provides Common Lisp bindings for LLVM. It takes the FFI approach, rather than attempting to output LLVM assembly or bitcode directly.
This library is available via Quicklisp.
mocl is a compiler for a relatively static subset of Common Lisp. It compiles via LLVM/Clang.
there's not (to my knowledge) a single
popular scheme/lisp on LLVM
Currently, llvm-gcc is the nearest thing to a popular implementation of any language on LLVM. In particular, there are no mature LLVM-based language implementations with garbage collection yet. I am sure LLVM will be used as the foundation for lots of exciting next-generation language implementations but that will take a lot of time and effort and it is early days for LLVM in this context.
My own HLVM project is one of the only LLVM-based implementations with garbage collection and its GC is multicore-capable but loosely bound: I used a shadow stack for an "uncooperative environment" rather than hacking the C++ code in LLVM to integrate real stack walking.
There is a Scheme2LLVM, apparently based on SICP:
The code is quite similar to the code in the book SICP (Structure and Interpretation of Computer Programs), chapter five, with the difference that it implements the extra functionality that SICP assumes that the explicit control evaluator (virtual machine) already have. Much functionality of the compiler is implemented in a subset of scheme, llvm-defines, which are compiled to llvm functions.
I don't know if it's "good".
GHC is experimenting with a scheme backend and getting really exciting preliminary results over their native code compiler. Granted, that's haskell. But they've recently pushed new changes into LLVM making tail calls easier IIRC. This could be good for some scheme implementation.
Related
I'm interested in seeing how low-level a programmer can go in pure Common Lisp (or, failing that, in implementation-specific extensions). Google hasn't been able to find me much information about this, so I'd like to hear what the experts have to say. This post mentioned a feature of SBCL to define what the author called "virtual operators", but searching for "common lisp virtual operators" didn't yield much. The author also mentioned how hard it was to find documentation about it. Do similar systems exist for other implementations, is there any basis for it in the standard (though considering that such a feature would mostly be used for writing ISA-specific code, portability shouldn't really be high on the priorities for users of it), and where can documentation for features such as this be found?
It would be great to find a way to extend the "programmable programming language" concept to low-level code as well (especially for areas where efficiency is highly important and other libraries written in C or assembly may not be available).
This is very implementation specific and not portable at all.
Yes, SBCL uses VOPs, but other implementations have completely different compilation targets.
If you intend to go low-level in a somewhat portable way, you have two avenues:
Optimize using declarations, inlining, manual unrolling etc., checking your progress with disassemble
Implement a static blob externally, then interface it with an FFI
Simple question really, however there doesn't seem to be a straight answer in the current developer documentation.
Does Swift compile to machine language (i.e. assembly), or does it compile to some intermediary form that then runs on a virtual machine?
(I suspect it does, but being unfamiliar with development in Apple's world it is not clear to me like it may be to someone who is.)
Yes, it compiles to machine language by way of LLVM Bitcode and, as #connor said, runs on top of the Objective-C runtime.
Swift not only compiles to native machine code but it has also been designed specifically for it. Unlike e.g. Java which has been designed specifically as a JITed language. By that I mean Swift achieves best performance with ahead of time compilation while Java benefits most from JITing.
There are many reasons for these design choices but among them is that Swift has a much bigger scope than managed languages like Java. It is supposed to work on both desktop computers and phones with more restricted hardware. You can use Swift as a systems programming language unlike say C#, Java or Python because it has little runtime requirements and allow fairly detailed control of memory. So in theory one should be able to build an OS kernel with Swift which would be difficult with say Java.
Swift, just like objective-c compiles to native code using llvm
A good explanation can be found in Apple's top secret Swift language grew from work to sustain Objective C, which it now aims to replace
From that article, talking about Swift
The compiler is optimized for performance, and the language is
optimized for development, without compromising on either.
Swift, like Objective-C, is compiled to machine code that runs on the Objective-C runtime.
I've had an eye on Parrot for a little while. I understand that it's a virtual machine designed to run a variety of dynamic languages, and to allow a degree of interoperability (e.g. calling a Perl function from a Python script). So, my question is in two parts:
Is Parrot ready for general use? I can see releases are being made, but it's not obvious whether it's something that works well now, or still a work in progress.
Is there any documentation on how to use Parrot? I've looked at links in previous questions, but all the documentation I can find talks about the various levels of Parrot-specific code (PIR, PASM, etc.), or how to add support for more languages. That's great, but how do I run code in existing languages on Parrot? And how do I use code written in another language?
Finally, I don't want to start a flamewar, but I know Parrot is tied up with Perl 6. I prefer Python. I understand Python is a supported language, but realistically, is it perceived as a multi-language VM, or is it a Perl 6 interpreter with other languages included as curiosities?
I'm a Python developer primarily, so I'm biased. But probably in the same direction as you.
Parrot is intended to be a multi-language VM. Its Perl roots show sometimes ("0" is false, the bootstrapping language NQP is a subset of perl), but at the runtime level it's quite language-agnostic.
That said, interop between languages won't be entirely seamless. For example, the String type will most likely be used as a base by all languages, but a Ruby object will probably need wrappers (but not proxies) to act pythonic. There's no story for object interop, at least not so far.
The Python 3 compiler "Pynie" has quite a way to go. Here's the repo http://bitbucket.org/allison/pynie. Maybe you'd like to help out? Right now it's quite young, not even objects yet.
And to answer your actual question:
Sort of. It's not fast and the languages that target it aren't complete, but it won't crash or corrupt your memory.
Normally, you write code in your favourite High Level Language (Python) and compile your .py code to parrot (and from there, you can compile it to native code if you want to). Another dev can write their Perl(6) code and compile it to parrot and, if the compilers have been written with interop in mind, you'll be able to call a Perl function from python
It is still work in progress, but it's mature enough for language implementors and library developers. Caveat: some subsystems are getting reworked (garbage collection, embedding), so there might be some bumps on the road ahead.
Each language needs a compiler that generates code Parrot understands. These compilers are released separately. (see http://trac.parrot.org/parrot/wiki/Languages )
Most languages targeting Parrot are in an early incomplete state, so interoperability isn't a big issue right now. Parrot isn't a Perl 6 interpreter, but Rakudo Perl 6 happens to be one of the most heavily developed compiler that targets Parrot.
Why did Apple decide to use Objective-C for the iPhone SDK and not C++?
It seems strange to me that they would not have chosen a language more popular than Objective-C. Is it because wanted to have something unique in their application which is not otherwise in general use?
Apple merged with NeXT in the '90s and Mac OS X was made from NeXT's operating system, NeXTSTEP. Objective-C was the official language of NeXTSTEP's application frameworks, which became Mac OS X's Cocoa. Mac OS X was then adapted into the iPhone OS, and Cocoa was made into Cocoa Touch. Objective-C has held up pretty well all along the way, and a lot of Cocoa's features would be difficult to translate into C++.
So essentially, it all comes from NeXT.
Objective C began life in 1983 I believe, created by Brad Cox and Tom Love. The idea of Objective-C was to take the purity and low-level control of C and merge that with true object-oriented features that would allow companies to customize system libraries that could communicate with the OOP layer of Obj-C. Essentially, it worked. Obj-C is a strict superset of C, unlike C++ which is most of C, but with many differences.
When Steve Jobs founded NeXT Computer (1985), he brought in some of his former Apple team and others. His best programmers were interested in using a language that expanded on C with the same speed benefits and system control. They chose Objective-C. NeXT eventually wrote many libraries and methods for the base language. These all begin with NS for Next Step. This was the name of the NeXT OS. By 1989 the Next Step OS was considered to be vastly superior to MS Windows or Mac OS, and many computer companies wanted to license it badly. Jobs simply didn't want to go in that direction.
Once Apple wised up and brought Steve Jobs back into the fold (1996), the infusion of Next Step OS into the new Mac OS X was really the key to Apple reviving its software and its programming strategy.
While C++ remains a truly excellent and powerful language, I find that Objective C has less flaws (just my opinion), and Apple's continued work on Cocoa libraries has made the Obj-C language a truly modern power with C underpinnings. Is it better than Java? Not sure. But for what it is primarily designed for (Mac OS, iOS) it is astonishingly good, if a bit overly verbose.
The greatest criticism of Obj-C is the syntactical styling, but any programmer that truly learns the language will quickly learn of its amazing power and seemless fit with all things Mac, iPhone, iPad.
Will any other platforms ultimately adopt Obj-C? not sure, but doubtful. But the Cocoa libraries are truly wonderful.
It's because Objective C has been the de facto language for Mac OS X development before it was Mac OS X. When Jobs left Apple to set up NeXT, the language Objective C was developed as a specific language that wasn't C++ and avoided many of its pitfalls. It therefore makes sense that any portable or consumer equipment (including Apple TV) use Objective C as their primary development language, and dropping down to the underlying C layer when needed for performance or interface issues.
Objective-C adds object oriented programming to C. It was used for NeXT, upon which a lot of OSX is derived. It supports all of C, and is simpler than C++.
http://discussions.apple.com/thread.jspa?threadID=2091191
Note that Objective-C is not a new language. It's been around since 1986 - well before Java or C#!
It has been in general use ever since NeXT, many real-world applications are around that make use of it.
Apple answered this very question here in 2010:
The Objective-C language was chosen for a variety of reasons. First
and foremost, it’s an object-oriented language. The kind of
functionality that’s packaged in the Cocoa frameworks can only be
delivered through object-oriented techniques. Second, because
Objective-C is an extension of standard ANSI C, existing C programs
can be adapted to use the software frameworks without losing any of
the work that went into their original development. Because
Objective-C incorporates C, you get all the benefits of C when working
within Objective-C. You can choose when to do something in an
object-oriented way (define a new class, for example) and when to
stick to procedural programming techniques (define a structure and
some functions instead of a class).
Moreover, Objective-C is a fundamentally simple language. Its syntax
is small, unambiguous, and easy to learn. Object-oriented programming,
with its self-conscious terminology and emphasis on abstract design,
often presents a steep learning curve to new recruits. A
well-organized language like Objective-C can make becoming a
proficient object-oriented programmer that much less difficult.
Compared to other object-oriented languages based on C, Objective-C is
very dynamic. The compiler preserves a great deal of information about
the objects themselves for use at runtime. Decisions that otherwise
might be made at compile time can be postponed until the program is
running. Dynamism gives Objective-C programs unusual flexibility and
power. For example, it yields two big benefits that are hard to get
with other nominally object-oriented languages:
Objective-C supports an open style of dynamic binding, a style that
can accommodate a simple architecture for interactive user interfaces.
Messages are not necessarily constrained by either the class of the
receiver or even the method name, so a software framework can allow
for user choices at runtime and permit developers freedom of
expression in their design. (Terminology such as dynamic binding,
message, class, and receiver are explained in due course in this
document.) Dynamism enables the construction of sophisticated
development tools. An interface to the runtime system provides access
to information about running applications, so it’s possible to develop
tools that monitor, intervene, and reveal the underlying structure and
activity of Objective-C applications.
Historical note: As a language, Objective-C has a long history. It was
created at the Stepstone company in the early 1980s by Brad Cox and
Tom Love. It was licensed by NeXT Computer Inc. in the late 1980s to
develop the NeXTStep frameworks that preceded Cocoa. NeXT extended the
language in several ways, for example, with the addition of protocols.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I develop in Lisp and in Scheme, but I was reading about Clojure and then I want to know, in which cases is better to use it than using Lisp or Scheme? Thanks
This question is impossible to answer. You should use Clojure nearly 100% of the time over CL and Scheme, is what I would say. But that doesn't mean you should listen to me. Others can make a good argument that the opposite is the case.
For me, the syntax and function names in Clojure aesthetically pleasing. Certain Java libraries are invaluable for what I do for data munging and web programming and GUI stuff. Functional programming is challenging and enjoyable. Clojure's flaws are unimportant and outweighed by its benefits in my eyes. Certain intolerable flaws in other Lisps are "fixed" in Clojure, because it's new and it can ignore backwards compatibility. It has a novel and arguably powerful approach to concurrency. The Clojure community is vibrant and welcoming and awesome. All of this says as much about me and what I value as it does about Clojure or other Lisps.
There are libraries for CL and Scheme that don't exist in Clojure or Java. There are people who dislike how Clojure uses too much syntax like [] and {} and want to use parens everywhere. If you want CLOS-style OOP or lots of mutable data structures, another Lisp is arguably better. The JVM is heavyweight, maybe too heavyweight and too much baggage for some people. A lot of Java leaks into Clojure (by design) and this offends some people's sensibilities. The STM and immutable data structures have overheads that make certain things (e.g. number crunching) slower or less elegant. Clojure is new and still rough in certain areas, still rapidly changing and evolving in others. Clojure has yet to pass the test of time, whereas other Lisps already have. Clojure is not a "standard" and some people find a language defined by an implementation to be unappealing. And so on. None of these things matter to me, but they may to you.
This is almost entirely subjective. Which language you should use depends on what you already know, what you are willing to learn, what libraries you want to use, what editors and tools you're comfortable with, what language flaws you're willing to live with and work around and what flaws you can't tolerate, and what helps you get your work done faster, more cheaply, more enjoyably, or achieve whatever your goals are.
Basically, whatever makes you feel warm and fuzzy. Learn them all and then make an informed choice based on your own tastes, and use whichever one you like the best. They're all good.
"Clojure runs on the JVM" means you get the whole cornucopia of Java libraries available. You can make pretty GUIs in Swing, use Apache's Web client or server code, connect a ready-built Sudoku solver... whatever you like.
Another big plus of Clojure is its very polished concurrency support, with about 3 different flavors. If you have a compute-intensive, parallelizable task, Clojure can make it easy. Well, easier.
Update: Another argument. Clojure is pretty strongly functional, so it's a plus if you want to force yourself to think and write functionally.
Clojure should be used when
you need to work with existing java code.
you work with people who are allergic to lisp ("boss, i would like to use a java concurrency library called clojue vs. I would like to re-write this in scheme" [1]
you will be programming for a multi-processor system.
Scheme would be better when:
you need to prove your code is correct. Clojures (call out to java) hinders but does not prevent this.
you are working with people who are allergic to java.
you are developing for a platform with no (new enough) JVM
[1] yes this is a bad bad bad reason. such is the world we live in...
When? As much as possible.
Why? Immutable Data Structures - they really are that good. There are plenty of other reasons too.
ABCL (Armed Bear Common Lisp) and a several of Scheme implementations (KAWA, SISC, ...) are also running on the JVM.
Generally Common Lisp is available in different 'flavors' - ABCL is one of them. Other compile to C, to native code, have extensive development environments or specialized extensions like logic languages or databases.
Clojure OTOH is a new Lisp dialect with emphasis on lazy functional programming and concurrent programming. Its author (Rich Hickey) is a very experienced software developer (he has also written Java and .net interfaces for Common Lisp) and did an excellent job with Clojure. Even though there is some hype around the language, it is worth checking out - it is definitely one of the better Lisp dialects developed in recent years (compared to say Newlisp or Arc).
There are lot's of reasons, some mentioned above. My take is:
The pre-existing libraries. This is such a benefit. I just can't praise this feature enough.
The language is more adapted to the
hardware currently available
(multi-core) and the development
paradigms in use today. It is so much easier to reason about concurrency. The functional aspects are nicer too. You can do functional programming in Lisp, obviously, but it is very easy to break the paradigm unknowingly, unwittingly, and unintentionally.
Cross platform. I run identical
programs on Linux, Windows, and the
Mac. There are lot's of native Lisps
that run across platforms, but
support for all features on all
platforms is a bit spotty and you
constantly have to be on the alert
for things that are missing on one
platform or the other. Likewise,the
libraries you need are not always
consistently supported across
platforms. ABCL and some of the
JVM Scheme implementations have this
consistent support as well, but I
still prefer Clojure because of
point 2.
The nature of the language
community. Let's face it, a lot of
the time the Common Lisp community
is just nasty to deal with. That is
not the case with Clojure at all.
It's easy to get useful help without
the condescension and meanness that
often comes with an answer from the
Common Lisp community. As I have
learned for myself several times,
there is no question so stupid that
you won't get a polite and helpful
reply from the Clojure community.
If I had to find one thing to complain about, it would be IDE support. Maybe it's a question of learning new habits, but it is still easier for me to handle the mechanics of Java development than Clojure. I have tried, and use, Clojure Box, enclojure on NetBeas, La Clojure on Intellij IDEA, and Counterclockwise on Eclipse. They all work fine if you are working primarily from the REPL, but for compilation and execution of class files, they all still feel a bit clumsy.
A subset of Clojure can also compile to javascript
Clojure runs on the JVM (and on the CLR), so there is that.
Clojure's design is concerned with accommodating several styles of concurrent programming safely, deliberately making it difficult to mistakenly write the dangerous, rickety, and often broken concurrency-tolerant code in other languages. If your problem domain involves concurrent programming, Clojure's array of integrated tools for managing concurrency may be a better fit than the implementation-specific or lowest-common-denominator libraries available in other Lisps and Schemes.
One of the greatest things about Clojure is the plethora of libraries you can use with it. You have the power of Java with the expressiveness of Lisp, and that is a badass combination. Clojure is more suited for real world development, because it was made for real world development. With Clojure, you have awesome libraries, awesome modern features, and an amazing community of helpful, like-minded people.
I would have to say that Clojure is a better language, all the way around. That is a highly argumentative statement to make, so I will point out here that this is just my honest opinion.
Clojure rocks.
I'm always trying to learn new languages, so I'm interested in learning Clojure. But, aren't SBCL and some other Common Lisp implementations much, much faster than Clojure? Wouldn't you need considerably more than 4 processors (and a reasonably parallelizable task) to make up for the performance difference between a Clojure app and even a single-threaded SBCL version of the same app?
As a general rule of thumb, I tend to favor Clojure over other languages in cases where either of these fit the bill:
(1). The domain model tends to look very recursive and/or graph-like.
(2). There's an opportunity to leverage a multi-core JVM environment (e.g., Elastic Beanstalk)
(3). There's a fuzzy barrier between data and code (think RPN calculator where nodes can be operators or numbers)
These might sound a bit contrived, but a lot of my work involves dealing with graphs and trees of information, whether it's looking at social networks, some kind of constrained-based optimization, or semantic relationship building. I find that my other favorite language, Ruby, cannot give me the mix of expressiveness and raw computing power compared to Clojure, particularly when it comes to quantitative, recursive, concurrent-type problem solving.