Post #107,196
6/24/03 11:24:19 PM
|
You win, again
By continuing to refine your claim, and rejecting evidence which doesn't directly fit your ever-narrower statement (particuarly when you set rules that make you the only arbitrator of what evidence is worth thinking about) you can succeed in not being convinced by anyone.
Now that the problem has been refined, and I am asked to produce what is not mine to produce, no I can't produce direct evidence.
Satisfied?
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #107,199
6/24/03 11:52:52 PM
6/24/03 11:53:17 PM
|
Can't ANYBODY ever find a #@!* BIZ example?
________________
oop.ismad.com
Edited by tablizer
June 24, 2003, 11:53:17 PM EDT
|
Post #107,222
6/25/03 9:14:37 AM
|
Ben's given me an idea.
First, Ben noted that callback functions are a type of closure.
Right. The app I am developing in my work is an intranet application that you access from a web browser. The current version is written as PHP pages which are backed by a database. You can think of the whole thing as a database application if you like, which it basically is, really. Some of the information needs to be displayed on-screen in a tree-like structure - much like the directory listing in Windows' File Explorer. Without getting into an argument about OO, we designed a Node object for representing a node. Each Node knows it's parent node, and has a list of it's children nodes. It also has a piece of arbitrary data which represents what is actually "at" that node. Thus a Tree is a Node with children Nodes, any of which can have children, etc etc. A simple recursive function is sufficient to print it using pre-order traversal, which display things as we want. But how to get something printable out of the opaque data?
In a pure OO world, the data could simply be defined as an object which responds to a suitable method. Well, while PHP's object infrastructure would support this, the rest of our app isn't pure written OO-style. Besides, these Trees are going to be created, displayed and then discarded in the same page. So we decided on a callback function: the display function takes as one of its parameters the function name which it calls for every node. The callback function is given the opaque data of the node in question as well as some optional extra information (to eliminate global variables) - all it has to do is output what is to be displayed.
Simple, clear and elegant.
FWIW, PHP also supports creating functions on-the-fly for this kind of thing, although it's a bit clunky and only works because the whole language parser is available at runtime...
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #107,322
6/25/03 9:07:51 PM
6/25/03 9:09:55 PM
|
different "core"?
In a pure OO world, the data could simply be defined as an object which responds to a suitable method. Well, while PHP's object infrastructure would support this, the rest of our app isn't pure written OO-style. Besides, these Trees are going to be created, displayed and then discarded in the same page. So we decided on a callback function: the display function takes as one of its parameters the function name which it calls for every node. The callback function is given the opaque data of the node in question as well as some optional extra information (to eliminate global variables) - all it has to do is output what is to be displayed.
I am still unclear as to why you need a closure. I suspect it is that you have complex tree traversal code, and you don't want to repeat it for each different use of the tree. Therefore, you pass the "core code" in the form of a function pointer to this complex looping or recursion thingy.
The simplistic solution is perhaps a Case structure in the middle of the loop or recursion. If you only have say 3 different processing options and they don't add new ones very often, this may work.
The "ideal" TOP solution would be to use a RDBMS that can traverse trees without coding recursion. (Oracle has this I beleive, but I cannot vouch for its friendliness.) If all usages use the same query, then simply have a global string or function to share (reuse) the same query. It is then no different from any other query-and-iterate-result-set pattern. Unfortunately, Dr. Codd excluded tree operations from his original relational operators.
________________
oop.ismad.com
Edited by tablizer
June 25, 2003, 09:09:55 PM EDT
|
Post #107,472
6/27/03 7:42:08 AM
|
That's one way to think of it.
The point of passing the function is that code to display the tree is entirely unaware of what the data is in the nodes. It simply doesn't care because it doesn't have to care - all it needs to be concerned about is that there is a function to call. Putting that logic in the walk-the-tree code does not make sense because that location is how the tree works, not where I use the tree. (Incidentally, the recursion is peripheral to the example: it's prime purpose is to permit the tree to be an arbitrary depth.)
A closure is like passing a pointer to a function, except that the function is anonymous (i.e. has no name) and is defined right where you would specify a pointer-to-a-function if the language doesn't have closures. They're sometimes called lambda functions.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #107,662
6/28/03 12:27:03 AM
|
But if tree traversal was trivial, then it does not matter
If the relational system supports tree operations, then it is as simple as:
----Usage 1:
rs = getTreeTraversal()
while (getNext()) {
. . doSomething_1
}
----Usage 2:
rs = getTreeTraversal()
while (getNext()) {
. . doSomething_2
}
----Usage 3:
rs = getTreeTraversal()
while (getNext()) {
. . doSomething_3
}
The problem you are having is that the bread is more complex than the meat of the sandwich. Simplify the bread (tree traversal), and using tricky closure meat is no longer so important.
In practice, we probably want different filtering, cross referencing, etc. for each usage. That is where custom relational queries would shine. One-size-fits-all traversal is not that likely if there are many usages.
________________
oop.ismad.com
|
Post #107,674
6/28/03 8:51:24 AM
|
It's a matter of perspective.
Using your coding style, my solution looks like:
rs = getTreeTraversal()
displayTree(rs, displayFunction)
function displayFunction(item) {
. . doSomething_1
}
Which one is easier to implement depends on the details of walking the tree*. The more state that must be kept between touching each node, the easier it is to implement it my way, although that is not the only consideration. (BTW, tree traversal need only look trivial for the code using the tree.)
Actually, implementing this with a closure makes it look like your example, but it works more like mine: you get the advantage of a loop-like construct in both places.
Wade.
* although I've let it slide 'till now, whether or not the tree is database-backed or just in-memory is not important in my example.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #107,257
6/25/03 12:52:13 PM
|
A TOP example
Pardon my Ruby; it's rusty... \n# do some work in a database transaction\ndef inTransactionDo(db)\n db.startTrans()\n yield\n db.commit()\nrescue\n db.rollback()\nend\n\ninTransactionDo(db) {\n #use db to update the database\n}Regards, John
|
Post #107,319
6/25/03 8:59:12 PM
|
re: transaction rollback
Why not:
sql = "select * from...."
rc = myTransaction(sql)
where "rc" is the "return code". We could also add a named parameter for specific handling:
myTransaction(sql, failure="messageAndDie")
The default could be to simply return the status in the return code.
I suppose we could even pass the name of the routine to execute if there is a problem, sort of like "onClick='foo(this)'" in JavaScript. It could be passed a dictionary structure with some info about the error. In some ways this is closure-like, but without explicit closer syntax. All we need is an Eval() or Execute() kind of operation in the language.
________________
oop.ismad.com
|
Post #107,474
6/27/03 8:33:53 AM
|
Why not just use a closure?
Why not:
sql = "select * from...."
rc = myTransaction(sql)
Because a "select" doesn't need a commit or rollback? I assume you would handle the need to execute multiple SQL with the following:
I suppose we could even pass the name of the routine to execute if there is a problem, sort of like "onClick='foo(this)'" in JavaScript. It could be passed a dictionary structure with some info about the error. In some ways this is closure-like, but without explicit closer syntax. All we need is an Eval() or Execute() kind of operation in the language.
Why create a hack workaround for closures when you could just use a closure?
BTW, I've never used a language that supported Eval() in a work environment, so none of your ideas would ever be usable for me.
Regards,
John
|
Post #107,532
6/27/03 11:28:06 AM
|
Eval () is a kind of closure
minus local variables, minus enclosing scope variables, minus compilation, minus parameter passing...
But it's easy to understand. So Tablizer understands it.
Perl, TCL, Shell support it. I am not sure about Python, but seems like it should support it too.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #107,533
6/27/03 11:30:47 AM
|
Python supports it...
Most interpreted languages do.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #107,660
6/28/03 12:15:21 AM
|
topic is not about me, Mr. Insult
But it's easy to understand. So Tablizer understands it.
It is not about me. I can care less whether a language supports ultra-closures or not. The issue here is why some languages are popular and some are not. Closures add more to the learning curve for "average" programmers than what the benefits they offer make up for [sentence needs rewrite]. If you need knives often, then a swiss-army-knife may be worth it. But if you don't, then a two-blade pocket knife (Eval) is probably sufficient. Eval() may not be as clean as full closures, but it offers almost the same power for *occasional* use.
I have not seen any slam-dunk realistic coded justification of full closures that one can wave in front of programmers and say, "See, it greatly simplifies the code. Thus, the learning curve is worth it".
Your sales presenation is lousy. Perhaps you are a programming genious, but a shitty marketer of languages and paradigms. Don't red herring your failure onto me. The marketing flunkage is yours, not mine. It is not my fault that putting closures in a language will kill its sales.
________________
oop.ismad.com
|
Post #107,710
6/28/03 3:45:30 PM
|
Re: Eval () is NOT a kind of closure
I don't see "eval" as a kind of closure. Eval would not be able to do the kinds of things I use closures for. Nor would a closure work where I needed "eval" capability.
They are not interchangable except for extremely trivial examples.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #108,471
7/5/03 1:52:00 PM
|
You are right.
No, you can't implement car and cdr with eval.
And no, you can't ask a user to type in an anonymous function that returns another function as a result.
But all the examples that Tablizer and his opponents have in mind have been trivial so far.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #108,580
7/7/03 3:24:34 PM
|
All?
But all the examples that Tablizer and his opponents have in mind have been trivial so far.
Did you look at the examples that I had him look at?
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #108,605
7/7/03 5:27:39 PM
|
I was thinking about
transactions (where you could pass in a set of SQL statements, I guess) and regression.
Your examples are not quite doable with eval. When, oh when will I be able to think like this! I am not too much above average, it seems :( .
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #108,654
7/7/03 11:28:36 PM
|
Thought you had missed those :-)
As for when you will think like that, perhaps after reading On Lisp, and working your way into The Structure and Interpretation of Computer Programming. And then some good conversations with people who already program like that...
At least that was my strategy. :-)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #108,705
7/8/03 1:12:10 PM
|
Re: Thought you had missed those :-)
I've ordered The Structure and Interpretation of Computer Programming yesterday :) BTW, the first example cam probably be done with straight recursion (but not with eval). If I get it right, the advantage of closures in that case is that you "prebuild" recursion stack, so the actual execution of recursion goes faster (you don't have to parse parameters for every call). \n\nproc multilevel_for {varname all_ranges code} {\n multilevel_for_implementor $varname $code {} $all_ranges\n}\n\nproc multilevel_for_implementor {varname code proc_args all_ranges} {\n if {[llength $all_ranges] == 0} { \n set $varname $proc_args\n unset varname proc_args all_ranges\n eval $code\n return\n }\n set range [lindex $all_ranges 0]\n set from [lindex $range 0]\n set to [lindex $range 1]\n for {set x $from} {$x <= $to} {incr x} {\n multilevel_for_implementor $varname $code [concat $proc_args $x] [lrange $all_ranges 1 end]\n }\n}\n\nmultilevel_for combination { {1 10} {3 4} {10 20} } { puts $combination }\n\n\n--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #108,715
7/8/03 2:03:05 PM
|
That mostly works
The one big mistake is that you assume that the ranges passed in are always ranges. I only did that in my example because it is easy to generate ranges, but the combination code doesn't care what kinds of arrays you want.
But the idea does accomplish the job.
However an advantage of closures is that they don't run into problems if, say, the function that you are calling happens to name a variable using one of your internal variable names (eg varname, proc_args, or all_ranges). Another advantage is that you don't have the same number of parsing/encoding steps to confuse you. Furthermore the code passed into eval can be a closure itself - and may have behaviour which has already been parametrized in other ways.
Still these technical advantages of closures notwithstanding, the basic notion depends on code manipulating programmable behaviour. And any method of doing that, including eval, can make it work.
Incidentally I suspect that Ruby's version of eval can replace (inefficiently) any possible use of closures. The reason being that you can capture a context, and then by passing that context to eval with the code, you can eval the code in the other context. In other words the one thing that closures fundamentally buy you (ability to access encapsulated lexical values in some other part of the code) can be done within eval. I haven't seen this capability in other languages. (Not that I have looked very hard.)
Cheers,
Ben
PS It took me a bit to figure out which language you were using... (Well, OK. It was my first guess, it just took me a bit to find my TCL interpreter and verify the guess. And a few others in gaim were just flailing.)
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #108,720
7/8/03 3:40:28 PM
|
Re: That mostly works
>>>>>>>>>>
The one big mistake is that you assume that the ranges passed in are always ranges. I only did that in my example because it is easy to generate ranges, but the combination code doesn't care what kinds of arrays you want.
<<<<<<<<<<<
I thought about it, but TCL has no construct equivalent to Perl's range array. And, as you know already, I hate Perl :)
I could do some special case processig to accomodate ranges and lists, something like
multilevel_for combination { {1-10} {3-4} {10 20 30} } { puts $combination }
and have a regexp to notice '-' in the middle of single-element list's only element. Very TCLish way to do things, and also very ugly, because now you need an escape for the lists that have one element ... and so on.
>>>>>>>>>>>>>>>>
However an advantage of closures is that they don't run into problems if, say, the function that you are calling happens to name a variable using one of your internal variable names (eg varname, proc_args, or all_ranges). Another advantage is that you don't have the same number of parsing/encoding steps to confuse you. Furthermore the code passed into eval can be a closure itself - and may have behaviour which has already been parametrized in other ways.
<<<<<<<<<<<<<<<<<
I know, I know. The only variable that is left to pollute the namespace is $code. I could work around it by using TCL's namespaces, but that's to much for a proof of concept.
As to parameterizing the closure, it can be acomplished to some small extent via exceedingly ugly use of concat command. I don't want to write it, and you don't want to see it :) .
Hey, I've never said it will be pretty :)
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #108,722
7/8/03 3:59:45 PM
|
Think we are even then
I thought about it, but TCL has no construct equivalent to Perl's range array. And, as you know already, I hate Perl :)
And my summary of TCL is that yes, you can base a language entirely around quoting and parsing strings, and it is a bad idea.
My solution wouldn't be very TCLish though. I would just write a function to produce ranges, and then I would pre-process arguments rather than post-process them in each function that wants to support such a basic notion. Of course the fact that this approach is not very TCLish speaks volumes for why I don't like the language...
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #108,820
7/9/03 10:08:08 AM
|
A function to produce list from range
would not work very well for huge ranges.
No, you need real iterators for that. Too bad for TCL.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #108,847
7/9/03 12:51:26 PM
|
So?
In the kinds of problem spaces that scripting languages are usually used for, wasting memory like that is just fine. When you get to a problem where the simple wasteful approach doesn't work, then you start to worry about it.
Though I admit that the better scripting languages have been moving for a while towards making it possible to replace basic data structures with real iterators. (With varying levels of ease.)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #109,006
7/10/03 11:34:37 AM
|
Fake Closures
Ben: Incidentally I suspect that Ruby's version of eval can replace (inefficiently) any possible use of closures. The reason being that you can capture a context, and then by passing that context to eval with the code, you can eval the code in the other context. [...]Since a closure is just code + context, you can do as you describe. Its a little tricky passing parameters since the parameter you wish is pass is generally not in the scope where the string is evaluated. I used a global stack ... global to handle the cross scope parameter passing and a stack to handle nested closure calls. Here's a Ruby class implementing fake Closures ... $args = Array.new\nclass FakeClosure\n def initialize(str, bind)\n @str = str\n @bind = bind\n end\n def call(*args)\n $args.push(args)\n eval @str, @bind\n ensure\n $args.pop\n end\nend Ben: [...] I haven't seen this capability in other languages. [...]TCL has it with its uplevel command. Old (pre-closure) versions of Lisp had something called "funargs" that represented scope and could be passed to eval (I don't know if modern Lisps still support funargs).
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #109,018
7/10/03 12:35:26 PM
|
Wow
first geniunely new TCL command in a long while
I missed it completely. Thank you.
Together with "info level" it's almost perfect.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #107,716
6/28/03 3:55:08 PM
|
Re: A TOP example
Pardon my Ruby; it's rusty...Actuall, the Ruby DBI library has a built in transaction method ... \n db = DBI.connect("DBI:Pg:yadayadayada")\n db.transaction {\n db.do("UPDATE people_table ...")\n db.do("UPDATE payroll_table ...")\n }\nEither both updates happen ... or they don't. (You might have to turn off autocommit ... I think that is DBD dependent unfortunately).
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #107,325
6/25/03 9:28:31 PM
|
Multivariate Regression Analysis
Best use I found for them was the ability to solve [link|http://www.angelfire.com/tx4/cus/regress/index.html|multivariate regression]. Closures give you the ability to specify the form of the equation external to the regression operation itself without having to have a function devoted to each particular form of equation.
Of course, this is not your "standard business app", but then I'm not paid to develop standard apps. I'm paid to develop software that does whatever is required, including forecasting, etc... - statistics is but a part of the discipline of analyzing business data.
|
Post #107,396
6/26/03 12:55:37 PM
|
Why not Eval()?
I have done data conversions where I put a bunch of expressions (equations) in a table and then processed each record through the conversions using Eval(). The accountant I was working with caught on to the expressions pretty quickly and started writing in some corrections to my initial guesses to the fixed assets depreciation calc conversions.
For those of you not familiar with such functions, you can do things like this:
x = "23 + b"
b = 5
r = eval(x)
print(r) // result: 28
Closures give you a bit more scope control than Eval() or Execute(), but for smaller programs it is not much of an issue. Again, I am not saying that closures won't simplify anything, I am just saying that the difference is relatively minor, and the inclusion of closures in a language often dooms it. Eval() or Execute() are non-intrusive syntax-wise; they are just functions like any other.
There are not that many places where Eval()-type things are needed, at least not all over the program, so a 5% reduction in syntax or a slight improvement in packaging for those few spots of the code is not a huge selling point. I see no reason to move them to the top of my wishlist as long as I have Eval-like functions.
________________
oop.ismad.com
|
Post #107,404
6/26/03 2:02:54 PM
6/26/03 2:05:28 PM
|
The problem is that the equations are part of the data
Eval doesn't do any good unless you want to parse a string to represent the equations - and even then you need some way to represent the equations as data (i.e. be able to manipulate it).
Your misunderstanding is to assume that I know the equation. I don't know the equation, I know one or more forms of the equation that I'd like to solve for (i.e. find the coefficients and r-square values). In your example, you are using of: x = "23 + b" - meaning that the a0 coefficient is 23 and the a1 coefficient is 1. The regression is designed to input some numbers [0,23], [1,24], [2,25], and figure out the coefficients (23,1). That just happens to be a simple linear equation that can be done without resorting to closures. However, what if wanted to solve the coefficients for:
y = a0 + a1*x + a2*x*x + a3*x*x*x
and just had a bunch of (x,y) data points. Or how about throwing in some additional exogenous variables:
y = a0 + a1*x + a2*z + a3*x*z + a4*x*x + a5*z*z
Now, how do you propose to solve for these coefficients given a series of data points? Having done this in a version of Pascal that does not have closures, my solution was to build a parser that allowed you to represent the form of the equation as a string. Problem is that a parser becomes a mini-language and occupies a good amount of space and requires an attention to detail. Whereas, by using closures in Python or code blocks in Smalltalk, I can sling together equation forms (i.e. lambda functions or anonymous functions).
Edited by ChrisR
June 26, 2003, 02:05:28 PM EDT
|
Post #107,458
6/27/03 2:02:25 AM
|
I am not following you
My math is too rusty I guess. The equations can be stored anywhere. In tables, in files, etc. You can have something like:
equation = prompt("Enter equation:")
// assumes equation has "a" and "b" in it
a = prompt("Enter A:")
b = prompt("Enter B:")
printLine("Result is " . eval(equation))
Example run:
Enter equation: a*2 + b*b
Enter A: 3
Enter B: 4
Result is 22
(Validation and security is another lesson)
________________
oop.ismad.com
|
Post #107,497
6/27/03 10:08:47 AM
|
Do you not understand Regression?
The equations can be stored anywhere. It's easy enuf to store the equations - IF YOU HAVE THE EQUATIONS! That's your problem, you're assuming that all you are doing is storing coefficients. // assumes equation has "a" and "b" in it
a = prompt("Enter A:")
b = prompt("Enter B:") There's your problem. Your program is not smart enuf to figure out the coefficients A && B. What if I give you a table of: CREATE TABLE MyData(x INT, y INT) INSERT INTO MyData VALUES(1,0) INSERT INTO MyData VALUES(3,1) INSERT INTO MyData VALUES(5,2) and I told you the equation was of the form: y = mx + b Now give me a program that uses the above data to derive m and b. Don't give me a program asking the end user to give me m & b. When you get that done, then start changing the form of the equation around, adding more variables and various combinations of power orders. Something simple like: y = a + b*x + c*x*x + d*x*z + e*z*z + f*z And don't ask the operator to supply the a,b,...f coefficients.
|
Post #107,537
6/27/03 11:39:49 AM
|
Eval can be used to compute arbitrary function
with arbitrary number of arguments.
It's really inconvenient, but possible, because most evals have access to global variables (and some even to local scope variables). So you do something like this:
getFunctionValue(string f, real x[], real a[]) {
idx = 0;
foreach anX in x {
eval("x" . idx . " = " . x);
}
idx = 0;
foreach anA in a {
eval("a" . idx . " = " . a);
}
return eval(f);
}
And then you build your "f"s so that they use x0, x1 and so on for argument names, and a0, a1 and so forth for parameter names.
And then you can look for minimum sum of squares by calling getFunctionValue in the known data points x[] and varying a[].
And then you throw up in disgust at this slow unvieldy buggy contraption and choose a language that supports real anonymous functions. You do. But not Bryce. He is happy. He has just achieved another triumph of Eval.
--
Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.
--Alan Cooper. The Inmates Are Running the Asylum
|
Post #107,556
6/27/03 1:02:48 PM
|
Eval is "good enuf" for occassional use.
It's really inconvenient, but possible, because most evals have access to global variables (and some even to local scope variables).
In the languages I am familiar with, they had the *same* scope as if the expression itself was there in the code where the Eval function was. It is just like a code replacment. I suppose I should have stated that assumption, but I have yet to see it otherwise.
And then you throw up in disgust at this slow unvieldy buggy contraption and choose a language that supports real anonymous functions.
Buggy? You have not identified any specific bugs. True, you get no compile-time checking, but if we are generating stuff during run-time, we don't have that anyhow. Slow? Perhaps. But I don't use it for finite element simulations or the like.
You seem to be agreeing with me that Eval is "good enough" for occassional usage, which is my point. If code was littered with eval's or dynamic execute's, then one might find closures would clean up the scoping issues more.
And no, I *don't* remember multiple regression. That was many many moons ago. My brain does a pretty good job of house-cleaning, except that it never asks permission before tossing. Kinda like my wife. Maybe if I studied your code long enuf I might figure it out, but I have other more practical things I would rather study if I go into study mode.
________________
oop.ismad.com
|
Post #107,563
6/27/03 1:51:44 PM
|
You are not familiar with Ruby then
In the languages I am familiar with, they had the *same* scope as if the expression itself was there in the code where the Eval function was. It is just like a code replacment. I suppose I should have stated that assumption, but I have yet to see it otherwise.
Ruby has several different eval functions running around. They vary in terms of whose scope they evaluate in. After all your code running in my package may do something very different from your code running in your package. Ruby gives you choice.
If you want to do something more sophisticated than the basic built-in options, there is even the notion of a binding, which can be taken anywhere, and then from anywhere else you can eval with that binding.
This is explained at [link|http://www.pragmaticprogrammer.com/ruby/articles/dynacall.html|http://www.pragmatic...les/dynacall.html]
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #107,714
6/28/03 3:50:32 PM
|
Of course Eval()?
Tablizer: I have done data conversions where I put a bunch of expressions (equations) in a table and then processed each record through the conversions using Eval().
Actually, this is a reasonable example of using Eval (provided you understand the dangers of passing external data to eval, but that's a different topic).
This is an example where a closure would NOT be a good choice.
Closures and Eval are NOT interchangable, except in trivial examples.
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
