@quartata ...mmhmm?

I guess my main concern is that with something like that it's not immediately obvious with x.y whether x is an object or an array

Also I'm in general not a fan of dots for member access, I like arrows better.

Hmmm

['a' 'b' 'c']->2

That doesn't look that bad

Why do you like arrows better?

I think it makes more intuitive sense and it also catches the eye a bit more imo

(also Perl does it lmao)

$obj->{member_name}

Doesn't C or C++ do arrows too?

That's for pointers to objects

x->y is (*x).y basically

ah-huh

@quartata The two meanings aren't all that different, though. I could even implement them with the same core function.

Hmm, tough choice between -> and .. I use the latter extensively in both Python and JS...

...I think I just provided myself with the answer. I am developing Pytek primarily because I want it, so I think I'll go with dot notation.

Good on you for making me reconsider, though. I appreciate it. :)

@El'endiaStarman Makes choices rather easy :P

Haha, some choices, yeah.

Damn, they beat us to quines:

this is unacceptable :P

Lawl.

What would/should a quine in Pytek be, though?

Hmmm

Also, \quine() is cheating.

Well of course

But I'll implement that anyway. :P

On topic, how were we planning on doing string interpolation?

I was thinking of copying Python's system.

Right, but are we going to overload % or have a function?

hmmm

Just wondering about the syntax

I should eat something

We could overload %, but it's probably better to make it a function. \strformat(...) (precise arguments to be determined).

@El'endiaStarman Hmm, what would x = `$ be?

I guess it would be "" -> """" -> """""" -> ...

That's pretty funny

Hmm...I guess so?

I was wondering if $ would provide a way to make a quine but I can't think of a way

It would be cool though

One of the cooler Perl stdlib things:

Tie::File essentially creates a lazy list of all the lines in a file

It's not an iterator though. @f[num] would get line NUM without reading any other lines into memory first

It fits well with how Pytek generators will work

Oh shit, I think <x="<x=%r%%$>"%$> will work for a quine

@El'endiaStarman

@quartata ....what were angle brackets for, again? Lambdas? How is that different from \()?

I'm not sure how \() would work

Oh, that wouldn't quite work. It would return the first generation of x which would just be <x=%r%%$>

I need to generate it twice

@El'endiaStarman How is that gonna work exactly?

I think the original idea was that referencing x would generate the next one

I guess then <x="<x=%r%%$>"%$;x;x>?

Hmm. $ is one of those things I simply haven't figured out all the details for...

It's meant to be iterated through.

<x="<x=%r%%$;x;x>"%$;x;x>
<x="<x=%r;x%%x>";x%x>

longer :(

@El'endiaStarman Oh, if it's a generator then...

...well shoot. That's awesome.

Yeah, pretty cool.

That's 17 bytes.

$ is all powerful

if we can get it working

Yup, therein lies the challenge. :P

If we can get that working that would be an amazing demonstration of Pytek's crazy cool stuff

question: will pytek have implicit casting?

I think el'endia has a casting table around here somewhere

true + (1+1i) = 2+1i?

looks like something JS would do

i like it

Uh-oh. Better take that out then

:|

lawl

But yeah true is 1 so

@Downgoat It's actually something Python would do.

C did it first !!!11!

._.

>>> True + (1+1j)
(2+1j)

wat python has complex numbers

TIL

Yup.

brb adding to cheddar

@Downgoat obviously

@Downgoat I mean, Fortran has complex numbers...

Not having complex numbers built-in is really just a C thing these days

JavaScript doesn't ;___;

neither does cheddar ;___;

You have rationals right?

That's a step up above Fortran

LegionMammal978 has made them but is still writing tests

question: what's your range operator?

@Downgoat javascript dont have complex numbers ಠ_ಠ

@Downgoat We don't have an operator. We have interval notation instead:

oh yeah

(x..y] or [x..y] or (x..y)

how to specify step size?

oh cool

@Downgoat No step size. You use \chunk instead if you want that

@Downgoat To be determined.

I do want to figure out how to put step size and/or chunk size.

Hmm

(x..y, step] looks ugly

^

(step:x..y]

Yeah, that's the other option

Why not [x..y: step,chunk)?

(x..y: step]

^ that looks better imo

@El'endiaStarman Der, got \chunk confused with slicing lel

How are we going to do step in slices now?

With the new index syntax

@El'endiaStarman Yeah, that's not bad

@quartata Python example?

@El'endiaStarman arr[x:y:step]

is what I mean

aahhhhhh python

@quartata arr.[x..y:step]

@Downgoat python is life

@El'endiaStarman oh perfect

ranges will generate generators or lists?

Generators

Our generators will be a little different though

They're more like lazy lists than iterators

\o/

lazy lists are life

@quartata: Just realized a potential problem. What if I want to slice off the first and last element of a list? In Python, arr[1:-1], so it should be arr.[1..-1) in Pytek? But \corePrint([1..-1)) should be "1 0"...

Yeah that's a problem

hm

@El'endiaStarman We should have a function that merges two streams/generators

I keep finding myself doing dumb shit like this in Python:

for e in EntityIter("entity1"):
  do something

for e in EntityIter("entity2"):
  do that same thing

The question is what order should they be sorted in...

I was thinking one from the first stream, then one from the second stream

That would work well for potentially infinite ones

Hmm. << should work on iterables too, which will take care of most of the cases.

Oh, that helps

Then we could have an \interleave function that works on any interable for the other behavior

If both iterables are infinite, then you could perhaps use something like- yes, like \interleave.