Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #15973 > unrolled thread

Using the Python Interpreter as a Reference

Back to article view | Back to comp.lang.python

Contents

  Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-20 16:46 -0800
    Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-21 13:33 +1100
      Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-21 05:44 +0000
        Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-21 17:48 +1100
        Re: Using the Python Interpreter as a Reference Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-11-21 10:03 -0800
        Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-21 16:07 -0800
    Re: Using the Python Interpreter as a Reference Alan Meyer <ameyer2@yahoo.com> - 2011-11-22 13:37 -0500
      Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-25 02:55 -0800
        Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-25 22:10 +1100
    Re: Using the Python Interpreter as a Reference rusi <rustompmody@gmail.com> - 2011-11-25 09:11 -0800
      RE: Using the Python Interpreter as a Reference "Sells, Fred" <fred.sells@adventistcare.org> - 2011-11-25 23:22 -0500
      Re: Using the Python Interpreter as a Reference Matt Joiner <anacrolix@gmail.com> - 2011-11-26 23:19 +1100
    Re: Using the Python Interpreter as a Reference Alec Taylor <alec.taylor6@gmail.com> - 2011-11-27 05:46 +1100
    Re: Using the Python Interpreter as a Reference Rick Johnson <rantingrickjohnson@gmail.com> - 2011-11-26 10:53 -0800
      Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-27 06:34 +1100
        Re: Using the Python Interpreter as a Reference Rick Johnson <rantingrickjohnson@gmail.com> - 2011-11-26 13:15 -0800
      Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-27 14:21 -0800
        Re: Using the Python Interpreter as a Reference Colin Higwell <colinh@somewhere.invalid> - 2011-11-27 23:02 +0000
        Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-27 23:55 +0000
          Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-28 11:26 +1100
          Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 10:03 -0800
          Re: Using the Python Interpreter as a Reference Ian Kelly <ian.g.kelly@gmail.com> - 2011-11-28 12:32 -0700
            Re: Using the Python Interpreter as a Reference Neil Cerutti <neilc@norwich.edu> - 2011-11-28 20:20 +0000
              Re: Using the Python Interpreter as a Reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-11-29 09:48 +1300
                Re: Using the Python Interpreter as a Reference Neil Cerutti <neilc@norwich.edu> - 2011-11-28 21:11 +0000
            Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 13:34 -0800
            Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-28 22:24 +0000
              Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 09:48 +1100
              Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 18:42 -0800
                Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 13:57 +1100
                  Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-29 08:12 +0000
                    Re: Using the Python Interpreter as a Reference Dave Angel <d@davea.name> - 2011-11-29 03:53 -0500
                Re: Using the Python Interpreter as a Reference Ian Kelly <ian.g.kelly@gmail.com> - 2011-11-28 21:56 -0700
          Re: Using the Python Interpreter as a Reference DevPlayer <devplayer@gmail.com> - 2011-11-28 16:54 -0800
            Re: Using the Python Interpreter as a Reference DevPlayer <devplayer@gmail.com> - 2011-11-28 16:59 -0800
            Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 12:49 +1100
              Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 19:00 -0800
              Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-29 08:04 +0000
                Re: Using the Python Interpreter as a Reference DevPlayer <devplayer@gmail.com> - 2011-12-01 10:03 -0800
                  Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-02 00:43 +0000
                    Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-12-02 13:02 +1100
                    RE: Using the Python Interpreter as a Reference "Sells, Fred" <fred.sells@adventistcare.org> - 2011-12-02 15:29 -0500
                    Re: Using the Python Interpreter as a Reference Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-12-02 15:58 -0500
        Re: Using the Python Interpreter as a Reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-11-29 09:40 +1300
          Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 13:29 -0800
            Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 08:57 +1100
            Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-28 22:57 +0000
              Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 18:57 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#16342

