News for hackers. Stuff that matters.
Re:Domain-Specific Languages vs. Notation by chrisseaton on Tuesday May 19, 2015 @10:44AM (#9570381)
So what's the difference between an internal DSL and any other library?
Re:Domain-Specific Languages vs. Notation by kenbellows on Tuesday May 19, 2015 @11:00AM (#9570525)
Usually you call something an internal DSL when it reads like its own language. The reason that Ruby lends itself to internal DSLs is how optional a lot of its punctuation is, especially parens around method parameters, making it easier to write code that looks like a variant of English. A good example of this is Rake.
Re:Domain-Specific Languages vs. Notation by chrisseaton on Tuesday May 19, 2015 @11:09AM (#9570622)
I still don't get what 'reads like its own language' really means though. Rake is still Ruby syntax and semantics. Rake just adds new methods - they're still Ruby methods and calling them reads like any other Ruby method using the same parsing rules.

I'm playing the fool here - I do know what an internal DSL is but I think the term is entirely meaningless when you really think about it.

Re:Domain-Specific Languages vs. Notation by drakecoffeecake on Tuesday May 19, 2015 @02:55PM (#9572278)
Lisps let you define the semantics and syntax of a form with macros. I would consider the loop macro in CL to have an internal DSL.

--edited

Re:Domain-Specific Languages vs. Notation by draegtun on Wednesday May 20, 2015 @12:42PM (#9577519)
And another example of this, but not using macros, would be Rebol's parse which is a top-down parsing dialect (internal DSL) within Rebol.

ref: http://en.wikipedia.org/wiki/Rebol#parse

Re:Domain-Specific Languages vs. Notation by hyperpape on Tuesday May 19, 2015 @10:25PM (#9574344)
shrug I just didn't like the attempt at language policing, because it seemed pointless. This, however, is a good question that I don't know the answer to.
Re:Domain-Specific Languages vs. Notation by moron4hire on Tuesday May 19, 2015 @01:09PM (#9571559)
I think the difference becomes clear when you consider that a language syntax is not just source code. Raw, text source code is just the means by which humans express utilizing the syntax of the language. Once that source code file is tokenized and parsed, it's no longer tied to whatever that text was. It becomes an abstract object in memory that either represents a process (a series of machine instructions) or is fed to a process to be manipulated and processed (i.e. interpreted scripting languages).

For example, this blog post walks through McCarthy's original specification for Scheme: http://programmingpraxis.com/2011/11/01/rip-john-mccarthy/

    apply[fn;x;a] =
         [atom[fn] → [eq[fn;CAR] → caar[x];
                     eq[fn;CDR] → cdar[x];
                     eq[fn;CONS] → cons[car[x];cadr[x]];
                     eq[fn;ATOM] → atom[car[x]];
                     eq[fn;EQ] → eq[car[x];cadr[x]];
                     T → apply[eval[fn;a];x;a]];
         eq[car[fn];LAMBDA] → eval[caddr[fn]; pairlis[cadr[fn];x;a]];
         eq[car[fn];LABEL] → apply[caddr[fn];x;cons[cons[cadr[fn];caddr[fn]];a]]]
This is a type of source code. Notice it even includes non-ASCII characters. But this code isn't executable as it is. It has to first be translated into a program, somehow. See the first reply at the original link, which I will not reproduce here, for brevity.

It is a Scheme interpreter. The call to `evaluate` at the end of each test function is where the program gets interpreted. No, it is not a Scheme source file, but it is Scheme syntax, written in Python.

Similarly, LINQ to SQL is a SQL syntax written in C#. Your LINQ expressions are C# code that construct objects that will be interpreted in a SQL context. LINQ to Objects, on the other hand, is NOT a SQL syntax, it's just a library. Even though the function calls look exactly the same, because the C# code you write defines objects that then execute in a C# context.

Of course, that's not to say most "DSL"s haven't misused the term "language". I see it applied a lot to interfaces of chainable method calls. It isn't a new language, it's an exploitation of the existing language. The code still executes in the host language's context, it does not define its own contexts or semantics in any way.

Look at Emscripten. Is it C because that was what the code was written as, or is it JavaScript because that is what the code gets translated to? It's C, because it creates an execution context within the JavaScript code to recreate C semantics.

Look at this toy language I once wrote (https://github.com/capnmidnight/betty-boop/blob/master/loosp...) and a Pong game that uses it (https://github.com/capnmidnight/betty-boop/blob/master/pong....). Is the Pong game Scheme because that's what it was written as, or is it JavaScript? It's JavaScript, because though the code looks like Scheme, it executes like JavaScript, it's just a different syntax that gets translated away.