primitive strings and other such things

[jeisner]

Strings should be double-quoted.

I'm not sure what the current single-quoted strings mean: in Prolog, that's just a way of writing functors that may contain special characters (if we decide to continue to support such functors)

[nwf]

Single-quote functors and double-quote strings are both supported by the parser. At present, strings are a little unfriendly in that they are not lists of characters -- they are just atoms like functors -- and we do not offer any string-specific functions from the back-end. That said, Tim is quite the expert in using mod/2 and an eval/1 hack to build custom Python from within Dyna.

The REPL occasionally single-quotes things that perhaps it should not; is that what this bug is about?

[jeisner]

The bug was reacting to the fact that one of the sample programs represented words like 'caviar' rather than "caviar". These are different, e.g., word(epsilon,I,J) is usefully different from word("epsilon",I,J) but is presumably equivalent to word('epsilon',I,J).

[timvieira]

Python allows for a variety of literal string delimiters, not limited to single and double quoted strings. I really like this feature because it lets me avoid escape characters. I know Prolog uses single quote for its operators, but perhaps backticks (like Haskell) would be better?

`++`(X,Y) instead of '++'(X,Y)

allowing 'one to "quote" with out the \"escapes\"'

On the other hand, I do really like X' as a variable name -- possibly more than I like single quoted strings -- does this pose a parsing problem for single quoted operators or strings, @nwf?

[jeisner]

String literals: The "foo" form is the default. We can consider extending this to also allow """foo""" as in Python, but we don't have to decide that now. I think single quotes are too valuable to waste on alternative string literal syntax.

We may not have to fuss too much about string literal syntax. That's because string literals are perhaps not going to be all that common in user-written Dyna programs, but only in dynabases that contain lots of data, which are more likely to be generated automatically. That's because string manipulation and printing are more likely to be done in a procedural language that calls Dyna. (But I might be wrong. We may have a print command in the scripting language, and we may also use Dyna to define text or drawings that contain text.)

Quoted functors: It is definitely tempting to disallow 'foo' or to change it to [backtick] foo [backtick] as Tim suggests. That would free up the ' symbol so we could

• write 'foo(a,b) instead of &foo(a,b) to suppress evaluation
• use ' as a prime symbol within X' as tim says and also f'. Actually I think ' should probably be a postfix operator so that the user can define X' = transpose(X) or F' = derivative(F), and then go around writing x' and f'. Making ' be an operator means that X' is no longer a variable, though.

Can we drop quoting of functors altogether? Prolog has it, but maybe Dyna doesn't need to. Two routes:

• Restrict functors: Say that functors have to be nice identifiers as in most languages. Prolog uses quoted functors partly as a way to hack in strings, but we have separate strings, so maybe it's not needed.
• Still allow arbitrary char sequences as functors, but not using functor(args) syntax. It is cleanest from a type viewpoint if the $functor member of a term can be any string; and it's convenient to say that X+Y is parsed as a term whose functor is + rather than plus. So I think I'd prefer this option. The problem is that some constructible terms then don't have a standard print notation, but maybe we can get away with an explicit $functor keyword argument, i.e., [$functor="#$X?!", 3, 4] rather than #$X?!(3,4).

[nwf]

Can we drop quoting of functors altogether?

Cross-reference issue #49.