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

Ruby constructors required to initialize lattices #294

Open
jhellerstein opened this issue Feb 18, 2013 · 6 comments
Open

Ruby constructors required to initialize lattices #294

jhellerstein opened this issue Feb 18, 2013 · 6 comments
Assignees

Comments

@jhellerstein
Copy link
Member

In order, for example, to initialize an lmax, we have to write code like this:

bootstrap do
    # initialize clock to 0.
    cloq <+ Bud::MaxLattice.new(0)
end

At minimum, this needs to be well documented, but it'd better if we had sugar for it.

@ghost ghost assigned neilconway Feb 18, 2013
@neilconway
Copy link
Member

Makes sense. I had thought along the same lines, but I wasn't sure of the right syntax sugar to use. One idea would be to use the wrapper_name as a kind of constructor:

cloq <+ lmax(0)

What do you think? It will require some ugly runtime dispatch to distinguish between the use of the wrapper_name here, vs. the usage in state blocks.

@jhellerstein
Copy link
Member Author

If we want to remain consistent with our initialization of tables, we'd promote Ruby types automatically:

events <+ [['event1'], ['event2']]
cloq <+ 0

Alternatively we could do something OO like:

events <+ table.new(['event1'], ['event2'])
cloq <+ cloq.new(0)

@neilconway
Copy link
Member

We already did implicit promotion for array literals (into set lattices) and hash literals (into map lattices), so I think it should be pretty easy to arrange for implicit promotion of other laterals as well.

@neilconway
Copy link
Member

Although one annoying property is that you can't pass Fixnum literals to a superator (e.g., <+), because of a superator limitation.

@jhellerstein
Copy link
Member Author

Great. But let's leave the issue open until we get a workaround for <+.

@jhellerstein jhellerstein reopened this Feb 21, 2013
@neilconway
Copy link
Member

Another case where the current syntax is kind of annoying is when embedding lattice values inside another lattice -- e.g., as a value in an lmap lattice. Because we don't have parametric types, we can't infer the expected class of the map's values.

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

2 participants