Re: Lisp refactoring puzzle
Teemu Likonen wrote: Please don't forget that the whole point of Lisps' (f x) syntax is that code is also Lisp data. It's possible to design other syntaxes that have a similar property. Prolog, for example -- a Prolog program is expressed in terms of Prolog data structures, yet it manages to have things that look like fairly normal function calls and infix expressions. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
Neil Cerutti writes: > On 2011-07-12, Petter Gustad wrote: >> Xah Lee writes: >> >>> it's funny, in all these supposedly modern high-level langs, they >>> don't provide even simple list manipulation functions such as union, >>> intersection, and the like. Not in perl, not in python, not in lisps. >> >> In Common Lisp you have: >> >> CL-USER> (union '(a b c) '(b c d)) >> (A B C D) >> CL-USER> (intersection '(a b c) '(b c d)) >> (C B) > > What's the rationale for providing them? Are the definitions > obvious for collections that a not sets? This seems like a good general question to me, although, I feel like the answer to this question specifically is "yes, obvious enough." A general purpose programming language ought to be general enough to allow expansion, but have enough "obvious" features, that one doesn't have to reinvent the wheel. I recently read somewhere that human languages "differ less in what they allow, and more in what they require" (paraphrase). I have little-to-no computer science expertise, but I sense that in computer languages with Turing equivalency this is exactly true. -- William Clifford -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
* 2011-07-13T10:34:41-04:00 * Terry Reedy wrote: > On 7/13/2011 4:29 AM, Teemu Likonen wrote: >> Please don't forget that the whole point of Lisps' (f x) syntax is >> that code is also Lisp data. > > Thank you for clarifying that. Some Lispers appear to promote the > simple, uniform syntax' as a end in itself (making code=data a side > effect) rather than as a means to accomplish a deeper end. Perhaps, yes. We can't really speak of Lisp's syntax in the same sense as syntax in other languages. >> CL-USER> (let ((lisp (cons 'programmable nil))) >> (setf (rest lisp) lisp)) > > This much looks like Lisp > >> #1=(PROGRAMMABLE . #1#) > > This must be some of the new-fangled Common LIsp stuff I never learned > ;=). It's a way for the Lisp printer to show circular structures. In this case it shows a cons cell. Its first part is the symbol PROGRAMMABLE and the second part is a pointer back to the cons cell itself. So, it's a kind of infinite linked list with the same item PROGRAMMABLE all the time. With Lisp printer settings (setf *print-circle* nil *print-length* 5) the same thing would be printed this way: (PROGRAMMABLE PROGRAMMABLE PROGRAMMABLE PROGRAMMABLE PROGRAMMABLE ...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
On 7/13/2011 4:29 AM, Teemu Likonen wrote: * 2001-01-01T14:11:11-05:00 * Terry Reedy wrote: As a side note, the same principle of expressions matching operations in symmetry suggest that majority of up are quite sensible and not dumb idiots for preferring 'f(x)' to the '(f x)' of Lisp. In a function call, the function has a different role than the arguments, so it is appropriate that it have a different role in the expression. Please don't forget that the whole point of Lisps' (f x) syntax is that code is also Lisp data. Thank you for clarifying that. Some Lispers appear to promote the 'simple, uniform syntax' as a end in itself (making code=data a side effect) rather than as a means to accomplish a deeper end. It's not just a function call with arguments. First, it's literal data (two linked cons cells and symbols) and then the Lisp evaluating model makes it a function call in certain situations. Lisp is CL-USER> (let ((lisp (cons 'programmable nil))) (setf (rest lisp) lisp)) This much looks like Lisp #1=(PROGRAMMABLE . #1#) This must be some of the new-fangled Common LIsp stuff I never learned ;=). programming language and it's totally irrelevant and pointless to say "which syntax someone prefers" because this feature (code being data) is very fundamental principle of the language. You know, it's easy to write programs that write programs. If we remove this feature (i.e., don't talk about Lisp at all) then it's perhaps relevant to discuss about such choices in syntax. You wouldn't want Python arrays have a read and print format "a[b, c]", that is, the first item of the array printed outside []'s. It would be silly. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
On Wednesday, July 13, 2011 05:34:23 AM Terry Reedy did opine: > On 7/12/2011 2:23 PM, gene heskett wrote: > > Now, I hate to mention it Terry, but your clock seems to be about 126 > > months behind the rest of the world. > > Please do not hate to be helpful. It was a bad malfunction perhaps due > to a run-down battery on a machine turned off for two weeks. I will keep > watch to see if it happens again overnight. > > > Does your system not run ntpd by default? > > Is that *nix or Windows? That's a *nix name. I have no clue what winderz might call it as I've only ever had one winderz machine here. My laptop had a copy of XP on it when I bought it years ago, shrunk it to 10Gb and let it live for about 6 months, but its had several fedora's, 2 different MDV installs, and now PCLos on it after discovering the windows bcm4318 driver was a bigger POS than the current linux driver. Everything else here is either 25 years old & running nitros9, or some flavor of *buntu LTS. IOW, all my windows are glass. ;-) > My XP system only checks the net time > automatically once a week and refused to update at first on request > because the dates did not match. Typically windows stupidity. If I click > 'Update from internet', it should believe that I really mean it. Cheers, gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Swap read error. You lose your mind. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
* 2001-01-01T14:11:11-05:00 * Terry Reedy wrote: > As a side note, the same principle of expressions matching operations > in symmetry suggest that majority of up are quite sensible and not > dumb idiots for preferring 'f(x)' to the '(f x)' of Lisp. In a > function call, the function has a different role than the arguments, > so it is appropriate that it have a different role in the expression. Please don't forget that the whole point of Lisps' (f x) syntax is that code is also Lisp data. It's not just a function call with arguments. First, it's literal data (two linked cons cells and symbols) and then the Lisp evaluating model makes it a function call in certain situations. Lisp is CL-USER> (let ((lisp (cons 'programmable nil))) (setf (rest lisp) lisp)) #1=(PROGRAMMABLE . #1#) programming language and it's totally irrelevant and pointless to say "which syntax someone prefers" because this feature (code being data) is very fundamental principle of the language. You know, it's easy to write programs that write programs. If we remove this feature (i.e., don't talk about Lisp at all) then it's perhaps relevant to discuss about such choices in syntax. You wouldn't want Python arrays have a read and print format "a[b, c]", that is, the first item of the array printed outside []'s. It would be silly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
On Jul 13, 9:39 am, Terry Reedy wrote: > On 7/12/2011 2:23 PM, gene heskett wrote: > > > Now, I hate to mention it Terry, but your clock seems to be about 126 > > months behind the rest of the world. > > Please do not hate to be helpful. Ha Ha. Cute one. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
On 7/12/2011 2:23 PM, gene heskett wrote: Now, I hate to mention it Terry, but your clock seems to be about 126 months behind the rest of the world. Please do not hate to be helpful. It was a bad malfunction perhaps due to a run-down battery on a machine turned off for two weeks. I will keep watch to see if it happens again overnight. Does your system not run ntpd by default? Is that *nix or Windows? My XP system only checks the net time automatically once a week and refused to update at first on request because the dates did not match. Typically windows stupidity. If I click 'Update from internet', it should believe that I really mean it. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
In article <4e1cf936.4050...@canterbury.ac.nz>, Gregory Ewing wrote: > Xah Lee wrote: > > they > > don't provide even simple list manipulation functions such as union, > > intersection, and the like. Not in perl, not in python, not in lisps. > > Since 2.5 or so, Python has a built-in set type that > provides these (which is arguably a better place for them > than lists). Set is the best addition to Python since string methods. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
Xah Lee wrote: they don't provide even simple list manipulation functions such as union, intersection, and the like. Not in perl, not in python, not in lisps. Since 2.5 or so, Python has a built-in set type that provides these (which is arguably a better place for them than lists). -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
Neil Cerutti writes:
> What's the rationale for providing them? Are the definitions
> obvious for collections that a not sets?
The rational is to prove that Xah is dumb.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
Petter Gustad wrote: > Xah Lee writes: > > > it's funny, in all these supposedly modern high-level langs, they > > don't provide even simple list manipulation functions such as union, > > intersection, and the like. Not in perl, not in python, not in lisps. > > In Common Lisp you have: > > CL-USER> (union '(a b c) '(b c d)) > (A B C D) > CL-USER> (intersection '(a b c) '(b c d)) > (C B) The order was changed. COBOL Lisp is always mindless. * (union '(2 2 3 4) '(7 7 8 9)) (4 3 2 2 7 7 8 9) The right way (MatzLisp): [2,2,3,4] | [7,7,8,9] ==>[2, 3, 4, 7, 8, 9] -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
On 2011-07-12, Petter Gustad wrote: > Xah Lee writes: > >> it's funny, in all these supposedly modern high-level langs, they >> don't provide even simple list manipulation functions such as union, >> intersection, and the like. Not in perl, not in python, not in lisps. > > In Common Lisp you have: > > CL-USER> (union '(a b c) '(b c d)) > (A B C D) > CL-USER> (intersection '(a b c) '(b c d)) > (C B) What's the rationale for providing them? Are the definitions obvious for collections that a not sets? -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
Xah Lee writes: > it's funny, in all these supposedly modern high-level langs, they > don't provide even simple list manipulation functions such as union, > intersection, and the like. Not in perl, not in python, not in lisps. In Common Lisp you have: CL-USER> (union '(a b c) '(b c d)) (A B C D) CL-USER> (intersection '(a b c) '(b c d)) (C B) //Petter -- .sig removed by request. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
On Tuesday, July 12, 2011 02:08:02 PM Terry Reedy did opine: > On 7/11/2011 11:37 PM, Xah Lee wrote: > > watch the first episode of Douglas Crockford's talk here: > > http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-1 > > The link includes a transcript of the talk, which I read > > I suspect Lee likes Crockford because they both think they are smarter > than everyone else. Writing about Smalltalk, for instance, Crockford > says: > > "I don't know why it is, but a lot of programmers just couldn't get used > to this syntax. [everything is done by sending a message with arguments > to some object] ...So this may be a superior notation, but it was > profoundly rejected. By who? By us, by the programmers, because we > couldn't understand it." > > Actually, I and others see Smalltalk as deeply flawed because its > message passing syntax arbitrarily breaks symmetries in operations. For > instance, in the expression 'a+b', both operands have equivalent roles > in the operation for all normal interpretations of '+'.# On the other > hand, in the expression 'a.extend(b)', where a is a list and b any > iterable and the result is to mutate a but not b, a and b have very > different roles in both the operation and the expression that invokes > it. > > # Under the covers, Python implements 'a+b' as first 'a.__add__(b)', but > it also tries 'b.__radd__(a)' if the first does not work. This > introduces a slight asymmetry in that a gets first say at defining the > meaning of 'a+b', but it does not get the only say. And, as far as I can > presently remember, this asymmetry is never visible with builtins. In > fact, this implementation makes it possible for 'a+b' and 'b+a' to both > give the same answer when a is a builtin and b is a user-class instance. > > Crockford is right that he does not 'know why it is' that not everyone > loves Smalltalk. He should have stopped there instead of projecting his > ignorance on everyone else. > I have my own reasons to hate smalltalk but won't elaborate. > As a side note, the same principle of expressions matching operations in > symmetry suggest that majority of up are quite sensible and not dumb > idiots for preferring 'f(x)' to the '(f x)' of Lisp. In a function call, > the function has a different role than the arguments, so it is > appropriate that it have a different role in the expression. Which should be well documented if one expects the programmers to use it properly. So far, I have only found two languages that are adequately defined and implemented. K&R C, and the now essentially defunct Amiga ARexx. But I should preface that by saying that I have not yet adequately studied python, one of the reasons I joined this list. Specifically, I am trying to install the altera quartus software so I can program one of their DE1 boards, but because the majority of the linux distro's have not kept their repo's zlib packages up to date, one of the quartus imports, gzdirect is on the missing list and I am dead in the water until I install zlib version 1.2.5. I hope this list serves me as a tutorial to fill in the gaps of my python knowledge which at the moment seem too wide to jump over. I hope I can ask intelligent, if newbie, questions occasionally. Now, I hate to mention it Terry, but your clock seems to be about 126 months behind the rest of the world. Does your system not run ntpd by default? The date in the header from your machine is "Mon Jan 1 14:11:11 2001". Cheers, gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) What makes us so bitter against people who outwit us is that they think themselves cleverer than we are. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
On 7/11/2011 11:37 PM, Xah Lee wrote: watch the first episode of Douglas Crockford's talk here: http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-1 The link includes a transcript of the talk, which I read I suspect Lee likes Crockford because they both think they are smarter than everyone else. Writing about Smalltalk, for instance, Crockford says: "I don't know why it is, but a lot of programmers just couldn't get used to this syntax. [everything is done by sending a message with arguments to some object] ...So this may be a superior notation, but it was profoundly rejected. By who? By us, by the programmers, because we couldn't understand it." Actually, I and others see Smalltalk as deeply flawed because its message passing syntax arbitrarily breaks symmetries in operations. For instance, in the expression 'a+b', both operands have equivalent roles in the operation for all normal interpretations of '+'.# On the other hand, in the expression 'a.extend(b)', where a is a list and b any iterable and the result is to mutate a but not b, a and b have very different roles in both the operation and the expression that invokes it. # Under the covers, Python implements 'a+b' as first 'a.__add__(b)', but it also tries 'b.__radd__(a)' if the first does not work. This introduces a slight asymmetry in that a gets first say at defining the meaning of 'a+b', but it does not get the only say. And, as far as I can presently remember, this asymmetry is never visible with builtins. In fact, this implementation makes it possible for 'a+b' and 'b+a' to both give the same answer when a is a builtin and b is a user-class instance. Crockford is right that he does not 'know why it is' that not everyone loves Smalltalk. He should have stopped there instead of projecting his ignorance on everyone else. As a side note, the same principle of expressions matching operations in symmetry suggest that majority of up are quite sensible and not dumb idiots for preferring 'f(x)' to the '(f x)' of Lisp. In a function call, the function has a different role than the arguments, so it is appropriate that it have a different role in the expression. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
I think the problem with so-called "forward looking" or "highest level" languages is that they tend to become domain specific. What Lispers are always saying is construct your own high level language out of your favorite Lisp. Of course no one else will use it then, or even discuss it, unless you have some good buddies. What happens is that high level languages don't end up addressing needs across a large community. The lower down languages can be common denominators across wide swaths of programmers. So we live in this world of roll-your-own on top of the common denominator language. One exception to this is in data base development, where there were some "4th generation" languages that had some success, where the needs of mapping business data models onto data base oriented implementation has had a large community. I guess Mathematica, or MatLab in my environment, also address a community of needs for modelling mathematical algorithms, or for doing analysis of data sets. However both the data base field and the math/arithmetic tool field are examples of domains that are narrower than programming in general. Hence those higher level languages could be seen as domain specific, but for domains with lots of users. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
On Mon, Jul 11, 2011 at 8:37 PM, Xah Lee wrote:
>
> it's funny, in all these supposedly modern high-level langs, they
> don't provide even simple list manipulation functions such as union,
> intersection, and the like. Not in perl, not in python, not in lisps.
> (sure, lib exists, but it's a ride in the wild)
Python has them, but, as they are set functions, not list functions, they
exist for the set type:
Intersection:
>>> set((1, 2, 3)) & set((2,3,4))
set([2, 3])
Union:
>>> set((1, 2, 3)) | set((2,3,4))
set([1, 2, 3, 4])
Symmetric Difference:
>>> set((1, 2, 3)) ^ set((2,3,4))
set([1, 4])
You can also get a non-symmetric difference by calling the difference method
of the set:
>>> set((1, 2, 3)).difference(set((2,3,4)))
set([1])
>>> set((2, 3, 4)).difference(set((1,2,3)))
set([4])
>>>
In Python 3 (2.7?) there is even more syntactical sugar for them: {1, 2, 3}
^ {2, 3, 4} produces {1, 4}.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
Xah Lee wrote: > it's funny, in all these supposedly modern high-level langs, they > don't provide even simple list manipulation functions such as union, > intersection, and the like. Not in perl, not in python, not in lisps. Ruby has them. Intersection: [2,3,5,8] & [0,2,4,6,8] ==>[2, 8] Union: [2,3,5,8] | [0,2,4,6,8] ==>[2, 3, 5, 8, 0, 4, 6] -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
I might argue that it isn't quite right (or politic) to call those who resist technological changes "idiots" so much as to observe they often have goals which cannot wait for the ideal expressive system. People love python not because Python is the platonic programming language, but because it does what they need it to do right now. Ditto (often) for Lisp. It is easy to point out an example of forward thinking languages like Mathematica, and who knows, perhaps it will be the template upon which languages are built in the next 100 years. But if it is, there will be tons of other technologies which _didn't_ make it but which might have seemed equally advanced. Early adoption is always a risk, and few people want to deal with it when technology exists now that solves their problem now, however sub-optimally. That is hardly idiotic, Xah. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
On 7/11/2011 11:37 PM, Xah Lee wrote: it's funny, in all these supposedly modern high-level langs, they don't provide even simple list manipulation functions such as union, intersection, and the like. Not in perl, not in python, Union and intersection are set operations, not list operations. Python has had a set type with a full set of set operations for several years. It has list concatenation, which is the list equivalent of union. It has lots of other useful list operations. > Mathematica has Union, Intersection, and a host of others > some 20 years ago, and today it has a complete set of combinatorics > functions as *builtin* functions Python has the basic combinatoric function in the itertools module, though they are not used much. If Mathematica has Catalan sequences builtin, I wonder how much they are used. Since Python is free, in both meanings, it does not have paid people sitting around writing things to pad numbers to justify a $2k price tag. On the other hand, lots of people have added and made available lots of good add-ons. Mathematica should probably be most fairly compared with Python+numpy+scipy and maybe a few other things. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
2011-07-11 On Jul 11, 6:51 am, jvt wrote: > I might as well toss my two cents in here. Xah, I don't believe that > the functional programming idiom demands that we construct our entire > program out of compositions and other combinators without ever naming > anything. That is much more the province of so-called "function- > level" programming languages like APL/J and to a more limited extent > concatenative languages where data (but not code) is mostly left > without names. > > Functional programming, in my mind, is about identifying reproducibly > useful abstractions, _naming them_, and constructing other > abstractions from them. Your piece of code above probably needs to be > factored out into named pieces so that the composition is more > sensible. If a piece of code isn't comprehensible, it might be > because it isn't using the right abstractions in the right way, not > because the notion of functional programming is itself problematic. > > One might instead provide a nightmare nest of procedural code and > claim that procedural programming has problems. Of course, this > particular kind of problem might be less common in procedural code, > since it depends heavily on naming and side effecting values, but it > isn't hard to find procedural code with a long list of operations and > namings wherein the chose names are random or otherwise unrelated to > the problem domain. My adviser in grad school used to name variables > after pieces of furniture in dutch, but that didn't cause me to > impeach the _notion_ of procedural code. hi jvt, of course, you are right. But i wasn't criticising functional programing in anyway. was just putting out my tale as a caution, to those of us — e.g. academic scheme lispers and haskell types — who are perpetually mangling their code for the ultimate elegant constructs. but speaking on this now... as you guys may know, i was a naive master of Mathematica while being absolute illiterate in computer science or any other lang. (see 〈Xah Lee's Computing Experience (Impression Of Lisp from Mathematica)〉 @ http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html ) When i didn't know anything about lisp, i thought lisp would be similar, or even better, as a highlevel lang in comparison to Mathematica. In retrospect now, i was totally wrong. lisp, or scheme lisp, is a magnitude more highlevel in comparison to C or C derivatives such as C++, Java. However, in comparison to Mathematica, it's one magnitude low level. (it pains me to see lisp experts here talking about cons and macros all day, even bigshot names such as one Paul Graham and in lisp books praising lisp macros. Quite ridiculous.) over the years, i had curiosity whether perhaps ML/OCaml, Haskell, would be equivalent high-level as Mathematica as i thought. Unfortunately, my study of them didn't went far. (best result is my incomplete 〈OCaml Tutorial〉 @ http://xahlee.org/ocaml/ocaml.html ) Am not qualified to comment on this, but i think that even Haskell, OCaml, are still quite low in comparison to Mathematica. it's funny, in all these supposedly modern high-level langs, they don't provide even simple list manipulation functions such as union, intersection, and the like. Not in perl, not in python, not in lisps. (sure, lib exists, but it's a ride in the wild) It's really exceedingly curious to me. And it seems that lang authors or its users, have all sorts of execuse or debate about whether those should be builtin if you force them to answer. (i.e. they don't get it) While, we see here regularly questions about implementing union etc with follow up of wild answers and re-invention the thousandth time. Of course, Mathematica has Union, Intersection, and a host of others some 20 years ago, and today it has a complete set of combinatorics functions as *builtin* functions (as opposed to add-on libs of second- rate quality). (this is not a question. No need to suggest some possible reasons why lang might not want to have a whole set of list manipulation builtin. You (the lisper/python/perl regulars and other lang fans) are a complete idiot, that's what i'm saying. COMPLETE IDIOT. (actually, this is not surprising, since genius and true thinkers are rare and few. (such as myself. As they say, beyond the times))) i also wondered, if Mathematica is truely a magnitude higher level than lisp, why we don't see any computer scientists talk about it? (of course there are, but almost non-existant in comparison to, say, academic publications on Scheme, Haskell, even Java) I think the reason is social, again. Proprietary langs isn't a revue of academicians, together with the fact that Stephen Wolfram goes about as if the entire science of computer science comprises of himself. Want Mathematica? Pay $2k+. recently i spent several days studying and watching a talk by Douglas Crockford. it is incredible. He went thru history, and explained, how it is the very people in computing community who laughed and stifled all th