On Nov 27, 6:55 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sun, 27 Nov 2011 14:21:01 -0800, Travis Parks wrote:
> > Personally, I find a lot of good things in Python. I thinking tabs are
> > out-of-date. Even the MAKE community wishes that the need for tabs would
> > go away and many implementations have done just that.
>
> Tabs have every theoretical advantage and only one practical
> disadvantage: the common toolsets used by Unix programmers are crap in
> their handling of tabs, and instead of fixing the toolsets, they blame
> the tabs.
>
> The use of spaces as indentation is a clear case of a technically worse
> solution winning over a better solution.
>
> > I have been
> > seriously debating about whether to force a specific number of spaces,
> > such as the classic 4, but I am not sure yet. Some times, 2 or even 8
> > spaces is appropriate (although I'm not sure when).
>
> Why on earth should your language dictate the width of an indentation? I
> can understand that you might care that indents are consistent within a
> single source code unit (a file?), but anything more than that is just
> obnoxious.
>
> > I have always found the standard library for Python to be disjoint. That
> > can be really beneficial where it keeps the learning curve down and the
> > size of the standard modules down. At the same time, it means
> > re-learning whenever you use a new module.
>
> I know what disjoint means, but I don't understand what you think it
> means for a software library to be disjoint. I don't understand the rest
> of the paragraph.
>
> > My language combines generators and collection initializers, instead of
> > creating a whole new syntax for comprehensions.
>
> > [| for i in 0..10: for j in 0.10: yield return i * j |]
>
> Are we supposed to intuit what that means?
>
> Is | a token, or are the delimiters [| and |] ?
>
> Is there a difference between iterating over 0..10 and iterating over
> what looks like a float 0.10?
>
> What is "yield return"?
>
> > Lambdas and functions are the same thing in my language, so no need for
> > a special keyword.
>
> That does not follow. Lambdas and def functions are the same thing in
> Python, but Python requires a special keyword.
>
> > I also distinguish between initialization and
> > assignment via the let keyword.
>
> What does this mean? I can guess, but I might guess wrong.
>
> > Also, non-locals do not need to be
> > defined explicitly, since the scoping rules in Unit are far more "anal".
>
> What does this mean? I can't even guess what you consider more anal
> scoping rules.
>
> > In reality though, it takes a certain level of arrogance to assume that
> > any language will turn out without bumps. It is like I was told in
> > college long ago, "Only the smallest programs are bug free." I think the
> > same thing could be said for a language. The only language without flaws
> > would be so small that it would be useless.
>
> I'm pretty sure that being so small that it is useless would count as a
> flaw.
>
> What does it mean to say that a language is "small"?
>
> A Turing Machine is a pretty small language, with only a few
> instructions: step forward, step backwards, erase a cell, write a cell,
> branch on the state of the cell. And yet anything that can be computed,
> anything at all, can be computed by a Turning Machine: a Turing Machine
> can do anything you can do in C, Lisp, Fortran, Python, Java... and very
> probably anything you can (mentally) do, full stop. So what does that
> mean about "small" languages?
>
> On the other hand, take Epigram, a functional programming language:
>
> http://en.wikipedia.org/wiki/Epigram_(programming_language)
>
> It is *less* powerful than a Turing Machine, despite being far more
> complex. Similarly languages like regular expressions, finite automata
> and context-free grammers are more complex, "bigger", possibly with
> dozens or hundreds of instructions, and yet less powerful. Likewise for
> spreadsheets without cycles.
>
> Forth is much smaller than Java, but I would say that Forth is much, much
> more powerful in some sense than Java. You could write a Java compiler in
> Forth more easily than you could write a Forth compiler in Java.
>
> --
> Steven
>
>

Yes. I was mostly rambling. More explanation would have meant more
typing.

Languages that use type inference heavily typically find unique ways
of indicating literals, including numbers and collections. In Unit,
[||] indicates fixed length arrays, [] is for dynamic arrays, {} is
for sets and unordered dictionaries (at least one value is needed). A
frozen set might be represented with a {||} in the future. I stole the
syntax from F#. Numbers have a trailing letter indicating their types:
signed byte (y), short (s), long (l), float (f), fixed (m), arbitrary
precision (i), rational (r) and imaginary (j). Unsigned versions have
a u before the letter (uy).

Also, .. is the range operator in Unit. 0..10 means "0 through 10" and
0.1 means a floating point number (I missed a dot). 0..10..2 means 0,
2, 4, 6, 8, 10. Saves me from needing a range function, like Python.
Quite a few functional languages support that syntax.

[toc] | [prev] | [next] | [standalone]

#16345

On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> My language combines generators and collection initializers, instead of
>> creating a whole new syntax for comprehensions.
>>
>> [| for i in 0..10: for j in 0.10: yield return i * j |]
>
> Are we supposed to intuit what that means?
>
> Is | a token, or are the delimiters [| and |] ?
>
> Is there a difference between iterating over 0..10 and iterating over
> what looks like a float 0.10?
>
> What is "yield return"?

I would assume that "yield return" is borrowed from C#, where it is
basically equivalent to Python's yield statement.  The advantage of
using two keywords like that is that you can compare the statements
"yield return foo" and "yield break", which is a bit clearer than
comparing the equivalent "yield foo" and "return".

Having to type out "yield return" in every comprehension seems a bit
painful to me, but I can understand the approach: what is shown above
is a full generator, not a single "generator expression" like we use
in Python, so the statement keywords can't be omitted.  It's trading
off convenience for expressiveness (a bad trade-off IMO -- complex
generators should be named, not anonymous).

>> Lambdas and functions are the same thing in my language, so no need for
>> a special keyword.
>
> That does not follow. Lambdas and def functions are the same thing in
> Python, but Python requires a special keyword.

I think the implication is that Unit has only one syntax for creating
functions, which is lambda-style.  In any case, why does Python
require a special keyword?  def is only used in a statement context,
and lambda is only used in an expression context.  Why not use the
same keyword for both?  I think the answer is historical:  def came
first, and when anonymous functions were added it didn't make sense to
use the keyword "def" for them, because "def" implies a name being
defined.

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#16349

On 2011-11-28, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> I think the implication is that Unit has only one syntax for
> creating functions, which is lambda-style.  In any case, why
> does Python require a special keyword?  def is only used in a
> statement context, and lambda is only used in an expression
> context.  Why not use the same keyword for both?  I think the
> answer is historical:  def came first, and when anonymous
> functions were added it didn't make sense to use the keyword
> "def" for them, because "def" implies a name being defined.

I've always held with the "anti-functional style conspiracy"
interpretation of Python's lambda expressions. They were added
but grudgingingly, made weak on purpose to discourage their use.

-- 
Neil Cerutti
  "This room is an illusion and is a trap devisut by Satan.  Go
ahead and dauntlessly!  Make rapid progres!"
  --Ghosts 'n Goblins

[toc] | [prev] | [next] | [standalone]

#16353

Neil Cerutti wrote:

> I've always held with the "anti-functional style conspiracy"
> interpretation of Python's lambda expressions. They were added
> but grudgingingly, made weak on purpose to discourage their use.

Seems to me that Python's lambdas are about as powerful
as they can be given the statement/expression distinction.
No conspiracy is needed, just an understandable desire on
Guido's part not to do violence to the overall syntactic
style of the language.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#16356

On 2011-11-28, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:
> Neil Cerutti wrote:
>> I've always held with the "anti-functional style conspiracy"
>> interpretation of Python's lambda expressions. They were added
>> but grudgingingly, made weak on purpose to discourage their
>> use.
>
> Seems to me that Python's lambdas are about as powerful as they
> can be given the statement/expression distinction. No
> conspiracy is needed, just an understandable desire on Guido's
> part not to do violence to the overall syntactic style of the
> language.

It's true. Most conspiracy theories do fall apart once facts and
clear thinking are applied. But we love them anyway. ;)

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#16359

On Nov 28, 2:32 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
>
> <steve+comp.lang.pyt...@pearwood.info> wrote:
> >> My language combines generators and collection initializers, instead of
> >> creating a whole new syntax for comprehensions.
>
> >> [| for i in 0..10: for j in 0.10: yield return i * j |]
>
> > Are we supposed to intuit what that means?
>
> > Is | a token, or are the delimiters [| and |] ?
>
> > Is there a difference between iterating over 0..10 and iterating over
> > what looks like a float 0.10?
>
> > What is "yield return"?
>
> I would assume that "yield return" is borrowed from C#, where it is
> basically equivalent to Python's yield statement.  The advantage of
> using two keywords like that is that you can compare the statements
> "yield return foo" and "yield break", which is a bit clearer than
> comparing the equivalent "yield foo" and "return".
>
> Having to type out "yield return" in every comprehension seems a bit
> painful to me, but I can understand the approach: what is shown above
> is a full generator, not a single "generator expression" like we use
> in Python, so the statement keywords can't be omitted.  It's trading
> off convenience for expressiveness (a bad trade-off IMO -- complex
> generators should be named, not anonymous).
>
> >> Lambdas and functions are the same thing in my language, so no need for
> >> a special keyword.
>
> > That does not follow. Lambdas and def functions are the same thing in
> > Python, but Python requires a special keyword.
>
> I think the implication is that Unit has only one syntax for creating
> functions, which is lambda-style.  In any case, why does Python
> require a special keyword?  def is only used in a statement context,
> and lambda is only used in an expression context.  Why not use the
> same keyword for both?  I think the answer is historical:  def came
> first, and when anonymous functions were added it didn't make sense to
> use the keyword "def" for them, because "def" implies a name being
> defined.
>
> Cheers,
> Ian
>
>

Most languages I have worked with have a "lambda" syntax and a
function syntax. It has always been a historical artifact. Languages
start out avoiding functional features and then eventually adopt them.
It seems that eventually, convenient high-order functions become a
must-have (most standard algorithm packages). It is a conflict between
old C-style programming and the need for functional code. As soon as
functions can be assigned to variables, the code starts looking oddly
like JavaScript.

[toc] | [prev] | [next] | [standalone]

#16363

On Mon, 28 Nov 2011 12:32:59 -0700, Ian Kelly wrote:

> On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
[...]
>>> Lambdas and functions are the same thing in my language, so no need
>>> for a special keyword.
>>
>> That does not follow. Lambdas and def functions are the same thing in
>> Python, but Python requires a special keyword.
> 
> I think the implication is that Unit has only one syntax for creating
> functions, which is lambda-style.  In any case, why does Python require
> a special keyword?  def is only used in a statement context, and lambda
> is only used in an expression context.  Why not use the same keyword for
> both?

Because the syntax is completely different. One is a statement, and 
stands alone, the other is an expression. Even putting aside the fact 
that lambda's body is an expression, and a def's body is a block, def 
also requires a name. Using the same keyword for both would require 
special case reasoning: sometimes def is followed by a name, sometimes 
without a name. That's ugly.

def name(args): block  # okay

funcs = [def args: expr,  # okay so far
         def name(args): expr,  # not okay
         def: expr,  # okay
         ]

def: expr  # also okay

def: expr
    expr  # but not okay

x = def x: expr  # okay
x = def x(x): expr  # not okay

Using the same keyword for named and unnamed functions is, in my opinion, 
one of those foolish consistencies we are warned about. When deciding on 
syntax, the difference between anonymous and named functions are more 
significant than their similarities.


> I think the answer is historical:  def came first, and when
> anonymous functions were added it didn't make sense to use the keyword
> "def" for them, because "def" implies a name being defined.

That reasoning still applies even if they were added simultaneously.

Lambda is pretty old: it certainly exists in Python 1.5 and almost 
certainly in 1.4. While it doesn't exist as a keyword in Python 0.9.1, 
there is a module called "lambda" with a function "lambda" that uses more 
or less the same syntax. Instead of lambda x: x+1, you would instead 
write lambda("x", "x+1"). So the idea of including anonymous functions 
was around in Python circles before the syntax was locked in.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#16364

On Tue, Nov 29, 2011 at 9:24 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Because the syntax is completely different. One is a statement, and
> stands alone, the other is an expression. Even putting aside the fact
> that lambda's body is an expression, and a def's body is a block, def
> also requires a name. Using the same keyword for both would require
> special case reasoning: sometimes def is followed by a name, sometimes
> without a name. That's ugly.
>

All you need to do is define that a block of code is an object (and
thus suitable material for an expression), and you have easy
commonality.

fn = def(args):
    block
    of
    code

