Reference Manual diagram conventions

2015-03-25 Thread Alexis


Hi all,

The Symbols section of the PicoLisp Reference Manual:

http://software-lab.de/doc/ref.html#symbol

seems to have the convention:

   +-+-+ | cdr | car | +-+-+

whereas the Numbers and Lists sections has the convention:

   +-+-+ | car | cdr | +-+-+

which, in an English-language left-to-right document, is what i 
would expect.


Is there a particular reason for the former?


Alexis.
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Reference Manual diagram conventions

2015-03-25 Thread Rick Hanson
I think (I’m speculating, that is) that the confusion was due to the
unusual (but not incorrect) choice of having key/val pairs stored in symbol
property lists as

  +-+-+
  | VAL | KEY |
  +-+-+

where VAL is the the CAR position and KEY in the CDR position. There is not
right or wrong about this, that’s just how it works. I find this point very
interesting. I believe it has something to do with streamlining the
picolisp (C or asm) code regarding properties, but I don’t know for sure.
Alex?
​


Building picolisp on (some) BSDs

2015-03-25 Thread Rick Hanson
Hello, list!

I thought I should write a few words on some information I’ve gleaned
trying to build picolisp on some of the BSDs. There are people on this list
with more experience than I with both BSD and picolisp; so please comment
upon what I have to say, and weigh in where you feel, or know, that it is
necessary, for the benefit of everyone. This is a learning experience for
me. I am not in a position to write authoritatively. I will try to
accurately report my findings, but please especially point out where I am
wrong or being misleading. (I would have done this unintentionally, of
course.)

*Bottom Line*

Starting from the picolisp 3.1.9.13 source — the latest as of this past
weekend (more about this below) — I was able to successfully build and
unit-test pil32 on the following BSDs: FreeBSD 10.1, OpenBSD 5.6, and
NetBSD 6.1.5. Also, I was able to successfully build and unit-test pil64 on
FreeBSD 10.1. (AFAIK, only FreeBSD, among the three, has bootstrap support
(with pil32) to build pil64, and I only looked at the bootstrapping option
for building pil64.)

The following sections just spell out some detail about the builds. A quick
note before that: on each BSD box in question, I had to install gmake. This
shouldn’t be a surprise — picolisp builds need GNU make, and the BSDs’
stock make is BSD, not GNU.

*FreeBSD 10.1*

I was aiming for a pil64 build in this machine, so I started with a 64-bit
(amd64) FreeBSD 10.1 box. First, I had to build pil32 (for the bootstrap
build).

On a fresh FreeBSD 10 box you won’t have gcc, so you need to install that.
I used pkg for that (i.e. I didn’t build gcc from ports). Its interface is
installed in /usr/local/bin/gcc48, by the way.

But, why install gcc? After all, clang (the stock compiler) is a “drop-in
replacement for gcc“, right? Wrong. If you try to build pil32 with clang,
you will be greeted with the following errors.

apply.o.log:apply.c:15:40: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
apply.o.log:apply.c:67:43: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:91:37: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:159:40: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:299:34: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:663:37: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:698:34: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:736:37: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
flow.o.log:flow.c:786:37: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
main.o.log:main.c:720:34: error: fields must have a constant size:
'variable length array in structure' extension will never be supported

Yes, that’s right folks, clang does not support dynamically sized arrays
and never will (!) as unequivocally stated by their error message: “extension
will never be supported“ (“never”? really?). (Take that picolispers! This
reminds me of the taunting Frenchman in Monty Python’s Holy Grail: “No
chance, English bedwetting types!”)

But gcc does support this; so, back to gcc. The objects build fine with gcc,
but then we run into a problem in the link step.

gcc48 -o ../bin/picolisp -m32 -rdynamic main.o gc.o apply.o flow.o
sym.o subr.o big.o io.o net.o tab.o -lm
/usr/local/bin/ld: skipping incompatible //usr/lib/libm.so when
searching for -lm
/usr/local/bin/ld: skipping incompatible //usr/lib/libm.a when searching for -lm
/usr/local/bin/ld: cannot find -lm
/usr/local/bin/ld: skipping incompatible
/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/libgcc.a
when searching for -lgcc
/usr/local/bin/ld: skipping incompatible //usr/lib/libgcc.a when
searching for -lgcc
/usr/local/bin/ld: cannot find -lgcc
/usr/local/bin/ld: skipping incompatible
/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/../../../libgcc_sso
when searching for -lgcc_s
/usr/local/bin/ld: skipping incompatible //usr/lib/libgcc_s.so when
searching for -lgcc_s
/usr/local/bin/ld: cannot find -lgcc_s
/usr/local/bin/ld: skipping incompatible /lib/libc.so.7 when searching
for /lib/libc.so.7
/usr/local/bin/ld: cannot find /lib/libc.so.7
/usr/local/bin/ld: skipping incompatible /usr/lib/libc_nonshared.a
when searching for /usr/lib/libc_nonshared.a
/usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a
/usr/local/bin/ld: skipping incompatible /usr/lib/libssp_nonshared.a
when searching for /usr/lib/libssp_nonshared.a

Re: Reference Manual diagram conventions

2015-03-25 Thread Danilo Kordic
AFAIK advantage is:
  varPtr = Val;
​as seen in @src/sym.c doSet:
  val(data(c1)) = data(c2);


Re: Reference Manual diagram conventions

2015-03-25 Thread Alexander Burger
Hi Alexis,

 The Symbols section of the PicoLisp Reference Manual:
 http://software-lab.de/doc/ref.html#symbol
 seems to have the convention:
 
+-+-+ | cdr | car | +-+-+
 
 whereas the Numbers and Lists sections has the convention:
 
+-+-+ | car | cdr | +-+-+
 
 which, in an English-language left-to-right document, is what i
 would expect.

No, this is not the case. In all these documentations, cells are always
displayed in the form

  +-+-+
  | CAR | CDR |
  +-+-+

The left half of the cell is the CAR, and the right half the CDR. Just
as the cell resides in memory. The CAR is at the lower address, and the
CAR at the higher.


The important point is that the pointer *TO* a PicoLisp item may point
to different parts of the cell:

1. In case of a pair (list cell) it points to the address of the CAR

  Pair
  |
  V
  +-+-+
  | CAR | CDR |
  +-+-+

2. In case of a symbol, it points to address of the CDR part of the
   cell, which holds the value of the symbol:

Symbol
|
V
  +-+-+
  |  |  | VAL |
  +--+--+-+

Note that still the CAR part of that cell is on the left side. It holds a 
pointer
to the symbol's tail. The CDR part of the cell holds VAL, the symbol's value.

3. Finally, a bignum cell is pointed to its middle

 Bignum
 |
 V
  +-+-+
  | DIG |  |  |
  +-+--+--+

   That is, it points to an address *inside* the cell, not to its
   starting address.

Confusing?
♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe