Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand chain and call to use generic callables #1224

Open
arthurpaulino opened this issue Mar 19, 2024 · 0 comments
Open

Expand chain and call to use generic callables #1224

arthurpaulino opened this issue Mar 19, 2024 · 0 comments

Comments

@arthurpaulino
Copy link
Member

Our chain server support generic chaining callables, rather than just functional commitments. So it would be consistent for us to do the same for the chain and call metacommands.

The main difficulty regards the ability to use the next callable object after chain when it's not a functional commitment because we don't have a reference to it (unlike a hash). In other words, this issue requires further design thinking.

Here are a few options, all suggested by @porcuquine at some point. I'm also including the challenges I perceive for each.

Use bind-last

This will be possible after #970, if/when we choose to implement it. The idea is that the result/callable cons-pair will be available for bind-last to capture it into a variable defined by the user.

An issue is that it's probably not very ergonomic to call bind-last everytime, also forcing the user to come up with names, which motivates the next option.

Use some distinct symbol like !* to refer to the last result of a meta command

This would only be possible within a meta-command, of course. This idea seems to be quite ergonomic.

The problem here is that of an engineering one. We parse symbols in the meta package by knowing beforehand that we should find a symbol in the meta package at the head of the Lurk expression when we see a !.

In other words, this would require a change in the parser.

Be able to refer to functions by their hashes

Then the following should work:

> (lambda () 123)
-> <fun 0x99999 () 123>
> ((fun 0x99999))
-> 123

The issue is that hashes are actually quite long, so the printing representation of functions would become more noisy. It would also require a change in the parser in order to recognize (fun ...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant