
Owl Lisp – A purely functional Scheme that compiles to C - rcarmo
https://github.com/aoh/owl-lisp
======
qwertyuiop924
Owl's pretty nice, but I wish it was documented better: I can't actually get
into it, because I have no idea what is valid Owl.

Also, I like how it doesn't call itself Scheme, because it's not Scheme.

This is a problem that annoys me: people seem to think that if you're a
lisp-1, and you follow a few naming conventions, you can call yourself scheme.
That's like calling yourself Common Lisp because you're a lisp-2 with setf.

Scheme is a family of languages, true, but it _does_ have a formal spec, and
if you do not follow it (or at least approximate it), than _you are not
scheme._ Scheme inspired, or scheme derived, maybe, (Racket got this one
right, and changed its name once it started going too far afield, thus saving
us from having to explain to 1000 confused newbies that PLT Scheme isn't
Scheme, and now must only deal with people who _tell_ newbies that Racket is
Scheme) but if you don't meet IEEE or RnRS, or at least Scheme as described in
AIM-349 (the original Scheme: a radically different language from Scheme
today), than you're not Scheme, and if you call yourself that, than you'll
confuse people.

/rant

~~~
nilved
The title is "a purely functional Scheme..."

~~~
qwertyuiop924
No, no, I think Owl did _well_ , because it didn't say that it's scheme, at
least up front. It's honestly more akin to DSSSL than anything else. Saying
that it's "functional scheme" is far less likely to cause confusion than some
of the other things people have done.

EDIT: No, it's not like DSSSL, and it's less cool than I thought it was. It's
still cool, though.

------
hellofunk
I really like the growing interest in making lisps that compile to C, and one
that is purely function is even better. I'd be curious how the GC in this
compares to the fascinating work in Chicken for novel GC in C environments.

~~~
etatoby
I agree that Chicken is based on a brilliant idea that turned out to work
really well in practice. It's a very practical language / implementation.

~~~
jopython
It is not practical enough for me to have a language which does not support
native threads.

~~~
hga
And as I read it sometime ago while searching for Scheme implementations with
native threads, Cheney on the MTA is inherently single threaded.

~~~
justinethier
Not necessarily, it can be extended to support multithreading:

[https://github.com/justinethier/cyclone](https://github.com/justinethier/cyclone)

------
rubiquity
Very cool! By purely functional I'm guessing they mean immutable by default?
Aside from Clojure, what other Scheme/Lisp implementations are immutable by
default? I know Lisp-flavoured Erlang is due to being on the BEAM but I'm
curious what else is out there.

~~~
35bge57dtjku
If I understand what you mean by "immutable by default", then it's all Scheme
implementations, and probably all Lisp as well.

~~~
bakul
What about set-car! set-cdr! vector-set! string-set!

~~~
35bge57dtjku
If you can't easily avoid those, you're not going to be capable of doing much
else anyway.

~~~
bakul
I was responding to "If I understand what you mean by "immutable by default",
then it's all Scheme implementations"; not whether one should or should not
use mutating operations!

~~~
35bge57dtjku
So what does "immutable by default" mean??? Is there even an agreed upon
definition? Because you certainly didn't explain / explain clearly if that's
what you were attempting to do... Clojure has mutable vars and set!, so it
seems Scheme is no worse and fits that guy's definition of IbD.

~~~
bakul
Consider:

    
    
      (define x (vector 1 2 3 4))
      (define y x)
      (vector-set! x 0 100)
    

Should y[0] be 100 or 1?

~~~
35bge57dtjku
That's not really relevant. According to the guy's own definition, Scheme is
as immutable as Clojure, which is what he was specifically asking. They both
have something like set!. If you want to wank off about Scheme not being 100%
immutable, go right ahead, but it's clearly not what was being discussed.

------
lbenes
C++ has many pure functional features that C lacks. For example immutable
methods with const and Lambdas. Wouldn't these features make it easier target
to C++ rather than C? Do these functional features only make it easier for a
human to write functional code or is there some other reason these Lisps all
use C?

~~~
wyager
If you're writing a compiler, you're going to want to explicitly manage
closures and function pointers anyway.

------
Jeaye
It's not purely functional if it supports side effects all willy-nilly. Scheme
sans mutation (which is not the same as Racket, since Racket's stdlib still
supports mutation) is no more purely functional than modern C++ sans mutation.

With that said, purely functional programming is arguably just a hassle; I
tend to think that "functional-first," as I call it, programming, a la
Clojure, is a good balance between practical and pure. In this way, side
effects are adhoc, but all definitions are immutable by default.

------
zer01
aoh also wrote the very awesome Radamsa fuzzing engine in it -
[https://github.com/aoh/radamsa](https://github.com/aoh/radamsa)

~~~
wepple
Yeah, unfortunately my only exposure to owl lisp is wishing that Radamsa
_wasnt_ written in it so I could understand/modify radamsa better.

Radamsa is seriously awesome.

~~~
zer01
...and that's 100% my experience with it too :-/

Awesome fuzzing engine but modifying it is not for the faint of heart.

