Python or Java or maybe PHP?

[Aahz]

Do you have any specific comments towards Logix's implementation?

Nope. I do know that Guido is generally in favor of Python-like
languages, and one of the goals of the AST project was to make that
easier. Ditto PyPy.
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"Given that C++ has pointers and typecasts, it's really hard to have a
serious conversation about type safety with a C++ programmer and keep a
straight face. It's kind of like having a guy who juggles chainsaws
wearing body armor arguing with a guy who juggles rubber chickens wearing
a T-shirt about who's in more danger." --Roy Smith

 

[Mike Meyer]

You have confused "many Python devs" with Guido. ;-) Guido hates
macros.

I vaguelly recall hearing that Guido thought about adding macros to
Python, and rejected the idea because he didn't want users to have to
deal with compile-time errors at run time. Or something to that
effect.

That doesn't sounds like "hates" to me. More like "doesn't like the
baggage."

<mike

 

[Aahz]

I vaguelly recall hearing that Guido thought about adding macros to
Python, and rejected the idea because he didn't want users to have to
deal with compile-time errors at run time. Or something to that
effect.

That doesn't sounds like "hates" to me. More like "doesn't like the
baggage."

The smiley applies to that whole bit. Guido's main problem with macros
is that there's no clean way to integrate them into a language with
strong syntactical structure. He also doesn't like the idea of splitting
Python itself into mini-languages (by adding new keywords). He does have
a strong distaste for functional programming and sees macros as partly an
attempt to expand inappropriate usage of functional programming in
Python.

Plus your point, that probably covers most of it.
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"Given that C++ has pointers and typecasts, it's really hard to have a
serious conversation about type safety with a C++ programmer and keep a
straight face. It's kind of like having a guy who juggles chainsaws
wearing body armor arguing with a guy who juggles rubber chickens wearing
a T-shirt about who's in more danger." --Roy Smith

 

[Xavier Morel]

That doesn't sounds like "hates" to me. More like "doesn't like the
baggage."

<mike

Yet anonymous functions are nice.

Wouldn't it be possible to change the `def` statement to return a
reference to the function, and allow omitting the function name thereby
bypassing the default binding (current behavior)?

Something along the lines of

pass
pass

Note that the function wouldn't "have" it's own name anymore (no more
"__name__" attribute? Or a blank one?)

Since functions can already be defined inline, the only thing that'd be
left would be to end the function's definition when the "wrapper"
structure ends:
.... # Multiline
.... pass
.... )

I'm not too sure about the multi line version (and it looks very ugly
with a non-monospaced font), but:

Pros (I think):
* Backwards-compatible (I think, since the new uses of `def` are
currently errors)
* Fairly obvious syntax
* No `lambda` or `macros` baggage, the new form of def would merely
define an anonymous function instead of a named one.
* No new keyword, or structure, or idiom
* Existing idioms are merely slightly extended without changing
their current meaning

Cons:
* May reduce readability when misused, and may be used in Very
Stupid Ways that reduce readability a lot (but then again most construct
may be abused in some way), e.g.:

doSomething(arg1, arg2, arg3, def foo(a): manipulate(a)) #
binds a function to `foo` _and_ sends it to `doSomething`
...
[a few lines of code]
...
foo(value) # where the hell did that "foo" come from?

* Replaces lambdas with something much more powerful, which may go
against the goal of getting rid of lambdas (unless the aforementioned
goal is mostly because of the historical baggage of lambdas/macros)

Unsure:
* Shows that Python is the Ultimate Language, people are not ready yet.
* May allow for blocks-like constructs (I'm not sure of the current
state of the closures over Python functions though, these may have to be
extended to "full" closures if they aren't) and be considered by some as
yielding to the hype (even though the structure itself is more or less
35 years old)

 

[Dan Sommers]

I vaguelly recall hearing that Guido thought about adding macros to
Python, and rejected the idea because he didn't want users to have to
deal with compile-time errors at run time. Or something to that
effect.

That would eliminate eval and exec, too.

Regards,
Dan

 

[Alex Martelli]

Wouldn't it be possible to change the `def` statement to return a
reference to the function, and allow omitting the function name thereby
bypassing the default binding (current behavior)?

It's _possible_ (doesn't introduce syntax ambiguities) though it does
introduce incompatible interactive-interpreter behavior, as you say:

