M Jared Finder wrote: > I agree that there is minimal additional expresive power; everything > that could be done with this new syntax could be done by just putting in > a funcall as the car of the form. That's why I mentioned it only > offhand. It's just that the special treatment of ((lambda ...) ...) > forms irks me. Why is the special treatment there, and why only for > lambda forms? Does anyone make use of it?
I think it's mainly a heritage from the past. I vaguely recall that it can be handy for macros for generating code, but I don't remember any details.
Matthias <n...@spam.pls> writes: > Greg Menke <gregm-n...@toadmail.com> writes: > > > To Python users their implementation (the one they chose to use) > > > serves the function of a standard: If they have a question regarding > > > the language, they type something into their interpreter.
> > No it doesn't serve as a "standard", its an example.
> I'm not participating in this game over words. If you define > "standard" as "a document, specifying..." then say so.
I define "standard" as a document, then.
> > > While that may not be as cool as searching in a typically > > > incomprehensible super-long document Python fans will argue: The worst > > > thing that could happen to Python is an ANSI standard. Because this > > > would slow down the pace of its development to that of other > > > ANSI-standardized languages.
> > How in the hell do you expect to document what must, may, must not and > > may not be in a language without a long document? If Python did become > > ANSI standardized, the language syntax, grammar and behavior would be > > standard, but it would probably not (and should not) standardize the > > library bindings. Same as Common Lisp & C.
> Because Python without libs is pointless. More pointless than CL or C.
C without libraries is quite useful; bootloaders, device drivers, etc.. CL without libraries is standard Common Lisp and covers a quite a lot of functionality.
> > I don't write throwaway apps, the stuff I work on has to work and be > > portable without major or even significant revision to evolving hardware > > architectures for 5 or 10 years- maybe longer depending on circumstance. > > I can't afford to be saddled with a language that evolves ever further > > past me year after year. And by "evolve", I mean object systems change, > > syntactical features come and go- I do not mean new libraries come in > > and deprecated ones leave.
> Then you should not use Python, Java, Perl, etc. With these > requirements, your best choice here would be a dead language that > doesn't change any more.
So C is dead?
> > I can write an app in Lispworks on an x86 Linux box, take the source and > > run it on CMUCL on a SPARC or CLISP on a Windows machine with no > > changes- no byte order issues, no byzantine ifdefs or makefile > > craziness- its all working off the ANSI Common Lisp standard.
> None of the applications I've used today would work with Ansi CL _only_. > Each would require some extension.
Thats true of the ones I've used today as well. OTOH, I know where the extensions are- I also have a number of apps that don't.
> > With a bit of planning & additional work, I can switch between > > architectures and compilers in C too. THAT is what a standard gives > > you.
> These are the benefits of a standard. There are also costs involved. > The indirect cost, that you have to port & maintain every lib to/in > every implementation, is probably the most significant one. Here the > Python/Java/etc. model shines.
Clearly there are costs- sometimes quite large. But there are also costs for non-standardized (spec'ed and/or paper documented type of standard) solutions. The relative magnitude of the two costs are also going to be vary widely.
> > > In my opinion, the best thing about Python is its libraries. It would > > > be an insanely huge and an insanely useless task to try to specify > > > them in a formal standard. The same holds for Java, Perl, Ruby, etc.
> > I agree with you there. In the same way it would be a mess to document > > that sort of thing for Common Lisp or C.
> I think it would be terrible for the Python community to have 12 > different implementations of language syntax and semantics, each with > a different set of libraries supported.
In the same way its terrible for C/C++?
> For C it's not a problem, since C bindings are the de facto standard > (meaning #3) anyway. CL decided to pay the costs, i.e., less/more > expensive libraries for any given implementation.
Its not a problem for Common Lisp either. If you want to add in a library, do so- same as C. The procedures for doing so do vary between implementations- which is a bummer- but they vary to some extent for C/C++ as well.
If you settle on a single Common Lisp implementation, then you don't have to deal with porting the library binding- just like Python.
Pascal Costanza wrote: > The devil is in the details. A stackless implementation that exposes > some of its advantages may have interactions with other features. A Lisp > implemented on top of a JVM will very likely have problems if it wants > to integrate with the JVM well. For example, some Scheme implementations > on top of a JVM restrict their strings to be immutable, although the > Scheme specifications say that they should be mutable. (A specification > - thanks to Duane for suggesting the better term - allows you to talk > about such deviations while an implemtation doesn't.)
Sure, a spec is better.
But to the example: I can see no reason why strings on the JVM should be immutable [1]. Anyway, this is a deviation from the spec or desired implementation (and would be one even if considered language in this case were Python).
[1]: The usual way to do this would be to not use Java strings, but define a SchemeString class that allows all Scheme string methods. Do you have a pointer to why some Schemes don't do that?
In comp.lang.lisp James Graves <ansi...@typhoon.xnet.com> wrote:
> GCL compiles to C first.
Which is funny, because GCC compiles to s-expressions first, in the form of Register Transfer Language.
A quote from _Using and Porting GCC_:
RTL is inspired by Lisp lists. It has both an internal form, made up of structures that point at other structures, and a textual form that is used in the machine description and in printed debugging dumps. The textual form uses nested parentheses to indicate the pointers in the internal form.
>> The devil is in the details. A stackless implementation that exposes >> some of its advantages may have interactions with other features. A >> Lisp implemented on top of a JVM will very likely have problems if it >> wants to integrate with the JVM well. For example, some Scheme >> implementations on top of a JVM restrict their strings to be >> immutable, although the Scheme specifications say that they should be >> mutable. (A specification - thanks to Duane for suggesting the better >> term - allows you to talk about such deviations while an implemtation >> doesn't.)
> Sure, a spec is better.
> But to the example: I can see no reason why strings on the JVM should be > immutable [1]. Anyway, this is a deviation from the spec or desired > implementation (and would be one even if considered language in this > case were Python).
> [1]: The usual way to do this would be to not use Java strings, but > define a SchemeString class that allows all Scheme string methods. Do > you have a pointer to why some Schemes don't do that?
Sorry, not at hand, but the reason is just because they want to interoperate with existing Java libraries, probably without loosing too much efficiency.
> These are good arguments, but miss the crucial point that many of us > work in environments that are dictated by PHB's. So we use Linux (and > other *NIX's) where possible, and then install cygwin and ntemacs and > other OSS tools on MS Win** systems when forced to use that > environment.
Yes, but Brandon had previously explicitly disregarded cygwin as it's not the windows way. He seems to want Open Source projects that take advantage of the peculiar advantages (there are some) and account for the particular quirks of the windows environment in a windowsy way, not change windows into a clunky unixoid with cygwin. Your goal or my goal might be to abstract away from windows as much as possible, I suspect (but do not claim to peak for him!) that brandon would like to see OSS projects that make maximal use of windows-only features like e.g. Direct3D, rather than minimal.
Back in the day, I sometimes felt similar about open source on the Amiga platform: the vast bulk just used ixemul (conceptually similar to cygwin, allowing running GNU toolchain on top of the Amiga pseudomicrokernel), disregarding the peculiar advantages of the Amiga platform (e.g. GNU clisp being an interesting exception, as far as I recall, with its native support for various Amiga-y things. But GNU clisp is german, and amiga had much higher penetration in europe than the US, so presumably there were amiga people maintaining the support)
I don't think that demanding someone else do the hard work of integrating for your favorite platform is reasonable: If Brandon wants windows makefiles for something, let him write them. If Brandon wants extensive changes to an OSS projects source tree to account for windowsisms (like prefixing every bloody function with some goofy pragma), let him maintain a patch set, ask for his patches to go into the main tree (or maintain a windows friendly-fork). (In fairness, AFAIK he has done some of that sort of thing in the past!).
> before > anyone uses C# and the CLR "for their own sake" independent of .NET.
Well, the Mono (of "let's name our project after the slang for a miserable infectious disease!" fame) project has done some vaguely interesting stuff, but do run the risk of falling foul of U.S. (and soon the EU if the bureaucrats are stupid enough to allow them) software patents held by Microsoft.
Most prominent of Mono-using projects is probably Beagle, very loosely the GNOME+Linux/BSD challenge to Microsoft WinFS (as far as I can see, they're further along than Microsoft have publically demonstrated WinFS to be, too).
"Brandon J. Van Every" <try_vanevery_at_mycompanyn...@yahoo.com> writes:
> Lisp has no de facto standard.
Perhaps true for "Lisp" in general, but "Common Lisp" has a de jure standard which, since it is widely implemented is also a de facto standard.
Just because the standard doesn't cover everything doesn't make it any less a standard. Python presumably doesn't have a standard xml parser, does it? Or a standard game engine?
-- Thomas A. Russ, USC/Information Sciences Institute
Greg Menke <gregm-n...@toadmail.com> writes: > > > > portable without major or even significant revision to evolving hardware > > > architectures for 5 or 10 years- maybe longer depending on circumstance. > > > I can't afford to be saddled with a language that evolves ever further > > > past me year after year. And by "evolve", I mean object systems change, > > > syntactical features come and go- I do not mean new libraries come in > > > and deprecated ones leave.
> > Then you should not use Python, Java, Perl, etc. With these > > requirements, your best choice here would be a dead language that > > doesn't change any more.
> So C is dead?
Please. It just wouldn't be your best choice.
Esp. the current ANSI standard C'99 would be a bad choice as it's still not so widely implemented and it's not clear when it will be and how long it'll be supported. Same holds for C++. Its ANSI standard changes every 5 years.
"Standard" does not guarantee everlasting compatibility. Though with CL you should be on the save side...
> > > With a bit of planning & additional work, I can switch between > > > architectures and compilers in C too. THAT is what a standard gives > > > you.
> > These are the benefits of a standard. There are also costs involved. > > The indirect cost, that you have to port & maintain every lib to/in > > every implementation, is probably the most significant one. Here the > > Python/Java/etc. model shines.
> Clearly there are costs- sometimes quite large. But there are also > costs for non-standardized (spec'ed and/or paper documented type of > standard) solutions. The relative magnitude of the two costs are > also going to be vary widely.
That was the whole and single point I was trying to make. (Well this, and that there are different meanings for "standard".)
> > I think it would be terrible for the Python community to have 12 > > different implementations of language syntax and semantics, each with > > a different set of libraries supported.
> In the same way its terrible for C/C++?
Much worse since integrating into C/C++ is at essentially a recompile/ relink. C bindings are omnipresent:
> > For C it's not a problem, since C bindings are the de facto standard > > (meaning #3) anyway. CL decided to pay the costs, i.e., less/more > > expensive libraries for any given implementation.
> Its not a problem for Common Lisp either. If you want to add in a > library, do so- same as C.
I don't want to. I just want to have the libs. I don't want to do the whole work myself. In fact, if it's something small I'm much more likely to quickly hack it in Python.
And again: There's no work involved integrating a lib with C. Libs already come with a C interface. Now, operating system issues are more annoying to deal with. But that's the price to pay when you work so close to the metal.
> The procedures for doing so do vary between > implementations- which is a bummer- but they vary to some extent for > C/C++ as well.
> If you settle on a single Common Lisp implementation, then you don't > have to deal with porting the library binding- just like Python.
Exactly. In fact, I _do_ use only one CL implementation. That's why I don't care overly for the standard. I'm still paying the cost that I cannot benefit from the nice work people do for these other CL implementations I happen not to use.
Then: The CL spec is an interesting read. Kind of cool. Others do use multiple implementations and love the slow pace of changes. So well, no deal. Just, please, don't try to bash the others for not having a standard. They just made different trade-offs.
According to Brandon J. Van Every <try_vanevery_at_mycompanyn...@yahoo.com>:
> Greg Menke wrote: > > Python is an implementation, not a standard. Once there's an ANSI or > > IEEE spec for Python, THEN its a standard.
> No, it is a "de facto" standard *NOW*. Just because you have personal > issues with de facto standards...
CPython is the de facto standard implementation of Python. Python doesn't have a standard because it is defined by the implementation known as CPython, not by some formal specification.
Jython and other Python implementations start from CPython's behaviour not some formal specification.
But yeah, nowadays there are the PEPs, so Python is getting specified.
> Because Python without libs is pointless. More pointless than CL or C.
One counter example: Most of the Python programming I do these days are 50 liner-type sysadmin or code/config generation scripts and AFAP I avoid using anything that doesn't come as part of the standard installation.
Since you don't play word games I trust you aren't going to argue that the stuff that comes with the standard installation is known as the "standard library" and therefore I'm still not "without libs".
michele.simion...@gmail.com writes: > I think Guido *on purpose* remove certain functionalities since he > wants other idioms to be used instead (for instance there is no > "case" statement, since you should dispatch on a dictionary
And this approach is extremely weak, in the absence of fully-fledged anonymous functions (or code blocks).
> More seriously, I think we are spending a disproportiate amount of > effort discussing a not-so-critical point. I can leave with or > without lambda, and there are still many other things that work > well, so lets go on!
> According to Matthias <n...@spam.pls>: > > Because Python without libs is pointless. More pointless than CL or C.
> One counter example: Most of the Python programming I do these days > are 50 liner-type sysadmin or code/config generation scripts and AFAP I > avoid using anything that doesn't come as part of the standard > installation.
> Since you don't play word games I trust you aren't going to argue that the > stuff that comes with the standard installation is known as the "standard > library" and therefore I'm still not "without libs".
Ulrich Hobelmann <u.hobelm...@web.de> writes: > Brandon J. Van Every wrote: > > I feel that people here are very lazy about inquiring into the actual > > process by which Python is developed, including myself. In an effort to > > somewhat alleviate this laziness and apathy among Lispers, I offer the > > following URL: http://www.python.org/peps/
> From that page: > The Zen of Python
> Beautiful is better than ugly. > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > Flat is better than nested. > Sparse is better than dense. > Readability counts. > Special cases aren't special enough to break the rules. > Although practicality beats purity. > Errors should never pass silently. > Unless explicitly silenced. > In the face of ambiguity, refuse the temptation to guess. > There should be one-- and preferably only one --obvious way to do it. > Although that way may not be obvious at first unless you're Dutch. > Now is better than never. > Although never is often better than *right* now. > If the implementation is hard to explain, it's a bad idea. > If the implementation is easy to explain, it may be a good idea. > Namespaces are one honking great idea -- let's do more of those!
> Reading this, who would have guessed they talk of *Python*?
Python people? IMO, the real odd bit about the above is that they are all subjective. I'm sure most any (excluding perhaps C++) language community would claim most if not all of those for their own. Which, come to think of it, was maybe what your point was.
> > As for the original point of this thread, the point is the Python world is > > far more unified than the Lisp world, because it is driven by a de facto
This I don't buy. And even if one did buy it, why wouldn't, say the cmucl world, be just as "unified"?
/Jon
-- 'j' - a n t h o n y at romeo/charley/november com
Ulrich Hobelmann <u.hobelm...@web.de> writes: > Still, people are looking to Python as a standard. If something > doesn't work in Jython as it does in Python, Python is treated as a > standard definition.
I'm sure you're right about that - doesn't mean it makes any sense. The logical implication here is that Python (the "de facto" one), _can't_ have any bugs in it. How could it? By definition whatever it does is the _correct standard behavior_. Frankly, to me, that makes it much closer to _insane_ than _standard_.
/Jon
-- 'j' - a n t h o n y at romeo/charley/november com
> What's the loss received from removing lambda? Nothing. > But you seem to give lambdas more 'power' than they deserve, and this > probably will eventually be your python ignorance. > Python is easy to use. But it's made for 'adults who know what they are > doing',
I believe this is just an excellent place to quote Kent M. Pitman. He generally argues that one should not denigrate somebody on the basis that one does not see the value that the other sees in something.
Some people see value in lambda in Python. If you don't, there not more value in your opinion than in your opponents. Just accept it as is.
KMP's lesson is: the ignorance is more likely to be on the side of the one who does not see.
Regards Jorg Hohle Telekom/T-Systems Technology Center
> "Brandon J. Van Every" <try_vanevery_at_mycompanyn...@yahoo.com> writes:
> > Lisp has no de facto standard.
> Perhaps true for "Lisp" in general, but "Common Lisp" has a de jure > standard which, since it is widely implemented is also a de facto > standard.
> Just because the standard doesn't cover everything doesn't make it any > less a standard. Python presumably doesn't have a standard xml parser, > does it? Or a standard game engine?
Well, to be blunt, Python doesn't have a Standard at all.
jayessay wrote: >> From that page: >>The Zen of Python
>> [...] >>Reading this, who would have guessed they talk of *Python*?
> Python people? IMO, the real odd bit about the above is that they are > all subjective. I'm sure most any (excluding perhaps C++) language > community would claim most if not all of those for their own. Which, > come to think of it, was maybe what your point was.
Yes.
>>>As for the original point of this thread, the point is the Python world is >>>far more unified than the Lisp world, because it is driven by a de facto
> This I don't buy. And even if one did buy it, why wouldn't, say the > cmucl world, be just as "unified"?
You could say it is, but the Python (language, not the Lisp compiler ;) ) world is probably far bigger. Of course any single programmer is unified in him/herself :)
Joerg Hoehle <hoe...@users.sourceforge.net> writes: > dial#####$$NOSPAM##$#...@gmail.com (Valentino Volonghi aka Dialtone) writes: > > What's the loss received from removing lambda? Nothing.
> > But you seem to give lambdas more 'power' than they deserve, and this > > probably will eventually be your python ignorance.
> > Python is easy to use. But it's made for 'adults who know what they are > > doing',
> I believe this is just an excellent place to quote Kent M. Pitman. He > generally argues that one should not denigrate somebody on the basis > that one does not see the value that the other sees in something.
> Some people see value in lambda in Python. If you don't, there not > more value in your opinion than in your opponents. Just accept it as is.
> KMP's lesson is: the ignorance is more likely to be on the side of the > one who does not see.
Anyway, perhaps it's a good thing that Python deletes lambda.
Then the programmers who want lambda will come to lisp civilization instead of staying in the barbarous lands of Python. :-)
We should move to remove cpp macros in C and C++...
-- __Pascal Bourguignon__ http://www.informatimago.com/ The rule for today: Touch my tail, I shred your hand. New rule tomorrow.
On Fri, 18 Mar 2005 13:22:07 -0600, Ulrich Hobelmann wrote: > ) world is probably far bigger. Of course any single programmer is > unified in him/herself :)
But only over relatively short periods of time. As I'm programming now, I'm definitely not unified in myself of 5 years ago...
> > Still, people are looking to Python as a standard. If something > > doesn't work in Jython as it does in Python, Python is treated as a > > standard definition.
> I'm sure you're right about that - doesn't mean it makes any sense. > The logical implication here is that Python (the "de facto" one), > _can't_ have any bugs in it. How could it? By definition whatever it > does is the _correct standard behavior_. Frankly, to me, that makes > it much closer to _insane_ than _standard_.
Poppycock. If you find a bug, you find a bug. There are no doubt some edge cases where the behavior is questionable, and you as an implementor may not know whether the demonstrated behavior of the de facto implementation is as intended or an actual bug.
But, that's what the lists and such are for. Thankfully you have at your disposal the implementor(s) of the de facto and they can clarify any odd behavior that you encounter.
There are ambiguous gray areas in any complicated standard that suffer this same problem.
Will Hartung wrote: > But, that's what the lists and such are for. Thankfully you have at your > disposal the implementor(s) of the de facto and they can clarify any odd > behavior that you encounter.
> There are ambiguous gray areas in any complicated standard that suffer this > same problem.
Exactly. How do you know if something in a standard isn't a bug? It's the some solution, ask the people who are into the language.
Matthias wrote: > Exactly. Seconds to minutes for C++ and several hours for Python. I > don't have the timings at my fingertips, but I did do them and the > 1000 is accurate.
We are doing a major project that involves parsing some 2000-7000 hierarchical messages per second. We used the two-language approach, Python and C, and re-wrote the speed-critical portions (the core parsers) in C. The speed difference between optimized Python and optimized C is 5x.
The C people aren't even ours, and suffice to say I am confident that they are outstanding C programmers. They are using specialized libraries that may be slow; not sure about that. But if my assumptions are true (namely that the C programmers involved are good and the libraries aren't terrible) the small speed difference in the case I describe suggests either that you are a brilliant C++ programmer, a so-so Python programmer, or both. I suspect it's both!
