@El'endiaStarman What did you figure out?

@quartata The parser structure

Also, have you thought more about replacing code blocks with lambdas?

@quartata I'm planning on sticking with {} for conditionals and loops, at least.

@El'endiaStarman So if and for won't be functions then

@quartata Mathematica does it like that and it's infuriating

@quartata Two key observations: 1) I don't have to decide what to do immediately; the "parse" method of each node can return the instantiated node and whatever's left over, and 2) I only have to do this delaying decision thing if the node is not delimited, which helps avoid constructing (say) number nodes while inside a string.

@AlexA. Why?

@quartata Why does Mathematica do it like that? I wish I knew.

@El'endiaStarman Ah, OK. That makes sense.

@AlexA. No, why is it infuriating

@quartata Actually, they might still be.

@El'endiaStarman But how will that work? Blocks aren't a type.

(yet)

@quartata They could be. Besides, each function can define what sort of parameters/block types/whatever they should be called that they take.

So blocks could be variable-arity and lambdas fixed-arity?

I don't fully know yet. We'll see.

I guess we should worry about parsing strings first :P

Anyway...I too am curious as to why @AlexA. thinks Mathematica's treatment of if and for as functions is infuriating...

@quartata Strings are actually super easy, funnily enough.

Well, strings and functions and all that.

@El'endiaStarman oh lel forgot to respond

By the way self.funcName = val[0] seems wrong

@quartata The code is rather inconsistent right now because I was trying to figure out how to do stuff.

self.funcName = val[1:val.index("(")-1], right?

Yeah.

Well, not exactly.

Oh right, named args.

Well we won't worry about those yet

It'll go up to the first opts/args/code node.

← 32 messages moved from The Nineteenth Byte

@AlexA. Still waaaitiiiing...

o> quack

¯\_(ツ)_/¯ Just makes more sense to me to have control flow as a separate language construct than functions.

hmm

\for(array, <x:
  \print(x)
>)

Doesn't look that ugly too me.

I dislike the need to do stuff like >) because it annoys me in JavaScript.

@quartata I'm literally gagging

<thing>.forEach(function(e){
    ...
};

See the error?

We should probably make lambdas {} I think.

@El'endiaStarman yes

@El'endiaStarman Gotta close them parens, son

Irked me every time it happened.

I often forgot about the forEach function.

That's why I want to stick with \for[opts]{code} or \for(args){code} syntax.

func:isPrime(n) {
  return [1...n]~\product,n->\mod == n - 1
}

@AlexA. What emotions does this piece of code arouse in you

@El'endiaStarman The former will perpetuate my opinion that this language is like LaTeX. :D

@AlexA. Well, it does derive its syntax heavily from that...

@quartata Confusion, nausea, arousal...

...Nauroused?

( ͡° ͜ʖ ͡°)

@Mego: Thoughts on the sample code above?

It honestly looks really confusing to me. I can kinda sorta see how it's supposed to work, but...

hahahaha

@AlexA. It's called a chain.

@quartata I figured

The list [1,2,...,n - 1] is put in a list, \product pops it and pushes the product to that list, n is added to it, then \mod pops both and pushes the result.

Oh god, don't tell me [1...n] actually makes [1, ..., n-1]. That's confusing as hell.

@AlexA. No, 1...n makes [1,...,n-1].

It's then wrapped in a list.

@Mego 1...n is range(1,n-1). This is like [range(1,n-1)]

@Mego I think that'd be neat so long as it's limited to integer ranges. Otherwise it's unclear.

@quartata That's literally what I just said

@AlexA. How is that confusing? It does that in Ruby too.

Because in math, the notation [1...n] means 1 to n, inclusive.

[1...n) would make more sense for 1 to n-1

@AlexA. The [] mean something completely different.

If it was just 1...n, the resulting list would be splatted.

YES

^

[1...n] -> [[1,2,3,...]]

@quartata Okay, but why is 1...n 1 to n-1? That's the part that's confusing.

Because the way it works is that if input is a list it appends the contents of it to the arg queue

@AlexA. We can change that I suppose. I made it triple dot because that's what Ruby does, so I figured it would be (slightly) more familiar

@AlexA. 1..n is 1 to n-1. 1...n is 1 to n.

Personally, I don't like this all that much.

That's really weird.

I like the double-dot one, but I think we can do better for the inclusive version.

I prefer the double dot as well. That matches how Mathematica does it, at least.

@El'endiaStarman er... no? 1..n is 1 to n. At least that's how I wrote it up.

Heh. I always thought 1..n was equivalent to range(1,n).

Ergo, exclusive, like Python.

Oh

I made it inclusive like Ruby. Sorry :P

OK, take two:

@AlexA. That's probably where I saw it. Err, no, maybe it was Ruby. In any case, it's not exactly original to me.

func:isPrime(n) {
  return 1..n~\product,n->\mod == n - 1
}

What if we did it like this?

List is taken as is, scalar is wrapped in a list.

Is that clearer?

I think we lost Alex's attention with all our "ugly" code sigh

heh

We're so misunderstood

lol

Quick post a picture of a puppy to get his attention

Seriously?

bans self

Imgur's being slow otherwise I would've had a puppy gif in here by now... :(

It's okay, once we start beating Jelly with Ptk, people will give us attention. :P

I think they're long gone already sigh

OK, it's your turn to find the next pair of hobos for the focus group

lol

I wanna get "Hello world!" working first. :P

@quartata ಠ_ಠ

@quartata Is this a question for me?

@AlexA. yes

@Mego irdK, it's yirdr turn tird find the next pair irdf hirdbirds fird the firdcus grirdup

@quartata Looks the same

func:isPrime(n) {
  return (1..n~\product,n->\mod) == n - 1
}

Now is it better

No.

OK, let's start from the very beginning...

1..n is wrapped into a list.

We have [[1,2,3...]] now.

The first stage of the chain is \product,n.

\product is monadic, so it takes [1,2,3...] from the front of the list and appends the result to the end of the list.

Then, n is added to the end of the list.

Now we have [<product result>,n].

Then, in the next stage, \mod takes those two results and computes the modulo. This is put in the list, and since there is only one element in the list at the end it is splatted and returned.

If it had more than one element it would be returned as a list.

With just one it just gives that first element back.

Everything between the ~ and the ) is called a chain. It's a special kind of varity function.

~ is how you call it.

We could assign it to a variable, say, x = \product,n->\mod.

Then call it like n~x.

It's worth noting that chains can be assigned to a function.

Hmm, I still think wrapping it in a list only if it is a scalar is more useful.

You mean at the end?

No, beginning.

I think so too - it's consistent.

oh, right

We can leave the square brackets off the range if it wraps it into a list always, but then there's no real way of passing multiple args.

By wrapping only if it is a scalar, passing a list = passing multiple args

It does mean in this case you need square brackets but I think it is a small price to pay.

Yeah, I think we'll do it like that.

Sorry @AlexA. @Mego but we're too set in our ways lmao

@ALEXA.

@Mego That's sorta part of the point. If there's a better/more succinct way to do things, go with that. It will always take time to get used to it.