3 ms·

> Aren't syntax and grammar synonymous? Or, if not exactly the same thing, essentially two sides of the same coin? No. (Syntax is a subset of grammar.) > If M

> Aren't syntax and grammar synonymous? Or, if not exactly the same thing, essentially two sides of the same coin? No. (Syntax is a subset of grammar.) > If Markdown has "no official grammar", it is because there is not one thing called Markdown, there are many. No, it's also because it's a pattern-based preprocessor. There are efforts to produce Markdown grammars; some have been done. > That claim makes zero sense to me. My claim that it was a point of contention? It really was. > The non-core syntax is (near-)infinitely flexible, but I could say the same thing about C or Java. In Tcl, I can define (near-)arbitrarily named commands that accept (near-)arbitrarily named arguments; in C/C++/Java/etc I can define (near-)arbitrarily named functions/methods which accept (near-)arbitrarily named arguments, (near-)arbitrarily named structs/classes/etc which have (near-)arbitrarily named fields, etc. No, these are not the same.

skissane 5y ago
> No. (Syntax is a subset of grammar.) Can you elucidate what you see the relationship between them as being? > No, it's also because it's a pattern-based preprocessor. What do you mean by that? Why does being a "pattern-based processor" imply something has "no official grammar"? > There are efforts to produce Markdown grammars; some have been done. So, if people have produced grammars for it, it has a grammar, no? > No, these are not the same. How and why are they different?
- unfocussed_mike 5y ago
  > Can you elucidate what you see the relationship between them as being? Grammar covers the correct use of the syntax of a language. With syntax alone you cannot know whether a program is a correct use of a language -- that is, it will parse or compile, even if its output is nonsensical. A grammar lets you do that. So for example an unambiguous grammar is essential to being able to translate higher level language into assembly language. > What do you mean by that? Why does being a "pattern-based processor" imply something has "no official grammar"? Can you parse and transform arbitrary HTML correctly with only regular expressions? The answer as I am sure you will know is no. That is your answer here too. > So, if people have produced grammars for it, it has a grammar, no? I don't know if any Markdown grammar exists that expresses all of what you can do in the reference implementation of Markdown, so *shrug*. Maybe, maybe not. The fact that it has no deliberately designed grammar is an interoperability problem though. > How and why are they different? Because you are comparing extending semantics within what is allowed by the grammar (writing functions in the programming language it concerns) (e.g. in Java), and extending the interpreter itself (Tcl as a "language" changes according to which extensions are compiled in, and the extensions determine what the symbols mean). The fundamental question here is this: Can a program conclude that a Tcl program will parse correctly (even if the code itself has errors) without running the specific Tcl interpreter for which it is designed (or at least without knowledge of the implementation of its extensions)? No, it essentially cannot. That is what a grammar gives you. You can stare at a bit of C code you do not understand and at least say "it is valid C". And so can another program (a static analyser/explorer, a linter, etc.) More difficult with Tcl. (And perl4, for example)
  - skissane 5y ago
    > Grammar covers the correct use of the syntax of a language. With syntax alone you cannot know whether a program is a correct use of a language -- that is, it will parse or compile, even if its output is nonsensical. A grammar lets you do that. Suppose I am writing a Pascal compiler. I might start with a grammar for Pascal, expressed in EBNF. I might write a parser from that grammar, either by hand, or by using some parser generator. My parser converts text (or a sequence of tokens generated by an independent lexical analysis stage) to some kind of parse tree or abstract syntax tree. Since Pascal is a statically typed language, I also need to write some code to do type-checking. If you look at a tutorial on writing a compiler, you might see this presented as a subsequent compilation stage, after parsing is complete. It takes the AST and symbol table, annotates it with type information (possibly even doing type inference), and checks various rules are obeyed. And, an EBNF grammar doesn't tell us how to do it. Generally you'd either express it informally, or if you were going to use some kind of formalism, you'd use a rather different formalism from those in which programming language grammars are commonly expressed. There are "typed grammar" formalisms which combine type-checking into parsing, but you don't see them commonly used by people implementing programming languages in the real world. In my experience they are mainly popular in academia (and I've seen them presented more often in the context of natural language processing than programming languages.) I don't get the impression you are thinking of one of those "typed grammar" formalisms; I more get the impression that you are using the word "grammar" in an idiosyncratic way which elides the conceptual distinction between syntax and semantics, and ignores the standard usage in which the word "grammar" is primarily associated with the former not the later.
    - unfocussed_mike 5y ago
      The fact remains -- you cannot know that a Tcl program is syntactically correct without running it, can you? Because the full syntax is determined by the extensions. Can you write a parser for Tcl in Yacc? https://compilers.iecc.com/comparch/article/99-08-100 https://compilers.iecc.com/comparch/article/99-08-100 http://computer-programming-forum.com/57-tcl/7aaac08c64c8c610.htm http://computer-programming-forum.com/57-tcl/7aaac08c64c8c61... This is why I say Tcl doesn't have a grammar. It literally lacks one by definition. Unless something fundamental has changed. IMO it's a terrible language which should have been left in the last century with perl4.
thaumasiotes 5y ago
>> Aren't syntax and grammar synonymous? > No. (Syntax is a subset of grammar.) Your answer does not agree with dictionary definitions, common usage, or linguistics terminology.
- unfocussed_mike 5y ago
  Syntax is part of grammar. Not all of it. They are not interchangeable or two sides of the same coin. That's all. You need syntax to then establish a grammar. We're talking about a programming language here, of course. Admittedly, you could say that Tcl is a language in the sense that english is (I was genuinely just snarking in my original comment). Because Tcl (unlike Java or C or Forth or Lisp) is context-sensitive -- the only way to know if a Tcl program uses its syntax correctly is to run it! With Java/Forth etc., you can tell whether the syntax is being used correctly because these languages have a context-free grammar. This has advantages. Above all these criticisms are why I think people should not learn Tcl as a serious endeavour if it can be avoided; it should be left to history with perl4.
  - skissane 5y ago
    > Because Tcl (unlike Java or C or Forth or Lisp) is context-sensitive -- the only way to know if a Tcl program uses its syntax correctly is to run it! I mentioned in my other comment how Lisp and Java are much closer to Tcl than you think they are. But that's true of Forth as well. Forth IMMEDIATE words are equal in power to Common Lisp reader macros, they also allow you to define arbitrary custom syntax – you can even define some custom syntax and then immediately start using it. Just like Common Lisp, it is impossible to know whether a Forth program uses its syntax correctly without running it through a complete Forth runtime environment.
  - thaumasiotes 5y ago
    Where are you supposedly deriving your definitions from?
    - unfocussed_mike 5y ago

skissane 5y ago

> No. (Syntax is a subset of grammar.) Can you elucidate what you see the relationship between them as being? > No, it's also because it's a pattern-based preprocessor. What do you mean by that? Why does being a "pattern-based processor" imply something has "no official grammar"? > There are efforts to produce Markdown grammars; some have been done. So, if people have produced grammars for it, it has a grammar, no? > No, these are not the same. How and why are they different?

unfocussed_mike 5y ago
> Can you elucidate what you see the relationship between them as being? Grammar covers the correct use of the syntax of a language. With syntax alone you cannot know whether a program is a correct use of a language -- that is, it will parse or compile, even if its output is nonsensical. A grammar lets you do that. So for example an unambiguous grammar is essential to being able to translate higher level language into assembly language. > What do you mean by that? Why does being a "pattern-based processor" imply something has "no official grammar"? Can you parse and transform arbitrary HTML correctly with only regular expressions? The answer as I am sure you will know is no. That is your answer here too. > So, if people have produced grammars for it, it has a grammar, no? I don't know if any Markdown grammar exists that expresses all of what you can do in the reference implementation of Markdown, so *shrug*. Maybe, maybe not. The fact that it has no deliberately designed grammar is an interoperability problem though. > How and why are they different? Because you are comparing extending semantics within what is allowed by the grammar (writing functions in the programming language it concerns) (e.g. in Java), and extending the interpreter itself (Tcl as a "language" changes according to which extensions are compiled in, and the extensions determine what the symbols mean). The fundamental question here is this: Can a program conclude that a Tcl program will parse correctly (even if the code itself has errors) without running the specific Tcl interpreter for which it is designed (or at least without knowledge of the implementation of its extensions)? No, it essentially cannot. That is what a grammar gives you. You can stare at a bit of C code you do not understand and at least say "it is valid C". And so can another program (a static analyser/explorer, a linter, etc.) More difficult with Tcl. (And perl4, for example)
- skissane 5y ago
  > Grammar covers the correct use of the syntax of a language. With syntax alone you cannot know whether a program is a correct use of a language -- that is, it will parse or compile, even if its output is nonsensical. A grammar lets you do that. Suppose I am writing a Pascal compiler. I might start with a grammar for Pascal, expressed in EBNF. I might write a parser from that grammar, either by hand, or by using some parser generator. My parser converts text (or a sequence of tokens generated by an independent lexical analysis stage) to some kind of parse tree or abstract syntax tree. Since Pascal is a statically typed language, I also need to write some code to do type-checking. If you look at a tutorial on writing a compiler, you might see this presented as a subsequent compilation stage, after parsing is complete. It takes the AST and symbol table, annotates it with type information (possibly even doing type inference), and checks various rules are obeyed. And, an EBNF grammar doesn't tell us how to do it. Generally you'd either express it informally, or if you were going to use some kind of formalism, you'd use a rather different formalism from those in which programming language grammars are commonly expressed. There are "typed grammar" formalisms which combine type-checking into parsing, but you don't see them commonly used by people implementing programming languages in the real world. In my experience they are mainly popular in academia (and I've seen them presented more often in the context of natural language processing than programming languages.) I don't get the impression you are thinking of one of those "typed grammar" formalisms; I more get the impression that you are using the word "grammar" in an idiosyncratic way which elides the conceptual distinction between syntax and semantics, and ignores the standard usage in which the word "grammar" is primarily associated with the former not the later.
  - unfocussed_mike 5y ago
    The fact remains -- you cannot know that a Tcl program is syntactically correct without running it, can you? Because the full syntax is determined by the extensions. Can you write a parser for Tcl in Yacc? https://compilers.iecc.com/comparch/article/99-08-100 https://compilers.iecc.com/comparch/article/99-08-100 http://computer-programming-forum.com/57-tcl/7aaac08c64c8c610.htm http://computer-programming-forum.com/57-tcl/7aaac08c64c8c61... This is why I say Tcl doesn't have a grammar. It literally lacks one by definition. Unless something fundamental has changed. IMO it's a terrible language which should have been left in the last century with perl4.

thaumasiotes 5y ago

>> Aren't syntax and grammar synonymous? > No. (Syntax is a subset of grammar.) Your answer does not agree with dictionary definitions, common usage, or linguistics terminology.

unfocussed_mike 5y ago
Syntax is part of grammar. Not all of it. They are not interchangeable or two sides of the same coin. That's all. You need syntax to then establish a grammar. We're talking about a programming language here, of course. Admittedly, you could say that Tcl is a language in the sense that english is (I was genuinely just snarking in my original comment). Because Tcl (unlike Java or C or Forth or Lisp) is context-sensitive -- the only way to know if a Tcl program uses its syntax correctly is to run it! With Java/Forth etc., you can tell whether the syntax is being used correctly because these languages have a context-free grammar. This has advantages. Above all these criticisms are why I think people should not learn Tcl as a serious endeavour if it can be avoided; it should be left to history with perl4.
- skissane 5y ago
  > Because Tcl (unlike Java or C or Forth or Lisp) is context-sensitive -- the only way to know if a Tcl program uses its syntax correctly is to run it! I mentioned in my other comment how Lisp and Java are much closer to Tcl than you think they are. But that's true of Forth as well. Forth IMMEDIATE words are equal in power to Common Lisp reader macros, they also allow you to define arbitrary custom syntax – you can even define some custom syntax and then immediately start using it. Just like Common Lisp, it is impossible to know whether a Forth program uses its syntax correctly without running it through a complete Forth runtime environment.
- thaumasiotes 5y ago
  Where are you supposedly deriving your definitions from?
  - unfocussed_mike 5y ago