Vyxal

AviFS

05:52

Can you convert between arbitrary bases?

I've found binary/decimal/hex etc.

Sorry, that's lame. I couldn't find the page.

Now I have!

Wait no. False alarm. Question still holds.

Given a list, is there a builtin to convert to a different base, like APL's 5 ⊥ 3 0 4 1 2 1

lyxal

one moment

AviFS

'Course!

lyxal

β

@AviFS ^

I just had to make sure it did what I thought you meant

AviFS

Wait, you're kidding. That was totally the obvious choice, but it looked to me like it was numbers to numbers

I hadn't realized it could do lists. What's the syntax?

lyxal

lyxal.pythonanywhere.com?flags=&code=%E2%9F%A81%7C2%7C3%7C%…

You can have pretty much anything in lists

AviFS

06:08

Thanks!

lyxal.pythonanywhere.com?flags=&code=%60123%6010%CE%B2&…

lyxal

@AviFS no, I'm Lyxal! :p

AviFS

Hahaha, I totally forgot about that old joke

lyxal

@AviFS you're trying to convert a string to integer?

AviFS

I was just going to say, yeah!

That it'd be cool if that was implict

lyxal

Use I or ⌊

Or E even

AviFS

06:11

If `123`10β did the same as ⟨1|2|3⟩10β

lyxal

`123`I

`123`⌊

@AviFS τ

AviFS

That that'd be cool I mean

lyxal

You're looking for τ

AviFS

Oh wait... I am, thanks

So what was fancy looking B doing?

That was converting the opposite way?

lyxal

Honestly idk

I never was good with comprehending bases

I'll look into it

AviFS

06:14

Haha, no worries

It's working great now!

And what about this?

Does unicode not work in strings?

No, it's not that simple because this works

lyxal

@AviFS Try it Online!

You need to escape non-ascii chars

AviFS

Ah, I see, interesting

lyxal

Because they are used for dictionary string compression

AviFS

Why's that?

Ah

Don't know what that means, but I'll take it

lyxal

Eg

`ƈṡ, ƛ€!`

Is Hello, World!

AviFS

06:18

No way! You've come up with the cleverest lang, my dear friend

lyxal

ƈṡ turns into Hello and ƛ€ turns into World

The comma space and ! are untouched

AviFS

Super duper neat

lyxal

There's also support for regex matching and defined functions as well as variables

github.com/Lyxal/Vyxal/blob/master/docs/elements.txt

AviFS

Nice nice nice

This is way more serious than I realized. I remember when it was a baby!

lyxal

It's really grown

AviFS

06:22

It's amazing

lyxal

And that's also due to everyone who has contributed code or raised issues on github

None of this would be possible without people like razetime, Aaron Miller, a username, hyper, user, unrelated string, wasif, Underslash, a stone arachnid and more

AviFS

Bummed to have missed all of its growth, but glad to be back on board!

lyxal

And I'm glad to have you back too/

*!

Stupid mobile keyboard making me use the wrong character

Feeds

lyxal has added AviFS to the list of this room's owners.

lyxal

Welcome to the team :p

AviFS

06:28

No way! I so don't deserve this. Thanks Lyxal!!

I'm a room owner, I'm a room owner, I'm a room owner

And YOU.

ARE.

NOTTTTT.

</end nonsensical childish song>

lyxal

@AviFS I add those who I trust to share the same vision for Vyxal

AviFS

Glad to be a part of the team!

But it's still 'vix-ul'. Period.

lyxal

🙃

AviFS

Is there a way to map this with the lambdas without using the for loop?

I've tried this.

And not sure why the output is what it is

