a couple of doc wish-list items

[Leif Johansson]

It would be very nice to have the following:

• a quick conversion guide for sabre/slang -> slurp
• the getting started guide mentions how to expose values and functions but this is missing

[Louis Thibault]

Hi Lief, it's good to hear from you! Thanks for your patience with our slang->slurp migration... I promise it's the last one 😬 ! How are the simulations coming along?

These are great suggestions, and I'll add these to the Wiki ASAP 👍 . Just to clarify:

1. Are you having any trouble converting from slang to slurp? If so, please feel free to let us know in this issue and we'll get it sorted.
2. Just to verify: when you say "expose values and functions", you are referring to binding values/functions to the environment (as in this example), correct?

Thanks for flagging these issues. It's often hard to tell if the docs are clear and complete since we are contaminated by our internal knowledge of the library, so this kind of feedback is super helpful.

[Louis Thibault]

@leifj I've drafted up a page about binding values to the environment. Let me know if I've missed anything important.

[Leif Johansson]

Hi Lief, it's good to hear from you! Thanks for your patience with our slang->slurp migration... I promise it's the last one ! How are the simulations coming along?

Thx :-)

SUNET/tq is coming along nicely

Looking at slurp I think you guys have nailed some of the challenges I've been fighting using lisp as a DSL for building async pipelines so I'm very happy.

These are great suggestions, and I'll add these to the Wiki ASAP . Just to clarify:

1. Are you having any trouble converting from slang to slurp? If so, please feel free to let us know in this issue and we'll get it sorted.

Mostly I've been looking to make sure slurp is mostly on feature-parity with slurp/slang or if I'm supposed to wait before taking the plunge... I can clearly see that slurp is much better than slang/sabre so I understand I'm moving but I am trying to understand the following to decide the right time:

1. is there going to be a "sabre for slurp" or is slurp expected to contain most of whats in sabre+slang
2. is namespaces coming to slurp (or some other project on top of slurp)?
3. what are some of the other "gotchas" I should be aware of - a couple of bullet points about what the major differences are would be gold

2. Just to verify: when you say "expose values and functions", you are referring to binding values/functions to the environment (as in this example), correct?

Yeah that did the trick!

Thanks for flagging these issues. It's often hard to tell if the docs are clear and complete since we are contaminated by our internal knowledge of the library, so this kind of feedback is super helpful.

I know it well... This stuff is made of awsome btw!

[Louis Thibault]

Looking at slurp I think you guys have nailed some of the challenges I've been fighting using lisp as a DSL for building async pipelines so I'm very happy.

Awesome! I'm very glad to hear it!

Mostly I've been looking to make sure slurp is mostly on feature-parity with slurp/slang or if I'm supposed to wait before taking the plunge... I can clearly see that slurp is much better than slang/sabre so I understand I'm moving but I am trying to understand the following to decide the right time:

The short answer is that we are not planning on building a specific lisp dialect. Slurp is intended to be a language-building toolkit rather than a language implementation, proper.

That said, Slang already includes most of the special forms you would expect from a full-blown lisp, so the DIY part of the language should be small.

1. is there going to be a "sabre for slurp" or is slurp expected to contain most of whats in sabre+slang

