so i think ive got a way to do polymorphism for Rol. basically you can define a type (idk what to call it yet. traits are not exactly what ive got. maybe contracts?) that is a collection of functions. any type that has all those functions is implicitly a member of that type. afaik this is a mix between rust and go

So it's like a protocol in python?

idk whats that

ooh nice name

A collection of functions so that any class that has them will implicitly be considered a subclass

similar yes

except methods dont exist in rol, thats why i ditched traits

Will you allow multiple functions with the same name?

yeah

static typing go brr

hmm there is a name for what im doing

What I like specifically about traits is the way that there can never be confusing when multiple interfaces define a method with the same name, but with slightly different semantics. You may want to implement both a little differently.

but the matching will be done using args too, not just name

That's good, and avoids most cases of confusion

I have seen cases where the function signature for a very similar interface from 2 different libraries are exactly the same but the meaning of the arguments is reversed. Then trying to make classes that work with both

meaning as in name?

One expected to return true in some condition the other false. Name was the same. Arguments where the same. This is a super rare case though.

yikes

now that i think about it, maybe implicit isnt the best

maybe i should do smth like LinkedList is List

wait i dont think what im proposing would work with generics

argh generics are the bane of me

i cant seem to think of a way to make polymorphism and generics fit together

or maybe...

ok i think i got it

proto List<T> {
	fun get(List<T>, Num)
	fun set(List<T>, Num, T)
}

That's about how generics work in most languages

yeah my original idea omitted the first param so i was a but confused

How would the LinkedList definition look like?

Like the function signatures

struct LinkedList<T> {
	// fields
}

fun <T> get(self: LinkedList<T>, idx: Num): T {
	// body
}

fun <T> set(self: LinkedList<T>, idx: Num, obj: T) {
	// body
}

get and set are standalone functions

Interesting

i use UFCS, so i can do list.get(0) (ofc w/o op overloading)

@mousetail wdym? One of them is sad and the other one is happy ;>

But <= is also happy

Proposal: >= and =< are the comparison operators, while => and <= are arrows

@DialFrost What does "abreh" mean? I've seen you use it several times, but unlike "lah" and "leh," Wiktionary doesn't have an entry for it.

@DLosc <= is used for closures: a => a + b <= b

Ooh even better, for infix operators

^^ is actually not an awful looking syntax for that

I'm honestly considering making an rSNBATWPL 2 which uses that syntax

Among some other...ideas I have come up with

@JoKing your 43 in ruby is strange, because i can find all kinds of 44-byters even with ("%b"%_1).sum but nothing gives 43

@emanresuA I could easily create a Vyxal PR but not the SBCS

¯\_(ツ)_/¯ There's always chars diamonds, we don't necessarily need the SBCS

The thing is, there's both bytes and chars scoring, but you can't just decide to only golf chars scoring and not worry about bytes. Because in chars scoring, you can pack the code because you can use huge Unicode characters

True

SBCS will probably need implemented anyway if people really want APL

I can probably implement SBCS, but it will take me a while

SirBogman could probably do it easily lol, he's contributed half of code.golf

If you want to, go for it. Personally, I don't want to attempt to build it

I might ask in the discord server if anyone wants to help add SBCS support. Then we could also add APL, which is of popular demand

And Jelly, and 05AB1E

I could use the excuse "so APL can be added" and then Vyxal/jelly/05ab1e is just a side-benefit

True, it'd recieve a lot more support then lol

Maybe "APL and other golflangs"

I'd drop "other" from that or Adám will personally hunt you down

lol

@RadvylfPrograms i saw a post on CS that said APL was a golflang

i quickly edited it

You don't want to end up on the wrong side of Dyalog's paramilitary arm

lol

@Steffan therefore i'm not using ("%b%_1).sum

of course you're not, you'd need to close your string

@Steffan Eugh, such an outdated and boring view of the sport

")

@RadvylfPrograms On the one hand, I do think that golflangs having Fibonacci or Hello World builtins is mostly a sign that we need to get more creative with our challenges. On the other hand, I also agree that such builtins are "overfitting" and can make golf competitions less interesting.

Thus why Pip doesn't have any primality builtins, e.g.

Thing is, none of the good, commonly used golflangs do have such overfitted built-ins

Um... doesn't Vyxal have both?

@DLosc i disagree abt primality

but agree with the rest

Vyxal gets a bit close, but it still takes a lot of bytes even for FizzBuzz, probably its most egregious case of that

my plan for fig is to have general builtins for the small codepage space i have

Primality makes sense because we have a ton of challenges about primes, and that's only one part of most of those.

@Seggan Yeah, that one's an edge case because it could conceivably be useful in a practical language.

And it's sometimes useful for e.g. hash functions or many numerical things

constant generation's one

@RadvylfPrograms But that's what I'm saying: the fact that golflangs feel a need to have primality builtins is a sign that we have too many challenges about primes.

I don't know of any golfing languages I've actually seen more than one answer in which have built-ins specifically for things like fibonacci or HW

@Steffan nope. while most golflangs do do that, its about time we start doing real innovation

@DLosc Yeah, but that doesn't make the languages themselves uninteresting

@RadvylfPrograms vyxal had(s?) a fib one and HW

Probably in its early days yeah, but given how much it's changed it's hardly fair to treat that as the same language

I mean I'd argue we've slowly moved away from such specific built-ins. If GS2 and CJam had them (and I don't know if they do, since they're a bit before my time), that would indicate they were popular during a very specific time period, when we suddenly had 160 new slots for operators and no real practice at filling those.

@Seggan It still has both

GS2 is ridiculously overfitted

Plus two other variants for Fibonacci and one other variant for Hello World

It has a configurable hello world monograph

Oh, as a digraph. Fib as a digraph isn't unreasonable, even Jelly has that IIRC

I'd still consider it overfitting.

I'm not a huge fan of some of Vyxal's k. digraphs, but most are reasonable (like the alphabet and stuff), and filling some unused slots with HW or whatever isn't a super nonsensical thing to do

^^

@DLosc I guess so yeah, but it's only detrimental to challenges which are incredibly boring in the first place

since those digraph slots would likely not have been used in the first place

So it's not like the language is just sacrificing general purpose golfiness for some cheaty trick

^

Quoting an answer somewhere,

> If a challenge is trivial in a golfing language, it's trivial anyway.

Yes and no. "Generate the Fibonacci sequence" can be quite interesting in languages that don't have a builtin for it. Once there are a hundred Fibonacci-based challenges, it gets less interesting.

@emanresuA true. rarely is a more complex challenge solvable in a builtin

@DLosc but then in context, that fibonacci code can get modified to fit the special case

@Seggan And when it is, that's often really cool, like with the Math.tanh trick on my Ash float division challenge

I'd argue that golflangs have more room for innovation than other languages

^^

I think what the person in that Discord conversation is arguing against is a really unfair strawman of modern golflangs

@emanresuA by huffman tree programs and fracbit and whatnot? or by builtins

@emanresuA - caird

probably because golflang solution is often a direct translation of the challenge spec

@Seggan Having 256 built-ins available and very little overhead due to syntax and long names and stuff allows for you to do interesting tricks which might otherwise have been prohibitively complex due to verbose syntax. Golfing languages kind of just compact the steps in a solution into their simplest syntactical representation IMO.

not simplest yet

@emanresuA I'd turn the quote around: just because a challenge is trivial in some languages doesn't mean it's trivial in all languages. We've got Add two numbers, which is by most standards ridiculously trivial, but it has engendered some really involved answers in certain esolangs.

@Seggan Well, I think for more interesting challenges, the spec tends not to be an exact step-by-step instruction sheet.

true

When there's multiple approaches is when it's interesting

@DLosc Agreed

And similarly, just because a challenge is trivial in golflangs doesn't make it trivial in praclangs

(or the other way around)

For a while I've wanted to make a golflang based on lambdas and recursion, inspired by the JS meta right now

JS meta?

I think it would be an interesting, if not as competitive take, on golflangs

@RadvylfPrograms lambda calculus

@Seggan meta in the gaming sense

@Seggan Facebook, but implemented in Node.JS :D

Like, what the current strats are

ah

im not that much of a gamer

Recently I was trying to make a simple golflang just by running a compression algo on all the JS answers to see what the most common tokens are, I ran into issues though since there's so many possible ways to write the same code, so it was really unoptimal

@Seggan a lambda calculus golflang would actually be interesting

(e.g., different variable names, or currying vs. multiple arguments)

@RadvylfPrograms wow

so MetaJapt?

Sort of. What I ended up with was a huffman-coded compressed JS thing, it worked pretty well but gave you much different results depending on what variable names you used

I was working on a JS normalizer based on the babel parser, but JS is complicated

lol

Even ignoring scoping rules, changing or removing all of the variable names would've been a massive undertaking

damn

CMC: Given two ranges, formatted something like (1, 4), (-1, 2), determine if they overlap

Your choice if they're inclusive or exclusive

And also your choice if they're of ints or floats

Oh wait it's literally as simple as (x,y)=>x[0]<y[1]&&y[0]<x[1]

Well I just crashed a Chrome tab faster than I ever have

Pushed to an array in a loop reading over that array. Surprised it OOM'd that quick lol

so ive been reading the rust book, i must say, this is a nice language

It was literally the second I hit enter in devtools

might learn it someday When I Have Time™

@RadvylfPrograms still nontrivial to golf depending on the language

@RadvylfPrograms Vyxal, 8 bytes: ‡÷rMf:Ul Try it Online!

exclusive range, inverse truthiness

maps the range element over each pair, flattens, then checks if the list with duplicates removed is the same length as the list without duplicates removed

oh yeah porting that looks like 6 bytes in jelly

and all ascii too lmao

r/fr/}

might be shorter in vyxal. havent used it in a while

i was trying _U}×\ṢƑ lmao

oh yeah of course 5 as a monad

r/€f/

with the dollar store over combinator

Nub invariant Concat Range over in FunStack, if taking input as four separate arguments is allowed

Or IRange for inclusive ranges

whats nub

It's Haskell for "remove duplicates"

I've got Unique as a synonym in FunStack

@Seggan why not vƒr

Then set intersection -> empty if nonoverlapping, nonempty if overlapping

@emanresuA ah forgot

also are you seriously mapping with M?

lmao

@DLosc oh

Bruh > Breh > uh/oh + breh > abreh

Get it? ;3

Aha. That was my best guess, but I wasn't sure.

Thanks!

@emanresuA yeah. im also using a 2 element lambda

so no bytes lost

@DLosc no