Bloomerlang?
Jamie Brandon
with using Bloom for
http://scattered-thoughts.net/one/1305/106859/184342 and most of the
current code is written in erlang. I'm totally happy to hack on
bloomerlang too if its not yet in a usable state.
Cheers
Jamie
Bill Marczak
Bloomerlang source code is available, but it has extremely limited
functionality. At the moment, it doesn't implement any sort of
message sending or receiving or timestepped execution -- it's
basically a Bloom runtime that only supports tables and some
equivalent of "<=" (no scratches, channels, "<+", "<-", "<~", no built-
in analysis, etc.). However, you should be able to put arbitrary
Erlang code in the rule bodies. So in terms of making it a full Bloom
runtime, it needs some significant work.
Here's the source code: https://bitbucket.org/billmarczak/erlog.
There's a simple all-pairs-all-paths example included with the code,
and instructions on how to compile and run it in the readme. We
developed the Erlang mini-runtime, as well as mini-runtimes in other
languages when we were evaluating what language to write our alpha
release in. I was writing the Erlang mini-runtime with an eye to
enabling Bloom-like syntax in Erlang, rather than attempting to re-
interpret the philosophy of Bloom in the Erlang setting, so although
it's written in Erlang, it may not be very Erlang-ish. When we
decided on Ruby for the Alpha, we decided to not pursue the mini-
runtimes further.
Thanks,
-Bill
On May 18, 3:25 am, Jamie Brandon <ja...@scattered-thoughts.net>
wrote:
Jamie Brandon
It still gives me somewhere to start from. Even plain datalog will
make the router code a lot simpler eg
https://github.com/jamii/erl-telehash/blob/master/src/th_bucket.erl .
Thanks
jamie
Alexis Richardson
Jamie Brandon
Alexis Richardson
On Sat, May 21, 2011 at 11:25 AM, Jamie Brandon
<ja...@scattered-thoughts.net> wrote:
> Alexis, did you intend to write something? :-P
Argh, no that was my phone sending emails on my behalf.
But as I'm here... perhaps you could tell us if you think Bloomerlang
could play nicely with Rabbit (eg for message sending?).
Sticking my neck out, I wonder if Bloom's runtime primitives couldn't
be sugared in Erlang, using something like this:
http://www.rabbitmq.com/blog/2011/05/17/can-you-hear-the-drums-erlando/
I'm also keen to understand what Bloom folks think about the last few
blog posts here: http://biosimilarity.blogspot.com/
alexis
Jamie Brandon
> could play nicely with Rabbit (eg for message sending?).
I don't see why not. I imagine bloom channels can be implemented
nicely using gen_event with various wrappers to hook them into the
outside world.
> Sticking my neck out, I wonder if Bloom's runtime primitives couldn't
> be sugared in Erlang, using something like this:
> http://www.rabbitmq.com/blog/2011/05/17/can-you-hear-the-drums-erlando/
I'm planning to do something along these lines, probably cribbing from qlc eg
bloom:update(
[ #path{from=X, to=Z} ||
#path{from=X, to=Y},
#link{from=Y, to=Z} ])
Joe Hellerstein
Can you take a look at that stuff? Not good for the mailing list to look like a dead zone, and you'd do the best job putting this into context methinks.
J
Bill Marczak
Excerpts from Alexis Richardson's message of 2011-05-21 03:43:18 -0700:
> Jamie
>
> On Sat, May 21, 2011 at 11:25 AM, Jamie Brandon
> <ja...@scattered-thoughts.net> wrote:
> > Alexis, did you intend to write something? :-P
>
> Argh, no that was my phone sending emails on my behalf.
>
> But as I'm here... perhaps you could tell us if you think Bloomerlang
> could play nicely with Rabbit (eg for message sending?).
>
It seems to me that a Bloom implementation in any language could be
augmented with a collection type like "AMQPChannel", or an interface,
that could send and receive messages via AMQP. However, I think we
might lose information about dataflow if we don't model the "exchanges"
in Bloom. It seems (from a cursory inspection of AMQP) that the
exchanges can be pretty much arbitrary in how they route sent messages
to receiver channels. So without modeling exchanges, the assumption our
analysis might have to make is that any dataflow leading in to an
AMQPChannel could pop out of any other AMQPChannel at any other
receiver. I don't think this would be too big of a problem for our
current CALM analysis (we could just axiomatize AMQPChannels as having
inherent asynchrony). However, some of the enhancements to the analysis
that we're working on to detect deterministic orders or atomicity
through message delivery may be affected.
So in conclusion, I think a naive combination would play fine with what
we've currently got, but long-term, as we leverage more dataflow
information in our analysis, we would probably need to look at modeling
AQMP clients and servers -- or, at the very least, exchanges -- in
Bloom.
> Sticking my neck out, I wonder if Bloom's runtime primitives couldn't
> be sugared in Erlang, using something like this:
> http://www.rabbitmq.com/blog/2011/05/17/can-you-hear-the-drums-erlando/
Yeah, I think parse transformers sound like a promising direction for
implementing Bloom operators in Erlang. However, based on the post, the
syntax might not be quite as clean as what we could achieve in a
language like Ruby.
I was initially quite perplexed at the introduction of monads into a
non-lazy language -- because when I think of monads, I think of
constraining the evaluation of side-effects to be monoid-like -- but by
the end of the post I was convinced that monads are also an interesting
way to do aspect-oriented imperative programming.
>
> I'm also keen to understand what Bloom folks think about the last few
> blog posts here: http://biosimilarity.blogspot.com/
>
As for the post about Datalog, I think we're all in complete agreement
about the isomorphism between data in-flight and data in a store.
Indeed, a uniform representation of data is one of the hallmarks of
distributed logic languages. As for the posts about Scala, I'm just
starting to learn Scala, so I don't have anything too intelligent to say
at the moment about the code.
I'm not sure yet what the best way to translate the monad stuff into
Bloom would be -- at the moment, we don't have any comparable
aspect-oriented programming facility in Bloom. As of yet, it's not
something that anybody in our research group has been clamoring for.
However, we have not yet fully tackled the problem of exception handling
in Bloom (and also, in my mind, the modularity question), so we may yet
find it necessary to introduce such a facility for these reasons.
Anyway, one way that I can think of to enable this would be to support
static meta-programming, so users could interpose rules between, or add
additional information to, existing dataflows (in previous research, I
did something similar to this for reconfigurable security in
logic-language-based distributed systems). Of course, it would also
take some work to package this into an intuitive abstraction for
distributed systems programmers.
-Bill
Alexis Richardson
Thank-you. Replies below.
On Wed, May 25, 2011 at 12:59 AM, Bill Marczak <w...@berkeley.edu> wrote:
> Hey Alexis,
..
>
> It seems to me that a Bloom implementation in any language could be
> augmented with a collection type like "AMQPChannel", or an interface,
> that could send and receive messages via AMQP. However, I think we
> might lose information about dataflow if we don't model the "exchanges"
> in Bloom. It seems (from a cursory inspection of AMQP) that the
> exchanges can be pretty much arbitrary in how they route sent messages
> to receiver channels. So without modeling exchanges, the assumption our
> analysis might have to make is that any dataflow leading in to an
> AMQPChannel could pop out of any other AMQPChannel at any other
> receiver. I don't think this would be too big of a problem for our
> current CALM analysis (we could just axiomatize AMQPChannels as having
> inherent asynchrony). However, some of the enhancements to the analysis
> that we're working on to detect deterministic orders or atomicity
> through message delivery may be affected.
>
> So in conclusion, I think a naive combination would play fine with what
> we've currently got, but long-term, as we leverage more dataflow
> information in our analysis, we would probably need to look at modeling
> AQMP clients and servers -- or, at the very least, exchanges -- in
> Bloom.
Exchanges should not impact order so I don't think they present a
problem for CALM. However it would be good to be aware of the overall
ordering semantics of RabbitMQ, if anyone looked at wiring Bloom to
it.
>> Sticking my neck out, I wonder if Bloom's runtime primitives couldn't
>> be sugared in Erlang, using something like this:
>> http://www.rabbitmq.com/blog/2011/05/17/can-you-hear-the-drums-erlando/
>
> Yeah, I think parse transformers sound like a promising direction for
> implementing Bloom operators in Erlang. However, based on the post, the
> syntax might not be quite as clean as what we could achieve in a
> language like Ruby.
>
> I was initially quite perplexed at the introduction of monads into a
> non-lazy language -- because when I think of monads, I think of
> constraining the evaluation of side-effects to be monoid-like
That's a nice way to put it ;-)
> -- but by
> the end of the post I was convinced that monads are also an interesting
> way to do aspect-oriented imperative programming.
There have been several papers written about the relationship between
AOP and monads. Might be of interest...
>> I'm also keen to understand what Bloom folks think about the last few
>> blog posts here: http://biosimilarity.blogspot.com/
>>
>
> As for the post about Datalog, I think we're all in complete agreement
> about the isomorphism between data in-flight and data in a store.
> Indeed, a uniform representation of data is one of the hallmarks of
> distributed logic languages. As for the posts about Scala, I'm just
> starting to learn Scala, so I don't have anything too intelligent to say
> at the moment about the code.
>
> I'm not sure yet what the best way to translate the monad stuff into
> Bloom would be -- at the moment, we don't have any comparable
> aspect-oriented programming facility in Bloom. As of yet, it's not
> something that anybody in our research group has been clamoring for.
> However, we have not yet fully tackled the problem of exception handling
> in Bloom (and also, in my mind, the modularity question), so we may yet
> find it necessary to introduce such a facility for these reasons.
> Anyway, one way that I can think of to enable this would be to support
> static meta-programming, so users could interpose rules between, or add
> additional information to, existing dataflows (in previous research, I
> did something similar to this for reconfigurable security in
> logic-language-based distributed systems). Of course, it would also
> take some work to package this into an intuitive abstraction for
> distributed systems programmers.
Interesting. I have bcc'd some friends and colleagues who might be
interested in commenting on the above.
For my part, the biggest challenge here remains your last point.
alexis