tag:blogger.com,1999:blog-17087850.post5863448823332339178..comments2023-10-31T06:50:41.697-04:00Comments on Factor: a practical stack language: Evaluating a quadratic polynomialSlava Pestovhttp://www.blogger.com/profile/02768382790667979877noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-17087850.post-32567543062111030922009-11-06T00:00:57.088-05:002009-11-06T00:00:57.088-05:00CuppoJava: Factor supports named variables also. h...CuppoJava: Factor supports named variables also. http://docs.factorcode.org/content/article-locals.htmlSlava Pestovhttps://www.blogger.com/profile/02768382790667979877noreply@blogger.comtag:blogger.com,1999:blog-17087850.post-44760005803448469082009-11-05T23:37:37.766-05:002009-11-05T23:37:37.766-05:00Hi Slava!
I've been interested in Stack-based ...Hi Slava!<br />I've been interested in Stack-based languages for a while now, and Factor sticks out as a extremely good implementation and language.<br /><br />But the lack of variables still bother me. I've heard advice similar to yours on this quadratic evaluator before. (namely, to re-interpret the mathematical function). But that has always seemed to me to be avoiding the issue.<br /><br />Consider the case where we have a derived formula already. It might involve many different parameters and functions... but these fell naturally out of the mathematical derivation.<br /><br />Given that the function is already well defined, it seems to me that the process of coding it should be almost a systematic process.<br /><br />The quadratic function was easy to re-factor. But I'm sure it's very possible to devise a formula that is very difficult to re-factor. <br /><br />In these cases, I think named parameters are a powerful abstraction that shouldn't be overlooked.<br /><br />Anyway, good job on Factor! I am continually amazed how clean and well designed everything is. From the language down to the libraries and even the editor!<br /><br /> -Patrick<br /><br />PS: I'm interested right now in a language that avoids heap allocation but still has a good abstraction for dealing with lists (or generators). Do you know of any?Unknownhttps://www.blogger.com/profile/03788768173213677157noreply@blogger.comtag:blogger.com,1999:blog-17087850.post-16350476963822972732007-03-30T18:42:00.000-04:002007-03-30T18:42:00.000-04:00Christopher, I certainly didn't mean to irritate a...Christopher, I certainly didn't mean to irritate anybody with my post.<BR/><BR/>When I first started working on Factor, I was not very good at dealing with the stack either. I would drop down into Java (the implementation language at the time) to implement various things, even though they could be done in Factor, because I was lazy. It wasn't until I started working on the native Factor implementation that I really learned Factor, because then I actually had no choice but to write a lot of Factor code!<BR/><BR/>I guess my whole point was that your function is <I>not</I> representative of stack code, at least not stack code written by humans (as opposed to compilers, rewrite systems, etc).<BR/><BR/>Array processing and similar tools greatly minimize the need for local names; the fact that they can be expressed in a stack language without a lot of effort is a plus, in my book. As Cat matures, you might find that having a rich library offsets the need for complex language features. Good luck.Slava Pestovhttps://www.blogger.com/profile/02768382790667979877noreply@blogger.comtag:blogger.com,1999:blog-17087850.post-47946519102096777492007-03-30T14:54:00.000-04:002007-03-30T14:54:00.000-04:00What you describe as a stack-based idiom, is in fa...What you describe as a stack-based idiom, is in fact an array processing idiom. Not that there is anything wrong with that, but it is unfair to accuse me of not understanding the idioms of stack-based language usage by comparing apples and oranges. Of course I am aware of array-processing techniques, and while they can be effective I chose not to use it in this case. Particularly because I wanted the code to be representative of stack-based code.<BR/><BR/>Leaving out the comment was also intentional, because I was intending to show that stack shuffling operations obscure the intention of code. <BR/><BR/>Even though I was vaguely irritated by the criticisms, which I view as unfounded, I am still very appreciative of the attention you have given Cat, and I am impressed with your work on Factor. I wish you lots of continued success.d166e8https://www.blogger.com/profile/04265118319823026605noreply@blogger.com