Daniel Buckmaster
07/11/2023, 11:30 PMGregg Irwin
07/12/2023, 2:08 AMparse
function, which makes it relatively easy to write BNF-like PEG grammars to build dialects (eDSLs). Not only at the string/char level, but at the value level, because everything is data once loaded from text.
All those lexical forms (and also standard types that don't have a literal syntax) can be used in your dialects. This makes for a very flexible and powerful "language construction toolkit", which is how I sometimes describe Red. And to bring it full meta-circle, parse
and other features are dialects, as is the low level Red/System
language, a C-level language that shares syntax, but not semantics, with Red and is used to write the runtime for performance reasons (it compiles to machine code). e.g. it's static and lacks most high level datatypes. Red also has a GUI dialect.
Now, for how expressive this all is...I'm biased, but there is an aspect that isn't very flexible: lexical forms (literal syntax for values). You have to hack the lexer and add new types for that, which is by design. Why not make it easy? Back to Red being a messaging language. In the context of data exchange, you need to agree on the basic language elements.
Formatting is another facet of expressivity. Consider poetry, free verse versus something like a pantoum or sestina, which are very rigid forms. This relates to both form and function for PLs. Whitespace, line breaks, statement-ending punctuation, all effect how you write for your readers, and perhaps how susceptible things are to (un)intentional corruption. e.g., you can't strip spaces and lines from a Python program. On the function side, we veer into static/dynamic aspects.
The less rules you have, the more expressive you can be. Consider art. What you gain in expressive freedom, you may give up in appreciation. Constraints are important, but also contextual. Can you have an effective fully expressive GPL? Or to get that (ASM) do you give up too much "appreciation", because we also have to share, communicate about, and understand these works we craft.
Personally, I think we have to balance things based on context. Be as flexible and expressive as possible, in the target domain, to the point where any more leads to less benefit and more cost for target users. Please some of the people, most of the time.Duncan Cragg
07/12/2023, 7:51 AMKonrad Hinsen
07/12/2023, 8:41 AMJimmy Miller
Andrew F
07/12/2023, 5:11 PMGregg Irwin
07/12/2023, 7:44 PMJimmy Miller
Gregg Irwin
07/12/2023, 7:49 PMnumber
but have many types of strings (plain, filename, email address, url, tag, etc.). Maybe you justify a Cartesian coordinate type, but not UTM coordinates for mapping projections. How do we keep from being overwhelmed, while being able to express things (thinking text here) as we do with natural language?David Alan Hjelle
07/13/2023, 1:11 AMGregg Irwin
07/13/2023, 5:18 AMDavid Alan Hjelle
07/13/2023, 12:43 PMDuncan Cragg
07/13/2023, 10:19 PMI enjoyed the little tangent on expressivity in the latest episode. I've had thoughts on this recently and it prompted me to skim Felleisen's paper. I really resonated with the hosts' reframing of expressivity as being the part of the language that's oriented towards the programmer, not towards the machine.Many decades ago I coined the acronym "DTIL" or Domain and Target Independent Language, to clarify what I was seeking in my Perfect Programming Language. Meaning: a language that's not in any way constrained by the machine (the Target) OR the Domain of application. A pure language of thought. A language that allows expression by humans in their most intuitive way of what they wanted the computer to manifest for them. So a cognitive-oriented programming language, but I was only allowing a formalism or symbolic mechanism, rather than in any way a natural language, which I saw as redundancy-heavy and fuzzy. Declarative languages immediately stood out and wiped out Imperative languages for me, as these had too much Target (machine) orientation. The Declarative mantra "What not How" gives it away: just say What you want, don't tell the machine laboriously How to do it.
I currently think that most programmers, when talking about "expressivity", actually mean essentially two things:
1. I can use my own words
2. I am not restricted by grammar
These things are strongly tied to writing, as that's still how we do most of our coding.Hmm, then that's "just" asking ChatGPT!
"Using my own words" is literally that - in any given chunk of source text, how many of the words were chosen by the programmer (e.g. to be particular to their domain or their theory of the program) and how many were specified by the language or environment? Punctuation, I think, also counts as words the programmer didn't get to choose. Random examples:
• In Ruby, one can create little DSLs where almost all words in a specific part of the code are "my own words"
• In assembly languages, the programmer can choose almost none of the words (except labels?)
• Being able to rename imported symbols lets the programmer choose their own words in specific contexts (same goes for type aliases, etc.)
• Languages with few keywords should tend to have more words chosen by the programmer... or at least, by the authors of the standard library?It's important in a DTIL that the mechanisms available are pure and singular: there should be only one language representation of each cognitive entity and nothing that biases the language to either a machine or a domain. Ideally the whole base syntax should be just half a dozen unique things (like symbol, sequence, structure, consequence). An important aspect of this whole conception is that data should be simply strings or text and structures of that. If you have a "double" - rather than a "float" or "int"- you're immediately binding yourself to machine concepts, as provided to you by the FPU. In reality, humans don't think like that, we simply write our "data" in text. So spreadsheets and Awk have some precedent there. This leads to the (apparently radical) concept of type being simply syntax: if you parse a string or structure in a way that's meaningful to you, you've made your own type matcher and thus your own type. You don't have to be bound by the types in the mind of the originator of some data, or by the types the machine supports best.
I equate being "unrestricted by grammar" roughly to whether a language is statement-oriented or expression-oriented. The Austral spec has a great section on why it chose to be statement-oriented, and concludes that "a statement-oriented syntax is less simple, but it forces code to be structurally simple": https://austral-lang.org/spec/spec.html#stmt-orientation
In Austral, it's an ideological choice to force programs into a certain shape. But in general, it seems to me that languages with less "grammatical restrictions" in their parser are described as more expressive. Maybe this is just correlation with other features of those languages.Not sure about the statement- vs expression-oriented thing, but again, simplicity and power are key to maximising human expression of virtual stuff and their desired behaviours.
Konrad Hinsen
07/14/2023, 9:27 AMHow do we keep from being overwhelmed, while being able to express things (thinking text here) as we do with natural language?The comparison with natural language is difficult. Natural language serves for informal, i.e. context-dependent, reasoning. It's OK to have the same terms refer to different meanings in different contexts. In a formal language, everything needs to be explicit and non-ambiguous. So I guess different but similar-in-spirit and interoperable languages are probably our best bet. That's something I think Red got right. As did Racket (although it lacks the system layer for now).
Marcelle Rusu (they/them)
07/14/2023, 4:20 PMAndrew F
07/14/2023, 5:52 PMGregg Irwin
07/14/2023, 6:34 PMNatural language serves for informal, i.e. context-dependent, reasoning. It's OK to have the same terms refer to different meanings in different contexts. In a formal language, everything needs to be explicit and non-ambiguous.@Konrad Hinsen context is the very thing I meant. The question is, can we have both context and unambiguous use in a proglang? Red tries. For some people it's a reason to never consider using it, and they run screaming in terror. For others it's "I can use that to do this really wacky thing.". For most I believe it's "Oh, I have no idea what's going on under the hood. It just works." Finally, a few deep divers will say "It makes this edge/exception case impossible to handle in all cases, so it's a bad design." Maybe prompt-based development will lead us to new approaches where, like with human dialogue, the system can say "Did you mean A or B here?"
Konrad Hinsen
07/15/2023, 1:17 PMGregg Irwin
07/17/2023, 2:18 AMSteve Dekorte
07/17/2023, 12:03 PMChristopher Shank
07/18/2023, 7:08 AMJimmy Miller
Andrew F
07/18/2023, 2:31 PMJimmy Miller
Andrew F
07/18/2023, 4:22 PMMarcelle Rusu (they/them)
07/18/2023, 7:01 PMAndrew F
07/18/2023, 7:29 PMJimmy Miller
I strongly disagree that a visual representation of a red-black tree transformation is more expressive than a textual one in the same sense that a language with higher order functions is more expressive than one without.
I look at it this way: the notion of the ability of a language to express different programs as a function of basically its abstract syntax and semantics exists and needs a name. "Expressivity" already means pretty much that in academia, as far as I can tell anyway. Different serializations of the same abstract syntax (visual, textual, morse code) definitely do have effects on our squishy brains, making coding easier or harder, but they're easily localizable to a different part of the computing system.
Different thing, different name.I don't see any reason to privilege one of these as expressivity vs the other. Nor do I think they are clearly distinct concepts. They definitely do not form a natural kind and how we decide to divide them up is going to be based on our concerns and desires. Personally, I think it is good to call both of these things (and some others) expressivity because it causes us to look holistically at the way in which we express ourselves in programs. That to me is what expressivity about, how does this language help and hinder me from expressing things the way I want to express them. You might not want to call that expressivity for your purposes. I think that's totally fine.
Andrew F
07/18/2023, 9:36 PM