Update to Tutorial D, July 2020
Quote from dandl on July 29, 2020, 12:33 amYes, the simplified syntax would be preferable. I should point out that
=is marginally preferable to:=for constants, as it's not really assignment.And why stop there? The whole language could benefit from this kind of streamlining.
I've often thought a fun exercise, when I have a bit of spare time, will be to create an alternative Rel Tutorial D grammar where the various syntactic Tutorial Disms are converted to conventional C/C++/C#/Java/JavaScript syntax. All the semantics will be preserved; it will strictly be syntax changes.
It should be straightforward (assuming it doesn't wind up being ambiguous) -- mostly changing BEGIN and END to { and }, using C-syntax conventions for defining operators, changing flow control and variable declarations to a close approximation to the usual C syntax, using infix or "function"-invocation syntax for all operator invocations, etc.
The result could be very appealing, fashionable, and -- at least for those used to that family of languages -- easy to code in.
The main distinctive feature is that it's a language of values, not objects. That might be confusing. Have you looked at other FP languages?
From my experience with Andl, the main feature I really liked was writing RA 'pipes' in dot notation, like LINQ. I dislike nested parentheses, for readability and bug proneness (if that's a word).
Quote from dandl on July 29, 2020, 1:37 pmThe main distinctive feature is that it's a language of values, not objects. That might be confusing. Have you looked at other FP languages?
Yes, but I was mainly thinking of ways to make typing -- and remembering where to put punctuation, and remembering whether it's 'r EXTEND {...}' or 'EXTEND r: {...}' -- a bit easier, and maybe for those new to the language (and without the benefit of knowing Tutorial D's closest living syntactic relative, PL/I) maybe a bit more intuitive.
For 'EXTEND', after always getting it the wrong way around, I made Rel support both.
From my experience with Andl, the main feature I really liked was writing RA 'pipes' in dot notation, like LINQ. I dislike nested parentheses, for readability and bug proneness (if that's a word).
Tutorial D supports method, er, operator chaining. In fact, it would be awkward without it. It doesn't need the dot. Currently, parentheses are only needed to force precedence, but due to the mixed prefix/infix syntax, are often required. With a consistent prefix notation, precedence of relational operators could simply be left to right.
Anyway, I'd definitely keep operating chaining.