(M doesn't work either)

lyxal

@AviFS Try it Online?

AviFS

06:38

Darn! How do you do that?

lyxal

Prepending v to an element vectorises it

AviFS

Ah, vectorize

I just found it

Searched for all occurrences of map

vectorize didn't occur to me

lyxal

Heh, looks like find might be a bit broken in the way it works with strings

I'll have to fix that too

Broken in the sense that it doesn't behave as expected

And it's because I need to add an explicit overload for non-lists

Internally that is

hyper-neutrino

v+ on 1,2,3 and 4,5,6 would give 5,7,9 rather than [5,6,7],[6,7,8],[7,8,9] right?

like, does v vectorize multiple or just on the top?

seems like it vectorizes on the TOS only (tested with v") - it might be worth clarifying? whether it vectorizes on all arguments or just one might be ambiguous, so idk if it's worth it, probably wouldn't hurt to specify

AviFS

One last question, I think: Any chance there's a string-type which doesn't need escaping for unicode?

I wonder if it'd be a good idea, since the bytes quickly rack up if your string has lots of unicode

AviFS

07:02

@lyxal

lyxal

07:16

@AviFS use the D flag

@hyper-neutrino it gives 5, 7, 9 by default and nested lists with v

I'll add that to the docs when I'm next at my computer

hyper-neutrino

aight, nice :+1:

lyxal

@AviFS heh, sorry about the late response: you caught me at a time when I was just heading down to the store to get groceries lol

AviFS

07:30

No worries! Thanks to your help I got this

At the time of writing, it was the best score. Though there are some serious improvements to be made.

@lyxal Oh wow! I def want to hear about this tomorrow pls. Gotta go to bed now, thoug

A username

12:41

How does Vyxal use Generators exactly?

lyxal

well

that is a good question

and I'll give you a hopefully good answer

The story of how and why Vyxal has a custom generator class

A username

Wait, custom?

lyxal

Generator

github.com/Lyxal/Vyxal/blob/master/Vyxal.py#L144

A username

I honestly thought that was a builtin.

lyxal

If you let me explain you'll see what I mean

Way back in the early days of Vyxal, there was only numbers, strings and lists

If you tried to do things with itertools/mapping/anything that would usually be lazily evaluated by python, it had to be converted to a list first

However, this meant that programs involving things like getting all the permutations of a largeish string and then filtering based on a predicate would take a long time

An optimal solution would be to just use the items returned by the mapping/itertools stuff/whatever as-is

however, there's just one problem with that

a map is a different type to itertools.<whatever> which is yet a different type to the built-in generator type

meaning that organising type cohesion would be an absolute pain

also, things like indexing would still face the same problem of having to convert the entire generator into a list

so I thought "hey what if I make a general wrapper for all the many types of generators"

"that way, I only have to deal with one type of class"

"and I can create custom methods for it too"

So I made the Generator class

Doing so also has the benefits of making user-defined generators play nice as well

because I can control how the instance is created using __init__

A username

12:49

This... is something I need to implement, but it might take a while to do so.

lyxal

That's why we have a custom Generator class

now for how it's used.

Anytime something that would otherwise be lazily-evaluated is returned, it's wrapped in Generator

A username

Infinite lists for one, like ∞ and ÞF.

lyxal

yeah

those are wrapped in Generator too

but also things like Generator(itertools.zip_longest(*iterable(lhs), fillvalue=rhs)

Generators have two main attributes that need considering: generated and gen

generated is a list of all the values that have been, well, generated so far by the generator

this is mostly so that generated values are retained somewhere

gen is the actual generator object that is being wrapped

Now seems like a good time to properly address issue 82 on the repo

A username

@lyxal On one hand, I don't have to deal with itertools, on the other hand, I don't have itertools.

@lyxal The corpus is not exactly useful.

lyxal

> Generators causing problems because they aren't lists #82

A username

12:53

Oh yeah

lyxal

By address, I mean "explain what the problem is in more detail"

A username

I saw that

"This is something that will take more than a quick fix - it would require a complete reworking of how the Generator class works."

lyxal

Yeah

Let me explain why

Say you want to map , to a list

that's easy enough, you just print each item because you know when the list ends

it's finite, so it can be evaluated as-is

A username

But if you've got something like ∞ (which btw no one uses, check the corpus)

lyxal

Does that make sense? (I'm not done yet, I'm just taking a moment to make sure you're still tracking along)

A username

12:55

I understand so far, yes

lyxal

2 mins ago, by A username

@lyxal The corpus is not exactly useful.

@Ausername good

now say you instead want to map , to an infinite list

your first idea might be to try and call list on the generator

the problem with that is that you'll be waiting a while for the list conversion to finish

because it's, well, infinite

meaning that the printing will never actually happen

pxeger

why would you need to call list on it?

what's wrong with just iterating over it?

A username

Can you overload comparison for Generators?

pxeger

Python's builtin map does that already

lyxal

@pxeger because if you're doing something like ƛ,;, it's returning a map object

pxeger

12:59

ok, so then have the interpreter automatically try to exhaust any map objects it gets if it's supposed to print them?

lyxal

problem is that because it's lazily evaluated, when it goes to be printed, it applies the mapping and tries to print the list item at the same time

@pxeger it's an infinite map though

it goes on forever

it uses yield

lyxal.pythonanywhere.com/…

A username

How does Husk handle it?

lyxal

Idk

I've never read the husk source

and I don't know haskell

A username

@lyxal Oh true

Just asking because one of Husk's main concepts is infinite lists.

Infinity is a pain.

pxeger

by "exhaust", I don't mean "create a list", I mean for x in generator: pass

just force every item to be evaluated

and if the generator is a map, then force every item to have the function applied to it

lyxal

13:01

that already happens

pxeger

well what's the problem then?

lyxal

and so long as you don't try to print anything inside a generator, you're good to go

the problem is printing inside a generator

it's to do with the way that printing a generator works

at the end of execution, it goes through each item and applies whatever chain of functions has been mapped/filtered/whatevered

and then once it has it's result, it prints it

followed by a | to indicate the next item

however, if during the mapping/filtering/whatevering, the value is printed, it still prints the list item

here's another way of thinking about it

pxeger

oh, so each item gets printed twice

lyxal

yes

if i call print on a finite list, it can print the whole list and still halt

pxeger

you need a separate "foreach" and "map" then. Map returns the generator after the result of the function, Foreach returns nothing

lyxal

13:04

the problem is when I call print on an infinite list

@pxeger how would you print a map object?

a finite map object

how would you print it as a list?

A username

What if you have a hardcoded Generator size limit that can be modified with flags?

lyxal

@Ausername I've considered that

2 mins ago, by lyxal

how would you print it as a list?

the obvious answer would be print(list(map(fn, iter)))

pxeger

@lyxal The same way you currently do. Python 2: print(map(print, range(10))) prints everything twice too. But if you want to map , over an infinite list, you should expect to get everything twice. If you don't want it twice, then either use a "forcibly exhaust iterator but return nothing" builtin, or use foreach instead of map.

A username

By printing the first (limit) items...

lyxal

@pxeger But we're using py3

35 secs ago, by lyxal

the obvious answer would be print(list(map(fn, iter)))

however, that doesn't work on infinite lists

because calling list on an infinite list will never halt

it'll keep on going and going

never stopping

so how is one to print an infinite list?

pxeger

13:08

@lyxal well it's the same, but instead it's print("[", end=""); for i in map(print, range(10)): print(i, end=", ")

and range(10) can just as well be an infinite list

lyxal

    def _print(self, end="\n"):
        main = self.generated
        try:
            f = next(self)
            # If we're still going, there's stuff in main that needs printing before printing the generator
            VY_print("⟨", end="")
            for i in range(len(main)):
                VY_print(main[i], end="|"*(i >= len(main)))
            while True:
                try:
                    f = next(self)
                    VY_print("|", end="")
                    VY_print(f, end="")

pxeger

yes

lyxal

that's what I currently do

pxeger

look I really don't see this as a bug. It's expected behaviour with a map builtin

lyxal

and that has the problem of duplicate printing

@pxeger neither do I really

pxeger

13:09

Who said it was a bug?

A username

"It's not a bug, it's a feature!"

lyxal

@pxeger github.com/Lyxal/Vyxal/issues/82

pxeger

yes I see

but why did you respond to this in a way that makes it seem like it is a valid bug

lyxal

is it a bug?

pxeger

Tell the issue creator to use foreach instead of map

it is not a bug

lyxal

13:10

does it need fixing?

pxeger

no

lyxal

ah

see my understanding of infinity isn't exactly the best

welp I think that's me done for the day

It's 11pm and I'm feeling too tired to make any more comprehensible sense

bye o/

pxeger

\o

A username

13:23

I fixed #92 but the check failed... Anyway, 'night.

Transcript for