On DSLs

[Ludovic Courtès]

Hello,

Konrad Hinsen <address@hidden> skribis:

>> What do we disagree on, actually?  :-)
>
> This:
>
>>> 2. Power users will always write code in powerful languages that exceed
>>>    what less advanced users can deal with. And since power users are not
>>>    necessarily benevolent, this creates a trust issue for the less
>>>    advanced ones.
>>
>> Good point.  I tend to (naively?) view it the other way around: that it
>> gives people an incentive to try and write actual code rather than mere
>> declarations.
>
> I'd say we should encourage people to write declarations as much as
> possible and resort to executable code only when declarations become
> too messy. As a corollary, we should support most configuration-style
> use cases with suitable declarative forms, much like these:
>
>> The goal for Guix was to have the ‘package’ and ‘operating-system’
>> forms, for instance, look exactly like what you’d write in JSON etc.,
>> only with a different syntax.

I agree.

> For better illustration, I'll try to rewrite my own manifests in the
> way I'd like to be able to write them. That's probably more useful
> than theory (a tough statement to make for a theoretician ;-)

Agreed!

> The main reason why I want to see more declarative style is:
>
>>> The problem with powerful formal languages (read: Turing-complete) is
>>> not writing, but (1) debugging and (2) reading.
>>
>> Yes and no.  Guile has a debugger, whereas XML/JSON/YAML don’t.  As for
>> reading, it’s subjective, but I don’t think a full-blown language is
>> necessarily harder to read.
>
> It's harder to read because you need to understand the language's
> execution model if there is one. YAML etc. don't, there is nothing
> but literals. Which is also why they don't need a debugger.

That’s not true.  In some cases, people write something that’s actually
code (in YAML, in JSON, etc.) and there’s an interpreter running it.
There’s usually no tooling coming with that interpreter, in particular
no debugger, error reporting may not be optimal either, and the
semantics may be ill-defined (I’m getting close to Greenspun’s tenth
rule :-)).  It’s just that it’s not presented that way, but that’s what
it is.

IOW, I think you can have a declarative _style_ in a full-blown
language, like:

  (define coreutils
    (package
      (name "coreutils")
      ;; …
      ))

And you can have “arbitrary code” in things that are presented as “pure
declarations” or not-a-programming-language.  For an example, see
‘eval-cabal’ in (guix import cabal), which evaluates Cabal “things”
(code or not?).  Or see the ‘syntax-rules’ “declarations”.

This is just to say that we should not conflate the style and the
language.  I think what we care about is supporting a declarative style,
and making it expressive enough that people don’t feel the need to
resort to complicated code.

>>   (define lst (list 1 2 3))
>>
>>   lst = [1, 2, 3]
>
> Fine. But then a power user comes along and writes
>
>    (define lst (cons* 1 2 '(3)))
>
> That may be bad style, but as a reader I have to be able to deal with it
> nevertheless. And bad style may in fact serve to obfuscate evil
> intentions.

I agree, but I think that this is hardly avoidable.  Sure, a pet DSL
will initially have nothing but ‘list’ so the problem won’t exist.  But
sooner or later, it’ll get ‘cons*’ as well.

Thanks,
Ludo’.