Now def is an expression that takes an optional name (omitted in the
above), an arg list, and a block of code... and there's minimal
difference between named and anonymous functions. (If it's given a
name, then it sets __name__ and also binds to that name, being
convenient for the common case. The above code is a silly way to do
almost the default.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#16369

On Nov 28, 5:24 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Mon, 28 Nov 2011 12:32:59 -0700, Ian Kelly wrote:
> > On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
> > <steve+comp.lang.pyt...@pearwood.info> wrote:
> [...]
> >>> Lambdas and functions are the same thing in my language, so no need
> >>> for a special keyword.
>
> >> That does not follow. Lambdas and def functions are the same thing in
> >> Python, but Python requires a special keyword.
>
> > I think the implication is that Unit has only one syntax for creating
> > functions, which is lambda-style.  In any case, why does Python require
> > a special keyword?  def is only used in a statement context, and lambda
> > is only used in an expression context.  Why not use the same keyword for
> > both?
>
> Because the syntax is completely different. One is a statement, and
> stands alone, the other is an expression. Even putting aside the fact
> that lambda's body is an expression, and a def's body is a block, def
> also requires a name. Using the same keyword for both would require
> special case reasoning: sometimes def is followed by a name, sometimes
> without a name. That's ugly.
>
> def name(args): block  # okay
>
> funcs = [def args: expr,  # okay so far
>          def name(args): expr,  # not okay
>          def: expr,  # okay
>          ]
>
> def: expr  # also okay
>
> def: expr
>     expr  # but not okay
>
> x = def x: expr  # okay
> x = def x(x): expr  # not okay
>
> Using the same keyword for named and unnamed functions is, in my opinion,
> one of those foolish consistencies we are warned about. When deciding on
> syntax, the difference between anonymous and named functions are more
> significant than their similarities.

A good example I have run into is recursion. When a local function
calls itself, the name of the function may not be part of scope (non-
local). Languages that support tail-end recursion optimization can't
optimize. In order to support this, a function in Unit will have
access to its own name and type. In other words, special scoping rules
are in place in Unit to allow treating a function as an expression.

>
> > I think the answer is historical:  def came first, and when
> > anonymous functions were added it didn't make sense to use the keyword
> > "def" for them, because "def" implies a name being defined.
>
> That reasoning still applies even if they were added simultaneously.
>
> Lambda is pretty old: it certainly exists in Python 1.5 and almost
> certainly in 1.4. While it doesn't exist as a keyword in Python 0.9.1,
> there is a module called "lambda" with a function "lambda" that uses more
> or less the same syntax. Instead of lambda x: x+1, you would instead
> write lambda("x", "x+1"). So the idea of including anonymous functions
> was around in Python circles before the syntax was locked in.

I find that interesting. I also find it interesting that the common
functional methods (all, any, map, filter) are basically built into
Python core language. That is unusual for most imperative programming
languages early-on.

[toc] | [prev] | [next] | [standalone]

#16370

On Tue, Nov 29, 2011 at 1:42 PM, Travis Parks <jehugaleahsa@gmail.com> wrote:
> A good example I have run into is recursion. When a local function
> calls itself, the name of the function may not be part of scope (non-
> local). Languages that support tail-end recursion optimization can't
> optimize. In order to support this, a function in Unit will have
> access to its own name and type. In other words, special scoping rules
> are in place in Unit to allow treating a function as an expression.

I'm inclined toward an alternative: explicit recursion. Either a
different syntax, or a special-case on the use of the function's own
name, but whichever syntax you use, it compiles in a "recurse" opcode.
That way, if name bindings change, it's still going to recurse -
something few languages guarantee, and therefore few languages can
optimize.

ChrisA

[toc] | [prev] | [next] | [standalone]

#16380

On Tue, 29 Nov 2011 13:57:32 +1100, Chris Angelico wrote:

> I'm inclined toward an alternative: explicit recursion. Either a
> different syntax, or a special-case on the use of the function's own
> name, but whichever syntax you use, it compiles in a "recurse" opcode.
> That way, if name bindings change, it's still going to recurse -
> something few languages guarantee, and therefore few languages can
> optimize.

As I recall, Forth uses (or used) a special RECURSE word which turned on 
the recursion bit while compiling, so that the compiled word could see 
itself.

By memory, the (incomplete) definition:

: fact dup 1- fact * ;

would fail, unless you happened to already have another word called fact 
existing at compilation time. To make it recurse correctly, the compiler 
needs to make sure that the namespace fact sees includes itself:

RECURSE : fact dup 1- fact * ;

which should work, apart from the embarrassing fact that I don't recall 
the syntax for conditional jumps and so the recursion never terminates.

:)


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#16383

On 11/29/2011 03:12 AM, Steven D'Aprano wrote:
> On Tue, 29 Nov 2011 13:57:32 +1100, Chris Angelico wrote:
>
>> I'm inclined toward an alternative: explicit recursion. Either a
>> different syntax, or a special-case on the use of the function's own
>> name, but whichever syntax you use, it compiles in a "recurse" opcode.
>> That way, if name bindings change, it's still going to recurse -
>> something few languages guarantee, and therefore few languages can
>> optimize.
> As I recall, Forth uses (or used) a special RECURSE word which turned on
> the recursion bit while compiling, so that the compiled word could see
> itself.
>
> By memory, the (incomplete) definition:
>
> : fact dup 1- fact * ;
>
> would fail, unless you happened to already have another word called fact
> existing at compilation time. To make it recurse correctly, the compiler
> needs to make sure that the namespace fact sees includes itself:
>
> RECURSE : fact dup 1- fact * ;
>
> which should work, apart from the embarrassing fact that I don't recall
> the syntax for conditional jumps and so the recursion never terminates.
>
> :)
>
The way I remember it, the current definition was "smudged" which made 
it invisible (it basically changed the name to something unlikely) 
during the compilation.  After all, if you actually ran it at compile 
time (which was frequently done), you could fall right into 
uninitialized space.  Anyway, some implementations had an immediate 
SMUDGE word, which toggled the smudge bit and made it visible again.

Other implementations had an immediate word RECURSE, which compiled in 
whatever word was being currently defined.
I'm pretty sure neither FIG nor Forth79 had either of these.  But I 
don't recall the ANSI standard (X3J14 ?), even though I was officially 
an observer.  I can't even remember what happened to my printed copy of 
the standard.

The easiest word for conditional is IF/ELSE/THEN.   IF will skip to the 
ELSE or THEN if the condition is false.  So something resembling:

: fact dup 1- dup 0<> if recurse * then ;

might do it.  That's very rough, however.  It's been a long time.

-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#16376

On Mon, Nov 28, 2011 at 7:42 PM, Travis Parks <jehugaleahsa@gmail.com> wrote:
> I find that interesting. I also find it interesting that the common
> functional methods (all, any, map, filter) are basically built into
> Python core language. That is unusual for most imperative programming
> languages early-on.

