3 ms·

That proposal is a nonstarter. It cannot and will not ever be accepted

by conartist6 11mo ago

botten 11mo ago
Why?
- conartist6 11mo ago
  In short, we can do much better. I'm building a full syntax extension/macro evaluation mechanism for JS.
  - herpdyderp 11mo ago
    Where is it? What is it called?
    - conartist6 11mo ago
      It's called BABLR as it takes concepts from Babel (transpiling) and ANTLR (parsing arbitrary syntax). https://github.com/bablr-lang/ https://github.com/bablr-lang/ I'm currently in the process of trying to pull together our first big release.
indolering 11mo ago
Please elaborate!
- conartist6 11mo ago
  The proposal is to introduce a whole slew of syntax to JS that according to the proposal will have no meaning. This is a paradox. You have only created a language if you can use it to convey meaning
  - gaigalas 11mo ago
    That's not entirely true. Ideally, there would be a follow up with a reflection API. Also, comments are syntax and they're mostly meaningless. By your reasoning, programming languages should have no comments. So, it's not really a qualitative issue (presence of meaningless syntax) but a quantitative one (presence of lots of parsing complexity).
    - conartist6 11mo ago
      If you say that whatever data is put there doesn't matter at all, the one thing you definitely cannot ever do later is give it meaning.
      - gaigalas 11mo ago
        Unless I say it's meaning is to be optionally reflected upon during runtime! Look, I understand the purism and mostly, I agree. But this is not a clean slate language, it will never be perfect and it's going to become more and more idiosyncratic as times go by.
        conartist6 11mo ago
        I don't see how it's optional. Comments are a kind of freedom in code. You're completely free to use them precisely because (in a plain execution environment) they cannot influence the result of evaluation If comments /can/ change the result of evaluation then you simply are not (completely) free to use them. (And yes I know that this is a simplification in JS where you can already get the source code of a function with toString... Ugh)
        gaigalas 11mo ago
        Makes sense. I'm excited for your solution, despite not having seen it. If you can solve that, it would be awesome.
gaigalas 11mo ago
Something needs to change. I don't care about one specific proposal. It's miserable having a de-facto build step for an interpreted language. Worst of both worlds. Maybe just TS is fast, but it encourages developers to put more and more stuff into that build step (and they do, they do that a lot). Culturally, that trend is not going to change unless the main reason for having said build step is removed. The whole babel/transpiling thing was meant to be temporary. It became temporarily permanent / permanently temporary.
- conartist6 11mo ago
  I'm the person who is developing a permanent solution.
  - prmph 11mo ago
    Which is?
    - conartist6 11mo ago
      A standard environment in which to run code that extends the builtin parser.

That proposal is a nonstarter. It cannot and will not ever be accepted

botten 11mo ago

Why?

conartist6 11mo ago
In short, we can do much better. I'm building a full syntax extension/macro evaluation mechanism for JS.
- herpdyderp 11mo ago
  Where is it? What is it called?
  - conartist6 11mo ago
    It's called BABLR as it takes concepts from Babel (transpiling) and ANTLR (parsing arbitrary syntax). https://github.com/bablr-lang/ https://github.com/bablr-lang/ I'm currently in the process of trying to pull together our first big release.

indolering 11mo ago

Please elaborate!

conartist6 11mo ago
The proposal is to introduce a whole slew of syntax to JS that according to the proposal will have no meaning. This is a paradox. You have only created a language if you can use it to convey meaning
- gaigalas 11mo ago
  That's not entirely true. Ideally, there would be a follow up with a reflection API. Also, comments are syntax and they're mostly meaningless. By your reasoning, programming languages should have no comments. So, it's not really a qualitative issue (presence of meaningless syntax) but a quantitative one (presence of lots of parsing complexity).
  - conartist6 11mo ago
    If you say that whatever data is put there doesn't matter at all, the one thing you definitely cannot ever do later is give it meaning.
    - gaigalas 11mo ago
      Unless I say it's meaning is to be optionally reflected upon during runtime! Look, I understand the purism and mostly, I agree. But this is not a clean slate language, it will never be perfect and it's going to become more and more idiosyncratic as times go by.
      - conartist6 11mo ago
        I don't see how it's optional. Comments are a kind of freedom in code. You're completely free to use them precisely because (in a plain execution environment) they cannot influence the result of evaluation If comments /can/ change the result of evaluation then you simply are not (completely) free to use them. (And yes I know that this is a simplification in JS where you can already get the source code of a function with toString... Ugh)
        gaigalas 11mo ago
        Makes sense. I'm excited for your solution, despite not having seen it. If you can solve that, it would be awesome.

gaigalas 11mo ago

Something needs to change. I don't care about one specific proposal. It's miserable having a de-facto build step for an interpreted language. Worst of both worlds. Maybe just TS is fast, but it encourages developers to put more and more stuff into that build step (and they do, they do that a lot). Culturally, that trend is not going to change unless the main reason for having said build step is removed. The whole babel/transpiling thing was meant to be temporary. It became temporarily permanent / permanently temporary.

conartist6 11mo ago
I'm the person who is developing a permanent solution.
- prmph 11mo ago
  Which is?
  - conartist6 11mo ago
    A standard environment in which to run code that extends the builtin parser.