search

spy16 / sabre

Sabre is highly customisable, embeddable LISP engine for Go. :computer:
GNU General Public License v3.0
28 stars 5 forks source link

Support goroutine invocation #15

Open lthibault opened 4 years ago

lthibault commented 4 years ago

I'd like to be able to call a function in a separate goroutine using the following syntax:

(go
  (expensive-function arg1 arg2))

A few design considerations:

  1. Separate goroutines might switch to different namespaces (by calling (ns 'some.other.namespace)).
  2. I would like to implement something a Clojure-style value/reference distinction in my own project. In particular, I am considering something like Clojure's Var, which provides a thread-local symbol mapping facility.

What are your thoughts? I think goroutine support is a must-have, but any idea on how the above items might work? Thread-local storage is usually achieved with context.Context in Go, so I'm thinking that Sabre's goroutines should probably have some soft of context attached.

To be clear: I don't think Sabre should support item 2. It would force us to provide immutable data structures ( I think ... 🤔), which adds a lot of complexity and fails to leverage native Go structures like map and slice (which is kind of the point of Sabre). Rather, I think Sabre should be flexible enough that I can implement these in my own language.

spy16 commented 4 years ago

goroutine support is a must-have

Agreed.

Currently none of the Sabre value types are designed with concurrency safety in mind. So will have to get that done first.

I don't think Sabre should support item 2. It would force us to provide immutable data structures

Yep. It sounds very tempting and interesting, but I don't think it's something Sabre should do at the moment..

Need to think about thread local storage..

lthibault commented 4 years ago

Currently none of the Sabre value types are designed with concurrency safety in mind. So will have to get that done first.

Couldn't we take the Go approach and leave proper synchronization to the user?

Exposing thread-safe value types seems to be at odds with our goal of simplicity.

spy16 commented 4 years ago

In most cases yes. But the special handling done for special forms modifies lists in place right now which user will not be able to synchronize.. but I do have a different approach for the special form handling which will fix this..

lthibault commented 4 years ago

@spy16 I'm slowly approaching the point at which I'd like to start working on this. What did you have in mind for fixing the special-form issue?