bloom-lang / bud

Prototype Bud runtime (Bloom Under Development)
http://bloom-lang.net
Other
856 stars 59 forks source link

Ruby constructors required to initialize lattices #294

Open jhellerstein opened 11 years ago

jhellerstein commented 11 years ago

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.

neilconway commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

jhellerstein commented 11 years ago

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

neilconway commented 11 years ago

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.