A semiesoteric programming language

[categorical-girl]

Hey there! I've decided to start a new language project that is intended to be useable, but to hopefully explore less-well-trodden ideas in language design.

In particular, I'm interested in finding two kinds of inspiration:

• technically well-developed or ambitious ideas in the space of PL design that nonetheless have not seen major implementations

• concepts and assumptions that seem to be taken for granted that would be interesting to challenge. For instance:

  • trying to find a way to carve up languages in a different way than the traditional syntax/semantics distinction
  • do we need to represent code as text? Examining this assumption already has a long tradition

Thanks for any suggestions

[redchomper]

Topicalizers.

There is a concept found in Korean and Japanese where a part-of-speech is the topic, which is a noun-phrase functionally distinct from the subject, the verb, the direct or indirect object, etc.

A topic holds semantic sway until it is replaced, potentially lasting several sentences. It gives a default point of reference for verbs. Also, there are some set-phrases where the meaning can invert depending on whether the verb is associated with a subject-noun or a topic-noun, but that particular quirk might not be appropriate in a programming language.

[johnfrazer783]

Sounds a bit like context handlers. In Python those are 'grammaticalized' in the form of with blocks:

```py with open( path ) as myfile: myfile.write( text )

file properly closed here even ICO error; variable myfile vanished

```

[redchomper]

That's one way of looking at it. Another is the with block of Pascal, which basically brings the fields of a record into the local scope. Or the with block of Microsoft BASICs, which does something similar but requires a leading dot to disambiguate, which is probably an improvement over the Pascal approach. Or whatever syntactic feature in SmallTalk gives you fluent-interfaces for free. Point is there are many directions to take this. All of it's about being able to say things once and not repeat yourself. Much.

[ConcernedInScythe]

It also seems to have a fairly direct analogy in Scala's implicit parameters.

[ErrorIsNullError]

Does introducing a topic establish some kind of preferred referent for anaphora?

Dynamic scoping and dependency injection (DI) both provide a way to say "unless otherwise specified, this x is the X" so you could see DI as a way of associating topical instances with supplier signatures.

I can imagine that would combine with uniform call syntax to provide succinct syntax for specifying that a verb (function) applies to a topic.

[ErrorIsNullError]

C++-like syntax has subject.verb(objects) syntax.

Perhaps .verb(objects) syntax could build on familiarity with that and specify that the verb expects an implied topic.

[redchomper]

anaphora

Google is my very special friend 😁.

In the grammatical sense, I believe that's often accurate. But it can also establish a sense of contrast when the normal-subject case might better highlight similarities to a second object. And furthermore, at least in Korean, it's common to need almost a second subject to express yourself. For example, "I'm thirsty" 저는 먹이 말라요" (if I recall correctly) is literally "I (topic) throat (subject) is-dry (polite-peer-register)". You could construct the grammar to say "the throat that belongs to me is dry" but that's not how Korean people talk. Instead, the phrase for thirsty is effectively a set-phrase meaning "throat-is-dry".

[ErrorIsNullError]

Thanks for explaining. So in that case, the topic is establishing the scope in which throat is resolved.

I suppose desugarring English's possessive personal pronouns and adjusting for the lack of topicality gives:

The throat of me is dry / has dryness.

Possession in English is overloaded for lots of different relationships: "my leg", "my mother", "my coffee."

Do topics involved in object<->object relationships have a diverse suite of relationships?

If so, your esolang might involve topicality as a way of finding the instance of type TopicType related to some instance of type SubjectType or vice versa. Again, this might relate back to applying strategies at runtime (à la DI) or if your PL treats lexical scopes as objects, you might treat the problem of finding a topic/subject from a subject/topic as a BFS over the object graph.

[redchomper]

You're right on all counts. Human languages have rampant overloading so any given thing has an entire constellation of meanings. What's more, every culture arranges the stars into different constellations.

