LA,RA = [],[] lol

LARA

?

I've almost got operators working.

.... almost.

noice

Input: 1+2*3+4. Output: 3+1*2+4. ???

How is it being parsed?

elendiastarman:~/workspace/src $ python3 pytek_main.py -c "\print(1+2*3+4)" -t
9
┬root
└┬\print
 └┬funcArgs
  └┬operator +
   ├┬leftArgs
   │└number: 3
   └┬rightArgs
    └┬operator +
     ├┬leftArgs
     │└┬operator *
     │ ├┬leftArgs
     │ │└number: 1
     │ └┬rightArgs
     │  └number: 2
     └┬rightArgs
      └number: 4

Using the shunting yard algorithm.

It works correctly for \print(1+2*3).

Aaand fixed! :D

Also, we need to come up with a better way to handle \add that can correctly use future types' \add methods.

I was thinking maybe for that kind of thing having the functions be implemented in the class of the type

yeah

So we'll need to make pInteger etc objects.

So when a function is called first it looks in the function table for it and if it cannot find it it looks in the class representing the type of the first argument

Hmmm, yeah, that could work.

@El'endiaStarman We could put them in the AST_ objects instead but that's a little messy

Actually, better idea.

I think the AST_ objects should remain only for the actual AST nodes.

Let's make the keys in the function dictionary be tuples like (name,type,type..) for fixed arity functions

Varity functions can be (name,varity). Function look up looks for a fixed entry first with the right types then a varity entry

Yeah that'll do it

I don't see yet.

OK so let's say we call \add with two strings

Then we look for entry ("add","string","string") in the function dictionary and call that function

Nice idea, but there's one issue with that: we will repeat a lot of code that way.

If we want to handle type checking ourselves for a certain function and not repeat code we can just make that function ("blah","varity")

If the function lookup can't find the function with the specific types it'll look up (func,varity)

The fiancée wants to Skype, so I'll be a bit unresponsive for a little time. :P

Go ahead and do what you're thinking for - and /, then test them.

k bai

I'll probably do it tomorrow

oh, okay

Alright, power towers correctly go from right to left! :D

Next is variables.

@El'endiaStarman Should + coerce strings to ints or concat strings together

Good question. Is "5"+5 "55" or 10? What about 5+"5"?

Oh wait.

Well, it kinda depends :P

:P

if you want "5"+5 to be 10 we could have a separate operator for concat

Perhaps. My goal is to reduce unexpectedness/confusion.

So 5+"5" should be 55 then probably.

By the way we really need to change how functions are handled.

Having all functions have to check args to see if it is an AST_function is annoying

Oh?

heh heh, yeah

It should probably be walked backwards instead

Like take the first function node then walk backwards from its leaf

That way the functions just get the results of the next functions, not the actual uncalled next functions :P

hmm

Right now I'm structuring this so that ("add","function","num") just returns lambda self,opts=[],args=[],code=[]: pAdd(args[0].execute(),args[1]) :P

Locally?

If locally = my head then yes

ahh, okay

I don't want to screw this up

The subtract and divide functions don't work. You can edit those.

\sub doesn't work?

I'm fairly sure it won't but I haven't tried.

I had a unit test for it

Well, I can't test it now because of your edits.

Oh, \sub does work. Okay then.

Execute is in AST_function right?

Yes, and AST_operator.

So right now the function is getting put in self.func at parse time

Actually, do we know the types of the args at parse time?

Yeah, we do.

@El'endiaStarman did I do this right lmao

@El'endiaStarman you guys are doing implicit type conversion XP

Well yeah.

Lines 185-187

...you haven't been coding in Python lately, have you?

What did I do wrong ;_;

python doesn't have implicit type conversion

5+"6" is an error

if(self.func is None):

that javascript

@El'endiaStarman Doesn't it return none if the element isn't in the hash?

Python: if self.func:

oh, you weren't talking to me

nevermind, ignore me

@El'endiaStarman Other way around surely

Won't that execute it if self.func is defined

Eh? None is falsy.

oh

if not self.func

OK.

That's gonna throw an error anyway. KeyError.

OK, so it throws a KeyError when it isn't in the hash?

DO NOT USE TRY/EXCEPT IF YOU DON'T HAVE TO.

It'll still throw an error for other kinds of errors.

Good to know when it does!

See how much cleaner my code is?

Ye.

I remember reading an article on exception-based programming...lemme find it.

Cleaner, more elegant, and wrong and its sequel, Cleaner, more elegant, and harder to recognize.

OK, fair enough.

Although that uses a catch(Exception e) which is just criminal

Haha, indeed. And I'd like to note that I do use try/except in Minkolang for parsing numbers out of strings.

But also, I didn't ever use try/except in my programming until a couple years ago, and even since then, very sparingly.

Oh wait, minor problem: + uses \pAdd.

I know, I'm gonna do operators up here in a second

okay

I think we will indeed end up making objects like pInteger that have add methods and the like. For instance, consider factorial. It is nothing more than the product of all elements between it and the identity. Note that this definition doesn't require that the argument be an integer at all.

If I give you a class that has 1) identity, 2) a precessor or successor function, and 3) a multiplication, you can do factorial on instances of that class.

So that's duck typing

OK, we can do that.

I'm gonna think on the best way to implement pInteger and the like. I want to reduce repetition of code as much as I can.

Within reason.

Yeah. I don't really like the way calling functions works right now

This type tuple thing is a little better but not much

yeah

It worked for getting something working.

I should make a type/ops table.

uh-oh this isn't working

I feel proud to have failed all unit tests

oh dear

It's OK, the editor has a file history

Literally can revert all changes :P

But I'd like to get this working

Does the unit tester still rely on the build?

Ye

Oh I see the problem:

('a', 'd', 'd', 'number', 'number')

d'oh

Worked.

Oops, I forgot to add factorial, function

Hmm, the unit tester claims that the output is incorrect \print(\add(2,2)) but it is correct

I modified the unit tester to tell you what the exception is.

It's a "no such file or directory" error for me. o.O

(exception Command '['bin/pytek', '-c', '\\print(\\factorial(\\factorial(3)))']' returned non-zero exit status 1) for me

You have to be in the pytek/ directory

yeah

I was running it from src/.

Oh, I know why. One moment.

Nope, "Hello world!" still fails.

Oh, have to build. How do.

Nevermind, figured that out.

@AquaTart I fixed that. Problem was that you had '4\n' and not b'4\n'. I made it so that you don't have to prepend all the strings with b.

Aaand all unit tests pass again.

Added two more, one of which fails because + doesn't yet support str concatenation.

@El'endiaStarman Oh oops I took that out to test something and forgot to put it back :P

haha