@DLosc can you make it so that a top-level def doesn't output anything?

You could have a debug flag.

@DLosc Are you on?

Also guys I posted the tips thing:

@DLosc Are you on?

@Qwerp-Derp No need to keep pinging me; I wasn't on, and now that I am I came here anyway.

Sorry, I'm impatient...

I will work on merging your pull request, but I've never done it before so it may take me a while to figure it out. Do you have experience you could share?

Like, can I make edits while merging, or do I have to comment and let you make the edits?

You can make edits after the things merged, but if you do it before it makes it much harder to merge the other things.

Because "conflicts" and all that

Ok.

And the first pull request that was closed--should I ignore that now?

Yeah, you can ignore that.

And I wasn't bothered to sort them out, so I made another PR.

Also @DLosc can you long-nameify chains.tl?

Before you merge the thing?

Also I think I should just state the problem straight away from now on instead of constantly pinging you to check if you're on.

@Qwerp-Derp Yeah, that's helpful. There's not enough traffic in this room for it to get lost. I'll see it whenever I'm on next.

@Qwerp-Derp Okay, confused again. Didn't you say above that I shouldn't edit before merging?

So chain-l is what you've been calling ->>, right? Does it need its own module, or can we put it in metafunctions? It seems like it's in the same category as apply, map, and foldl.

I'm gonna experiment a bit with this pull request merging stuff... if I mess something up, I guess you can create another pull request or I can just make the changes manually on my end.

@DLosc Uhh... I might implement chain-f as well, you can put it in metafunctions.

@DLosc You edit chains.tl on my pull request (so you PR my PR), and then I accept it

@Qwerp-Derp Okay, so I thought the l in chain-l stood for "left" (like my foldl function), but if that's the case I don't know what f would stand for...?

l stands for last, and therefore f stands for first.

Ah, okay. I wonder if (given my own confusion) it would be better to spell those out.

chain-last and chain-first

Hmmm but that would be really long

I mean, it isn't longer than something like foldl-default which we already have. The main problem is that the abbreviation l would stand for left but also last, which are direct opposites.

Ah.

Maybe last-> and first->?

Hm. Can you describe (or give me an example of) the behavior of the first variant?

Uhh, it would basically do ->>'s job, but instead of latching on as the last argument, it would latch on to the next expression as the first argument

So:

((first->
   (c (1 2 3 4)
   (rev)) 0)

= (4 3 2 1 0)

Ok. (I think you're missing a paren but) I see.

I think chain-last and chain-first are good, descriptive names that aren't overlong. last-> and first-> are readable once you know what they mean, but could be harder to learn. (That was my problem with the ->> syntax too.)

More naming concerns: you've used both append and conj at different times to refer to adding an element to the end of a list. Both of those names have drawbacks, though: append in Common Lisp is the command for joining two lists end-to-end (equivalent to concat in Clojure, which I think is a better name); and conj in Clojure, based on what I've read, adds items to the end of certain data structures but to the beginning of lists.

I guess I'm leaning toward append because that's what it does in Python.

If there's a good third option, though, I'm all ears.

(Also: let's not use that function much. Traversing the whole list twice? Ugh. It is necessary sometimes, though.)

Yeah...

@DLosc If you can optimise the function that would be neat.

I've turned it over in my head a bit, but I don't think I can without writing it in Python.

I found a constant-time version on Stack Overflow in Common Lisp, but it used setf to modify the cons structure of the list directly, which isn't an option in tinylisp.

Uhhh... how does the lambda thing work?

Are you asking how to use it or how it's implemented?

How do I use it for variadic args?

TBH I kinda want to know both

Is lambda built-in?

No, it's implemented in lib/utilities (along with macro).

@Qwerp-Derp Like this: (lambda args (head (reverse args)))

Oh that's nice

Basically, it transforms (lambda x y) into (x y) without evaluating x and y.

So it does exactly the same thing as (q (x y)), but it's more self-explanatory and requires fewer parentheses.

Similarly, (macro x y) gives you (() x y) without evaluating x and y; it does exactly the same thing as (q (() x y)).

TL;DR: Lisp macros are cool ^_^

Whoa that's awesome :)

Your naming is inconsistent - you should just make h head and t tail

You've got variations of car and cdr everywhere, it's inconsistent

"Everywhere"?

I think I just have them in the definitions of cadr and cddr, which I proceed not to use anywhere else.

I wanted to provide those for hardcore Lispers who couldn't get their fingers used to typing head and tail. But I agree they shouldn't be used in library code.

On a related note: I'm thinking of adding functions ttail and htail for (tail (tail ls)) and (head (tail ls)). Sound good?

@Pavel Actually, that's a good idea: a top-level def doesn't output anything, but a def nested inside another function still does. Let me see if I can make that happen.

@Qwerp-Derp I'm calling the function to put an item on the end of a list insert-end. It's unambiguous, and the somewhat clunky name hints that this isn't a function you really want to be using a lot. ;)

Incidentally, I haven't yet made this CnR post safe, if anyone's interested in cracking it: