instead of expanding to (compose ...), or compose should perform a lexical composition

Simple threaded server code

(def doreq (s)
    (let (i o ip) (socket-accept s)
      (thread
    (let e (w/stdin i (read))
      (w/stdout o (prn (eval e))))
    (close i)
    (close o))))
(w/socket s 8080 (while t (doreq s)))

This works fine with reference Arc. Arcueid segfaults with a double free/corruption error when a second connection is made to the port.

We need to implement this properly someday.

I'm running into issues when running configure.

After running the following commands:

sudo apt-get install check pkg-config libgmp-dev autoconf git libtool automake
git clone git://github.com/dido/arcueid.git
cd arcueid
autoreconf -i
./configure

configure quits with the following issue.

checking for a readline compatible library... no

Similarly when running make an issue that is caused by a missing readline.

repl.c: In function ‘main’:
repl.c:203:40: error: ‘S_STDIN’ undeclared (first use in this function)
repl.c:203:40: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [arcueid-repl.o] Error 1
make[2]: Leaving directory `/home/austin/sandbox/arcueid/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/austin/sandbox/arcueid'
make: *** [all] Error 2

repl.c

....
#ifdef HAVE_LIBREADLINE
  readfp = arc_readlineport(c);
  arc_bindsym(c, arc_intern_cstr(c, "repl-readline"), readfp);
#else
  readfp = arc_hash_lookup(c, c->genv, ARC_BUILTIN(c, S_STDIN));
#endif
...

I have both coreutils and readline-common installed in ubuntu which is supposedly where readline is.

I'm slightly unsure what the issue is.

Reference Arc:

arc> (ssexpand 'a!b!c!d)
(((a (quote b)) (quote c)) (quote d))

Arcueid:

arc> (ssexpand 'a!b!c!d)
(((a quote b) quote c) quote d)

Title says it all. Might be that it's confused with the semicolon being a comment character.

Reference Arc:

arc> (withs (x (obj a 1 b 2 c 3) y (obj a 1 b 2 c 3)) (iso x y))
t

Arcueid:

arc> (withs (x (obj a 1 b 2 c 3) y (obj a 1 b 2 c 3)) (iso x y))
nil

But of course... arc_iso can't handle tables yet!

(< 1 2 3) produces wrong number of arguments error

This is just an ugly bit of work and it's probably slow, but I can't be bothered to do it just now. Just a note so we don't forget it.

e.g.:

arc> (do (write "foo\n") (prn))
"foo\012"
nil

the \012 should be \n.

n/t

It seems that the atstring feature of Arc is a bit more subtle than expected. If atstrings are enabled, this means that strings can no longer be compiled merely as literals. Only strings that do not contain an unescaped @ sign can be compiled as such. An atstring can thus be treated as a form of ssyntax, and as such will expand to an sexpr, e.g.

"and so we say (+ 1 1) is @(+ 1 1) right?"

would expand to

(string "and so we say (+ 1 1) is " (+ 1 1) " right?")

I suppose the best place to do this sort of expansion is in the reader.

The join function in arc.arc compiles to an infinite loop:
(def join args
(if (no args)
nil
(let a (car args)
(if (no a)
(apply join (cdr args))
(cons (car a) (apply join (cdr a) (cdr args)))))))

arc> (disasm join)
00000000 env 01 00
00000003 mvrarg 00
00000005 cont 000f (0a)
00000007 lde 00 00
0000000a push
0000000b ldg 01
0000000d apply 01
0000000f jf 0014 (05)
00000011 nil
00000012 jmp 0020 (0e)
00000014 cont 0020 (0c)
00000016 lde 00 00
00000019 car
0000001a push
0000001b ldl 02
0000001d cls
0000001e apply 01
00000020 ret
Literal: 00 Type: cons
(#hash((args . 0) ))
Literal: 01 Type: sym
no
Literal: 02 Type: code
00000000 env 01 00
00000003 mvarg 00
00000005 cont 000f (0a)
00000007 lde 00 00
0000000a push
0000000b ldg 01
0000000d apply 01
0000000f jf 0021 (12)
00000011 cont 001f (0e)
00000013 lde 01 00
00000016 cdr
00000017 push
00000018 ldg 02
0000001a push
0000001b ldg 03
0000001d apply 02
0000001f jmp 003a (1b)
00000021 lde 00 00
00000024 car
00000025 push
00000026 cont 0039 (13)
00000028 lde 01 00
0000002b cdr
0000002c push
0000002d lde 00 00
00000030 cdr
00000031 push
00000032 ldg 02
00000034 push
00000035 ldg 03
00000037 apply 03
00000039 consr
0000003a ret
Literal: 00 Type: cons
(#hash((a . 0) ) #hash((args . 0) ))
Literal: 01 Type: sym
no
Literal: 02 Type: sym
join
Literal: 03 Type: sym
apply
Literal: 03 Type: sym
nil
Literal: 04 Type: sym
nil
Literal: 05 Type: sym
nil
Literal: 06 Type: sym
nil

arc> (eval ``(+ 1 ,,@(list 2 3) 4))
Error: Unbound symbol: _unquote-splicing

Presumably we want the above form to evaluate to (+ 1 2 3 4) the way Common Lisp would, as opposed to the '(+ 1 2 4) that Scheme (erroneously) produces.

Frankly though, I don't like overloading + this way, but well, reference Arc does it that way so I suppose we should do it like that too.

Symbols sometimes get collected when they shouldn't. There seems to be interactions between the garbage collection cycle restarts and all that.

Reference Arc:

arc> (let x nil (maptable (fn args (= x (cons args x))) tbl) x)
((b 2) (a 1))

Arcueid:

arc> (let x nil (maptable (fn args (= x (cons args x))) tbl) x)
((b 2 #<procedure: (anonymous)> #hash((a . 1) (b . 2) )) (a 1))

Why is extra garbage getting into the args?

Reference Arc:

arc> (< 'a 'b)
t

Arcueid:

arc> (< 'a 'b)
Error: Invalid types for comparison

Try to figure out how to get the return code from a popen'd program. Also, see if redirecting stdin to a system by means of call-w/stdin makes sense. We may need to do something like Ruby's popen3 library function

I don't know though, if it's a good idea to emulate the behavior of reference Arc, which inherits this behavior from Racket/MzScheme, which is itself a holdover from the days when there were debates about whether Scheme should be case-sensitive. This is to my mind what Paul Graham calls an onion.

title says it all.

It hangs Arcueid.

arc> (is 1 1 1)
Error: wrong number of arguments (3 for 2)

Arc allows an optional function argument to the table function that is applied with the newly created table. This is not supported by Arcueid.

arc> (table (fn (t) (= (t 'foo) 'bar)))
Error: wrong number of arguments (1 for 0)

arc> ((fn ((n o p)) n) '(1 2 3))
1
arc> ((fn ((n o p)) o) '(1 2 3))
Error: Unbound symbol: _o
arc> ((fn ((n o p)) p) '(1 2 3))
(2 3)

The 'o' should be treated special only if it is the first argument of a pair with two or three elements, denoting an optional argument. The disassembly for

(fn ((n o p)) o)

is
00000000 env 02 00
00000003 pop
00000004 push
00000005 car
00000006 push
00000007 mvarg 00
00000009 pop
0000000a cdr
0000000b push
0000000c mvoarg 01
0000000e ldg o
00000010 ret
Note that mvoarg is used for the p argument, and o is treated as though it were a global symbol. The same code for

(fn ((p q r)) q)

is in contrast:
00000000 env 03 00
00000003 pop
00000004 push
00000005 car
00000006 push
00000007 mvarg 00
00000009 pop
0000000a cdr
0000000b push
0000000c car
0000000d push
0000000e mvarg 01
00000010 pop
00000011 cdr
00000012 car
00000013 push
00000014 mvarg 02
00000016 lde 00 01
00000019 ret
The destructuring bind was properly handled here.

Reference Arc:

arc> (= h (table))
#hash()
arc> (h "foo")
nil
arc> (h "foo" 0)
0
arc> (++ (h "foo" 0))
1arc> h
#hash(("foo" . 1))

Arcueid:

arc> (= h (table))
#hash()
arc> (h "foo")
nil
arc> (h "foo" 0)
"foo"
arc> (++ (h "foo" 0))
Error: Invalid types for addition
Segmentation fault

On standard Arc:

arc> (apply (fn a a) '(1 2) '(3 4))
((1 2) 3 4)

On Arcueid:

arc> (apply (fn a a) '(1 2) '(3 4))
((1 2) (3 4))

Additional arguments should be consed to the end of the argument list, as per Scheme.

In reference Arc:

arc> ((fn (xs acc) (while (= xs (cdr xs)) (assign acc (* acc (car xs)))) acc) '(1 2 3 4 5 6 7) 1)
5040

In Arcueid:

arc> ((fn (xs acc) (while (= xs (cdr xs)) (assign acc (* acc (car xs)))) acc) '(1 2 3 4 5 6 7) 1)
2

Strange that tracing the expansion of the while macro in Arcueid produces the following expansion:

((fn (xs acc) ((rfn g3121 (g3120) (when g3120 (assign acc (* acc (car xs))) (g3121 (= xs (cdr xs))))) (= xs (cdr xs))) acc) '(1 2 3 4 5 6 7) 1)

which correctly evaluates to 5040 in both ref Arc and Arcueid!

Furthermore, expanding the (= xs (cdr xs)) to ((fn nil (assign xs (cdr xs)))) so the expression looks like:

((fn (xs acc) (while ((fn nil (assign xs (cdr xs)))) (assign acc (* acc (car xs)))) acc) '(1 2 3 4 5 6 7) 1)

also produces correct results.

Reference Arc:

arc> (with (x 'xorig y 'yorig) (list ((fn () (= x 2) (= y 3) 1)) x y))
(1 2 3)

Arcueid:

arc> (with (x 'xorig y 'yorig) (list ((fn () (= x 2) (= y 3) 1)) x y))
(1 xorig yorig)

This happens because Arcueid at the moment evaluates arguments from right to left, rather than left to right the way it should.

arc> (with (x 1))
Segmentation fault

We get a segfault. --enable-tracing works, and has been set as default until we can figure out why.

Reference Arc:
arc> (let str (outstring) (w/stdout str (system "echo foo")) (inside str))
"foo\n"

Arcueid:
arc> (let str (outstring) (w/stdout str (system "echo foo")) (inside str))
foo
""

Looks like we have to do a popen(3) instead of system(3), and we'll need to do some substantial trickery to make this happen.

Running suite(s): CIEL
61%: Checks: 13, Failures: 0, Errors: 5
check_ciel.c:61:E:CIEL:test_ciel_int:0: (after this point) Received signal 11 (Segmentation fault)
check_ciel.c:165:E:CIEL:test_ciel_string:0: (after this point) Received signal 11 (Segmentation fault)
check_ciel.c:192:E:CIEL:test_ciel_sym:0: (after this point) Received signal 11 (Segmentation fault)
check_ciel.c:285:E:CIEL:test_ciel_code:0: (after this point) Received signal 11 (Segmentation fault)
check_ciel.c:331:E:CIEL:test_ciel_memo:0: (after this point) Received signal 11 (Segmentation fault)
FAIL: check_ciel
Running suite(s): Built-in Functions
100%: Checks: 9, Failures: 0, Errors: 0

PASS: check_builtins

1 of 9 tests failed

Please report to [email protected]

make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory /home/dido/progs/arcueid/test' make[1]: *** [check-am] Error 2 make[1]: Leaving directory/home/dido/progs/arcueid/test'
make: *** [check-recursive] Error 1

We should fix disp, e.g.
(do (disp "*** redefining ")
(disp 'foo)
(disp #\newline))

produces

"*** redefining "foo#\newline

Optional arguments should be able to refer to previously defined arguments, e.g., for reference Arc:

arc> ((fn (a (o b a)) b) 1)
1

This, however, fails on Arcueid, which interprets the (o b a) as referring to a global variable named a:

arc> ((fn (a (o b a)) b) 1)
Error: Unbound symbol: _a

e.g.

arc> (let d '(0 1 2) d.2)
Error: Unbound symbol: _2

It should be:

arc> (let d '(0 1 2) d.2)
2

Reference Arc:

arc> (is 'nil nil)
t

Arcueid:

arc> (is 'nil nil)
nil

Hi,

I just downloaded latest release (0.0.11) and after compile/install, I'm getting core dump on running 'arcueid' command. The same applies after I pulled latest code from repository.

Here is stacktrace from gdb:

GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/arcueid/bin/arcueid...done.
(gdb) run
Starting program: /opt/arcueid/bin/arcueid
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x001318dc in arc_errexc (c=0xbfffef9c, ex=134592964) at vmengine.c:1239
1239      CPUSH(c->curthread, ex);
Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-24.fc16.4.i686 gmp-4.3.2-4.fc16.i686
(gdb) backtrace
#0  0x001318dc in arc_errexc (c=0xbfffef9c, ex=134592964) at vmengine.c:1239
#1  0x00131a52 in arc_err_cstrfmt2 (c=0xbfffef9c, lastcall=0x13de98 "hash_increment", fmt=0x13d9cc "hash_increment: object of undefined type encountered!") at vmengine.c:1266
#2  0x00125d06 in hash_increment (c=<optimized out>, v=134529812, s=0xbfffee10) at hash.c:263
#3  0x0012609a in arc_hash (c=0xbfffef9c, v=134529812) at hash.c:314
#4  0x001260f5 in hash_lookup (c=0xbfffef9c, hash=134529972, key=134529812, index=0xbfffee8c) at hash.c:421
#5  0x001262af in arc_hash_lookup (c=0xbfffef9c, hash=134529972, key=134529812) at hash.c:482
#6  0x0012c699 in arc_intern (c=0xbfffef9c, name=134529812) at reader.c:39
#7  0x0012dc0a in arc_init_reader (c=0xbfffef9c) at reader.c:740
#8  0x00119ba7 in arc_init_sq (c=0xbfffef9c, stksize=512, quanta=4096, gcquanta=8192) at arcueid.c:720
#9  0x00119c53 in arc_init (c=0xbfffef9c) at arcueid.c:739
#10 0x0804888b in main (argc=1, argv=0xbffff0c4) at repl.c:255
(gdb) q
''''

See for instance

arc> (compile '('(1 2 3) -1) '(nil) nil nil)
((icont 20 ildi -1 ipush inil ipush ildi 7 icons ipush ildi 5 icons ipush ildi 3 icons iapply 1))

The second instruction is of course garbage. It should be INT2FIX(-1), which is 18446744073709551615 in the 64-bit representation used by Ciel.

A bug in garbage collection has been found:

 (let expander 
     (fn (f var name body)
       `(let ,var (,f ,name)
          (after (do ,@body) (close ,var))))

  (mac w/infile (var name . body)
    (expander 'infile var name body))

  (mac w/outfile (var name . body)
    (expander 'outfile var name body))

  (mac w/instring (var str . body)
    (expander 'instring var str body))

  (mac w/socket (var port . body)
    (expander 'open-socket var port body))
  )

In this portion of arc.arc, the compiler creates an environment with the definition of expander, and uses it to define four macros. This environment should be part of the closures that form the definitions of the macros, so expander is bound in them. However, it would seem that the garbage collector doesn't see the parent environment, and garbage collects it.

Here's a minimal example that should work for illustrating the problem

((fn (foo)
  (assign test (fn (x) (foo x)))) (fn (x) x))

Make a unit test involving this code.

arc> (coerce 0 'string)
""
This should be 0!

It seems we have to modify the PORT(fd)->close portion of the file to point to one that uses pclose instead of fclose

arc> (or 1)
Segmentation fault

Seems that the or macro as defined in arc3 fails. Still unclear as to why.

Tried to build this on an ASUS EEEpad Transformer TF-101, Tests for Ciel and hashing fail. Running Debian Squeeze in a chroot.

32-bit systems that use fseeko may have some trouble with large files because file_seek returns an int. On such systems, the seek function should return a bignum instead, and we need to adapt the code to handle this.

(let div2 (fn (x) (/ x 2)) ((compose div2 len) "abcd"))

wrong number of arguments (0 for 378877440)

On pg-arc:

arc> ((testify no) nil)
t

On Arcueid:

arc> ((testify no) nil)
nil

figure out how ac.scm defines this and try to make it as similar as possible.

Reference Arc:
arc> (= x 0)
0
arc> (each elt '(1 2 3) (let y (+ 1 elt) (= x (+ x y))))
nil
arc> x
9

Arcueid:

arc> (= x 0)
0
arc> (each elt '(1 2 3) (let y (+ 1 elt) (= x (+ x y))))
too few arguments

Reference arc makes no such distinction.