Le ven. 3 juil. 2020 à 18:50, Adam Sobieski adamsobieski@hotmail.com a écrit :
Abstract Wikipedia Mailing List,
Hello. Congratulations on launching the new and exciting Wikilambda and Abstract Wikipedia projects.
I am very excited by wikilambda and abstract wikipedia because it intersects with several of my projects.
Which Programming Languages?
Which programming languages are to be developed with on Wikilambda for use with Abstract Wikipedia?
Might a new programming language be useful?
A new programming language will be a mistake because it will increase friction and reduce the ease of adoption, also it will require to rebuild the wealth of documentation that exists for existing programming languages. It is sure that people do not love to learn new languages. wikilambda should be a trampoline toward regular (?) programming hence if / when possible not re-invent the wheel.
I already did that research for myself and find that scheme hits a sweet spot (even if there is a lot of parentheses). Wikilambda will probably not need call/cc (but might require exceptions) and macros. So, it will make the implementation much much easier. I mentioned the parentheses, well there are sugar syntaxes that allow you to work around it. In particular, Racket is working on a wanna-be mainstream language that will be the best of all worlds... See https://github.com/racket/rhombus-brainstorming/blob/master/resources/goals.....
Might it be useful to transpile a new programming language into an existing one (e.g. resembling TypeScript and JavaScript)?
That will be great, for sure. I think the best target will be Web Assembly.
Models of Function Definitions
On the topics of programming language design, while we most often consider functions as being comprised of signatures and bodies, might it be useful to consider models of functions with more components? We could express such things with multiple, nested “{}” brackets or scopes.
In some models, a function definition might include a guard, preconditions, a body, and effects.
Inspired by PDDL:
function foo(…) { guard { /* … */ } preconditions { /* … */ } body { /* … */ } effects { /* … */ } }
It seems to me it is similar to Racket contracts. I am not very familiar with those. I will prefer that complexity to be opt-in, unlike the previous generation of statically typed programming language (C, C++, Java) and which is to some extent still the case (Rust, in particular, is not very friendly to the newbie even seasoned developer).
My idea about the subject of "specifying" the expected behavior of the program inside the program is to rely on "asserts" which are opt-in and can be disabled. The idea is to infer types from asserts. Remain the question of who to specify exceptions (which is missing from Python's gradual/optional typing facility).
In other models, a function definition might include requires, a body, and ensures.
Inspired by code contracts:
function foo(…) { requires { /* … */ } body { /* … */ } ensures { /* … */ } }
Such models can be phrased as transformations or mappings from existing languages that separate and organize varieties of content that frequently occur in function body definitions.
I prefer to imagine a programing language as a sandbox. And document patterns and designs.
Structured Comments, Metadata and Versioning
Structured content (e.g. XML) in comments is both useful and increasingly popular. Structured comments can provide extensible metadata for functions, ease the searching for functions in large collections, and make possible the automatic generation of documentation.
I am not against the idea of comments. That said, I am not sure what structured means in this contexte. XML to document functions? Seriously? Again, I think I prefer complexity to be opt-in, and help spread good practice through IDE, linter and other toolings.
Structured comments could be processed and utilized by the Wikilambda project to provide features.
Certainly comments will be useful.
Also, some programming languages (e.g. C#, Java) have the expressiveness of metadata attributes which can adorn methods and their parameters. A useful attribute is [Obsolete] which supports the use of messages to make use of a newer version of a function, e.g. [Obsolete(“Consider use of foo_2 instead.”)].
That can be scraped from code... Adding "adornement" would complicate the syntax and increase the surface and required knowledge necessary to play with the language. I imagine that simply having a function that is "log.warning("deprecated", ...)" is good enough.
Namespaces and Modules
Namespaces and modules can be useful when organizing large collections of functions. With namespaces or modules, multiple paradigms or ecosystems of functions could coexist in a crowdsourced resource for use in natural language generation scenarios.
Not necessarily, content-addressable code does not require namespaces.
Global Variables and Runtime Environment API
Global variables, such as the currently desired natural language for output, could be provided by the runtime environment. An API could be specified for the runtime environment.
I was under the impression that global variables were evil!
Output Streams, Logging and Diagnostic Events
When editing / developing Wikilambda content for use on Abstract Wikipedia, it would be convenient to be able to output to multiple streams, to log, or to raise typed events. It would also be useful to be able to aggregate, organize and view these diagnostic outputs with a configurable granularity or verbosity.
Developer Experiences with the Rendering of Natural Language
A possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that one could view rendered articles and hover over natural language output to view relevant diagnostic messages in hoverboxes.
Another possible user experience for Wikilambda editors / developers is having a means of toggling a developer mode or debugging mode on Abstract Wikipedia such that visual indicators for diagnostic messages would be placed in a margin to the side of rendered natural language output.
Best regards,
Adam Sobieski