@lyxal No one's ever used °...;, can we get rid of it and replace with a digraph that takes a string and returns the function with that name?

@emanresuA no

That's one feature I'm going to insist on keeping

Point.

It's a practicality feature

So no.

...

If you're going to suggest removing it, you might as well suggest removing named functions

!!/run °1 1+;

[@PyGamer0: 59124953]
0

STDERR:
invalid syntax (<string>, line 2)
Most recently popped arguments: []
Final stack: []

!!/run 1 2 3W°1 2+;

[@PyGamer0: 59124956]
0

STDERR:
invalid syntax (<string>, line 8)
Most recently popped arguments: []
Final stack: []

!!/run 1 2 3 W

@PyGamer0 ⟨1|2|3⟩

!!/run 1 2 3W4 5W6W9W8W0W

@PyGamer0 ⟨⟨⟨⟨⟨⟨1|2|3⟩|4|5⟩|6⟩|9⟩|8⟩|0⟩

!!/run 1 2 3W4 5W6W9W8W0Wabcd

@PyGamer0 0

ok?

So, I've got a crazy idea, but hear be out on this.

What if we implement the Vyxal standard library... In Vyxal?

I'm not saying the whole thing should be implemented in Vyxal.

Everything that's a golfy alias can get done in Vyxal, the rest we do in Python.

And no, I'm also not saying we just append this to the code during evaluation.

See, Vyxal is transpiled. So all we need to do is create a modified transpiler that doesn't prefix names.

Sounds good to me

I'll make a poll

Actually no

Example?

As in, I like the sound of the idea so far, but example of what you mean?

Like, implement øṁ as something like @vertical_mirror:1|↵vm⁋;

So you mean the digraphs?

Maybe not just those

If we added a typecheck function

that would be good

You'd have to be careful not to have circular references to elements though probably

And how do you objectively determine what gets implemented in Vyxal and what gets implemented in python?

As in, what criteria do you use?

Probably anything that's more than a golfy alias

Like regex stuff would be in Python.

Most basic operators (E.g. most things that came from Keg) would be in Python.

Something like Ḃ, a golfy alias for :Ṙ, would be in Vyxal.

I can make a list of what I'd do for each if you want.

The main advantage of this would be that code writing would be 2-3x faster.

Also, it would teach us all how to write clean, efficient and readable Vyxal.

And give us more oppurtunities to troll promote Vyxal on Code Review.

We'd want to keep the modified transpiler completely separate from the ordinary one.

If someone can override print, that

would be bad

We'll see what everyone else says

Also,

!!/hyperping

@AaronMiller @Allxy @Ausername @PyGamer0 @emanresuA @exedraj @hyper-neutrino @math @pxeger @user @vyxal ^

no

Read everything first

still categorically no

this seems like a bad idea

it will complicate transpilation 1000x

Btw I tried this once with Keg: github.com/Lyxal/Keg/blob/master/BFL.keg

Just in case people want an example

@pxeger Did you see what I said?

We transpile it into python and keep that as a static file that the interpreter can use

not something else more complicated

@emanresuA yes I have read everything

@emanresuA where exactly did you say that before? don't blame me for not reading the things you didn't write

Oops, I forgot to write that bit

I thought I had, I just forgot to

@emanresuA that sounds less horrible, but still it adds a step to development (it has to be retranspiled when the vyxal changes)

np lol

and it seems extremely easy to accidentally get a circular dependency

I had an answer typed up to that but forgot to post it.

And now I've forgotten what it was.

@emanresuA yes

Gotta agree with pxeger, writing the stl in vyxal and/or bootstrapping are cool but would be hell to keep up

vyxal may be better than other esolangs for this stuff, but it’s still not as readable as python

Are we going to allow miltifile vyxal projects in the future?

Ok, it was just an idea :p

!!/'night

@emanresuA o/

@user *multifile

@lyxal ^