Python implementation

[jking]

In order to learn bloom-lang internals and fully understand the language I'm taking a stab at writing an implementation of bloom-lang in Python.

My work can be found at https://github.com/agentultra/knockblock (a temporary name perhaps)

I'll be presenting what I've learned so far at pycon.ca on November 9.

My first step is to try and get my interpreter running with just lattices and channel data types (I tried working on tables but judging from the paper on BloomL, it seems I can get some small programs written using just these structures... please correct me if I'm barking up the wrong tree here). I've got the basic lattices worked out and a meta-class interface for defining new ones. I'm working on the program meta-class and rules parser at the moment.

In terms of compilers and interpreters I've never written anything more than simple scheme parsers and stuff. I understand the principles but this will be my first project getting down to the details. Any help or advice is greatly appreciated. Also, any recommended reading would be helpful -- I've been devouring what I can find on Datalog and have been working my way through the list of papers on the BOOM website.

Cheers

[Joe Hellerstein]

Sweet! I didnt start by writing a parser either, I just made up a sublanguage of Ruby and did some violence with it :-). My recommendation is to start with somthing that parses as legal Python and worry about syntax niceties later.

Stay in touch.

Sent from a telephone.

[jking]

Exactly my plan of action.

I'm reading up on http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-173.pdf

I'm having trouble finding a specification of Datalog; there are lots of papers on it but I can't find a formal description of the language.

I'm also curious if tables/collections are even necessary -- is it possible to express equivalent Dedalus programs with only lattices? (For example, Figure 1 in Logic and Lattices for Distributed Programming -- could an equivalent program be written with lattices?).

[Joe Hellerstein]

I wouldnt sweat it at first. If you do a lattice version of bloom, procs should be less prevalent than in a relational version. 

Sent from a telephone.

On Oct 25, 2012, at 6:11 PM, jking <j.kenne...@gmail.com> wrote:

Exactly my plan of action.

One thing that seems like it might be tricky is that Python doesn't have Proc's to pass around.  In simple rule bodies this might not be an issue since we can use lambda's but I'd be limited to a single expression in the lambda body.  Seems like that might be a limitation for non-trivial programs.

On Monday, October 22, 2012 7:54:38 PM UTC-4, jmh wrote:

[Neil Conway]

On Thu, Oct 25, 2012 at 8:32 PM, jking <j.kenne...@gmail.com> wrote:
> I'm having trouble finding a specification of Datalog; there are lots of
> papers on it but I can't find a formal description of the language.

I don't know of a handy formal spec, although Datalog is a simple
language (also, "Datalog" is often taken as shorthand for a family of
related languages with different degrees of expressiveness).

Datalog is discussed in depth in a few textbooks; for example,
Foundations of Databases by Abiteboul, Hull, and Vianu. Looks like
there is a free version of the book online:
http://webdam.inria.fr/Alice/

To implement a version of Bud, you probably don't need an exhaustive
understanding of the Datalog literature. We basically use Datalog as
"SQL + recursion"; to ensure that recursion is used safely in
programs, use of non-monotonic constructs must be stratified.

> I'm also curious if tables/collections are even necessary -- is it possible
> to express equivalent Dedalus programs with only lattices? (For example,
> Figure 1 in Logic and Lattices for Distributed Programming -- could an
> equivalent program be written with lattices?).

Good question. Certainly the set lattice covers a lot of the common
things that you might want to use Bud collections for. When adding
support for lattices to Bloom, I didn't replace collections with
lattices for a few reasons:

(a) there was already a convenient syntax for doing relational-style
operations over collections. You could perhaps invent similar syntax
for lattices, but that would probably mean adding a notion of schemas
to lattices, which isn't always necessary (e.g., lbool or lmax don't
need a schema).

(b) the Bud collection types include channels, timers, and scratches;
Bud collections also support deletion (<- operator). In Bloom^L as it
was proposed, there is no analogous lattice-y version of this
functionality.

(c) I didn't want to break existing Bloom programs that used collections.

In the context of a new language implementation, none of those reasons
is very compelling -- it certainly might make sense to start with
lattices as the only representation of state and then see what else
you need to add along the way. One factor is how closely you'd like to
keep to the existing Bloom implementations vs. experiment with related
language designs.

Neil

[jking]

Hey Neil,

Thanks for the reply. Your talk at Basho is what inspired me down this path. ;)

As far as my own implementation goes, it's purpose is primarily to catch me up to where your team is. So I don't want to start experimenting yet before I've fully grasped the fundamentals. However I see what you're saying and appreciate the advice.

Hopefully I'll have some of the basic structures and a simple ast rewriter in the next couple of weeks. If I break through the wall I might even have an interpreter ready for my presentation on Nov 10.

Cheers!

[Naveen Michaud-Agrawal]

Hi,

Is your python port still available? The github repo you linked below looks empty. Thanks!

Naveen