pass
<function at 0x00FA37B0>

This could be avoided if 'def <name><etc>' remained a statement like
today, and a separate expression 'def<etc>' returned a function object
as a result; this would have the aded plus of avoiding the totally new
(to Python) idea of "statement returning a value" (_expressions_ return
a value).

Note that the function wouldn't "have" it's own name anymore (no more
"__name__" attribute? Or a blank one?)

Currently, a lambda has a __name__ of '<lambda>'; I'd assume a similar
arrangement if 'expression def' took lambda's place.

I'm not too sure about the multi line version (and it looks very ugly

Yeah, the multiline's the rub -- there's currently no multiline
expression, and it does look ugly.

* May allow for blocks-like constructs (I'm not sure of the current
state of the closures over Python functions though, these may have to be
extended to "full" closures if they aren't) and be considered by some as

Python's closures are 'full', but don't allow inner functions to rebind
names in the namespace of outer functions.

I'm not sure a PEP like this has ever been proposed, but the idea of
anonymous def is not new (bar some details of your proposal): if a PEP
doesn't exist, you could write one, at least to firm up all details.


Alex

 

[Xavier Morel]

It's _possible_ (doesn't introduce syntax ambiguities) though it does
introduce incompatible interactive-interpreter behavior, as you say:


This could be avoided if 'def <name><etc>' remained a statement like
today, and a separate expression 'def<etc>' returned a function object
as a result; this would have the aded plus of avoiding the totally new
(to Python) idea of "statement returning a value" (_expressions_ return
a value).

True that, I didn't even consider the possibility to create an
independent expression.

And it completely remove the possibility to generate the first "con".

Python's closures are 'full', but don't allow inner functions to rebind
names in the namespace of outer functions.

I'm not sure a PEP like this has ever been proposed, but the idea of
anonymous def is not new (bar some details of your proposal): if a PEP
doesn't exist, you could write one, at least to firm up all details.


Alex

Or maybe start by creating a thread on the subject of an anonymous def
expression on this list first?

 

[Mike Meyer]

That doesn't sounds like "hates" to me. More like "doesn't like the
baggage."
<mike

Yet anonymous functions are nice.

Wouldn't it be possible to change the `def` statement to return a
reference to the function, and allow omitting the function name
thereby bypassing the default binding (current behavior)?
[...]

pass

This kind of thing has been proposed a number of times, by a number of
people. Including me.

[examples elided]

I'm not too sure about the multi line version (and it looks very ugly
with a non-monospaced font), but:

The multi-line version is actually a killer problem. If you allow
newlines it, you get all kinds of problems with nesting, and the code
gets really ugly. If you don't allow newlines, what you have is barely
more powerfull than the existing lambda, and would tempt people to
write really ugly suites in a single line.

Pros (I think):
* Backwards-compatible (I think, since the new uses of `def` are
* currently errors)
* Fairly obvious syntax
* No `lambda` or `macros` baggage, the new form of def would
* merely define an anonymous function instead of a named one.
* No new keyword, or structure, or idiom
* Existing idioms are merely slightly extended without changing
* their current meaning

My version was actually even more backwards compatible - I only
returned the value in the case where you were defining an anonymous
function. Not that that makes any real difference.

Cons:
* May reduce readability when misused, and may be used in Very
* Stupid Ways that reduce readability a lot (but then again most
* construct may be abused in some way), e.g.:

It's not clear that there are any useful uses that are readable. I had
examples in my proposal, and freely admitted that they were ugly. I
may even have mentioned it in the proposal.

How about some use cases with example usage? That would show us
whether or not there are uses that are both useful and not ugly. Even
if the idea is ultimately rejected, the use cases may generate
different proposals for solving them that are accepted.

<mike

 

[Steve Holden]

Shall we assume DYR == "Do You Ruby?" ? <wink>

No. it's the Forth equivalent of DRY: Don't yourself repeat.

regards
Steve