Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perhaps extensible syntax? #51

Closed
adrian-herscu opened this issue Dec 1, 2016 · 6 comments
Closed

Perhaps extensible syntax? #51

adrian-herscu opened this issue Dec 1, 2016 · 6 comments

Comments

@adrian-herscu
Copy link

All languages today provide a fixed set of tokens , keywords, and constructs. What about letting users define their own "little languages" and have them supported by the tools?

yegor256 pushed a commit that referenced this issue Dec 2, 2016
@yegor256
Copy link
Member

yegor256 commented Dec 2, 2016

@adrian-herscu I'm personally strongly against that kind of DSL's. I believe that they only make code less readable. I'm using Ruby a lot and I really hate their DSL's. Very often I simply can't understand what the code does and have no idea where to look for documentation. So, I'm in favor of a very strict and specific syntax. No sugar, no DSLs, etc. See aa56f21

@ArneBachmann
Copy link

Agree. Languages with too much "magic" give me the creeps (e.g. Elixir, Ruby frameworks)

@flammar
Copy link

flammar commented Mar 2, 2017

As I understand, every such custom DSL uses the idea of using compile-time analysis, mainly in IDE, to verify a statement in this DSL. Also, a question about DSL is not always a question about syntax extensibility, e.g. Scala-based DSLs.

@ljleb
Copy link

ljleb commented May 10, 2021

@yegor256 I believe there should be space for DSLs in a general programming language. Otherwise, boilerplate code will probably be necessary for some particular tasks.

In an attempt to support my point of view, I want to point out that the README already contains some code that could be considered as beloning to a DSL. Namely, the printf function takes a string in which % is considered special character. If the argument to printf is not a DSL, I don't know what is :)

@kerelape
Copy link
Member

@yegor256 I believe there should be space for DSLs in a general programming language. Otherwise, boilerplate code will probably be necessary for some particular tasks.

In an attempt to support my point of view, I want to point out that the README already contains some code that could be considered as beloning to a DSL. Namely, the printf function takes a string in which % is considered special character. If the argument to printf is not a DSL, I don't know what is :)

printf's % is not a language feature. You can always make your own parser for that using EO and no DSL in context of the language would appear

@ljleb
Copy link

ljleb commented Jan 16, 2024

printf's % is not a language feature. You can always make your own parser for that using EO and no DSL in context of the language would appear

You're reviving a very old thread!

In any case, I believe what I meant is that printf's argument has its own domain specific syntax. Even though you put quotes around the argument, it still has to follow a domain specific syntax and isn't free form. AFAIK, part the definition of a DSL is that it has to have a grammar, no matter whether the parsing occurs at runtime or compile time.

I agree with you that it isn't a language feature, but a DSL doesn't have to be a language feature, all it needs to do is be its own language IIUC.

It appears I wanted to use this point to support the view that DSLs can help simplify code, which I still believe is sound. For example, printf %, regexes or numpy's einsum mini-language (which, IIUC, are all domain specific languages) can consolidate code and make it easier to read.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants