Archive for the ‘DSL’ Category

The Pragmatic Haskeller, Episode 4 – Recipe Puppy

Monday, April 29th, 2013

The Pragmatic Haskeller, Episode 4 – Recipe Puppy by Alfredo Di Napoli.

From the post:

Now we have our webapp that can read json from the outside world and store them inside MongoDB. But during my daily job what I usually need to do is to talk to some REST service and get, manipulate and store some arbitrary JSON. Fortunately for us, Haskell and its rich, high-quality libraries ecosystem makes the process a breeze.

Alfredo continues his series on building a basis web app in Haskell.

Promises a small DSL for describing recipes in the next espisode.

Which reminds me to ask, is anyone using a DSL to enable users to compose domain specific topic maps?

That is we say topic, scope, association, occurrence, etc. only because that is our vocabulary for topic maps.

No particular reason why everyone has to use those names in composing a topic map.

For a recipe topic map the user might see: recipe (topic), ingredient (topics), ordered instructions (occurrences), measurements, with associations being implied between the recipe and ingredients and between ingredients and measurements, along with role types, etc.

To a topic map processor, all of those terms are treated as topic map information items but renamed for presentation to end users.

If you select an ingredient, say fresh tomatoes in the salads category, it displays other recipes that also use fresh tomatoes.

How it does that need not trouble the author or the end user.

Yes?

Posted in DSL, Haskell | No Comments »

Green-Marl – The Paper

Wednesday, June 20th, 2012

Green-Marl: A DSL for Easy and Efficient Graph Analysis by Sungpack Hong, Hassan Chafi, Eric Sedlar, and Kunle Olukotun.

I previously reported on the Green-Marl website/software and mentioned this paper: Green-Marl. Catching up on a severe backlog of papers during a slow summer weekend and read in Green-Marl paper:

The above mathematical descriptions imply two important assumptions that Green-Marl makes:

1. The graph is immutable and is not modified during analysis.

2. There are no aliases between graph instances nor between graph properties.

We assume an immutable graph so that we can focus on the task of graph analysis, rather than worry about orthogonal issues such as how graphs are constructed or modified. Since Green-Marl is designed to be used in re-writting only parts of the user application (Section 3.1), one can construct or modify the graph in their own preferred way (e.g. from data file, from a database, etc.) but when a Green-Marl generated implementation is handed a graph, the assumption is that the graph will not be modified while a Green-Marl procedure is analyizing it.

I can imagine assumption #1 being in place for processing a topic map but certainly not assumption #2.

But given the type of graph analysis they want to perform, the assumptions are justifiable.

Given a graph, \( G = (V;E) \), and a set of properties defined on the graph, \( \amalg = \{P_1; P_2; \ldots P_n\} \), our language is specifically designed for the following types of graph analysis:


  • Computing a scalar value from \( (G,\amalg) \), e.g. the conductance of a sub-graph

    • 

  • Computing a new property \( P_{n+1} \) from \( (G, \amalg ) \), e.g. the pagerank of each node of a graph

    • 

  • Selecting a subgraph of interest out of the original graph \( (V^’,E^’) \subset (V,E) \), e.g. strongly connected components of a graph

What if we share the assumption:

1. The graph is immutable and is not modified during analysis.

And have a different second assumption:

There are aliases between nodes and graph properties.

We want to say:

Given a graph, \( G = (V;E) \), and a set of properties defined on the graph, \( \amalg = \{P_1; P_2; \ldots P_n\} \),

  1. Compute the aliases for each property defined on the graph
  2. Compute the aliases for each node of the graph

(My suspicion being that aliases of properties must be computed before aliases on nodes, although that would depend upon how aliases between nodes are defined.)

Where actions based on the computation of aliases for both properties and nodes are a separate step in the analysis.

(There are some other complexities that I haven’t fully teased out so suggestions/comments welcome. But then that is always the case.)

Posted in DSL, Graphs, Green-Mari | No Comments »

High-Performance Domain-Specific Languages using Delite

Saturday, June 2nd, 2012

High-Performance Domain-Specific Languages using Delite

Description:

