What is there to fight about?

Post #191,403 by FuManChu 1/24/05 4:47:45 PM 1/24/05 6:09:03 PM Reply	What is there to fight about? Tcl is over there --> Every comment you make comes down to "I want language aspect _____ to be implicit". One of the core design principles of Python is "Explicit is better than implicit". Either you agree with that design philosophy, or you go find another language--there's no fight to be had. Python's not going to change to meet your list of "should's" for "a dynamic language". There's no such thing as a function pointer. Whatever "it" was, it was not interchangable with a string containing the function name. Which might lead one to believe that there's a good reason "it" is not interchangable with the string. Don't know what "it" really is? Find out first, then critique. The page I pointed you to is a good start--like any language, Python has fundamental differences from those with which you are familiar. The binding of names to objects is probably the first and most significant hurdle to Python newbies, and is exactly what that link talks about, and is exactly what you're stumbling over with the function name issue. The fact that you then tie this in to operator overloading is completely orthogonal (except that, in both cases, you seem to want the language to guess in the absence of information). Edited by FuManChu Jan. 24, 2005, 06:09:03 PM EST What is there to fight about? Tcl is over there --> Every comment you make comes down to "I want language aspect _____ to be implicit". One of the core design principles of Python is "Explicit is better than implicit". Either you agree with that design philosophy, or you go find another language--there's no fight to be had. Python's not going to change to meet your list of "should's" for "a dynamic language". There's no such thing as a function pointer. Whatever "it" was, it was not interchangable with a string containing the function name. Which might lead one to believe that there's a good reason "it" is not interchangable with the string. Don't what "it" really is? Find out first, then critique. The page I pointed you to is a good start--like any language, Python has fundamental differences from those with which you are familiar. The binding of names to objects is probably the first and most significant hurdle to Python newbies, and is exactly what that link talks about, and is exactly what you're stumbling over with the function name issue. The fact that you then tie this in to operator overloading is completely orthogonal (except that, in both cases, you seem to want the language to guess in the absence of information). Collapse All History
Post #191,415 by admin 1/24/05 5:33:49 PM Reply	Explicit is definitely what Python is about And the main reason I prefer it to Perl. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #191,968 by tablizer 1/27/05 1:12:22 PM Reply	Name and pointer unnecessary duplication A function name and pointer are generally duplicated references to the same information. You essentially have 2 primary keys. Now maybe it is done for speed, but otherwise is a sloppy or compromized theoretical arrangment. except that, in both cases, you seem to want the language to guess in the absence of information There is no need for "guessing" if the duplication is removed. ________________ oop.ismad.com
Post #191,977 by admin 1/27/05 1:48:33 PM Reply	No, it isn't duplicated. The function "pointer" is actually an object that contains a lot more information than a simple string can convey. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #192,160 by tablizer 1/28/05 7:27:07 PM Reply	references versus the record itself The function "pointer" is actually an object that contains a lot more information than a simple string can convey. The string is like an ID that points to (references) a record, not the record itself. If it requires more, then make it an associative array, but I don't see a need for that so far either. Someone below suggested that more is needed to implement closures. Personally I have not seen a slam-dunk justification for closures. They may simplify code a few percent at most. We had a huge debate here about this once and I see no need to repeat it again. ________________ oop.ismad.com
Post #192,003 by FuManChu 1/27/05 2:54:20 PM Reply	...and the duplication is necessary. Once you realize that it's not just 2 copies, but n copies. In this way, you can have multiple bindings to the same object, to be used in different descriptive contexts (with its own semantics tht map to the appropriate problem domain). A local namespace can have a named reference to the object. A list can have an anonymous, but indexed, reference to the object. A hashmap/dictionary can possess a named reference which approaches worst-case O(n) lookup on the name, instead of on the value (the function pointer). In other words, there's a reason we use variable names instead of register or memory addresses.
Post #192,054 by ben_tilly 1/27/05 11:34:17 PM Reply	You clearly do not know what a closure is If you can figure out the following piece of code, then you'll understand how there can be many different copies of a function, all slightly distinct. \nuse strict;\n\nnested_for(\n sub {print "@_\\n";},\n [1..2], ['a'..'c'], ['A'..'D']\n);\n\nsub nested_for {\n ret_iter(@_)->();\n}\n\nsub ret_iter {\n my $fn = shift;\n my $range = shift;\n my $sub = sub {$fn->($_, @_) for @$range};\n return @_ ? ret_iter($sub, @_) : $sub;\n}\n Cheers, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)

Welcome to IWETHEY!