all and any are actually quite recent additions.  Guido added them to
placate users of "reduce(lambda x, y: x and y, foo)" back when the
plan was to remove reduce in Python 3.

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#16366

On Nov 27, 6:55 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sun, 27 Nov 2011 14:21:01 -0800, Travis Parks wrote:
> > Personally, I find a lot of good things in Python. I thinking tabs are
> > out-of-date. Even the MAKE community wishes that the need for tabs would
> > go away and many implementations have done just that.
>
> Tabs have every theoretical advantage and only one practical
> disadvantage: the common toolsets used by Unix programmers are crap in
> their handling of tabs, and instead of fixing the toolsets, they blame
> the tabs.
>
> The use of spaces as indentation is a clear case of a technically worse
> solution winning over a better solution.
>
> > I have been
> > seriously debating about whether to force a specific number of spaces,
> > such as the classic 4, but I am not sure yet. Some times, 2 or even 8
> > spaces is appropriate (although I'm not sure when).
>
> Why on earth should your language dictate the width of an indentation? I
> can understand that you might care that indents are consistent within a
> single source code unit (a file?), but anything more than that is just
> obnoxious.
>

I do not understand why the interpreter preprocesses each logical line
of source code using something as simple as this:

def reindent( line, spaces_per_tab=os.spaces_per_tab):

    index = 0  # index into line of text
    indent = 0 # increase 1 when in next tab column
    spaces = 0 # index into current column

    for c in line:
        if c == ' ':
            spaces +=1
            if spaces >= spaces_per_tab:
                indent += 1
                spaces = 0
        if c == '\t':   # jump to next tab column
            indent += 1
            spaces = 0
        if c <> ' ' and c <> '\t':
            break
        index += 1
    rest_of_line = line[index:]
    new_indent = ' ' * indent * spaces_per_tab + ' ' * spaces
    newline = new_indent + rest_of_line

    return newline

or even some regex equivelent.

That function would need to be run on each line of source code, after
processing the line continuation character and single/double/triple
quote pairs are processed but before the code block tokenizer (INDENT/
DEDENT) if possible. Unless some of you expert parser/compiler writers
know fancier tricks.

To me, I would think the interpreter finding the coder's intended
indent wouldn't be that hard. And just make the need for consistant
spaces or tabs irrevelent simply by reformatting the indent as
expected. Pretty much all my text editors can.

[toc] | [prev] | [next] | [standalone]

#16367

> I do not understand why the interpreter preprocesses each logical line
> of source code using something as simple as this:


correction:

I do not understand why the interpreter - does not- preprocess each
logical line
of source code using something as simple as this:

[toc] | [prev] | [next] | [standalone]

#16368

On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer <devplayer@gmail.com> wrote:
> To me, I would think the interpreter finding the coder's intended
> indent wouldn't be that hard. And just make the need for consistant
> spaces or tabs irrevelent simply by reformatting the indent as
> expected. Pretty much all my text editors can.

The trouble with having a language declaration that "a tab is
equivalent to X spaces" is that there's no consensus as to what X
should be. Historically X has always been 8, and quite a few programs
still assume this. I personally like 4. Some keep things narrow with
2. You can even go 1 - a strict substitution of \t with \x20. Once you
declare it in your language, you immediately break everyone who uses
anything different.

ChrisA

[toc] | [prev] | [next] | [standalone]

#16371

On Nov 28, 8:49 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer <devpla...@gmail.com> wrote:
> > To me, I would think the interpreter finding the coder's intended
> > indent wouldn't be that hard. And just make the need for consistant
> > spaces or tabs irrevelent simply by reformatting the indent as
> > expected. Pretty much all my text editors can.
>
> The trouble with having a language declaration that "a tab is
> equivalent to X spaces" is that there's no consensus as to what X
> should be. Historically X has always been 8, and quite a few programs
> still assume this. I personally like 4. Some keep things narrow with
> 2. You can even go 1 - a strict substitution of \t with \x20. Once you
> declare it in your language, you immediately break everyone who uses
> anything different.
>
> ChrisA

Yeah. We must remember the Unix users, espcially those who don't know
how to hack Vim or bash. I've decided not to require a specific number
of spaces. I am still teetering on whether to allow tabs.

[toc] | [prev] | [next] | [standalone]

#16379

On Tue, 29 Nov 2011 12:49:49 +1100, Chris Angelico wrote:

> On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer <devplayer@gmail.com> wrote:
>> To me, I would think the interpreter finding the coder's intended
>> indent wouldn't be that hard. And just make the need for consistant
>> spaces or tabs irrevelent simply by reformatting the indent as
>> expected. Pretty much all my text editors can.
> 
> The trouble with having a language declaration that "a tab is equivalent
> to X spaces" is that there's no consensus as to what X should be.
> Historically X has always been 8, and quite a few programs still assume
> this. I personally like 4. Some keep things narrow with 2. You can even
> go 1 - a strict substitution of \t with \x20. Once you declare it in
> your language, you immediately break everyone who uses anything
> different.

Why should we enforce how many spaces a tab is set to? That is literally 
only visible to the editor, not the compiler. (Unless the parser is 
particularly stupid and merely substitutes X spaces for a tab every time 
it sees one.)

Mixed spaces and tabs in an indent are ambiguous, and so raises 
SyntaxError (or at least it *should* raise SyntaxError). But separate 
code blocks can use different absolute indent levels without ambiguity, 
so long as the relative indentation is consistent:

def ham(): # tab stops at 4 and 8
    do(a)
    do(b)
    if c:
        do(c)
    else:
        do(d)


def spam(): # tab stops at 8 and 12
        do(a)
        do(b)
        if c:
            do(c)
        else:
            do(d)

There is no meaningful difference in indentation between ham and spam 
above. In either case, I could replace spaces with tabs to get the same 
relative indents regardless of the absolute indentation.

I can appreciate the aesthetic argument that *within a single file*, 
indentation should be consistent. But it's not logically necessary for 
the parser: it need only be consistent within a single code unit 
(function or class usually). In other words: syntax should only care 
about relative indentation, absolute indentation belongs as a coding 
standard.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#16507

On Nov 29, 3:04 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Tue, 29 Nov 2011 12:49:49 +1100, Chris Angelico wrote:
> > On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer <devpla...@gmail.com> wrote:
> >> To me, I would think the interpreter finding the coder's intended
> >> indent wouldn't be that hard. And just make the need for consistant
> >> spaces or tabs irrevelent simply by reformatting the indent as
> >> expected. Pretty much all my text editors can.
>
> > The trouble with having a language declaration that "a tab is equivalent
> > to X spaces" is that there's no consensus as to what X should be.
> > Historically X has always been 8, and quite a few programs still assume
> > this. I personally like 4. Some keep things narrow with 2. You can even
> > go 1 - a strict substitution of \t with \x20. Once you declare it in
> > your language, you immediately break everyone who uses anything
> > different.
>
> Why should we enforce how many spaces a tab is set to? That is literally
> only visible to the editor, not the compiler. (Unless the parser is
> particularly stupid and merely substitutes X spaces for a tab every time
> it sees one.)
>
> Mixed spaces and tabs in an indent are ambiguous, and so raises
> SyntaxError (or at least it *should* raise SyntaxError). But separate
> code blocks can use different absolute indent levels without ambiguity,
> so long as the relative indentation is consistent:
>
> def ham(): # tab stops at 4 and 8
>     do(a)
>     do(b)
>     if c:
>         do(c)
>     else:
>         do(d)
>
> def spam(): # tab stops at 8 and 12
>         do(a)
>         do(b)
>         if c:
>             do(c)
>         else:
>             do(d)
>
> There is no meaningful difference in indentation between ham and spam
> above. In either case, I could replace spaces with tabs to get the same
> relative indents regardless of the absolute indentation.
>
> I can appreciate the aesthetic argument that *within a single file*,
> indentation should be consistent. But it's not logically necessary for
> the parser: it need only be consistent within a single code unit
> (function or class usually). In other words: syntax should only care
> about relative indentation, absolute indentation belongs as a coding
> standard.
>
> --
> Steven

Great point. Your point is why I started writting my own little Python
parser/scanner (as an pet project/lesson project) and is in part, why
I wrote my little reindent() in the first place. I am/was trying to
figure out the algorithim for how Python's indent/dedents made logical
"code blocks" or "closures" or whatever they are called. That and see
if there was a way to interpret docstrings in various formats.

I often get indentation syntax errors when I cut and paste
stackflow.com, devprogrammer.com, daniweb.com, etc. code snippets into
my various IDEs/ editors and I wanted to make a little tabnanny of my
own. Some of the IDEs and editors (Editra) allow plugins. So I wanted
to get a baseline for the various plugins.

So I call the reindent() after I call the blocker(), which determines
a block by -releative- indent/dedent as +1 or, 0 or -1 whether that be
+4 spaces, +2 spaces, +1 tab or -3 spaces, whatever...; as you, Steve,
mentioned indent is not fixed but relative.

(btw I'v posted this in this topic because I thought it could
contribute to how Unit's choice of how indents are handled my benefit
from this discussion).

My thoughts on tab verse space chars;, for most old and even current
commandline interfaces, text editors, and historically line printers,
tabs simply acted like a macro to move x number of fixed spaces. It
wasn't until varible width fonts, kerning, and other advanced printing
techniques became mainstream<- did space chars differ in meaning from
tab chars, exception perhaps being file storage space (way back in the
day). I only say this because I can't stand hitting the right and left
arrow keys or using multiple fingers to move left and right 3 more
times then I have to while editing my text. I -feel- I move faster
around my text files with tabs then I do with 4 spaces.

They only annoyance I've had with Python's flexiblity with indent
using tab and or spaces is the docstrings.
\t = tab
def myfunc():
\t"""here is my docstring that bla bla bla's
\t\tand indented do da days...
\t"""

verse (s = space)
def myfunc():
ssss"""here is my docstring that bla bla bla's
ssssssssand indented do da days...
ssss"""

verse space = tab or space
def myfunc():
    "here is my docstring that bla bla bla's"\
    "    and indented do da days..."\
    "\n"

verse the legal and sometimes seen form:
def myfunc():
\tmyval = somefunc( arg0, arg1, arg2, lotsofargs,
\t\tsssspaces_to_align_arg_to_arg0)

If you strip the text and display it using basic reformatting in fixed
font, like in the python interpreter, no biggy. But when you want to
display the docstrings in an advanced font, like that of an ide with
truetype fonts, formatting gets lost without having the app account
for all the various ways Python coders do their docstrings.

So if you wanted a consistant flexible (really) long term way to
autogenerate and publish your and others code/packages/libraries, it
gets tricky. Ask big-python-library maintainers know, many people go
to chat and forums simply because autogenerated documention wasn't
clear to the non-expert, thus repeating the same questions over and
over. AND perhaps in the beginning it was well documented but since
new constructs and refactoring of code, often auto-generated
documentation can get "reduced" to something unuseful to those not-in-
the-know.

If whitespace indentation is used to define some construct of a
programming language, then how people like to document their code (by
using various forms of whitespace) could impact how well -some- people
learn the new language. Auto-generated documention could very well be
influenced by that decision.

What form of whitespace indentation could effect readability/
understandable code.
For example reducing indentation to 2 spaces instead of 4 might
encourage some coders to use even deeper indentation because the code
could fix more stuff (it's not being used up by whitespace
indentation). Many feel that's a bad thing (I do too).
(not knowing Unit code; I'll use Python)

class Wow(object):
  def myfunc(self):
    a = func()
    if a:
      small_indent = something()
        if small_indent:
          getting_silly = godeeper()
        while getting_silly > a:
          bet_you_get_the_point += getting_silly -
code_makes_no_sense()
          for i in range(100:
            if bet_you_get_the_point in SOMEGLOBAL['part1'][0]:
              display(a, small_indent, getting_silly,
bet_you_get_the_point)

Well, that may be a little hyperbolic.
But with 2 spaces you can encourage coders to get very deep,
indentially, and still fit 80 chars.
(newly invented word: indentially.  But I don't care, you get the
point.)

To me, each viewer of that code should be able to put the indent to
something that fits their taste. And lets face it. most source code
today is viewed in some gui text editor that can reinterpret that
indent to whatever, without generating interperter indentation errors
later. The only exception to consistancy would again be docstrings or
more precisely string blocks, or block strings, or tripe quoted,
whatever you want to call them.

My words are not meant to garner flames or anything, just to cause
thought;

[toc] | [prev] | [next] | [standalone]

#16517

On Thu, 01 Dec 2011 10:03:53 -0800, DevPlayer wrote:

[...]
> Well, that may be a little hyperbolic. But with 2 spaces you can
> encourage coders to get very deep, indentially, and still fit 80 chars.

Why would you want to encourage coders to write deeply indented code?

In my opinion, if your code is indented four or more levels, you should 
start to think about refactorising your code; if you reach six levels, 
your code is probably a mess.

class K:
    def spam():
        if x:
            for a in b:
                # This is about as deep as comfortable
                while y:
                    # Code is starting to smell
                    try:
                        # Code smell is now beginning to reek
                        with z as c:
                            # And now more of a stench
                            try:
                                # A burning, painful stench
                                if d:
                                    # Help! I can't breathe!!!
                                    for e in f:
                                        # WTF are you thinking?
                                        try:
                                            # DIE YOU M***********ER!!!
                                            while g:
                                                # gibbers quietly
                                                ...


The beauty of languages like Python where indentation is significant is 
that you can't hide from the ugliness of this code. 

class K: {
  # Code looks okay to a casual glance.
  def spam():{
   if x: { for a in b:{
     while y:{ try:{ with z as c:{
       try:{ if d:{ for e in f:{ try:{
         while g:{ ... }}}}
       }}}}
     }}}}

Deeply indented code *is* painful, it should *look* painful.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web