Syntax across languages

[Tom Anderson]

On Sun, 23 Oct 2005, Fredrik Lundh wrote:

> bearophileHUGS at lycos.com wrote:
>
>> - ~== for approximate FP equality
>
> str(a) == str(b)

This is taken from the AIEEEEEEEE 754 standard, i take it? :)

Seriously, that's horrible. Fredrik, you are a bad man, and run a bad 
railway.

However, looking at the page the OP cites, the only mention of that 
operator i can find is in Dylan, and in Dylan, it's nothing to do with 
approximate FP equality - it means 'not identical', which we can spell "is 
not".

What would approximate FP equality even mean? How approximate?

>> - Exception retrying: after catching an exception, tell the snippet to
>> be re-run "retry" as in Ruby
>
>>>> x = 0
>>>> while 1:
> ...     try:
> ...         x += 1
> ...         if x <= 5:
> ...             raise ValueError
> ...     except ValueError:
> ...         print "retry"
> ...         continue
> ...     else:
> ...         break
> ...
> retry
> retry
> retry
> retry
> retry
>>>>

That works well for trivial cases, and not at all for anything complex. If 
you have this sort of structure:

def reverse_the_polarity_of_the_neutron_flow():
 	five_hundred_lines_of_code()
 	and_dozens_of_layers_of_nesting_and_indirection()
 	interrossitor.activate() # can raise InterrossitorError
 	do_what_we_came_here_to_do()

try:
 	reverse_the_polarity_of_the_neutron_flow()
except InterrossitorError:
 	degausser.degauss(interrossitor)
 	interrossitor.activate()
 	RETRY # how do you implement this?

You're in trouble. I realise that this snippet is not a hugely compelling 
example, but the point is that there could be some corrective action that 
you can take in an exception handler which, for some reason, you can't 
write close enough to the source of the exception that control can carry 
on flowing in the right direction.

What you can do - and this is fairly high-grade evil of a different sort - 
is package the exception-handling specifics in a function, and pass that 
in, to be applied at the appropriate point:

def reverse_the_polarity_of_the_neutron_flow(ie_hdlr):
 	five_hundred_lines_of_code()
 	and_dozens_of_layers_of_nesting_and_indirection()
 	try:
 		interrossitor.activate() # can raise InterrossitorError
 	except InterrossitorError, e:
 		ie_hdlr(e)
 	do_what_we_came_here_to_do()

def handle_interrossitor_error(e):
 	degausser.degauss(interrossitor)
 	interrossitor.activate()
reverse_the_polarity_of_the_neutron_flow(handle_interrossitor_error)

You can even do extra bonus higher-order-functioning:

def reverse_the_polarity_of_the_neutron_flow(ie_hdlr):
 	five_hundred_lines_of_code()
 	and_dozens_of_layers_of_nesting_and_indirection()
 	ie_hdlr(interrossitor.activate)
 	do_what_we_came_here_to_do()

def handle_interrossitor_error(fn):
 	try:
 		fn()
 	except InterrossitorError, e:
 		degausser.degauss(interrossitor)
 		interrossitor.activate()
reverse_the_polarity_of_the_neutron_flow(handle_interrossitor_error)

Although i can't see any reason why you'd want to.

>> - recursive "flatten" as in Ruby (useful)
>
> if you can define the semantics, it's a few lines of code.  if you're 
> not sure about the semantics, a built-in won't help you...

While we're on the subject, we had a big recursive flatten bake-off round 
here a few months back: look for a thread called "flatten(), [was Re: 
map/filter/reduce/lambda opinions andbackground unscientific 
mini-survey]", and filter out the posts with code from the posts with 
rants. There are all sorts of solutions, coming at the problem from 
different angles, but the end of it is more or less here:

http://groups.google.co.uk/group/comp.lang.python/msg/0832db53bd2700db

Looking at the code now, i can see a couple of points where i could tweak 
my flatten even more, but i think the few microseconds it might save 
aren't really worth it!

tom

-- 
It is a laborious madness, and an impoverishing one, the madness of
composing vast books. -- Jorge Luis Borges