> If we process code [in a particular manner] Apologies if I'm harping on about this too much but I would like to object to "If" as being too ambiguous in this

> If we process code [in a particular manner] Apologies if I'm harping on about this too much but I would like to object to "If" as being too ambiguous in this context. The most active non-memory/attention brain circuits used in comprehending the code samples in the study I referenced were consistently for natural language processing, not math/logic processing, for all 17 of the 17 participants in the study. It's a small test but a pretty emphatic one nonetheless. For at least some folk (and it's at least plausibly most/all folk) for at least some code (and it's at least plausibly most/all code), it's "WHEN we comprehend code we use natural language circuits and so...", not "IF...". > that argues for having our programming languages emulate natural languages. Well, careful. Natural languages are fuzzy! We want programming languages that do TWO things -- leverage our natural processing capacities to the degree they're relevant AND render their fuzziness relatively harmless at the same time. > Even in matters of precision such as legal contracts, we don't always conform exactly to the "rules" of grammar - indeed I'd say that legal language violates those rules even more than natural language does. Yes. This is a very important point. Think in terms of thousands of DSLs. How does one enable that? How does one cope with that? > To my mind that suggests an ideal programming language would not "hardwire" rules of grammar Right. The Perl 6 project not only addresses this but is a full frontal assault on it. It's one of the various reasons it took 15 years to get to 6.c. There's a standard Perl 6 grammar but Perl 6 Rules can relatively easily specify any grammar. And I mean any grammar, whether Chomsky hierarchy level 1 (regular languages -- where regexes originally came from) or level 2 (context-free -- where parser combinators have traditionally shone) or level 3 (context-sensitive -- various parser combinators extensions have recently started to nibble at this) or the final level 4 (recursively enumerable languages). Aiui Perl 6 can reasonably be viewed as the world's first practical "universal unrestricted grammar" capable of accepting any other language.[1] > sigils should be more like flexible hints to the reader than things that have rigid language-level meanings. Sure. For starters, sigils are just a part of standard Perl 6. You can write any language in Perl 6. So, for example, the ipso language is a sigil free lang (it's a lisp) in Perl 6[2] and Slang::SQL is for embedded SQL.[3] If we stick to standard Perl 6, sigils just mean a few very general things, as follows. First, that the associated term is primarily a "noun". This determines where it does and doesn't fit in the grammar. Then particular sigils -- the main ones are $, @ and % -- establish some other properties of a given noun. $ emphasizes the noun's singular nature rather than any potential plural nature it might also have. @ emphasizes the noun's plural nature and having an integer index (the array `my @bananas[15]` corresponds to a bunch of 15 bananas indexed by 0 thru 14). And finally % emphasizes plural nature and having an associative index (%colors<red> corresponds to the 'red' key'd value in the %colors dictionary). You might argue that those are rigid. I'd counter that they correspond to human's natural processing circuits. But regardless, if you don't like them or want to repurpose them you can just create a slang or another lang that tweaks or entirely changes the grammar to suit your needs... [1] https://en.wikipedia.org/wiki/Unrestricted_grammar https://en.wikipedia.org/wiki/Unrestricted_grammar [2] https://github.com/masak/ipso https://github.com/masak/ipso [3] https://github.com/tony-o/perl6-slang-sql https://github.com/tony-o/perl6-slang-sql