This tutorial is an introduction to developing domain specific languages (DSLs) for productivity and performance using Delite. Delite is a Scala infrastructure that simplifies the process of implementing DSLs for parallel computation. The goal of this tutorial is to equip attendees with the knowledge and tools to develop DSLs that can dramatically improve the experience of using high performance computation in important scientific and engineering domains. In the first half of the day we will focus on example DSLs that provide both high-productivity and performance. In the second half of the day we will focus on understanding the infrastructure for implementing DSLs in Scala and developing techniques for defining good DSLs.

The graph manipulation language Green-Marl is one of the subjects of this tutorial.

This resource should be located and “boosted” by a search engine tuned to my preferences.

Skipping breaks, etc., you will find:

  • Introduction To High Performance DSLs (Kunle Olukotun)
  • OptiML: A DSL for Machine Learning (Arvind Sujeeth)
  • Liszt: A DSL for solving mesh-based PDEs (Zach Devito)
  • Green-Marl: A DSL for efficient Graph Analysis (Sungpack Hong)
  • Scala Tutorial (Hassan Chafi)
  • Delite DSL Infrastructure Overview (Kevin Brown)
  • High Performance DSL Implementation Using Delite (Arvind Sujeeth)
  • Future Directions in DSL Research (Hassan Chafi)

Compare your desktop computer to the MANIAC 1 (calculations for the first hydrogen bomb).

What have you invented/discovered lately?

Posted in DSL, Delite, Machine Learning, Parallel Programming, Scala | No Comments »

Green-Marl

Saturday, June 2nd, 2012

Green-Marl

From the website:

Green-Marl [1] is a domain-specific language that is specially designed for graph data analysis. For the further information for the Green-Marl language, refer to the language specification draft [2], which can also be found in this directory in the source package.

‘gm_comp’ is a compiler for Green-Marl. It reads a Green-Marl file and generates an equivalent, efficient and parallelized C++ implementation, i.e. .cc file. More specifically, the compiler produces a C++ function for each Green-Marl procedure. The generated c++ functions can be compiled with gcc and therefore can be merged into any user application that are compilable with gcc.

The C++ codes that are generated by ‘gm_comp’ assume the following libraries:

  • gcc (with builtin atomic functions)
  • gcc (with OpenMp support)
  • a custom graph library and runtime (gm_graph)

The first two are supported by any recent gcc distributions (version 4.2 or higher); the third one is included in this source package.

‘gm_comp’ is also able to generate codes for a completely different target environment (See Section 5).

This is the sort of resource that should appear in a daily “update” about topic map relevant material on the WWW or in the published literature.

The paper, Green-Marl: A DSL for Easy and Efficient Graph Analysis (ASPLOS 2012), by Sungpack Hong, Hassan Chafi and Eric Sedlar, is quite good.

I first saw Green-Marl at Pete Warden’s Five Short Links.

Posted in DSL, Graphs, Green-Mari | 2 Comments »

Bird’s Eye View of the ElasticSearch Query DSL

Saturday, February 18th, 2012

Bird’s Eye View of the ElasticSearch Query DSL
 Peter Karich.

From the post:

I’ve copied the whole post into a gist so that you can simply clone, copy and paste the important stuff and even could contribute easily.

Several times per month there are questions regarding the query structure on the ElasticSearch user group.

Although there are good docs explaining this in depth, I think a bird’s eye view of the Query DSL is necessary to understand what is written there. There is even some good external documentation available. And there were attempts to define a schema but nevertheless I’ll add my 2 cents here. I assume you set up your ElasticSearch instance correctly and on the local machine filled with exactly those 3 articles.

Do you have a feel for what a “bird’s eye view” would say about the differences in NoSQL query languages?

SQL has been relatively uniform, enabling users to learn the basics and then fill in the particulars as necessary. How far are we from a query DSL that obscures most of the differences from the average user?

Posted in DSL, ElasticSearch, Query Language | No Comments »

QL.IO

Thursday, December 8th, 2011

QL.IO – A declarative, data-retrieval and aggregation gateway for quickly consuming HTTP APIs.

From the about page:

A SQL and JSON inspired DSL

SQL is quite a powerful DSL to retrieve, filter, project, and join data — see efforts like A co-Relational Model of Data for Large Shared Data Banks, LINQ, YQL, or unQL for examples.

