Re: Using the Python Interpreter as a Reference
> 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.
Here's some code I encountered while grading assignments from
first-year CS students:
if 'not' in temp_holder:
for item in (range(len(ial))):
for key in (range(len(ial[item]))):
if type(ial[item][key]) == str:
if temp[term].find(ial[item][key]) > 0:
for value in range(len(ial[item][1])):
if ial[item][1][value] in images:
while ial[item][1][value] in images:
images.remove(ial[item][1][value])
I think after some point of nesting, not only can we conclude that the
code is difficult to read, we can probably conclude the author wasn't
thinking very clearly about what he or she was doing.
Devin
On Thu, Dec 1, 2011 at 7:43 PM, Steven D'Aprano
wrote:
> 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
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
RE: Using the Python Interpreter as a Reference
Steven, that's probably the most elegant explanation of the "pythonic"
way I've ever seen. I'm saving it for the next time upper management
want to use Java again.
-Original Message-
From: python-list-bounces+frsells=adventistcare@python.org
[mailto:python-list-bounces+frsells=adventistcare@python.org] On
Behalf Of Steven D'Aprano
Sent: Thursday, December 01, 2011 7:43 PM
To: python-list@python.org
Subject: Re: Using the Python Interpreter as a Reference
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
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Fri, Dec 2, 2011 at 11:43 AM, Steven D'Aprano wrote: > 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. So... would it be a bad thing to wrap up all my code into a single massive expression that returns a single integer for success/failure? Oh wait, the only time I ever saw code do that was in the IOCCC. Still, it WAS pretty awesome code! IOCCC is a code perfume factory. Cloying smell. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 29, 3:04 am, Steven D'Aprano wrote: > On Tue, 29 Nov 2011 12:49:49 +1100, Chris Angelico wrote: > > On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer 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(): """here is my docstring that bla bla bla's and indented do da days... """ 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\tpaces_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 the
Re: Using the Python Interpreter as a Reference
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Tue, 29 Nov 2011 12:49:49 +1100, Chris Angelico wrote: > On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Mon, Nov 28, 2011 at 7:42 PM, Travis Parks 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 28, 5:57 pm, Steven D'Aprano wrote: > On Mon, 28 Nov 2011 13:29:06 -0800, Travis Parks wrote: > > Exception handling is one of those subjects few understand and fewer can > > implement properly in modern code. Languages that don't support > > exceptions as part of their signature lead to capturing generic > > Exception all throughout code. It is one of those features I wish .NET > > had. At the same time, with my limited experience with Java, it has been > > a massive annoyance. Perhaps something to provide or just shut off via a > > command line parameter. What indications have there been that this has > > been a flaw? I can see it alienating a large group of up- and-coming > > developers. > > http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html > > Note also that Bruce Eckel repeats a rumour that checked exceptions were > *literally* an experiment snuck into the Java language while James > Gosling was away on holiday. > > http://www.mindview.net/Etc/Discussions/UnCheckedExceptionComments > > Even if that is not true, checked exceptions are a feature that *in > practice* seems to lead to poor exception handling and cruft needed only > to satisfy the compiler: > > http://www.alittlemadness.com/2008/03/12/checked-exceptions-failed-ex... > > and other annoyances. It's main appeal, it seems to me, is to give a > false sense of security to Java developers who fail to realise that under > certain circumstances Java will raise certain checked exceptions *even if > they are not declared*. E.g. null pointer exceptions. > > See also: > > http://java.dzone.com/articles/checked-exceptions-i-love-you > > and note especially the comment from the coder who says that he simply > declares his functions to throw Exception (the most generic checked > exception), thus defeating the whole point of checked exceptions. > > -- > Steven I think all of the examples you listed referred specifically to most programmers finding ways around the annoyance. I have heard about throwing generic Exception or inheriting all custom exception types from RuntimeException. I did this quite often myself. In general, unchecked exceptions shouldn't be caught. They occur because of bad code and insufficient testing. Checked exceptions occur because of downed databases, missing files, network problems - things that may become available later without code changes. One day, I went through about 10,000 lines of code and moved argument checking code outside of try blocks because I realized I was handling some of them by accident. Here is the program: if me == idiot: exit(). People don't think about this, but the exceptions thrown by a module are part of that module's interface. Being able to make sure only what you expect to come out is important. Unlike Java, Unit requires you to opt in to using throws clauses. If you don't list one, one is generated for you automatically. The benefit: you can see what a function throws and protect yourself without all the babysitting. A lack of exception handling is big problem in .NET. I have had libraries from big names including Novell and Oracle throw NullReferenceExceptions because _they_ didn't know what would happen in cases where a DLL is missing or a dependency isn't installed. They could have done better testing, but if the biggest names in development can't manage to figure it, I say leave it up to the compiler. Returning nulls or special value in cases of failures takes us back to the days of C and Fortran. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 28, 8:49 pm, Chris Angelico wrote: > On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Tue, Nov 29, 2011 at 1:42 PM, Travis Parks 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 28, 5:24 pm, Steven D'Aprano 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
> > 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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
> 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: -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 27, 6:55 pm, Steven D'Aprano 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Mon, 28 Nov 2011 13:29:06 -0800, Travis Parks wrote: > Exception handling is one of those subjects few understand and fewer can > implement properly in modern code. Languages that don't support > exceptions as part of their signature lead to capturing generic > Exception all throughout code. It is one of those features I wish .NET > had. At the same time, with my limited experience with Java, it has been > a massive annoyance. Perhaps something to provide or just shut off via a > command line parameter. What indications have there been that this has > been a flaw? I can see it alienating a large group of up- and-coming > developers. http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html Note also that Bruce Eckel repeats a rumour that checked exceptions were *literally* an experiment snuck into the Java language while James Gosling was away on holiday. http://www.mindview.net/Etc/Discussions/UnCheckedExceptionComments Even if that is not true, checked exceptions are a feature that *in practice* seems to lead to poor exception handling and cruft needed only to satisfy the compiler: http://www.alittlemadness.com/2008/03/12/checked-exceptions-failed-experiment/#comment-219143 and other annoyances. It's main appeal, it seems to me, is to give a false sense of security to Java developers who fail to realise that under certain circumstances Java will raise certain checked exceptions *even if they are not declared*. E.g. null pointer exceptions. See also: http://java.dzone.com/articles/checked-exceptions-i-love-you and note especially the comment from the coder who says that he simply declares his functions to throw Exception (the most generic checked exception), thus defeating the whole point of checked exceptions. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Tue, Nov 29, 2011 at 9:24 AM, Steven D'Aprano 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Mon, 28 Nov 2011 12:32:59 -0700, Ian Kelly wrote:
> On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
> 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Tue, Nov 29, 2011 at 8:29 AM, Travis Parks wrote: > Languages that don't support > exceptions as part of their signature lead to capturing generic > Exception all throughout code. It is one of those features I wish .NET > had. At the same time, with my limited experience with Java, it has > been a massive annoyance. In Java, it mainly feels like syntactic salt. There's still a class of RuntimeExceptions that aren't listed in the signature, so you still have to concern yourself with the possibility that unexpected exceptions will propagate; and you're forced to decorate every method with the list of what it might propagate up, other than that. It's like const-decorating a series of functions in C++, only far less consequential and requiring far more typing. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 28, 3:40 pm, Gregory Ewing wrote: > Travis Parks wrote: > > I thinking tabs are > > out-of-date. Even the MAKE community wishes that the need for tabs > > would go away > > The situation with make is a bit different, because it > *requires* tabs in certain places -- spaces won't do. > Python lets you choose which to use as long as you don't > mix them up, and I like it that way. > > > let Parse = public static method (value: String) > > throws(FormatException UnderflowException OverflowException) > > Checked exceptions? I fear you're repeating a huge mistake > going down that route... > > -- > Greg > > Exception handling is one of those subjects few understand and fewer can implement properly in modern code. Languages that don't support exceptions as part of their signature lead to capturing generic Exception all throughout code. It is one of those features I wish .NET had. At the same time, with my limited experience with Java, it has been a massive annoyance. Perhaps something to provide or just shut off via a command line parameter. What indications have there been that this has been a flaw? I can see it alienating a large group of up- and-coming developers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 28, 2:32 pm, Ian Kelly wrote: > On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano > > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On 2011-11-28, Gregory Ewing 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
Hello all, My python runs and crashes after another run. I am getting errors like Microsoft Visual C++ Runtime Library program c:\Python27\pythonw.exe This application has requested the Runtime to terminate it in an usuak way. Please contact the application's support team for more information. Any Idea ? my plot also does not work ? frustrating On Mon, Nov 28, 2011 at 12:32 PM, Ian Kelly wrote: > On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano > 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 > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
Travis Parks wrote: I thinking tabs are out-of-date. Even the MAKE community wishes that the need for tabs would go away The situation with make is a bit different, because it *requires* tabs in certain places -- spaces won't do. Python lets you choose which to use as long as you don't mix them up, and I like it that way. let Parse = public static method (value: String) throws(FormatException UnderflowException OverflowException) Checked exceptions? I fear you're repeating a huge mistake going down that route... -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On 2011-11-28, Ian Kelly 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 27, 6:55 pm, Steven D'Aprano 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
Re: Using the Python Interpreter as a Reference
On Mon, Nov 28, 2011 at 10:55 AM, Steven D'Aprano wrote: > 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... Ook has only three tokens (okay, it's a derivative of BrainF** so it kinda has eight, but they're implemented on three). It's Turing-complete, but it is so small as to be useless for any practical purposes. The ONLY way to use Ook for any useful code would be to write an interpreter for another language in it, and use that other language. However, Ook can be proven to be flawless, as can an Ook interpreter, much more easily than a full-featured language like Python or C. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Sun, 27 Nov 2011 14:21:01 -0800, Travis Parks wrote:
> On Nov 26, 1:53 pm, Rick Johnson wrote:
>> On Nov 20, 6:46 pm, Travis Parks wrote:
>>
>> > Hello:
>>
>> > I am currently working on designing a new programming language. It is
>> > a compiled language, but I still want to use Python as a reference.
>> > Python has a lot of similarities to my language, such as indentation
>> > for code blocks,
>>
>> I hope you meant to say "*forced* indention for code blocks"! "Forced"
>> being the key word here. What about tabs over spaces, have you decided
>> the worth of one over the other or are you going to repeat Guido's
>> folly?
>>
>> And please, i love Python, but the language is a bit asymmetrical. Do
>> try to bring some symmetry to this new language. You can learn a lot
>> from GvR's triumphs, however, you can learn even more from his follys.
>
> 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. 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).
>
> 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.
>
> 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 |]
>
> Lambdas and functions are the same thing in my language, so no need for
> a special keyword. I also distinguish between initialization and
> assignment via the let keyword. Also, non-locals do not need to be
> defined explicitly, since the scoping rules in Unit are far more "anal".
>
> 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 love these types of discussions though, because it helps me to be
> aware. When designing a language, it is extremely helpful to hear what
> language features have led to problems. For instance, C#'s foreach loops
> internally reuse a variable, which translates to something like this:
>
> using (IEnumerator enumerator = enumerable.GetEnumerator())
> {
> T current;
> while (enumerator.MoveNext())
> {
> current = enumerator.Current;
> // inner loop code goes here
> }
> }
>
> Since the same variable is reused, threads referencing the loop variable
> work against whatever value is currently in the variable, rather than
> the value when the thread was created. Most of the time, this means
> every thread works against the same value, which isn't the expected
> outcome. Moving the variable inside the loop _may_ help, but it would
> probably be optimized back out of the loop by the compiler. With the
> growth of threaded applications, these types of stack-based
> optimizations may come to an end. That is why it is important for a
> next-gen language to have a smarter stack - one that is context
> sensitive. In Unit, the stack grows and shrinks like a dynamic array, at
> each scope, rather than at the beginning and end of each function. Sure,
> there's a slight cost in performance, but a boost in consistency. If a
> programmer really wants the performance, they can move the variable out
> of the loop themselves.
>
> In fact, there are a lot of features in Unit that will come with
> overhead, such as default arguments, non-locals, function-objects, etc.
> However, the game plan is to avoid the overhead if it isn't used. Some
> things, such as exception handling, will be hard to provide without
> overhead. My belief is that, provided a tool, most developers will use
> it and accept the slight runtime overhead.
>
> I think everyone has an idea about what would make for the perfect
> language. I am always willing to entertain ideas. I have pulled from
> many sources: C#, Java, Python, JavaScript, F#, Lisp and more. The hope
> is to provide as much expression with as much consistency as possible.
> Just the other day I spent 2 hours trying to determine how to create a
> null pointer (yeah, it took that long).
>
> let pi = null as shared * Integer32 # null is always a pointer
>
> Originally, I wanted 'as' to be a safe conversion. However, I decided to
> make use of the 'try' keyword to mean a safe conversion.
>
> let nd = try base as shared * Derived let d = if nd.Succeeded: nd.Value
> else: null # or, shorthand let i = try Integer32.Parse("123") else 0
>
> Of cour
Re: Using the Python Interpreter as a Reference
On Nov 26, 1:53 pm, Rick Johnson wrote:
> On Nov 20, 6:46 pm, Travis Parks wrote:
>
> > Hello:
>
> > I am currently working on designing a new programming language. It is
> > a compiled language, but I still want to use Python as a reference.
> > Python has a lot of similarities to my language, such as indentation
> > for code blocks,
>
> I hope you meant to say "*forced* indention for code blocks"! "Forced"
> being the key word here. What about tabs over spaces, have you decided
> the worth of one over the other or are you going to repeat Guido's
> folly?
>
> And please, i love Python, but the language is a bit asymmetrical. Do
> try to bring some symmetry to this new language. You can learn a lot
> from GvR's triumphs, however, you can learn even more from his follys.
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. 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).
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.
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 |]
Lambdas and functions are the same thing in my language, so no need
for a special keyword. I also distinguish between initialization and
assignment via the let keyword. Also, non-locals do not need to be
defined explicitly, since the scoping rules in Unit are far more
"anal".
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 love these types of discussions though, because it helps me to be
aware. When designing a language, it is extremely helpful to hear what
language features have led to problems. For instance, C#'s foreach
loops internally reuse a variable, which translates to something like
this:
using (IEnumerator enumerator = enumerable.GetEnumerator())
{
T current;
while (enumerator.MoveNext())
{
current = enumerator.Current;
// inner loop code goes here
}
}
Since the same variable is reused, threads referencing the loop
variable work against whatever value is currently in the variable,
rather than the value when the thread was created. Most of the time,
this means every thread works against the same value, which isn't the
expected outcome. Moving the variable inside the loop _may_ help, but
it would probably be optimized back out of the loop by the compiler.
With the growth of threaded applications, these types of stack-based
optimizations may come to an end. That is why it is important for a
next-gen language to have a smarter stack - one that is context
sensitive. In Unit, the stack grows and shrinks like a dynamic array,
at each scope, rather than at the beginning and end of each function.
Sure, there's a slight cost in performance, but a boost in
consistency. If a programmer really wants the performance, they can
move the variable out of the loop themselves.
In fact, there are a lot of features in Unit that will come with
overhead, such as default arguments, non-locals, function-objects,
etc. However, the game plan is to avoid the overhead if it isn't used.
Some things, such as exception handling, will be hard to provide
without overhead. My belief is that, provided a tool, most developers
will use it and accept the slight runtime overhead.
I think everyone has an idea about what would make for the perfect
language. I am always willing to entertain ideas. I have pulled from
many sources: C#, Java, Python, JavaScript, F#, Lisp and more. The
hope is to provide as much expression with as much consistency as
possible. Just the other day I spent 2 hours trying to determine how
to create a null pointer (yeah, it took that long).
let pi = null as shared * Integer32 # null is always a pointer
Originally, I wanted 'as' to be a safe conversion. However, I decided
to make use of the 'try' keyword to mean a safe conversion.
let nd = try base as shared * Derived
let d = if nd.Succeeded: nd.Value else: null
# or, shorthand
let i = try Integer32.Parse("123") else 0
Of course, the last line could cost performance wise. For that reason,
Unit will allow for "try" versions of methods.
let Parse = public static method (value: String)
throws(FormatException UnderflowException OverflowException)
returns(Integer32)
Re: Using the Python Interpreter as a Reference
On Nov 26, 1:34 pm, Chris Angelico wrote: > On Sun, Nov 27, 2011 at 5:53 AM, Rick Johnson > > wrote: > > I hope you meant to say "*forced* indention for code blocks"! "Forced" > > being the key word here. What about tabs over spaces, have you decided > > the worth of one over the other or are you going to repeat Guido's > > folly? > > I recommend demanding that indentation strictly alternate tabs or > spaces in successive non-blank lines. Funny. > Comment-only lines must be > identical to the immediately-preceding line. ...as in "indentation" you mean, then yes. OR suffer the syntax error. > A tab is equivalent to > seven spaces. ...as for "the litmus test of stdlib code" you mean, then yes. OR suffer the syntax error. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Sun, Nov 27, 2011 at 5:53 AM, Rick Johnson wrote: > I hope you meant to say "*forced* indention for code blocks"! "Forced" > being the key word here. What about tabs over spaces, have you decided > the worth of one over the other or are you going to repeat Guido's > folly? I recommend demanding that indentation strictly alternate tabs or spaces in successive non-blank lines. Comment-only lines must be identical to the immediately-preceding line. A tab is equivalent to seven spaces. End the ambiguity! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 20, 6:46 pm, Travis Parks wrote: > Hello: > > I am currently working on designing a new programming language. It is > a compiled language, but I still want to use Python as a reference. > Python has a lot of similarities to my language, such as indentation > for code blocks, I hope you meant to say "*forced* indention for code blocks"! "Forced" being the key word here. What about tabs over spaces, have you decided the worth of one over the other or are you going to repeat Guido's folly? And please, i love Python, but the language is a bit asymmetrical. Do try to bring some symmetry to this new language. You can learn a lot from GvR's triumphs, however, you can learn even more from his follys. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
Consider implementing OOP, reflection and implement in HLA or C =] On Mon, Nov 21, 2011 at 11:46 AM, Travis Parks wrote: > Hello: > > I am currently working on designing a new programming language. It is > a compiled language, but I still want to use Python as a reference. > Python has a lot of similarities to my language, such as indentation > for code blocks, lambdas, non-locals and my language will partially > support dynamic programming. > > Can anyone list a good introduction to the files found in the source > code? I have been poking around the source code for a little bit and > there is a lot there. So, I was hoping someone could point me to the > "good parts". I am also wondering whether some of the code was > generated because I see state transition tables, which I doubt someone > built by hand. > > Any help would be greatly appreciated. It will be cool to see how the > interpreter works internally. I am still wonder whether designing the > language (going on 4 months now) will be harder than implementing it. > > Thanks, > Travis Parks > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
http://pyjs.org/ On Sat, Nov 26, 2011 at 3:22 PM, Sells, Fred wrote: > I'm looking at a variation on this theme. I currently use > Flex/ActionScript for client side work, but there is pressure to move > toward HTML5+Javascript and or iOS. Since I'm an old hand at Python, I > was wondering if there is a way to use it to model client side logic, > then generate the javascript and ActionScript. I don't see an issue > using custom python objects to render either mxml, xaml or html5 but I'm > not aware if anyone has already solved the problem of converting Python > (byte code?) to these languages? Any suggestions. > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
RE: Using the Python Interpreter as a Reference
I'm looking at a variation on this theme. I currently use Flex/ActionScript for client side work, but there is pressure to move toward HTML5+Javascript and or iOS. Since I'm an old hand at Python, I was wondering if there is a way to use it to model client side logic, then generate the javascript and ActionScript. I don't see an issue using custom python objects to render either mxml, xaml or html5 but I'm not aware if anyone has already solved the problem of converting Python (byte code?) to these languages? Any suggestions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 21, 5:46 am, Travis Parks wrote: > Hello: > > I am currently working on designing a new programming language. It is > a compiled language, but I still want to use Python as a reference. > Python has a lot of similarities to my language, such as indentation > for code blocks, lambdas, non-locals and my language will partially > support dynamic programming. > > Can anyone list a good introduction to the files found in the source > code? I have been poking around the source code for a little bit and > there is a lot there. So, I was hoping someone could point me to the > "good parts". I am also wondering whether some of the code was > generated because I see state transition tables, which I doubt someone > built by hand. > > Any help would be greatly appreciated. It will be cool to see how the > interpreter works internally. I am still wonder whether designing the > language (going on 4 months now) will be harder than implementing it. > > Thanks, > Travis Parks - compiled language - indentation based - functional programming features Looks like a description of Haskell. You may want to look there. Back end: LLVM is gaining a lot of traction these days. Seems to give best of both worlds -- compiling to C and to machine code -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Fri, Nov 25, 2011 at 9:55 PM, Travis Parks wrote: > I have been thinking about compiling into a > language like C++ or C instead of assembler for my first time through. Yep, or any other language you feel like using as an intermediate. Or alternatively, just start with an interpreter - whatever's easiest. Compiling to C gives you a massive leg-up on portability; so does writing an interpreter in C, as either way your language is easily made available on every platform that gcc's been ported to. As long as you're happy with the idea of building a massively language that'll never be used by anybody but yourself, you can have immense fun with this. And hey, Unit might turn out to be a beautiful niche language, or even go mainstream. But mainly, you'll have fun doing it. And if you're not having fun, what's the use of living forever? (Oh wait, you're not a vampire from Innistrad. Sorry about that.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 22, 1:37 pm, Alan Meyer wrote: > On 11/20/2011 7:46 PM, Travis Parks wrote: > > > Hello: > > > I am currently working on designing a new programming language. ... > > I have great respect for people who take on projects like this. > > Your chances of popularizing the language are small. There must be > thousands of projects like this for every one that gets adopted by other > people. However your chances of learning a great deal are large, > including many things that you'll be able to apply to programs and > projects that, at first glance, wouldn't appear to benefit from this > kind of experience. If you get it working you'll have an impressive > item to add to your resume. > > I suspect that you'll also have a lot of fun. > > Good luck with it. > > Alan I've been learning a lot and having tons of fun just designing the language. First, I get think about all of the language features that I find useful. Then I get to learn a little bit how they work internally. For instance, functions are first-class citizens in Unit, supporting closures. To make that happen meant wrapping such functions inside of types and silently elavating local variables to reference counted pointers. Or, I realized that in order to support default arguments, I would have to silently wrap parameters in types that were either set or not set. That way calls to the default command could simply be replaced by an if statement. It was a really subtle implementation detail. It is also fun thinking about what makes sense. For instance, Unit will support calling methods with named arguments. Originally, I thought about using the '=' operator: Foo(name="bob" age=64) but, then I realized that the equals sign could be confused with assignment. Those types of syntactic conflicts occur quite often and lead to a lot of rethinking. Ultimately, somewhat good ideas get replaced with much better ideas. I had been contemplating Unit for months before the final look and feel of the language came into view. It isn't what I started out imagining, but I think it turned out better than I had originally planned. Recently, I rethought how functions looked, since the headers were too long: alias Predicate = function (value: & readonly T) throws() returns(Boolean) let Any = public function (values: & readonly IIterable) (?predicate: Predicate) throws() # ArgumentNullException inherits from UncheckedException returns(Boolean): # this can be on one line default predicate = (function value: true) assert predicate != null "The predicate cannot be null." ArgumentNullException for value in values: if predicate(value): return true return false Most of the time, throws clauses, returns clauses and parameter type constraints can be left off. Plus, now they can all appear on one line. Assertions and default statements now appear in the body. Assertions now optionally take a message and the exception type to throw. So, yeah, this has been an awesome project so far. I have dozens of documents and I have been keeping up on a blog. I've even started implementing a simple recursive descent parser just to make sure the syntax doesn't conflict. Now it will be a matter of formally defining a grammer and implementing the backend of the compiler... which I've never done before. I have been thinking about compiling into a language like C++ or C instead of assembler for my first time through. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On 11/20/2011 7:46 PM, Travis Parks wrote: Hello: I am currently working on designing a new programming language. ... I have great respect for people who take on projects like this. Your chances of popularizing the language are small. There must be thousands of projects like this for every one that gets adopted by other people. However your chances of learning a great deal are large, including many things that you'll be able to apply to programs and projects that, at first glance, wouldn't appear to benefit from this kind of experience. If you get it working you'll have an impressive item to add to your resume. I suspect that you'll also have a lot of fun. Good luck with it. Alan -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Nov 21, 12:44 am, Steven D'Aprano wrote: > On Mon, 21 Nov 2011 13:33:21 +1100, Chris Angelico wrote: > > What's your language's "special feature"? I like to keep track of > > languages using a "slug" - a simple one-sentence (or less) statement of > > when it's right to use this language above others. For example, Python > > is optimized for 'rapid deployment'. > > "Python will save the world" > > http://proyectojuanchacon.blogspot.com/2010/07/saving-world-with-pyth... > > -- > Steven The language, psuedo name Unit, will be a low-level language capable of replacing C in most contexts. However, it will have integrated functional programming features (tail-end recursion optimization, tuples, currying, closures, function objects, etc.) and dynamic features (prototypical inheritance and late binding). It is a hybrid between C#, C++, F#, Python and JavaScript. The hope is that you won't pay for features you don't use, so it will run well on embedded devices as well as on desktops - that's to be seen. I'm no master compiler builder, here. The functional code is pretty basic: let multiply = function x y: return x * y # automatic generic arguments (integer here) let double = multiply _ 2 # short-hand currying - inlined if possible let doubled = [|0..10|].Apply(double) # double zero through 10 The dynamic code is pretty simple too: dynamic Prototype = function value: self.Value = value # simulated ctor Prototype.Double = function: self.Value * 2 # self refers to instance new Prototype(5).Double() # 10 new Prototype(6).Double() # 12 dynamic x = 5 # five wrapped with a bag x.Double = function: self * 2 x.Double() # 10 dynamic y = 6 y.Double = x.Double # member sharing y.Double() #12 The language also sports OOP features like are found in Java or C#: single inheritance; multiple interface inheritance; sealed, virtual and abstract types and members; explicit inheritance; extension methods and namespaces. The coolest feature will be its generics-oriented function signatures. By default everything is generic. You apply constraints to parameters, rather than specific types. For instance: let Average = function values: where values is ICountable IIterable assert values.Count > 0 "The values list cannot be empty." throws ArgumentException returns Float64 let sum = 0 for value in values: sum += value return sum / values.Count # floating point division As you can see, the function headers can be larger than the bodies themselves. They support type constraints, assertions (argument checking), exceptions enumeration, default parameters and return type information. All of them can be left out if the type of arguments can be inferred. This will not be an overnight project. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Mon, Nov 21, 2011 at 4:44 PM, Steven D'Aprano wrote: > On Mon, 21 Nov 2011 13:33:21 +1100, Chris Angelico wrote: > >> What's your language's "special feature"? I like to keep track of >> languages using a "slug" - a simple one-sentence (or less) statement of >> when it's right to use this language above others. For example, Python >> is optimized for 'rapid deployment'. > > "Python will save the world" > > http://proyectojuanchacon.blogspot.com/2010/07/saving-world-with-python.html I don't think Python has a hard disk big enough to save all of it... ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Mon, 21 Nov 2011 13:33:21 +1100, Chris Angelico wrote: > What's your language's "special feature"? I like to keep track of > languages using a "slug" - a simple one-sentence (or less) statement of > when it's right to use this language above others. For example, Python > is optimized for 'rapid deployment'. "Python will save the world" http://proyectojuanchacon.blogspot.com/2010/07/saving-world-with-python.html -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Sun, Nov 20, 2011 at 4:46 PM, Travis Parks wrote: > Hello: > > I am currently working on designing a new programming language. It is > a compiled language, but I still want to use Python as a reference. > Python has a lot of similarities to my language, such as indentation > for code blocks, lambdas, non-locals and my language will partially > support dynamic programming. > FWIW, comprehensions are often nicer than lambdas. You might want to check out PyPy. It's written in a more flexible implementation language than CPython, and facilitates writing languages - IOW, PyPy is more than just Python written in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using the Python Interpreter as a Reference
On Mon, Nov 21, 2011 at 11:46 AM, Travis Parks wrote: > I am currently working on designing a new programming language. It is > a compiled language, but I still want to use Python as a reference. > Python has a lot of similarities to my language, such as indentation > for code blocks, lambdas, non-locals and my language will partially > support dynamic programming. If you want to use Python as a reference for designing your language, look at the documentation. It's pretty decent on the subject of language specs (you may find yourself reading a lot of PEPs as well as the "normal" docs). But for actual code - you may want to look at Cython. I've never used it, but it compiles Python code to C (IIRC); that's more likely to be what you're after. What's your language's "special feature"? I like to keep track of languages using a "slug" - a simple one-sentence (or less) statement of when it's right to use this language above others. For example, Python is optimized for 'rapid deployment'. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Using the Python Interpreter as a Reference
Hello: I am currently working on designing a new programming language. It is a compiled language, but I still want to use Python as a reference. Python has a lot of similarities to my language, such as indentation for code blocks, lambdas, non-locals and my language will partially support dynamic programming. Can anyone list a good introduction to the files found in the source code? I have been poking around the source code for a little bit and there is a lot there. So, I was hoping someone could point me to the "good parts". I am also wondering whether some of the code was generated because I see state transition tables, which I doubt someone built by hand. Any help would be greatly appreciated. It will be cool to see how the interpreter works internally. I am still wonder whether designing the language (going on 4 months now) will be harder than implementing it. Thanks, Travis Parks -- http://mail.python.org/mailman/listinfo/python-list
