Pytek

« first day (68 days earlier) ← previous day next day → last day (592 days later) »

quartata

12:50 AM

I've been thinking about how Pytek will handle encoding some more.

The only times encoding will matter is when reading from STDIN or a file (including the file containing the program)

Ideally it would be awesome to be able to have only to specify whether or not the encoding is variable-width

But the problem is that UTF-8 and UTF-16 encode the same code points in very different ways

Somewhat more problematic is that there are encodings like UTF-32 that are fixed-width but use multiple bytes.

Hm.

I do actually know of a way to solve this.

But it would mean interactions with \ord would be very strange.

Well, not strange.

Just.. different from what another language would output.

My head hurts from thinking about encodings now.

OK, I think we have no choice really here.

We have to have multiple modes: SINGLETON, MULTI_UTF_8, MULTI_UTF_16, MULTI_UTF_32

Oh well.

quartata

1:10 AM

Actually, I think this would be better: FIXED_8, FIXED_16, FIXED_32, VAR_UTF_8, VAR_UTF_16

Gee, do you think UTF-7 will ever come up? :PP

@El'endiaStarman Had some code for @define but I commented it out

I'll have to think about it some more

El'endia Starman

1:38 AM

@quartata Hopefully not, and I guess we could mark it as low priority.

El'endia Starman

2:03 AM

Okay, what I'm gonna do in the parser tonight is that I'm going to modify the third stage to use pObject's enter and exit methods, which will do what it does now by default.

To these methods, I'll pass basically everything that's being tracked.

quartata

2:47 AM

@El'endiaStarman what's our to-do list looking like right now?

El'endia Starman

I'm looking to get user-defined functions working.

To do that, it makes good sense to move language-specific stuff out of the third stage.

Variables are already somewhat accounted for.

quartata

I assume user defined functions wil get parsed in the second stage right?

El'endia Starman

The next thing might be user-defined operators, maybe. And then user-defined types.

@quartata Third stage, actually.

quartata

AST_operator : -> AST_identifier "func" AST_identifier "foo" and AST_code all to a pUserFunc

El'endia Starman

Actually, the first stage substitutes <AST_identifier func> <AST_operator :> <AST_identifier foo> with <AST_UserFunc foo>, and then <AST_code> is parsed as its child.

quartata

2:54 AM

Oh, that's clever. How does that happen?

El'endia Starman

Syntatic sugar AST nodes! :D

quartata

whoa I'm not sure our meta is ready for that kind of power

But why does the AST_userfunc not get added to the symbol table when it is objectified?

El'endia Starman

Variables are added to the symbol table in the third stage.

I originally had planned to do the symbol table in the second stage, but realized that that was basically totally unnecessary.

quartata

Fair enough.

El'endia Starman

User defined functions don't work right now for two reasons: 1) they're not added to the symbol table, and 2) their contents are executed by the third stage.

This is why I'm going to move to .enter() and .exit() methods.

The former goes before any children are executed and the latter goes after all children have been executed.

Or when it goes to the next child, I guess.

quartata

3:04 AM

You could have .enter .next and .exit

El'endia Starman

yeah

quartata

Could sugar nodes do type specifiers too? should just substitute the identifier on the right for a new one with an appropriate type field

El'endia Starman

How do you mean? Like, in a situation like unique:list:x?

quartata

Yah.

El'endia Starman

Incidentally, most type specifiers won't need sugar nodes. I only need one for func: because I have to parse the children properly.

quartata

3:08 AM

Also off topic but link to the blog post you made on the multi threaded sieve of sundaram in minkolang?

El'endia Starman

(And type:, class:, etc.)

quartata

@El'endiaStarman Oh, I see why now

El'endia Starman

@quartata >_> ....... I haven't written it yet.

I keep meaning to...

quartata

The rest can just be done pOperator right

El'endia Starman

Yeah.

quartata

3:09 AM

@El'endiaStarman I swore you said you had written it :P

Link to the codez then?

El'endia Starman

I definitely said I wanted to or was going to... :P

github.com/elendiastarman/Minkolang/blob/master/…

It's meant for situations like factorizing numbers in general, where there's a high chance you'll have small prime factors.

Basically, how it works is it keeps a list of every prime. Well, actually, their multiples. This way, I know what the composities are. The main loop counts up, and every time I hit a prime multiple, I "increment" it (add the prime). Any number that isn't covered by a prime multiple is a prime, which I yield and also add to the composites list.

This way, I can generate an infinite list of primes in a way that's slightly more efficient than trial division (I think), and I don't need to precompute an upper bound for sieves.

Oh, another benefit is that exactly as many primes as are needed are generated. If you were to use a sieve to get all primes below \sqrt(3^30), you'd calculate far more primes than you needed. With my method, you'd get to 3 and then be done.

El'endia Starman

4:21 AM

@quartata Meta?

3 hours later…

El'endia Starman

6:57 AM

@El'endiaStarman s/tonight/tomorrow/

Mars Ultor

what happens after the third stage?

13 hours later…

El'endia Starman

7:57 PM

@MarsUltor The third stage is actually where all the execution happens, so there is no "after".

So you could say that the parser only consists of the first stage (parsing) and second stage (conversion), and that the executor is the third stage (execution).

El'endia Starman

8:10 PM

@quartata, were you able to understand my code alright?

2 hours later…

quartata

9:53 PM

Yeah, it's fairly straightforward.

Might do some benchmarks later.

I was thinking we'd use that for \primes(). It just returns that generator

El'endia Starman

10:29 PM

@quartata Yeah, and if a limit is provided as an option, then we can do a plain sieve of Sundaram.

quartata

Sieve of Eratosthenes is better for that I think.

But the Sieve of Sundaram is interesting for an infinite list style thing

El'endia Starman

The Sieve of Sundaram is basically exactly the same as Sieve of Eratosthenes. The primary modification is that multiples of two are eliminated beforehand.

Sieve of Sundaram

In mathematics, the sieve of Sundaram is a simple deterministic algorithm for finding all prime numbers up to a specified integer. It was discovered by Indian mathematician S. P. Sundaram in 1934. == Algorithm == Start with a list of the integers from 1 to n. From this list, remove all numbers of the form i + j + 2ij where: The remaining numbers are doubled and incremented by one, giving a list of the odd prime numbers (i.e., all primes except 2) below 2n + 2. The sieve of Sundaram sieves out the composite numbers just as sieve of Eratosthenes does, but even numbers are not considered; the work...

> the work of "crossing out" the multiples of 2 is done by the final double-and-increment step.

We could potentially do something with wheel factorization to develop a better generator.

quartata

11:24 PM

We probably should do a new name poll.

I personally liked "Kypet" :P

El'endia Starman

Could do a strawpoll.

I'll make one and post it in TNB.

@quartata I like that one too, and given that it's currently tied with "Typek", that'll probably end up being the new name.

« first day (68 days earlier) ← previous day next day → last day (592 days later) »

all rooms