> Where do you think a language like Inform fal...
# thinking-together
Where do you think a language like Inform fall on the ‘formal’ vs ‘informal’ spectrum?
Preliminary question; what exactly changes from one end to the other of that spectrum? My current answer is: how much of the total information conveyed is formal. I'd love to hear from others who have thought about this question, or know about work on this topic in the literature. To illustrate my definition, a few examples: • Machine code is near 100% formal. • Standard programming languages are mostly formal, the informal part being the variable names, which convey context-dependent information to humans but nothing to the compiler/interpreter. • Markup languages (HTML, Markdown, ...) are mostly informal, because the formalized information is not the most relevant part. You could strip it away and the rest would still fulfill its purpose. There are lots of subtleties I am glossing over. Example: A Python program saying
with a 100 KB string is basically just decorated informal prose. My definition applies to typical or intended use, not possible extremes. Back to Inform: I cannot judge from the example which information is extracted from the code by formal processing. Is this a controlled natural language, like Attempto ? Or plain English from which some engine extracts isolated keywords?
Informal aspects of notation are generally known as 'secondary notation' in the psychology of programming literature https://en.wikipedia.org/wiki/Secondary_notation
as part of the cognitive dimensions of notation https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations
I like to cleave “programming languages” into 2 categories (1) human readable and (2) machine readable. The task of developing programming languages boils down to figuring out how to map (1) to (2). I think that the best language for (2) machine readability is Lisp syntax (not necessarily Lisp semantics, which is a different issue). I think that the best language for (1) human readability is a hybrid of box-and-arrow diagrams mixed with text. Currently, I am writing programs in
and compiling them to executable Odin code (thanks to Zac Nowicki). I am using this, also, as a visual shell (VSH) to plumb together Ohm-JS and ‘.RWR’ (“rewrite” nano-DSL) specifications to form transpilers (e.g. Scheme->JS). I firmly believe in what I learned in Physics - invent multiple notations suited to expressing the task(s) using “simplifying assumptions” and bolt them all together to form solutions using divide-and-conquer mentality.
@Alex McLean Thanks for those pointers! This area looks a bit messy: the article on cognitive dimensions says that secondary notation is independent of syntax, and the article on secondary notation quotes syntax highlighting as its first example. More to the point, I don't see any of these dimensions as being about degree of formalization of the basic notation. It seems to be tacitly assumed that it's a highly formal programming language.
I suppose syntax colouring is still independent of syntax in a sense.
With the exception of e.g. Piet.
Are computer programming languages highly formal by definition?
The only definition I am aware of is "formal language", which is defined as a set of symbols plus a set of syntax rules for valid expressions made from these symbols. That definition covers numbers written as Arabic numerals (or Roman numerals if you prefer). It also covers HTML, no matter the contents of the page. And it covers programming languages, which are formal languages with execution or evaluation semantics. But that definition covers only the formal aspects of formal languages, not the informal aspects that remain outside of the definition. Like, for example, the information conveyed by the variable names of a program.
So for HTML would you say that the data is informal language, but the metadata/semantic markup around it is formal language?
Yes. XML is a more difficult case, because it is used both as a markup language for textual documents (i.e. Docbook) and as a file format for storing tree-structured data.