Tag Info

Hot answers tagged

7

A few thousand lines for a parser + interpreter that actually does something interesting is not unusual in the least. I looked at the SVN repo and especially your main grammar and noticed various things: You have various utility classes that would make more sense in a general algorithms library. A quicksort implementation, really? IIRC, the C++ standard ...


5

The distinction is hard to make, and depend of the language used. It is also subjective. In clojure, you can define APIs which look like a DSL. For exemple, hiccup allows you to generate html: (html [:span {:class "foo"} "bar"]) This can be considered as a DSL with a lisp syntax. The fact that html could be a macro gives it the same amout of power as if ...


3

In general, no. A DSL is deliberately made non-general for the purpose of making some operations more convenient. Things like HTML or Logo were originally domain-specific languages. In general, you can't embed a DSL into another language even with the most powerful API; whatever you program against that API will still look like a series of expressions in ...


2

I recommend become familiar with several programming languages (including Scheme or CommonLisp and Ocaml or Haskell). It is probable that implementing your translator in such languages would be good for you. Then I suggest to read Programming Language Pragmatics (by M.Scott) and Lisp In Small Pieces (by C.Queinnec). Of course, you'll need to read a good ...


2

I have never written a compiler, so I am out of my depth here, but here is a try: I would start by writing a lexer and parser for the language. There are many tools for this. ANTLR is one of them; it can handle both lexing and parsing. Alternatively, you can use Lex or GNU Flex to create a lexer and create a parse tree with Yacc and its implementation Bison ...


2

Parsing is inherently complex. It's difficult to do correctly, and even more difficult to do elegantly. A lot of code is not necessarily a sign of a problem. However, there are a lot of things you can do to make it easier. Use functions instead of cramming everything into your yacc file. You want a yacc file to be only the specification of your ...


2

APIs and DSLs are quite different concepts and there are only some areas where they might be said to overlap. All DSLs are computer languages. They might be interpreted, compiled, mark-up, query languages (e.g. SQL) or (like JSON or some uses of XML) data languages which might used in messages passed over an API, but they must be languages. The term ...


2

The biggest problem is the huge set of assumptions that you so easily skip. Just take your example: "$600 is paid by Client A for inspection" USD or other dollar? Paid when? To whom? What counts as an inspection? Is this a mandatory payment, or only incurred if A opts to do the inspection? Are multiple inspections allowed, If so, is this per inspection? ...


2

At the syntax level, either XML or JSON would do fine. But that's the easy bit. The challenge is defining what can go in the rules. I would adopt a standard object modelling approach: what are the entities you need to represent, and what are their attributes and relationships? When you know that, encoding it in XML is easy.


2

The most commonly accepted way is to use a Business Rules Engine of some sort. Of course, if you're willing to roll your own BRE, and just need a reading on the markup language to use, I would imagine that XML is as good as any. It is hierarchical, has namespaces, and is unlikely to become obsolete any time soon. Since it's likely that we're not talking ...


1

Here's the thing with unit tests. You want them to be really easy to write. Anytime writing a test is made more difficult, it will result in tests not being written, and bugs will be allowed to live. So let's imagine I'm writing a test: void testCanDrive() { Person person = new PersonBuilder() .doRequired() .addFirstName("John") ...


1

I think every API is an embedded DSL but the converse is not true: not every embedded DSL is an API. Only when the language is used as a means to integrate components it can be called an API. Why can an API be considered an embedded DSL? First of all, it forms a language: it has primitive elements (types and operations) which can be combined (by the means ...


1

Are there valid FTP/FTPS/SFTP/SCP URIs which will break this scheme? Yes. Any user that has a password containing "<" or "> is likely to cause problems. Are they at all likely? Absolutely, since you don't have any control over the passwords used by the users (presumably). What mini-DSL is less likely to be broken by valid URIs? None. Any un-escaped ...



Only top voted, non community-wiki answers of a minimum length are eligible