[Python-ideas] Why shouldn't Python be better at implementing Domain Specific Languages?

[Steven D'Aprano]

On Fri, Aug 31, 2018 at 03:40:22AM +0200, Guido van Rossum wrote:
> On Fri, Aug 31, 2018 at 3:19 AM, Michael Selik <mike at selik.org> wrote:
> 
> > On Thu, Aug 30, 2018 at 5:31 PM James Lu <jamtlu at gmail.com> wrote:
> >

[James]
> >> It would be nice if there was a DSL for describing neural networks
> >> (Keras).
> >>
> >> model.add(Dense(units=64, activation='relu', input_dim=100))
> >> model.add(Dense(units=10, activation='softmax'))

Is there something wrong with that style?

I'm not sure what syntax you would consider an improvement.


[Michael]
> > Why not JSON or XML for cross-language compatibility?

James dodn't mention cross-language compatibility, he presumably wants a 
better way to write machine learning code. Being able to exchange data 
from one application to another is great. Having to write your code as 
XML is not.


[Guido]
> Presumably because those are even harder to read and write for humans.

Indeed. One criticism of XML is that it is the hammer which leads people 
to treat every problem as a nail. "Just use XML". Now you have two 
problems *wink*


> I believe that the key issue with using Python as a DSL has to do with its
> insistence on punctuation -- the above example uses nested parentheses,
> commas, equal signs, and quotation marks. Those are in general needed to
> avoid ambiguities, but DSLs are often highly stylized, and a language that
> doesn't need them has a certain advantage.

Right -- especially for imperative-style code.

I'm reminded of an example from Leo Brodie's classic "Learning Forth", 
the top level application in an embedded washing machine controller:

    WASH SPIN RINSE SPIN

That sort of punctuation-free imperative code elegantly matches the way 
we might right it down as a list of commands.


> For example if a shell-like
> language was adopted, the above could probably be written with spaces
> instead of commas, parentheses and equal signs, and dropping the quotes
> (though perhaps it would be more readable if the equal signs were kept).
> 
> I'm not sure how we would go about this though. IIRC there was a proposal
> once to allow top-level function calls to be written without parentheses,
> but it was too hard to make it unambiguous (e.g. would "foo +1" mean
> "foo(+1)" or "foo + 1"?)

Please no, Ruby has that, and the meaning of expressions depends on 
whether you put whitespace around operators or not.

Given:

def a(x=4)
    x+2
end
b = 1

the result of "a+b" depends on the spaces around the plus sign:

irb(main):005:0> a + b
=> 7
irb(main):006:0> a +b
=> 3




-- 
Steve