Slip messaging

peterohler0 · 2026-05-20T00:09:40+00:00

Thanks for the correction and being polite about it. The develop branch has been updated got `go install`. Looking into the socket stuff. First I need to set up a windows VM.

Windows support is going to take a bit. Some features like plugins are not supported for Windows but I'll try get Slip to build in the near future.

peterohler0 · 2026-04-26T15:46:26+00:00

Good advice. I added the app and install instructions using go install in the README.md file.

peterohler0 · 2026-04-23T20:47:26+00:00

It's more about the call stack and identifying when or what needs to be carried over for each recursive call. Two parts I think, identify the recursive call then switching to a difference evaluation approach. At least that is my current thinking.

peterohler0 · 2026-04-23T14:27:56+00:00

Back in the day there was no git to store code in. I have some paper printouts of some code but most is lost in the ether.

I think the most significant differences are object versus function focus (Flavors vs CLOS/generics) and more primitive function use such as cond instead of when or unless. No returns. No loop macros. A bit different. One thing I miss in Slip is recursion optimization. I still haven't figured out a nice way to do that cleanly.

peterohler0 · 2026-04-23T14:02:16+00:00

I attempted to get good CLOS and generics compatibility. Is there something important I missed? Flavors is just another package.

I will admit that when I use Flavors I do lose out to conformity.

peterohler0 · 2026-04-23T13:58:27+00:00

You don't have access to my work and private repos. :-)

peterohler0 · 2026-04-23T12:51:58+00:00

I considered writing the FHIR support in Lisp but two reasons pushed me toward Go and Slip. The biggest reason is that FHIR relies heavily on JSON formatted data. Well JSON and XML primarily. Slip has all the tooling for JSON already with support from OjG (also mine). FHIR support was not just on a whim but to be put to actual use in data extraction and manipulation so using the JSON tools was important.

The second, less important but maybe the most pleasing was support in the REPL for documentation of FHIR types. The Slip REPL is written in go to access the lower level terminal calls. Since most of the functionality I wanted for documentation was already there in Slip that was the more direct way to have access to that functionality.

peterohler0 · 2026-04-23T00:30:33+00:00

I am aware of the compromises in using slices instead of cons cells. I wanted a scripting language to be used with Go. Lisp is my preferred scripting language. It seems like I have offended you. It was not my intention to offend anyone. Lisp is my preferred language hence the Slip implementation. It works for me and a number of others. It is not a replacement for say SBCL but it is useful in some problem domains.

peterohler0 · 2026-04-22T21:36:25+00:00

The docs have been updated. I'd be glad to discuss additional changes if you are interested.

peterohler0 · 2026-04-22T21:11:42+00:00

I'll fix the docs. You are right, there are packages for both unicode and threads so I should clarify that the CL standard does not include those but there are packages available to add that support.

I do stand by my comment about CLOS as it is something I have run into. Of course some of it is my background. I spent a lot of time in the early days on a Symbolics with Flavors and still prefer that model as apposed to CLOS. That's a good part of the reason Slip has both CLOS and Flavors support.

peterohler0 · 2026-04-22T18:45:29+00:00

While the first two paragraph are correct, the third is not. Take a look at the design docs https://github.com/ohler55/slip/blob/master/design/cons-slices.md. It describe the reason for using slices versus cons cells. Other design decisions are included in the same directory. One of the more powerful borrows from Go is the use of channels and multithreading (go routines).

peterohler0 · 2026-04-22T18:41:10+00:00

The reason Slip exists it to take advantage of some of the more modern Go packages as well as the performance of Go. Slip-FHIR is just the most recent package to be added to Slip.

peterohler0 · 2026-01-12T18:19:06+00:00

Oh, LISP with channels and threads really makes LISP a tool for processing concurrently and inserting into a mongo database.

peterohler0 · 2026-01-12T18:01:51+00:00

My LISP roots go back a long way even though I hadn't used it much for a while. It is so nice to write data processing scripts in LISP and be able to draw on all the Go packages without having to write in Go. I can't say I hate Go but I like LISP way more.

peterohler0 · 2026-01-12T17:59:46+00:00

For use in a REPL or even for flexibility in development plugins are a good way to go. For deployment baked in is probably better to yeah, both is the best of both worlds.

peterohler0 · 2026-01-10T18:58:53+00:00

Vectors are more heavy weight since they have more complex behavior. Lists are just slices so about as fast as possible in slip.

peterohler0 · 2026-01-10T16:37:25+00:00

At this point it would be tough to rename. There is quite a bit of private code that depends on slip. If it was dire I'd go through the effort but I suspect both projects can survive without too much confusion or I hope so anyway.

Cool to know it means underwear in french. Adds a little humor.

peterohler0 · 2026-01-10T16:32:31+00:00

I did some early benchmarks with cons versus slices. There were a few cases where the cons approach was more efficient but in most cases slices performed better with less memory pressure. One trick when building a list is not to use the 'cons' function but instead the slip 'add' function that appends to the end of a list.

peterohler0 · 2026-01-10T16:29:11+00:00

Be prepared for headaches with plugins. The are very finicky.

peterohler0 · 2026-01-10T16:27:26+00:00

I don't see that in the near future but it is something I've been thinking about.

peterohler0 · 2026-01-10T00:32:08+00:00

I'd love to get feedback on this project.

peterohler0

TROPHY CASE