Quote:Original post by joanusdmentia
Ahh, ok then, so the apparently superfluos brackets actually change the meaning. With them, the define'd expression is evaluated each time and without them it's evaluated the once (ie. it's constant). I had tried remove the brackets where those 2 were being evaluated and got some errors so put them back, but I didn't think to remove them from the defines as well.
Something like that, yes. When using the parens, you're defining a function, meaning that when you "use" the value, you need to put 'change-ratio' or 'good-enough?' between a pair of (), which denotes a function call. When no parens are present in the define, you just define a value which you can use by referring to it by name without extra ().
(define x 5)(print x);; or(define (x) 5)(print (x))
In case you're familiar with lambdas:
(define (myfunc args) body);; is the same as(define myfunc (lambda (args) body))
Quote:
Quote:Original post by SamLowry
Another question then :) What advantages/disadvantages are there to my way and your way? When does using functions for 'change-ratio' and 'good-enough?' become interesting?
Hmm, would change-ratio and good-enough? be evaluated *before* the main body of the newton-method function in your case, whereas in mine they would be evaluated during? If so then I think yours might have a performance benefit as mine would produce a more complicated expression tree. As for when they would benefit from being functions, when they take parameters other than those of the outer function I suppose (eg. called twice from the main body with different parameters).
In "real" scheme (and not the substitution model used in the current chapter) both values would indeed be computed first, after which the body gets evaluated. The main difference I had in mind was the fact that in my case, the values for 'change-ratio' and 'good-enough?' will only be computed once, regardless of how many times they're used in the body, while using a function will have the same expressions evaluated multiple times. Using functions (like in your version) would be necessary if the arguments to 'newton-method' were to change inside the body: this way the values for 'change-ratio' and 'good-enough?' are guaranteed to be valid for the current values of the arguments (automatic "synchronisation" because you re-evaluate it each time). But this is stateful programming, and will only be handled in a later chapter.
I wanted to mention this because replacing data with code is a pattern which often returns.
Both your arguments are of course also correct.
Quote:
Quote:
I'm not familiar with GCC, what would happen here:
*** Source Snippet Removed ***
I've only seen the extension mentioned in a couple of places, but have never really used it before. I doubt that your code (with whatever syntactic sugar gcc wants) would compile though, because increment() would require the stack of make_counter() to exist you wouldn't be allowed to call it through a function pointer from outside of make_current(). I'd imagine the type of '&increment' would have to behave somewhat like pointer-to-members, you would be allowed to return the pointer and pass it around but only be allowed to call it from within make_counter() and couldn't cast it to a normal function pointer.
Indeed, the stack makes it problematic. Using Scheme, you'll be often returning functions like this (section 1.3.4), and there won't be such a problem. How Scheme does it will be handled in a later chapter. It might be interesting to watch out for those little differences between Scheme and C++.
I'll stop bothering you like this (for now :)), I hope I'm not confusing you too much, feel free to tell me so. My reason for doing this is mainly to be able to find out which little "assumptions" you make about Scheme, like thinking it's the same as in other languages you're used to. A lot of confusion arises from this kind of small details which more experienced Scheme-users take for granted and fail to point out.