ql.io combines SQL, JSON, and a few procedural style constructs into a compact language. Scripts written in this language can make HTTP requests to retrieve data, perform joins between API responses, project responses, or even make requests in a loop. But note that ql.io’s scripting language is not SQL – it is SQL inspired.

Orchestration

Most real-world client apps need to mashup data from multiple APIs in one go. Data mashup is often complicated as client apps need to worry about order of requests, inter-dependencies, error handling, and parallelization to reduce overall latency.

ql.io’s scripts are procedural in appearance but are executed out of order based on dependencies. Some statements may be scheduled in parallel and some in series based on a dependency analysis done at script compile time. The compilation is an on-the-fly process.

Consumer Centric Interfaces

APIs are designed for reuse, and hence they cater to the common denominator. Getting new fields added, optimizing responses, or combining multiple requests into one involve drawn out negotiations between API producing teams and API consuming teams.

ql.io lets API consuming teams move fast by creating consumer-centric interfaces that are optimized for the client – such optimized interfaces can reduce bandwidth usage and number of HTTP requests.

I can believe the “SQL inspired” part since it looks like keys/column headers are opaque. That is you an specify a key/column header but you can’t specify the identity of the subject it represents.

So, if you don’t know the correct term, you are SOL. Which isn’t the state of being inspired.

Still, it looks like an interesting effort that could develop to be non-opaque with regard to keys and possibly values. (The next stage is how do you learn what properties a subject representative has for the purpose of subject recognition.)

Posted in Aggregation, DSL, JSON, SQL | No Comments »

Creating a DSL for Cypher graph queries

Monday, November 21st, 2011

Creating a DSL for Cypher graph queries

From the post:

My first assignment at Neo4j was to create a Java DSL for the Cypher query language, that is used to access data from the Neo4j database in a graphy way.

First off, why a DSL? There’s a ton of reasons why using a DSL instead of strings is a good idea. From a practical point of view a DSL and a decent IDE will make creating queries so much easier, as you can use code completion to build the query. No need to refer to manuals and cheat sheets if you forget the syntax. Second, I have found it useful to create queries iteratively in a layered architecture, whereby the domain model can create a base query that describes some concept, like “all messages in my inbox”, and then the application layer can take this and enhance with filtering, like “all messages in my inbox that are sent from XYZ”, and then finally the UI can add the order by and paging. Doing something like this would be extremely difficult without a DSL.

You get to learn something about DSLs and Cypher at the same time!

How cool is that?

Posted in Cypher, DSL | No Comments »

DSL for the Uninitiated (Legends?)

Saturday, October 1st, 2011

DSL for the Uninitiated by Debasish Ghosh

From the post:

One of the main reasons why software projects fail is the lack of communication between the business users, who actually know the problem domain, and the developers who design and implement the software model. Business users understand the domain terminology, and they speak a vocabulary that may be quite alien to the software people; it’s no wonder that the communication model can break down right at the beginning of the project life cycle.

A DSL (domain-specific language)1,3 bridges the semantic gap between business users and developers by encouraging better collaboration through shared vocabulary. The domain model that the developers build uses the same terminologies as the business. The abstractions that the DSL offers match the syntax and semantics of the problem domain. As a result, users can get involved in verifying business rules throughout the life cycle of the project.

This article describes the role that a DSL plays in modeling expressive business rules. It starts with the basics of domain modeling and then introduces DSLs, which are classified according to implementation techniques. The article then explains in detail the design and implementation of an embedded DSL from the domain of securities trading operations.

The subject identity and merging requirements of a particular domain are certainly issues where users, who actually know the problem domain, should be in the lead. Moreover, if users object to some merging operation result, that will bring notice to perhaps unintended consequences of an identity or merging rule.

Perhaps the rule is incorrect, perhaps there are assumptions yet to be explored, but the focus in on the user’s understanding of the domain, where it should be (assuming the original coding is correct).

This sounds like a legend to me.

BTW, the comments point to Lisp resources that got to DSLs first (as is the case with most/all programming concepts):

Matthias Felleisen | Thu, 04 Aug 2011 22:26:46 UTC

DSLs have been around in the LISP world forever. The tools for building them and for integrating them into the existing toolchain are far more advanced than in the JAVA world. For an example, see