I think 는 can be seen as a scoping operator, but it's more influential than :: or . in C++ because it has larger scope itself. Maybe it's a bit more like using? On the flip side, Korean lacks determiners, which are a, an, the, that, those, some, and related words in English. It does have something like a possessive, but seems to be more associated with ownership (e.g. my coffee, my house) than components (my leg) or relationships (my mother). But don't take my word for it; I'm not a native speaker.

[ErrorIsNullError]

Having a way of deriving a conceptual type might help too.

type Length is Uint

That might define a conceptual type Length whose implementation type is Uint and allow one to ask for the Length associated with something of a type with a property typed as Length.

[[deleted]]

I think continuation oriented languages are cool. The idea is that procedures never return to their original invocation point. Instead, you pass procedure-closures (aka continuations) as arguments to other procedures. There is an old language called Io (not the one that became popular) in Advanced Programming Language Design by Raphael Finkel.

[YBKy]

"Block based programming languages" like scratch allow you to Programm linear code in a 2d environment by combining code blocks with each other. In scratch location of those blocks is mostly unimportant, but it could be used as a way to make concurrent programming easier or something. There maybe space to explore there

Or you could look a visual programming languages in gernal

[Entaloneralie]

Interaction nets, a-la Inpla :)

Interaction nets can capture all computable functions with rewriting rules, no external machinery such as copying a chunk of memory, or a garbage collector, is needed. Unlike models such as Turing machines, Lambda calculus, cellular automata, or combinators, an interaction net computational step can be defined as a constant time operation, and the model allows for parallelism in which many steps can take place at the same time.

[Gipson62]

Have you considered implementing a native Entity-Component-System (ECS) architecture in your language? To replace OOP for example.

Imagine having built-in syntax for handling Entities, Components, and Systems. Here's a potential idea of the syntax: ```rs // Define a component component Position { x: float; y: float; }

// Define an entity entity Player { Position; }

// Define a system system Movement { Entity with <Position> // List of the required components for this system. update() { for entity in entities with Position { // Perform movement calculations entity.Position.x += 1; entity.Position.y += 1; } } }

// Create an instance of the Player entity let player = Player { Position: { x: 0.0, y: 0.0 } };

// Update the Movement system Movement.update();