As mentioned above, Slurp is analogous to Sabre. There are no plans for a new Slang (unless @spy16 is cooking up something I'm not aware of).

2. is namespaces coming to slurp (or some other project on top of slurp)?

Yes, absolutely. This is one of the most important features for me, personally, so it will definitely happen. See #1.

3. what are some of the other "gotchas" I should be aware of - a couple of bullet points about what the major differences are would be gold

Slurp was actually designed to fix a number of "gotchas" in Sabre (namely: decoupling syntactic analysis from evaluation, and decoupling evaluation from the data-structure itself), so there should be fewer gotchas in Slurp than any of its predecessors. Off the top of my head I can't think of anything fundamental.

In short, any gotcha in Slurp is just a case of "we haven't implemented this yet". Right now, the following are in various states of completion:

• Macros (#4)
• The let special form (#2)
• The map and set data-structures (#9)
  I have this issue pretty well mapped out, so I'm feeling ready to tackle implementation as soon as I find some time.
• Concurrency primitives (#3)
  @spy16 and I still have to settle on a final design; In the meantime, you can always write custom Go functions that spawn goroutines under the hood.

Most of these issues should be pretty quick to implement, so if any of them are blocking you, let us know and we can prioritize them.

In case it's helpful, https://github.com/wetware/ww uses Slurp in its pkg/lang subpackage (see internal/cmd/shell for the interpreter setup). It modifies nearly every part of the Slurp stack, including the data-structures, the analyzer, and the special forms, so I think it's a real testament to the flexibility of Slurp's design. Wetware is a big project (and very much WIP), so let me know if you need help navigating, or understanding something in particular.

I know it well... This stuff is made of awsome btw!

😊

SUNET/tq is coming along nicely

This is really cool! What are you using it for?

[Louis Thibault]

@leifj I've implemented the let special form today (see #15).

I'm closing this issue, but feel free to follow up with any questions/comments here.

[Leif Johansson]

Looking at slurp I think you guys have nailed some of the challenges I've been fighting using lisp as a DSL for building async pipelines so I'm very happy.

Awesome! I'm very glad to hear it!

Mostly I've been looking to make sure slurp is mostly on feature-parity with slurp/slang or if I'm supposed to wait before taking the plunge... I can clearly see that slurp is much better than slang/sabre so I understand I'm moving but I am trying to understand the following to decide the right time:

The short answer is that we are not planning on building a specific lisp dialect. Slurp is intended to be a language-building toolkit rather than a language implementation, proper.

That said, Slang already includes most of the special forms you would expect from a full-blown lisp, so the DIY part of the language should be small.

1. is there going to be a "sabre for slurp" or is slurp expected to contain most of whats in sabre+slang

As mentioned above, Slurp is analogous to Sabre. There are no plans for a new Slang (unless @spy16 is cooking up something I'm not aware of).

That is super-clear, thx!

1. is namespaces coming to slurp (or some other project on top of slurp)?

Yes, absolutely. This is one of the most important features for me, personally, so it will definitely happen. See #1.

1. what are some of the other "gotchas" I should be aware of - a couple of bullet points about what the major differences are would be gold

Slurp was actually designed to fix a number of "gotchas" in Sabre (namely: decoupling syntactic analysis from evaluation, and decoupling evaluation from the data-structure itself), so there should be fewer gotchas in Slurp than any of its predecessors. Off the top of my head I can't think of anything fundamental.

In short, any gotcha in Slurp is just a case of "we haven't implemented this yet". Right now, the following are in various states of completion:

• Macros (#4)
• The let special form (#2)
• The map and set data-structures (#9)
  I have this issue pretty well mapped out, so I'm feeling ready to tackle implementation as soon as I find some time.
• Concurrency primitives (#3)
  @spy16 and I still have to settle on a final design; In the meantime, you can always write custom Go functions that spawn goroutines under the hood.

Most of these issues should be pretty quick to implement, so if any of them are blocking you, let us know and we can prioritize them.

Great - and for me the major blocker seems to be namespaces.

It would be great if the doc had a short "conversion guide"; i.e. what to think about when converting from a sabre/slang integration to slurp - major behavioral/datatype differences, pattern X was replaced with pattern Y etc.

In case it's helpful, https://github.com/wetware/ww uses Slurp in its pkg/lang subpackage (see internal/cmd/shell for the interpreter setup). It modifies nearly every part of the Slurp stack, including the data-structures, the analyzer, and the special forms, so I think it's a real testament to the flexibility of Slurp's design. Wetware is a big project (and very much WIP), so let me know if you need help navigating, or understanding something in particular.

I know it well... This stuff is made of awsome btw!

SUNET/tq is coming along nicely

This is really cool! What are you using it for?

An application message-bus without having to run a lot of infrastructure.

[Louis Thibault]

@leifj

Great - and for me the major blocker seems to be namespaces.

Noted. I don't think there's much to it, so I'll try to implement this over the next week or so (though I can't promise anything).

It would be great if the doc had a short "conversion guide"; i.e. what to think about when converting from a sabre/slang integration to slurp - major behavioral/datatype differences, pattern X was replaced with pattern Y etc.

I'll have to think about this because it's been just long enough that I'm having trouble recalling all the changes. @spy16 You're the mastermind behind Slurp's architecture -- any chance I could kick this part over to you (because I think Lief has a point...)?