http://www.ccs.neu.edu/scheme/pubs/#pldi11-thacff for a research-y introduction

or

http://hashcollision.org/brainfudge/ for a hands-on introduction.

You might also want to simply start at the Racket homepage.

Posted in DSL, Legends | No Comments »

SAGA: A DSL for Story Management

Monday, September 12th, 2011

SAGA: A DSL for Story Management by Lucas Beyak and Jacques Carette (McMaster University).

Abstract:

Video game development is currently a very labour-intensive endeavour. Furthermore it involves multi-disciplinary teams of artistic content creators and programmers, whose typical working patterns are not easily meshed. SAGA is our first effort at augmenting the productivity of such teams.

Already convinced of the benefits of DSLs, we set out to analyze the domains present in games in order to find out which would be most amenable to the DSL approach. Based on previous work, we thus sought those sub-parts that already had a partially established vocabulary and at the same time could be well modeled using classical computer science structures. We settled on the ‘story’ aspect of video games as the best candidate domain, which can be modeled using state transition systems.

As we are working with a specific company as the ultimate customer for this work, an additional requirement was that our DSL should produce code that can be used within a pre-existing framework. We developed a full system (SAGA) comprised of a parser for a human-friendly language for ‘story events’, an internal representation of design patterns for implementing object-oriented state-transitions systems, an instantiator for these patterns for a specific ‘story’, and three renderers (for C++, C# and Java) for the instantiated abstract code.

I mention this only in part because of Jack Park’s long standing interest in narrative structures.

The other reason I mention this article is it is a model for how to transition between vocabularies in a useful way.

Transitioning between vocabularies is as nearly a constant theme in computer science as data storage. Not to mention that disciplines, domains, professions, etc., have been transitioning between vocabularies for thousands of years. Some more slowly than other, some terms in legal vocabularies date back centuries.

We need vocabularies and data structures, but with the realization that none of them are final. If you want blind interchangea of topic maps I would strongly suggest that you use one of the standard syntaxes.

But with the realization that you will encounter data that isn’t in a standard topic map syntax. What subjects are represented there? How would you tell others about them? And those vocabularies are going to change over time, just as there were vocabularies before RDF and topic maps.

If you ask an honest MDM advocate, they will tell you that the current MDM effort is not really all that different from MDM in the ’90′s. And MDM may be what you need, depends on your requirements. (Sorry, master data management = MDM.)

The point being that there isn’t any place where a particular vocabulary or “solution” is going to freeze the creativity of users and even programmers, to say nothing of the rest of humanity. Change is the only constant and those who aren’t prepared to deal with it, will be the worse off for it.

Posted in DSL, TMDM, TMRM, Topic Maps, Vocabularies | No Comments »

Growing a DSL with Clojure

Thursday, August 25th, 2011

Growing a DSL with Clojure: Clojure Makes DSL Writing Straightforward by by Ambrose Bonnaire-Sergeant.

From the post:

From seed to full bloom, Ambrose takes us through the steps to grow a domain-specific language in Clojure.

Lisps like Clojure are well suited to creating rich DSLs that integrate seamlessly into the language.

You may have heard Lisps boasting about code being data and data being code. In this article we will define a DSL that benefits handsomely from this fact.

We will see our DSL evolve from humble beginnings, using successively more of Clojure’s powerful and unique means of abstraction.

Is a DSL in your subject identity future?

Posted in Clojure, DSL | No Comments »

Growing a DSL with Clojure

Wednesday, July 20th, 2011

Growing a DSL with Clojure by Ambrose Bonnaire-Sergeant.

From the post:

From seed to full bloom, Ambrose takes us through the steps to grow a domain-specific language in Clojure.

Lisps like Clojure are well suited to creating rich DSLs that integrate seamlessly into the language.

You may have heard Lisps boasting about code being data and data being code. In this article we will define a DSL that benefits handsomely from this fact.

We will see our DSL evolve from humble beginnings, using successively more of Clojure’s powerful and unique means of abstraction.

You know, the “…code being data and data being code” line reminds me of DATATAG in ISO 8879 (SGML).

I suspect this gets us keys being first class citizens but that will have to await another post.

Posted in Clojure, DSL | 3 Comments »