guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

clambda


From: Stefan Israelsson Tampe
Subject: clambda
Date: Sun, 12 Mar 2017 13:41:58 +0100

Hey guilers!

I am playing with my repository Clambda (https://gitlab.com/clambda/clambda)
and plan to revive it. I want to learn rust and the way to do this is to
compile a lispy language that has those features. The way I will do this is
to typecheck and compile to C and from C one can take any compiler to
machine code. That is enough. My first step will be do mainly output
something close to C but scheamy using the idea of type inference that rust
have and I want to showcase the current status to share the fun.

I don't like too much automatic type mangling so + is (A,A) -> A, with
A=int,uint,long,ulong,... Type casts (:) need to be explicit and in ordfer
to cast an uint to an uchar one should use :p: in stead of to do stuff that
means the numbers might not be correctly converted, (lnt a (:p: int 1ui))
e.g. 1ui is an unsigned int. So in case the number in a conversion might be
mangled we use :p:. p is for projection but ather schemes might be applied.
we currently support begin, let, named let's the C operaors and if. We also
introduce a boolean type bool used in if and in order to use integers to
type converge to a bool we may use :p:.  We currently don't support C
looping, use named let's in stead e.g.

scheme@(guile-user)>
...  (test
...   (let lp ((i 0) (s 0))
...     (if (< i 100)
...         (lp (+ i 1) (+ s i 2))
...         s)))


((long (cbegin
        (c: long x_2)   /* declaration and settings shall not be
                           separate chunks BUG*/
        (c= x_2 0)
        (c: long x_3)
        (c= x_3 0)
        (label lp_1)
        (cbegin
          (cbegin
            (cbegin
              (c: int x_4)
              (cbegin
                (c: long x_5)
                (c: long x_6)
                (cbegin c= x_5 x_2)
                (cbegin c= x_6 100)
                (c= x_4 (c< x_5 x_6)))
              (cif x_4
                   (cbegin
                     (cbegin
                       (cbegin
                         (c: long x_7)
                         (c: long x_8)
                         (cbegin c= x_7 x_2)
                         (cbegin c= x_8 1)
                         (c= x_2 (c+ x_7 x_8)))
                       (cbegin
                         (c: long x_9)
                         (cbegin
                           cbegin
                           (c: long x_10)
                           (c: long x_11)
                           (cbegin c= x_10 x_2)
                           (cbegin c= x_11 2)
                           (c= x_9 (c+ x_10 x_11)))
                         (c= x_3 (c+ x_9))))
                     (goto lp_1))
                   (c= ret x_3))))))))

We see that the ouput is in a form that can be quite easilly be translated
 to C.

Also we have error checking in e.g.

cheme@(guile-user)>
1.. (test
2..   (let lp ((i 0) (s 0))
  3..     (if (< i 100)
4..         (lp (+ i 1) (+ s i 2UL))   <- i is long and 2UL is unsigned long
5..         s)))
compile_error(
   type_error(c+, arg2, long, [[line|4], [column|20], [filename|#f]]))

Note we translat (+ s i 2UL) to (+ s (+ i 2UL)) and hence the wrong arg
number. This is a bug.

named lets are restrictive becasue there are no closures  implemented yet,
what we have is a restriction that the application (lp ..) should be at a
tail position. Soo this errors:

cheme@(guile-user)>
(test
  (let lp ((i 0) (s 0))
    (if (< i 100)
        (begin
          (lp (+ i 1) (+ s i 2UL))
           s)
        s)))

compile_error(recur_at_nontail)
BUG we should have a location added here as well will do.

There are plenty more work that one could add to the C output that would
make it more schemy, structs unions, :p:, functions, tail calls via
trampolines, closures, SCM integration e.g. do the right thing when adding
two SCM types etc. When I think the interface has matured I will write
doc's and release a 0.1 version. Then The next step would be to introduce
the rust memory model ontop of this.

Regards
Stefan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]