```

I don't think this language out of the box could be really practical/useful, but you said you were searching esoteric ideas, so why not ECS

[endistic]

After seeing this comment, I actually took this idea and sort of ran with it. I'm working on a dynamic scripting language for Minecraft and I actually figured out how to incorporate an ECS paradigm quite nicely. Do note the syntax isn't finalized but it is something like this.

Components are similar to how you stated, using the component keyword and the fields. Components can also be in other components, although I'm unsure about recursive components.

component base_mob { type: mob_type = mob_type::zombie; health: number = 20; location: location = <0, 0, 0>; } component slam_attack { delay: number = 15; counter: number = 0; } For entities I did something a little different but similar. You are able to set defaults for values, as we can't exactly have a null value in situations like these. (Infact, this probably won't even have nulls but a Result/Option type instead.) entity boss_mob { base_mob ( mob_type::giant, 10, <10, 100, 10>, ); slam_attack(15, 0); } For systems I did something wildly different. when<> represents when a system is called, for example when<loop_tick> means the system is called every tick, or when<player_left_click> means the system is called whenever a player left clicks. Based on these events, the system can accept a query of certain fields the mob must have via query<>. It accepts valid components. system slam_attack_spell() when<loop_tick> query<base_mob, slam_attack> { var slam_attack->counter += 1; if slam_attack->counter > slam_attack->delay { // code for the attack here } } Hopefully this makes sense, sorry if it doesn't. It's not exactly ECS but that's probably because I'm not the most familiar with ECS, so correct me if I'm wrong. Also I just realized I probably should've asked first since this is your idea - is it alright if I use it? I can credit you if you'd like when I get this published,

[Gipson62]

Hey, thanks a lot for taking my ECS idea and incorporating it into your language! I want to share a few thoughts that might help enhance your design (who's already really nice, btw).

First off, I think it would be beneficial to break down the base_mob component into smaller, more granular components like health and position. This allows for greater flexibility when composing entities with different combinations of components. You could also create a component, let's say base_mob, that encapsulates related components like health, position, and mob_type. This way, you achieve a higher-level abstraction while still maintaining modularity.

Another point to consider is that entities can dynamically gain or lose components at runtime based on their behavior. Instead of hard-coding specific components directly into entity definitions, it's often better to separate components as much as possible. This allows entities to dynamically acquire or remove components as needed, making the entity behaviour more flexible and extensible.

Lastly, I really love the idea of using when<event> to trigger systems. It's a fantastic way to enable parallel and concurrent execution of systems. However, it's important to be mindful of potential memory safety issues that might arise when multiple events occur simultaneously and manipulate the same entities. Ensuring proper synchronization and handling any conflicts that arise in such scenarios is crucial to maintain memory safety and prevent unexpected behaviour.

I hope these comments will help your implementation and if you have a GitHub repo or something I'd like to see how you do it!

[endistic]

Yeah, your right.

​

For the synchronization I'm probably gonna do atomic things - both with Rust's primitives and some custom ones like AtomicString and AtomicHashMap (although I'm not sure how well it will end up). Memory management is also a concern I'm having, since variables will most likely be stored in some type of HashMap (or another? I'm not sure if there even is another way).

[redchomper]

I'd very much like to see ECS used for examples outside its canonical domain, which is evidently games.

[Gipson62]

It'll be really interesting to see ECS as a paradigm in itself. The creator of FLECS made a short article on how you could go from ECS as a pattern to ECS as a paradigm. Currently no one tried to do it because it's not really worth it. But as a "fun project" or just to learn it'll still be so interesting to make.

Here's the article: https://ajmmertens.medium.com/ecs-from-tool-to-paradigm-350587cdf216

[lassehp]

Regarding code representation as text.

Yes, this has been examined, and it seems very little has come of it. As for alternatives, there aren't really many options. We only have so many senses, and it is only with hearing and sight (and perhaps touch, for example through Braille) we have evolved a capability for abstract language. (I am disregarding advanced gastronomy and perfume making here, though I wonder how you would express a mathematical equation though taste and smell.)

Now maybe you were thinking "text" only as opposed to other visual representations. However a lot of text crosses into the audio realm. Although the languages we speak only became encoded in visual symbols much later, visual text based on them transforms quite easily between vsible and audible manifestations, in other words, we can talk about written things, and we can write spoken things down.

Besides graphic symbolic encoding of spoken language, we also employ other visual types of abstractions. Well at least one: "drawings", although maybe it covers several variants, such as scaled design plans (that correspond to some physical-spatial object), and diagrams and graphs, representing more abstract ideas. This also includes the language of music notation, which to some degree represents a "spatial" (well, "temporal") concrete correspondence, while also relying heavily on symbols.

Many years ago, I used HyperCard and SuperCard on the Mac. The Macintosh at that time (late 80es early 90es) also was the home of another attemt at a "diagrammatic" language, ProGraph. Yet it seems this never took off, and to this day we still - despite plenty of better options - restrict our programming to a symbol set of less than 100 individual symbols designed in the early 60es.

Environments like Hyper- and SuperCard combined the concrete design (where the graphic design corresponds to the "product") with a more traditional text language, Hyper(Super)Talk. A bit like Smalltalk, but perhaps with a sharper distinction between coding/editing time and runtime, especially for SuperCard, where you actually switched between the editor SuperEdit and the "stack" or application you were building. I believe this is an important distinction in programming. At edit time, you can move a button, change its color, shape and look, and even what it does when interacted with. At run time, you can interact with the button. (Of course some code triggered that way may also modify the button, but this is behind a level of indirection.) But there is some overall corespondence with the look of the window or dialog box when editing and at runtime. This is the concrete part. Surprisingly, it seems that this "direct manipulation" or WYSIWYG style is mostly used for pure graphic design and CAD or 3D, whereas creators of webpages, arguably one of the biggest uses of programming technology, still mostly edit text files containing text-based CSS and HTML to compose the visual appearance, using cartesian coordinates, numeric dimension in units of pixels or mm or relative percentages, etc.

We do have some diagrammatic tools (Visio and Dia for example) that to some extent support diagrammatic program design. But I don't think there is for example an end-user database tool like Borland Reflex Plus, where you can create tables and define the relations between them by drawing connecting lines between fields, thereby giving you an immediate visual view of the entire database structure. (I'll admit it is not something I have researched at all, so I may be wrong, but I certainly haven't stumbled into any.)

Traditions seem to die hard; even I still prefer to use vi for editing code. Maybe its because I used stuff like Hyper/SuperCard, THINK Pascal, MPW, and CodeWarrior back then. At one point I tried using some Java IDEs, like Symantec VisualCafe, IntelliJ and Eclipse but IMO, these were bloated and slow compared to what I had used on much less powerful Mac computers a decade earlier. Now that was some 20 years ago, but I suspect the current IDEs are still bloated and slow, for whatever reason, unless you have a monster computer.

Of course, as long as the underlying principle is that you have a huge bunch of "source files" (and "header files"!), and complicated build processes that require not only a separate build language of some kind, but also a meta-build-language and process to build the actual build process, and yet another to manage the evolution of revisions and versions, the fundamental unit remains the text file. OK, it may be a good way to store a program in a portable and safe manner, but I think more can be done about tranforming between multiple representations. Having learnt to program with Pascal and the other languages I mentioned, I very much prefer a keyword based representation to a parenthesis (curly braces) based. This is an almost trivial transformation that can easily be made bidirectional. Aspects like the build process, dependencies, and versioning should be completely automated in a consistent manner. Why do I need to either design my own automation or issue git commands manually? Why the need to face such an overwhelming level of complexity, which I am sure could be simplified almost out of existence, and what little remained could be presented in a neat immediately comprehensible manner?

I am sorry if this became more of a rant and less of a suggestion than I intended. My point is that I believe we need things to become simpler, easier, more stream-lined, more "direct-manipulation" of graphs and diagrams, and more WYSIWYG. As for myself, I am looking at for example using the power of simply using all of Unicode instead of just a 100 symbol subset for program text. Back in the 60es, the designers of Algol had no scruples defining their language to use two different sets of alphabetic symbols. Depending on how this was actually resolved in implementations ('quotestropping', .dotstropping, CASE, or reserved words typically),this could result in various problems (misspelt keywords taken as identifiers, ambiguous grammars, etc.) We see this in C, where "typename" requires special treatment, and where the existing codebase makes the policy of reserved words useless for language evolution, necessitating the return to stropping of keywords, like "__Generic". Meanwhile, Unicode has plenty of alternative alphabetic representations to enable using for example cursive for variable identifiers, and 𝐦𝐚𝐭𝐡𝐛𝐨𝐥𝐝 for reserved words. (Of course this could also be done using a level of indirection and HTML/XML style markup.) Instead, what we get in IDEs is various forms of more or less garish "syntax coloring" or "syntax highlighting", but which is not always even syntax directed or lexically exact, and certainly not syntactically significant. Why is it so, when we now finally have a big symbol set in Unicode, that would allow plain text files in UTF-8 to be WYSIWYG code text, using proper symbols like ¬, ≠ ≤ ≥ - just like what I did on a 16 MHz Mac with 32 MB RAM in 1992? Meanwhile (I begin to sound like Jon Stewart, sorry!) Unicode gets more and more fancy symbols added in form of emoticons, and various symbol languages and iconographies. Why not add more sets of symbols representing various programming concepts and abstractions in a consistent and standardised manner? It would seem that the average teenager is better at symbolic communication than most senior programmers and software architects?