I like how the kotlin docs do it, too (see e.g: kotlinlang.org/docs/basic-s...). For a couple of years now, I've wanted to find/make something like kotlinx-knit and integrate it with Try Ruby, to embed executable code samples directly in the docs.

I want “we can engineer the best processor in the world” to be a motivation and for “we’re gonna make an immortal Machine God that will suck you off” to be stigmatized

Right, I agree that's good. I want ruby to add both type hints/annotations (similar to python, can be used by libraries and tools but ignored by the language) and runtime type checks. I just don't like the syntax that makes type declarations look like the default value in a method definition.

Anyway, all that to say, I do like the idea and it's a natural progression of Literal. But, where Literal feels to me like a natural extension of how I already use ruby, this feels to me like a neat subversion, a really cool hack. But it's in juxtaposition next to other ruby code. Just my $0.02. 🙂

Fair. But recent versions (beside 3.4, which debuted prism) have all had syntax tweaks. And Matz has indicated that he's interested in features that would require significant syntax changes (e.g real macros), so I've interpreted that as "not now", rather than "not ever".

Anyway, my goal wouldn't be a new language. It'd be a proof of concept for a ruby syntax proposal.

Ahhh, I saw that it was a preprocessor and immediately assumed you were altering the grammar. I see now that it's tweaking semantics within the existing grammar. Which is a neat trick, but... IMO, it can feel more like the uncanny valley than just making tiny grammar tweaks.

It seems to me, that could work *very* well with libraries like Literal

It could use `#~===` on the pattern, instead of `#===`.
We might define it on Module as

def ~===(obj)
respond_to?(:try_convert)) ?
self.try_convert(obj) :
self === obj ? obj : nil
end

Simplifying coercion like:

case input
in ~Integer => int then ...
in ~String => str then ...
etc

Tangentially, I'd also like to augment pattern matching syntax with "deconstructing matchers". e.g: matching with a regexpr then deconstructing the MatchData.

`str => ~/(foo+)(ba+r)/ => (foo, bar)`
or
`str => /(foo+)(ba+r)/ ~> (foo, bar)`

I'd prefer to append (or insert) existing pattern matching syntax onto existing parameter syntax, e.g: the examples I gave above. So, use either the `=>` operator, the `in` operator, or both: perhaps `in` would be for type hints and `=>` for runtime typechecks.

Repurposing ruby's parameter default syntax for types is still throwing me off (it's not the syntax I'd choose), but `|` makes perfect sense---it fits in nicely with the rest.

How do optional parameters' default values work? I'd've expected
`def log(msg = "" => String, level: :info => Level) => void`
or
`def log(msg = "" in String, level: :info in Level) => void`
or
`def log(msg in String = "", level: in Level = :info) => void`
etc