Re: traverse a list two elements at a time?
  Home FAQ Contact Sign in
comp.lang.functional only
 
Advanced search
POPULAR GROUPS

more...

 Up
Re: traverse a list two elements at a time?         

Group: comp.lang.functional · Group Profile
Author: John Thingstad
Date: Jul 15, 2008 11:18

På Sat, 12 Jul 2008 23:53:21 +0200, skrev xahlee@gmail.com
gmail.com>:
> On Jul 12, 6:55 am, Joost Kremers yahoo.com> wrote:
>> xah...@gmail.com wrote:
>>> In Mathematica, you can just partition it first. e.g.
>>
>>> mylist = {1, 2, 3, 4, 5, 6};
>>> Map[First@# &, Partition[mylist, 2]]
>>
>>> returns {1,3,5}
>>
>> which, however, is not what i was interested in...
>
> Of course. I know.
>
> I post to fuck with the Common Lisp fuckheads that slaves here.
>
> Why? Because, since i'm heavily interested in functional programing,
> in lisp, often i see well known problems in Lisp yet that could be
> fixed yet the regular Common Lisping old hats shut out any possible
> improvement the moment they see it. (note to readers: i'm not just
> interested in functional programing, i'm the world's top expert, far
> beyond the common lisp fuckheads here that has some 10 years of
> experience programing in CL.)
>
> As you can see in this thread, a simple, truely trivial problem,
> practically trivial in the most basic sense of that word, as exhibited
> in the solution in Mathematica, took a lot Common Lisper discussions
> about it. This happens very frequently here, most painful to the mind
> because a lot of the problem is pure problems on list manipulation.
> (suppose that LISP stands for LISt Processing. Fuck cons, fuck you car
> & cdr, and mostly, fuck you Common Lispers because if you didn't die
> these problems'd fixed long ago.)
>
> I myself am particular pissed because i have strong practical interest
> in emacs lisp. Am doing increasingly more code in elisp. The xyz
> fundamental problems that could be easily fixed technically ... etc
> pisses me off. Of course no lang can be perfect... but many obvious
> fixable problems i constantly see the motherfucking Lisper regulars
> here kill any seed for improvement of the situation.
>
> Sure... you or other might start to argue blab blab, blab blab, about
> being opinions or whatnot. I've read 10 years of comp.lang.lisp. I've
> seen, practically speaking, it all.
>
> I'm beginning to realize, the situation is actually a common pattern
> in human social groups. I haven't exactly narrowed down on a name or
> something, but basically when a human group is established for a
> while, it's political structures may resist improvements that calls
> for change. Possibly, from a political science's point of view, the
> reason is that the change harms the identity or integrity of the
> group.
>
> Further readings. (a few are simple rants)
>
> How Purely Nested Notation Limits The Language's Utility
> http://xahlee.org/UnixResource_dir/writ/notations.html
>
> A Text Editor Feature: Syntax Tree Walk
> http://xahlee.org/emacs/syntax_tree_walk.html
>
> A Simple Lisp Code Formatter
> http://xahlee.org/emacs/lisp_formatter.html
>
> --
>
> Lisp's List Problem
> http://xahlee.org/emacs/lisp_list_problem.html
>
> My First Encounter And Impression Of Lisp
> http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html
>
> --
> Lisp Needs A Logo
> http://xahlee.org/UnixResource_dir/writ/logo_lisp.html
>
> The Jargon “Lisp1” vs “Lisp2”
> http://xahlee.org/emacs/lisp1_vs_lisp2.html
>
> --------------------------------------
>
> since i'm writing... n i wrote a lot in the past on diverse issues
> scattered in various essays... i'll sum some fundamental problems that
> are repeated in the above:
>
> • Lisp relies on a regular nested syntax. However, the lisp syntax has
> several irregularities, that reduces such syntax's power and confuses
> the language semantics. (i.e. those ' # ; chars.) (and whenever i
> tried to get some technical answer about this to clarify at least my
> own understanding, the lisp fuckheads prevents it)
>
> • Lisp's irregular syntax those “' # ;” things, are practically
> confusing and made the lang less powerful. i.e. in elisp, there's no
> form for matching comments (and consequently no nested comment)... The
> reliance on eol chars as part of the syntax semantics is one of the
> major fuckup to the power of pure nested syntax.
>
> • Lisp relies on a regular nested syntax. Because of such regularity
> of the syntax, it has very powerful consequences, at least
> theoretically. (and practically, lispers realized just one: the lisp
> macros) For example, since the syntax is regular, one could easily
> have alternative, easier to read syntaxes as a layer. (the concept is
> somewhat known in early lisp as M-expression) Mathematica took this
> advantage (probably independent of lisp's influence), so that you
> really have easy to read syntax, yet fully retain the regular form
> advantages. Lisp, on the other hand, such alternative syntax has been
> done and tried here and there in various forms or langs, but for some
> social reasons, never caught on due to many largely social reason.
> Part of these reasons is a political one. (thanks to, in part, the
> Common Lisp fuckheads that slaves here.)
>
> • Lisp relies on a regular nested syntax. One of the power of such
> pure syntax is that you could build up layers on top of it, so that
> the source code can function as markup of conventional mathematical
> notations (i.e. LaTeX) yet lose practical nothing. This is done in
> Mathematica in ~1996 with release of Mathematica version 3.
>
> • one of the advantage of pure fully functional syntax is that a
> program should never, ever need to format his source code (i.e.
> pressing tabs, returns) in coding, and save the hundreds hours of
> labor, guides, tutorials, advices, publications, editor tools, on
> what's come to known as “coding style conventions”, because the editor
> can trivially reformat the source code on the fly based on a simple
> lexical scan. This is done in Mathematica 3 ~1996. In coding elisp,
> i'm pained to no ends by the manual process of formatting lisp code.
> The lisp community, established a particular way of formatting lisp
> code as exhibited in emacs's lisp modes and written guides in
> conventions. Such “official” convention further erode any possibility
> of fixing this problem.
>
> The above are some of the damages lispers has done to themselfs, with
> respect to its pure functional syntax. The other major one is the cons
> business.
>
> • Lisp at core is based on functional programing on lists. This is
> very powerful, however, because lisp for historical reasons based on
> its list on the hard-ware oriented “cons” cell, this fundamentally
> fucked up almost all the advantages of power of list processing. (for
> example, the very need of you, a professional lisp programer, having
> to ask about a extremely trivial problem of manipulating list, and as
> seen in this thread, various lisp expert has to discuss it so
> stupiditly and complexity about such a trivial problem)
>
> Lisp being historically based the cons for like 2 or 3 decades. The
> cons (and cdr, car, caadar etc) are fundamentally rooted in the lisp
> langs, is thus not something that can be easily fixed. Quite
> unfortunate. However, this situation could be improved. But, whenever
> i discuss this, you can see that the lispers slaves here, their
> mentality, prevents any possible improvement. (in general, this is
> because, lispers usually do not have serious experience or investment
> in other functional langs, such as Mathematica, Haskell, etc.)
>
> One of the myth that are quickly embedded into budding lispers, is
> that cons are powerful. Powerful my ass. It is powerful in the sense
> any assembly lang is powerful. Lisp's cons is perhaps the greatest
> fuck up in the history of computer languages.
>
> --------------------
>
> Mathematica today sells for over 2 thousands dollars. It's sales
> record, throughout its history, is probably more than ALL commercial
> lisps combined. Such a illuminating social fact, in not known in lisp
> communities. These fuckheads thinks that lisp is more popular.
>
> 10 years ago, in the dot come days (~1998), where Java, Javascript,
> Perl are screaming the rounds. It was my opinion, that lisp will
> inevitably become popular in the future, simply due to its inherent
> superior design, simplicity, flexibility, power, whatever its existing
> problems may be. Now i don't think that'll ever happen as is. Because,
> due to the tremendous technological advances, in particular in
> communication (i.e. the internet and its consequences, e.g. Wikipedia,
> youtube, youporn, social networks sites, Instant chat, etc) computer
> languages are proliferating like never before. (i.e. because the
> abundance of tools, libraries, parsers, existance of infrastructure)
> New langs, basically will have all the advantages of lisps or lisp's
> fundamental concepts or principles. I see that, perhaps in the next
> decade, as communication technologies further hurl us forward, the
> proliferation of langs will reduce to a trend of consolidation (e.g.
> fueled by virtual machines such as Microsoft's .NET. (and, btw, the
> breaking of social taboo of cross communication led by Xah Lee)).
>
> There is one slight hope for Lisp the lang as we understood it, and
> that is emacs lisp. Due to, it being deeply rooted in the industry as
> a powerful text editor, and the embedded lisp have major practical
> impact in getting people to know lisp and also actually use it for
> practical need. (this satisfying prospect is however mar'd by the tech
> geekers. e.g. the Common Lispers, and Scheme Lispers, perennially
> inject snide and sneer at emacs lisp that harms its progress, while
> the fucking emacs priests, want to coffin emacs perpetually in its
> 1980s UI and terminologies.)
>
> Xah
> ∑ http://xahlee.org/
>
> ☄

You don't need to change the language you need to write the function
partion.

(defun partion (list parts)
(assert (= (rem (length list) parts) 0))
(loop repeat (/ (length list) parts) collect
(loop repeat parts collect (first list) do (pop list))))

--------------
John Thingstad
no comments
diggit! del.icio.us! reddit!