@ASCII-only I am now

Ok so what now

@dzaima ping

oo I found my old progress on the function file

:D

@dzaima {inc: {fn: a => a + 1, types: [Number]}

or ["num"]

oh yeah it also specifies the output type

"+": {
  "nn n": (a,b) => push(a.plus(b)),
  "tt s": (a,b) => push(a.toString()+b)),
}

example of a function there

t?

two any types equal a string

type, if you have any better ideas tell me as that was just a random choice a while ago

@dzaima Hmm I'd say make it an array, the only benefit of this is it looks nicer

@ASCII-only so how would that look?

"duplicate": {
  "1 11": (a) => {push(a); push(a);}
}

actually

"+": [
  nn: ['n', (a,b) => push(a.plus(b))],
  tt: ['t', (a,b) => push(a.toString()+b))],
]

actually numbers instead of t are a better idea

why

"swap": {
  "12 21": (a,b) => {push(b); push(a);}
}

IMO we should at least have t as well (well we don't need to)

but I'd prefer tt s over 12 s (tttt s over 1234 s)

@ASCII-only good point

so t means any type independent of anything

yes, oops

huh, I never implemented the interpreter part of this

wait wat

I thought you did

@ASCII-only same

@ASCII-only this = the "tt s" command type interpreter

oh

next problem: how is that system gonna handle loops/ifs

@ASCII-only that doesn't even work

@dzaima ??

{
  "+": [
    nn: ['n', (a,b) => push(a.plus(b))],
    tt: ['t', (a,b) => push(a.toString()+b))],
  ]
}

@dzaima :| oh yeah

I was going to go with ['nn', 'n', ...]

But realized we can still use a dictionary since we know input types

a bonus of using dictionaries is that ,loop:true is allowed and loop doesn't need to be quoted

@dzaima ??????

oh yeah

just remembered why the interpreter has to be half rewritten.. Currently the objects don't anywhere store whether they're dependent on the input/whether their type is known at all

:|

oh yeah I was gonna integrate that in the function setup so I wouldn't have to deal with it

I'm thinking now whether splitting the execution from the pseudo-stack would be a better idea..

two separate parts?

@ASCII-only the actual implementation of the stack based language and info of how it acts for the decoding process

Right

@dzaima ..easy fix: just make another stack for that extra info

which reminds me, I wanted to have the functions usable in other functions, so they wouldn't push to the stack when possible

?????????

So a bit like brain-flak?

"+": {
  "nn n": (a,b) => a.plus(b),
  "tt s": (a,b) => a.toString()+b,
}

and the interpreter realizes that the function hasn't pushed that number/string it had to so pushes result of the function

??????????????

what.

so later I could execute the function inside another one, e.g. fn("+")(10, 5). Well maybe not for + but for more complicated functions that could be useful

having that not possible is one of my biggest mistakes with SOGL

:P

but what i mean is I don't understand what you mean by realize function hasn't pushed

@ASCII-only well the definition of the function is tt s, meaning that it has to push a string one way or another. The function never pushes anything, so the interpreter, trying to fix that, pushes what the function returned

Shouldn't the interpreter push everything

stack.push(sum(...args))

@ASCII-only pushing/popping in a function may be useful, e.g. a function that pushes the whole stack as an array

@dzaima return this.stack

or pushes the contents of an array all on the stack

@dzaima I'd say make interpreter push if function does not return undefined

@ASCII-only Yeah, that's a good idea too

yay it works :D

@dzaima :O what it works

"getType": {
  "s s": (a) => "it's a string!",
  "n s": (a) => "it's a number!"
},

although that resulting type - here s - isn't used (because it has no use really on the regular language)