[scott_s]

I had a similar reaction, and I'm not sure that it's a "damn kids, get off my lawn" reaction. Specifying an unambiguous grammar may be difficult - which implies parsing may become a problem.

An implementation exists, so the author has something working, but I'm wondering how robust the parsing is. I haven't seen many code examples (only short fragments on the page), so I don't know what potential issues, if any, there are. But, this is the sort of thing that could significantly complicate adding new language features that requires additional syntax.

edit: I'm perusing the source for the compiler, which is of course written in Zinc. This code from the main driver of the compiler perhaps gives a better feel for how it may look in practice:

  while i < argc
    def arg = argv[i]

    if is equal (arg, "-debug")
      debug = true

    elsif is equal (arg, "-v")
      version = true

    elsif is equal (arg, "-u")
      unicode = true

    elsif is equal (arg, "-o") && i < argc-1
      out filename = new string (bundle, argv[++i])
      to OS name (out filename)

    elsif is equal (arg, "-I") && i < argc-1
      append (include path, new string (bundle, argv[++i]))

    else
      filename = new string (bundle, arg)

    end

    ++i
  end

From an aesthetic point of view, it doesn't look that bad. In this example, I think "is equal", "out filename", "to OS name" and "include path" are all identifiers. But I'm still wondering what kind of parsing and lexing issues that may arise.

[nene]

I already have hard time parsing this code. The main problem I see, is that to read the code I have to know every single keywords in the language.

For example I was wondering if "new" is a keyword. If it is, then "new string ()" might be something interesting, otherwise it's just a function call.

Similarly this raises a question of whether I can write the following code:

  if end of line (str)

This might or might not be permitted because "end" is a keyword. If it is permitted, then the result looks pretty damn ambiguous to me. If it's not then I have to name my identifier differently, like so:

  if end_of_line (str)

But then I'm skrewing up the style of my code...

[scott_s]

I thought of the recognizing a keyword issue, but then I dismissed it: syntax highlighting make it a non-issue. The ambiguity with using keywords in identifiers is valid, though.

[kranner]

Syntax highlighting is not available everywhere, e.g. in black-and-white print.

[tianyicui]

Usually black-and-white print use bold to indicate the keywords.

[chc]

Your complaint is that you can't parse the code with 100% certainty without some basic knowledge of the language? That hardly seems like a complaint at all. The same is true of any language that isn't explicitly identical to one you already know.

[mattmanser]

No, his complaint is that you can't parse the code without knowing all the keywords in the language.

He wrote every single keyword == all the keywords.

That's not basic knowledge of a language.

Maybe I'm odd, but when I start on a new language I don't learn all the syntax first, I usually I start mucking around with variable declaration, iterators, simple stuff like that just to get a feel of it. I'm guessing it's not that odd as most tutorials also follow that approach.

[chc]

I don't see how what you said disagrees with what I said aside from a minor semantic quibble. You can't parse any other language with certainty without knowing all the keywords either. For example, in Ruby, you might see the identifier "continue" by itself. Is this a method call, variable access or keyword? What about "private"? No way to know if you don't know all the keywords. This is precisely cognate with nene's objection that you can't tell whether "new" is a keyword in Zinc if you don't know the language's keywords.

You can form a rough guess of what the various tokens are in a snippet of Ruby code without knowing all the keywords, and you can do the same with Zinc code. Any additional difficulty is most likely because you're less familiar with Zinc, not because it has the nearly universal property of needing to know the full grammar to correctly parse arbitrary programs.

And I agree, playing around with a language is a great way to learn. But if you play around without reading about the things you're doing first, you should expect not to always know what you're doing. That's a huge part of the learning process.

[jbri]

No, you can't really do the same with Zinc. In Ruby, if there's a keyword somewhere, it's pretty damn obvious it's not part of an identifier.

With Zinc, you need to know what all the keywords are just to tell what the name of something is.

And that doesn't even start on additions to the language completely breaking your code because you used that word in an identifier somewhere...

[jhpriestley]

Issues only arise if the language designer wants to use spaces for something else as well (like function application).