Quote Free Language

I'm leaning toward the belief that QuoteFreeLanguages may be better for DomainSpecificLanguages because one potentially uses more constants than variables[1]. At least it's an idea I'm toying with. It's partly inspired by ToolCommandLanguage, which to me had the feel of a good idea done wrong.

Instead of:

  field(ssn, "Soc. Sec. Num", "string", required=yes, template="AAA-AA-AAAA")

You could have:

  field($ssn, Soc. Sec. Num, string, required=yes, template=AAA-AA-AAAA)

You'd only need quoted values if there were commas, equal signs, or a left parenthesis in the constant.

More to come...

-t

---

How do you tell constants from keywords? If the constant/keyword ratio is high enough, you would want an escape mechanism to mark actual keywords. One example is TeX, a Turing-complete book-writing format.

I see no reason why key-words would have to be inside a statement.

---

[1] A high ratio of constants to variables can be used as a rough metric for the success of a DSL in my opinion. -t

---

What about constants that you wish to reuse?

    const commonstring = 'this is an error';

    ...
    func1(commonstring, foo, bar)
    func2(bar, foo, bar1, commonstring)
    if error then print(commonstring + " because you divided by zero");

If commonstring occurs several places throughout the program and is constant, how do you define this constant? Do you just make it a $variable even though it is not a variable and is a named constant?

I'm not sure I understand the question. What specifically are you trying to achieve? Many scripting languages don't have named constants and just use variables for the same purpose. Is it to "lock" the value so that the program doesn't accidentally change it? That seems more up the ally of compiled and "strong typed" languages where there is more rule enforcement expected. I'm happy to keep the draft "scripty" at this point. Have a "defineAndLock" function if you really want such in your pet language:

Reinventing constants, reinventing types, what next? reinventing math and coming up with your own subtraction and addition? Are you seriously saying that constants are a useless tool and that it is better to leave things as variables even if they are constant.. and then add some futzing around function like "defineAndLock" instead of the more clear "CONST". ReinventingTheWheel again.

You like what I sometimes call "nanny-state languages". I get that. As I've said elsewhere, different domains and needs fit best with different kinds of programming languages. I'm not going to bring the protection-versus-free-form battles into this topic. I'm just kicking around ideas. If you want to fork this topic and create TypeSafeQuoteFreeLanguage?, that's fine by me. -t

Your language is nanny state when it does things like isNum() or "validation" as you call it. Validation is nannystate, you crackpot. You claim up above that a high concentration of constants are in DSL's. If so, why not support a CONST feature. You make no sense and are completely contradicting yourself. Oh yeah, and please provide empirical evidence for your claim about constants in DSL's.

Your nanny measuring techniques don't make any sense to me. My point was originally to make the language easier to type and read and perhaps be more compact because less text is devoted to quotes. I was trying to improve expressiveness, and not attempting to improve TypeSafety or related concepts here. I don't even believe that the need for a formal CONST declaration is more likely in DSL's than a regular app. Using more "embedded" constants doesn't necessarily translate into needing more named constants. At least that's my experience with my DSL-like areas of apps. It's not something that would have improved things in a noticeable way for me. (But I do realize that different people make different kinds of errors in different frequencies.) I don't like to add extra features to languages unless have have sufficient utility. And, no I have no empirical counts/surveys. It's just an observation of mine. If your experience varies, so be it. You have the freedom to express your experience on this topic also.

Constants are not type safety. Being able to label a common constant such as "this is a very long error message about so and so" to "ERR_STRING" is very useful and has nothing to do with type safety. It allows you to edit the string in one single place instead of copy and pasting the string all over the program. It is similar to when you keep using a procedure over and over again, you make one procedure and keep reusing that named procedure instead of copy and pasting the code everywhere.

Variables can do the very same thing. I didn't do away with variables.