19:03 <polarian> question about vectors and lists... do the same rules apply as with other languages, vectors are stored in contiguous memory and when interated they are simply offsetted from the initial position of the vector. As for lists (which can be represented in cons pairs), each element is allocated separately and contains a pointer to the next element?

19:03 <polarian> (how they work under the hood that is)

19:03 <polarian> therefore vectors are faster to iterate than lists?

19:07 <shawnw> Correct.

19:09 <shawnw> Scheme/Racket vector == java array, basically.

21:39 <polarian> I spoke to my professor and she said lists should always be done recursively

21:39 <polarian> but recursive adds a stack frame per iteration

21:40 <polarian> duplicates the variables passed in, and then repeats

21:40 <polarian> until the break condition is met... and then pops backwards with the return result until the original call is returned

21:40 <polarian> for/list exists, why would you recurse?

21:50 <polarian> *I'm aware recursion is useful for transversal and path finding*

21:51 <samth> for/list is implemented with recursion

21:53 <polarian> oh...

21:53 <polarian> so recursion is required for lists... why?

21:53 <polarian> why can't it be done like other programming languages... I assume its due to how lists are structured in racket?

22:02 <shawnw> A lot of list iteration is done with tail recursive constructs which get turned into effectively iterative loops. Plus for non-tail recursion Racket allocates stack frames on the heat so you don't get stack overflows. See https://docs.racket-lang.org/guide/Lists__Iteration__and_Recursion.html#%28part._.Recursion_versus_.Iteration%29

22:02 <rudybot> https://teensy.info/ihi2UjuL9h

22:04 <shawnw> All iteration in scheme and racket is ultimately done via recursion. They're just two sides of the same coin.

22:23 <polarian> shawnw: even vectors (arrays)?

22:25 <polarian> however stack frame allocation to the heap is slower... would it not? constantly asking to allocate/reallocate memory, aka spamming the kernel with syscalls...?

22:26 <polarian> however I assume if everything in scheme/racket is recursive orientated, then its a must...

22:39 <dzoe> It is not "stack frame" in the sense a C stack frame is. And also "asking to allocate" - remember the runtime performing the "stack frame" (ehm, continuations) management, is the same runtime in charge of the memory. And no matter how you call that region of memory (stack, heap, my favourite part of RAM ...) it is always the same memory.

22:40 <dzoe> Discussion can be made about cache affinity of such memory and other performance-related issues, but from algorithmic complexity perspective, you don't care. This just affects the constant factor.

22:40 <dzoe> And also with CS all of this is DAMN FAST compared to typical naive C implementation.