I have a C S-expression library floating around

[marcoxa]

I have to check the licensing, but otherwise I guess it could be included.

[lassik]

Nice. If it's permissively licensed, it would be a useful starting point.

[lassik]

The code in this repo so far is ISC-licensed but that's debatable. MIT license is the Lisp custom.

[marcoxa]

Hi

I dug it out. The License is BSD-like. It has to be like that, because the original code is from... Berkeley :)

I will create a separate repo that coulld be linked here after cleaning it up.

[marcoxa]

The repository is at marcoxa/crscl

It suffered from a lot of bit rot and it needs to be reworked. Mostly make it compile (and renaming the API C functions, getting rid of the C++ namespace which may become redundant).

Keep me posted...

Marco

[lassik]

Thank you for the quick turnaround!

typedef struct lispval shows that your library supports the following types:

• symbol
• cons cell
• string
• fixnum
• double

Those are the types that we're planning for POSE as well, which is great.

All of the above types use the obvious C representation, apart from symbols which are more involved:

/* symbol */
struct
{
  char *vpname;             /* print name */
  struct lispval *vshlink;  /* hash link */
  struct lispval *vplist;   /* property list (an alist) */
  short vsindex;            /* used by hasher */
} s;

I assume that's to keep a symbol table which lets you test symbols via eq using their numerical values. You also support an alist; POSE has no way to encode those.

There's a simple mark-sweep GC in the .c file. POSE won't be able to encode shared structure (i.e. circular lists and cyclic graphs) so it may be that malloc/free would be enough for POSE.

Fixnums are stored as int; nowadays that should probably be either int64_t or intmax_t. A complete implementation would support bignums, but C has no standard bignum library. GNU libgmp is probably the closest thing to a standard, but it's not universal.

You also support the following non-standard data types, which I assume come from the application where the lib was used:

• IR node
• Other (custom void* pointer)

The POSE C reader should probably be delivered as two modules:

• Tokenizer (required for all users)
• Parser (optional add-on for users who want it)

That way users can run a code generator to produce custom deserializers that can read the S-expression piecemeal, matching with expected tokens, and don't require the parser's help i building a representation complete in-memory copy of the S-expression on the heap.

The COPYING file has four copies of the BSD license with different Copyright line(s) in each. That would make quite a lot of license boilerplate for a small library. Would all of those license notices still be needed for a pared-down POSE version of the library, or could we manage with only one copy of the BSD license text?

[marcoxa]

Hi

as you noted the library has accrued some baggage over the years. Yes, there are a few things that came from the needs of the earlier applications it was used for.

Feel free to use it as you see fit. As per the licensing, I suppose the last BSD notice (on top; I just added it) will suffice.

All the best

Marco

On Wed, May 5, 2021 at 12:41 AM Lassi Kortela @.***> wrote:

Thank you for the quick turnaround!

typedef struct lispval shows that your library supports the following types:

• symbol
• cons cell
• string
• fixnum
• double

Those are the types that we're planning for POSE as well, which is great.

All of the above types use the obvious C representation, apart from symbols which are more involved:

/ symbol /struct { char vpname; / print name / struct lispval vshlink; / hash link / struct lispval vplist; / property list (an alist) / short vsindex; / used by hasher */ } s;

I assume that's to keep a symbol table which lets you test symbols via eq using their numerical values. You also support an alist; POSE has no way to encode those.

There's a simple mark-sweep GC in the .c file. POSE won't be able to encode shared structure (i.e. circular lists and cyclic graphs) so it may be that malloc/free would be enough for POSE.

Fixnums are stored as int; nowadays that should probably be either int64_t or intmax_t. A complete implementation would support bignums, but C has no standard bignum library. GNU libgmp is probably the closest thing to a standard, but it's not universal.

You also support the following non-standard data types, which I assume come from the application where the lib was used:

• IR node
• Other (custom void* pointer)

The POSE C reader should probably be delivered as two modules:

• Tokenizer (required for all users)
• Parser (optional add-on for users who want it)

That way users can run a code generator to produce custom deserializers that can read the S-expression piecemeal, matching with expected tokens, and don't require the parser's help i building a representation complete in-memory copy of the S-expression on the heap.

The COPYING file has four copies of the BSD license with different Copyright line(s) in each. That would make quite a lot of license boilerplate for a small library. Would all of those license notices still be needed for a pared-down POSE version of the library, or could we manage with only one copy of the BSD license text?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lassik/pose/issues/1#issuecomment-832294565, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5SWXZZUFVNU6VML3POCTTMBZZVANCNFSM44C4PLYA .

-- Marco Antoniotti Somewhere over the Rainbow

[lassik]

Now imported into the c directory. Thank you!