IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 1 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Python and function pointers
Remember that time I was playing with Python and Tk graphics and used a string with a function name instead of a function pointer in a call-back and youses jumped all over me for trying to interchange the two?

In a truly dynamic language it should not matter. If one does arithmentic on a series of variables, such as x = a + b + c, and "c" happens to be a string such as "69", then it should automatically convert, or interpret it as a number. (Ideally another symbol is used for string catenation, such as "." or "&", not overloading plus IMO.)

If it does this with numbers, why not function pointers? Why treat them differently? Python seems to have a half-ass typing system where there is a hidden "type" indicator/flag associated with each variable. Sometimes it will ignore/bypass this, such as when adding, and sometimes it will be anal about it, such as function pointers. Such inconsistency is annoying. IMO, the hidden type indicator is bag of headaches. A dynamic language should use only context and not a hidden type flag. And if it does have and use a type-flag, then at least be consistent about its usage. Python flunks KISS 101 and consistency 101.
________________
oop.ismad.com
New No such thing as a fool-proof language.
Apparently.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New I'll assume "fool" is not meant to label a specific person
________________
oop.ismad.com
New Well, you know what they say about ASSuming...
-YendorMike

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759 Historical Review of Pennsylvania
New parse: 1 + 2 + "3" + 4 + 5
(a). "12345"
(b). "339"
(c). "3345"
(d). "1239"
(e). illegal addition

Here's what the rules for python look like in psuedo code.

op+(a:number, a':number) => number
op+(a:string, a':string) => string

If I had designed the language, I'd have made the concat operator different than the addition operator. But this is not an uncommon language design choice. Fortunately Python does not allow you to add|concat a number to a string, so you can catch the problem (try that in javascript or vbscript).

Anyhow, as usual you can't see the forest for the trees. It's a problem that I had with the language for, oh, about 30 seconds.
New Gruh?
> Remember that time I was playing with Python and Tk graphics
> and used a string with a function name instead of a function
> pointer in a call-back and youses jumped all over me for trying
> to interchange the two?

No.

> In a truly dynamic language it should not matter. If one does
> arithmentic on a series of variables, such as x = a + b + c,
> and "c" happens to be a string such as "69", then it should
> automatically convert, or interpret it as a number.

That's an awful lot of "should's" for someone who's never designed a language.

> If it does this with numbers, why not function pointers?

1. It doesn't "do this" with numbers.
2. There's no such thing as a function pointer.

Read [link|http://effbot.org/zone/python-objects.htm|http://effbot.org/zo...ython-objects.htm]

> Python seems to have a half-ass typing system where
> there is a hidden "type" indicator/flag associated
> with each variable.

Not at all. It's quite accessible. Try inspecting type(a) or b.__class__

> Sometimes it will ignore/bypass this

It's never *ignored*. Errors should not pass silently.

> A dynamic language should use only context
> and not a hidden type flag.

1. Again, it's not hidden, and
2. Relying on context is what gets you into "annoying", "inconsistent" (dare I say) "magical" runtime evaluation.
New Another language fight?
That's an awful lot of "should's" for someone who's never designed a language.

Would it change anything if I built a language that had the features I wanted? It would probably resemble Tcl in many ways.

It's never *ignored*. Errors should not pass silently

Well, in that case it did. Maybe it was a bug in the Tk library or the adapters, but it silently ignored it.

[there is a hidden "type" indicator/flag associated
with each variable.] Not at all. It's quite accessible. Try inspecting type(a) or b.__class__


I didn't mean it was undeterminable. "Hidden" and undeterminable are two different things. My pet language would not have ANY hidden "type" indicators, by the way.

Relying on context is what gets you into "annoying", "inconsistent" (dare I say) "magical" runtime evaluation.

Not if you don't overload the operators. And responding to a nearby comment about it being common, so is COBOL. But that does not make it "good". The masses are often idiots. The election proved that.

There's no such thing as a function pointer.

Whatever "it" was, it was not interchangable with a string containing the function name.
________________
oop.ismad.com
New 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).
Expand Edited by FuManChu Jan. 24, 2005, 06:09:03 PM EST
New Explicit is definitely what Python is about
And the main reason I prefer it to Perl.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New 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
New 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..."
New 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
New ...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.
New 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)
New Wrong forum.
You wanted to post that to Flame Quarantine. :-)

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.

New Please tell me the language(s) that do what you want
So I can avoid them.

I like closures to be possible, and what your describing would keep that from happening.

Thanks,
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)
New You want to use Rexx
It will do what you want with the conversion from "69" to 69.

The concatanation operators are "|", "||", " ", "'", and '"'. Depending on how they're used, they can mean concatanate with our without a space: for example "Bill"'"The Cat" will produce "BillThe Cat". "Bill" "The Cat" will produce "Bill The Cat". The pipes are a little bit different: one pipe produces a space, two pipes mean no space.

A "function pointer" doesn't exist in rexx, unless I misunderstand what you mean by it. There are no pointers in rexx.
--\n-------------------------------------------------------------------\n* Jack Troughton                            jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca]                   [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada               [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
     Python and function pointers - (tablizer) - (16)
         No such thing as a fool-proof language. - (admin) - (2)
             I'll assume "fool" is not meant to label a specific person -NT - (tablizer) - (1)
                 Well, you know what they say about ASSuming... -NT - (Yendor)
         parse: 1 + 2 + "3" + 4 + 5 - (ChrisR)
         Gruh? - (FuManChu) - (8)
             Another language fight? - (tablizer) - (7)
                 What is there to fight about? - (FuManChu) - (6)
                     Explicit is definitely what Python is about - (admin)
                     Name and pointer unnecessary duplication - (tablizer) - (4)
                         No, it isn't duplicated. - (admin) - (1)
                             references versus the record itself - (tablizer)
                         ...and the duplication is necessary. - (FuManChu)
                         You clearly do not know what a closure is - (ben_tilly)
         Wrong forum. - (static)
         Please tell me the language(s) that do what you want - (ben_tilly)
         You want to use Rexx - (jake123)

So anyway...
70 ms