Design and implementation

[Rudxain]

Intro

I'm not sure if this should be a Discussion, but I believe it makes sense as an Issue.

I guess I should quote The Purpose™

an educational project for introducing various ways of implementing programming languages in a humorous and interactive way, without any painful processes of memorizing unfamiliar and complicated concepts!

which kinda serves as an informal "design-goals"/"philosophy" manifest of the Rick-Roll-Lang. Although it's not entirely clear how this affects the following sections, we should take it into account when making changes to the lang.

Type system

Since this implementation will compile RR to machine code, I think it's worth considering static-typing (with inference, for ergonomics, of course)

RR has always had a dynamic sys (inherited from Python 3), so perhaps we could go the TypeScript route and introduce graduals.

I also find Gleam's type-sys kinda cool, especially the parametric polymorphism HM inference, which (correct me if I misunderstood) allows function-param-types to be inferred from the passed arguments on a per-call-site basis while rejecting any arg-type that's incompatible with the fn implementation in its body (thereby enforcing soundness), without the boilerplate of templates (see C++) or explicit type-parameters (see TS and Rust).

The Gleam Team is considering type-classes, but IDK WTF they are 💀 (I know they are like Rust traits, but more general), so let's forget about that.

Grammar

I believe we should take inspiration from Golang, while preserving most of the current syntax. I've been reading the FAQ and the cool semantics of consts, and I've begun to have some appreciation for the lang. I'm still "married" to Rust, don't get me wrong lol, but Go is also a "respectable language".

As per the FAQ heading I linked, it should be obvious why Go is an appropriate template, as it's "quite simple really" (Mumbo Jumbo certified).

Even if we don't change the grammar/syntax at all, we could learn some stuff from gc's parser, which is designed to be fast, but that's a secondary concern.

Memory management

Clearly, the memory used by a RR program should be automatically-managed (ref-count or general GC).

RR shouldn't have an ownership system (no "fighting the borrow-checker"), nor force the user to manually allocate and free memory. RR must be a fun lang!

But how do we implement it?:

• Does Inkwell take care of that?
• Should we use some crate/library that injects a GC runtime into built binaries?
• Should we reinvent the wheel?

Outro

Anyways, thank y'all for your time. I hope this post is helpful

[SatinWukerORIG]

Basically, you have pointed out most of the problems of Rickroll in Rust. You can also examine this problem this way: we are rewriting a simple Python in Rust.

Type System: Parametric polymorphism is also the mechanism of Python's type system.
So, let's stick with it and implement a dynamic type for Rickroust.
This is actually doable in Inkwell, by dynamically checking variable types in runtime.

Grammar: we should preserve Rickroll's grammar because once we update it, we also have to change it for Rickroll in Python.
I am not worried about grammar; rather, I am concerned about whether we can implement this language efficiently and successfully.

Memory Management: I agree that we should have a more memory-free language because this is how Rickroll in Python is.
Let's use reference count because Inkwell supports low-level constructs like incrementing integers and conditional checks for freeing memory.
These are sufficient to implement reference counting without using additional tools.

Goal: Speaking of a design goal, my philosophy is: faster, simpler, and more maintainable. The faster and easier we can implement this the better. This does not mean that we don't care about the quality. In contrast, a fast and easy code base can help use maintain this repo and this language much better. Furthermore, Rickroll Language aims to make learners learn implementing languages in a "low-cost", efficient way. So, let's just keep everything simple!

[Rudxain]

Parametric polymorphism is also the mechanism of Python's type system

That's true, but Py checks it at runtime while Gleam does it at compile-time (unless I'm confusing something? 😕)

implement a dynamic type for Rickroust.

I agree! Static-typed langs are usually designed for complex production projects, while RR is mostly a fun educational tool.

Replying to everything else: I agree, and I'm surprised that Inkwell has so many features!