On DSL, Smalltalk and FP

I was watching the interview with Dave Thomas. Dave mentioned very early in the interview Smalltalk has a "keyword syntax" which makes it easy to implement (embedded) DSL.

What's "keyword syntax"?

And, what makes a language a good platform for (E)DSL?

I know Haskell has been a good platform for doing EDSL. It looks like to me its Type Class and high-order functions enable us to implement EDSL. But, are they essential? LISP doesn't have type class, but i think it's also a common candidate for EDSL. So, what are the essential language features for EDSL?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

keyword == parameter passing by name

I think that by 'keyword syntax', he means that in Smalltalk you pass parameter by name not by position like in other language i.e
my_function arg:foo instead of my_function(foo).

It's too bad that this syntax isn't more widespread:
- it's more readable
- it helps avoiding mistakes when calling functions (the famous memset error).

by position AND name

In Smalltalk you pass parameters by both position and name.


There are different techniques for building DSELs, so I don't think this is the right question: there isn't one set of essential features one must have in order to build DSELs.

metonymy for message passing?

sciomako: ..."keyword syntax" which makes it easy to implement (embedded) DSL.

Sounds like that might be metonymy, with "keyword syntax" somehow intending to mean "message passing", which is a runtime behavior that's not syntax specific.

In Smalltalk, selectors (method names) with colons in them are called keyword messages (in contrast to unary and binary messages), but all methods are invoked by message passing and nothing is really different about keyword messages, except more than one method argument with keywords interspersed between args.

But I don't see how message passing makes it easier to implement embedded DSL either ... except that message passing is a very hands-off style of communication which doesn't over-specify what a receiver will do in response. You could easily embed a language using message passing in a runtime, because it won't constrain much -- it would be like posting events, which most apps and servers handle anyway (from the OS or from connections, or whatever).

But embedding doesn't imply anything about a DSL (domain specific language) unless the domain is the app into which you embedded the language, and then you're really just talking about an embedded language ... maybe any embedded language is necessarily specific to the domain of an app it lives inside, in order for there to be bindings for the language in the execution context. (For example, JavaScript as an embedded language tends to be domain specific to the browser context in which it runs, so it can interact with the DOM and browser, etc.)

I suppose I should listen to the interview, but I have a slow connection at the moment.

simpler than that

And I should also listen to the interview before commenting but I haven't so I'm guessing - I guess he means something simpler, I guess he just means that keyword syntax reads like a DSL.

We really need a code example from medicine or finance or ... to make the point, but maybe with sufficient imagination this will do -

newCollection replaceFrom: 1 to: limit with: collection startingAt: 1.

That's what I thought (not

That's what I thought (not that I listened to the interview....)

Yes, the term DSL is now

Yes, the term DSL is now framed by Rubys use of it: 7.more.lucky.Rails.users

In a few years everyone will wonder why this programming style was ever respected but it's cool right now like a summer hit. Ruby is the carnival after the "nuclear winter" ( Gilad Bracha ) of Enterprise Java. I kinda love programming language trash.

Keyword messages in Smalltalk are not named parameters

Smalltalk keyword messages are not true named parameters, in that order argument matters. If I implement a class and provide a method called doThis: toThat:, then the following works:

myObject doThis: oneObject doThat: anotherObject

But the following does not:

myObject doThat: anotherObject doThis: oneObject

Unless doThat: doThis: is also defined, the latter invokation returns #doesNotUnderstand. It is possible to simulate true keyword arguments by providing multiple versions--the boolean classes True and False both provide methods ifTrue: ifFalse: and ifFalse: ifTrue:, which behave as expected, but you have to write that sort of thing yourself. There's no requirement that two similarily-named methods behave identically; and extending this trick to n-ary argument methods will require n! different versions--hardly scaleable.

not keywords like other languages

Yes, that's exactly my understanding too, from implementing it before. Smalltalk keyword messages with multiple keywords (each ending with a colon) are order dependent -- every combination is a unique message. This is about the same as saying individual letters in method names in other programming languages are order dependent, so foobar() is not the same method as barfoo().

Languages newer than Smalltalk have started to add or discuss "keyword arguments" with a common understanding they are unordered -- the purpose of such keywords was to make them order-independent.

The evolution of terminology in other languages (what keyword means elsewhere) makes that of Smalltalk from 1980 seem inconsistent, when it's actually more the other way around if precedence matters.

named parameters, optional parameters

I wondered which other languages you meant, Google turned up Python and maybe Common Lisp wins if precedence matters (how many times do you think we can get away with repeating that?)

I'm more used to the term "named parameters" which become kind-of important when parameters can be optional.