hi all,
i know i can traverse a list with dolist, or use mapcar and family if i
want to traverse multiple lists simultaneously. however, what if i want to
traverse one single list, but two elements at a time?
basically, what i want to do is to take a list of the form (a b c d e f)
and transform it into a list of the form ((a b) (c d) (e f)). i've come up
with a do-loop that does this, but i have this feeling there must be a
better way...
TIA
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
On Jul 11, 5:50 pm, Joost Kremers <············@yahoo.com> wrote:
> hi all,
>
> i know i can traverse a list with dolist, or use mapcar and family if i
> want to traverse multiple lists simultaneously. however, what if i want to
> traverse one single list, but two elements at a time?
>
> basically, what i want to do is to take a list of the form (a b c d e f)
> and transform it into a list of the form ((a b) (c d) (e f)). i've come up
> with a do-loop that does this, but i have this feeling there must be a
> better way...
(loop for (x y) on '(a b d c e f) by #'cddr collect (list x y))
Cheers
--
Marco
Marco Antoniotti wrote:
> (loop for (x y) on '(a b d c e f) by #'cddr collect (list x y))
thanks. i didn't think of using loop for this. though i doubt i'd have
found the right incantation easily, because i wasn't aware that lists could
be destructured in this way...
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
On Fri, 11 Jul 2008 12:29:26 -0700 (PDT), Grant Rettke <·······@gmail.com> said:
| (defun 2elems (list)
| (if (null list) nil
| (cons (list (car list) (cadr list)) (2elems (cddr list)))))
While this is indeed elegant, alas, it would have trouble with long
lists (unless the compiler is Really Smart...). It can be rewritten
to avoid that trouble, of course, but at the price of significantly
reduced elegance...
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Kent M Pitman
Subject: Re: traverse a list two elements at a time?
Date:
Message-ID: <uskufp0ea.fsf@nhplace.com>
Vassil Nikolov <···············@pobox.com> writes:
> On Fri, 11 Jul 2008 12:29:26 -0700 (PDT),
> Grant Rettke <·······@gmail.com> said:
>
> | (defun 2elems (list)
> | (if (null list) nil
> | (cons (list (car list) (cadr list)) (2elems (cddr list)))))
>
> While this is indeed elegant, alas, it would have trouble with long
> lists (unless the compiler is Really Smart...). It can be rewritten
> to avoid that trouble, of course, but at the price of significantly
> reduced elegance...
>
> ---Vassil.
Significantly reduced? Hmm...
Before people were happier with LOOP, we used to write it like this,
except I've thrown in a funcall at no extra cost.
(defun map-pairs (f list)
(do ((list list (cddr list))
(result '() (cons (funcall f (first list) (second list)) result)))
((null list) (nreverse result))))
The standard NREVERSE trick keeps the stack small, at the expense that
the list is backwards. But this uses no extra conses in all serious
implementations, and it runs in the same O(n) time that the tail recursive
form does. And, getting back to that elegance issue, DO has the nice
property that it mirrors the structure of a tail recursion (which is what
it effectively implements).
Once you have that you can write:
(defmacro do-pairs (((first rest) list) &body forms)
`(map-pairs #'(lambda (,first ,rest) ,@forms) ,list))
You can proclaim MAP-PAIRS to be INLINE ahead of its definition if you
are worried about the function call overhead for MAP-PAIRS.
[Assuming I made no errors, of course. Caveat emptor, and all that.
As so often happens, I wrote this in kind of a hurry on my way out
the door to somewhere, so it's not heavily tested.]
On 12 Jul 2008 11:50:21 -0400, Kent M Pitman <······@nhplace.com> said:
| Vassil Nikolov <···············@pobox.com> writes:
|| On Fri, 11 Jul 2008 12:29:26 -0700 (PDT),
|| Grant Rettke <·······@gmail.com> said:
||
|| | (defun 2elems (list)
|| | (if (null list) nil
|| | (cons (list (car list) (cadr list)) (2elems (cddr list)))))
||
|| While this is indeed elegant, alas, it would have trouble with long
|| lists (unless the compiler is Really Smart...). It can be rewritten
|| to avoid that trouble, of course, but at the price of significantly
|| reduced elegance...
||
|| ---Vassil.
| Significantly reduced? Hmm...
I used "significantly" in the sense of "noticeably" or "to a
non-neglible degree", rather than "greatly". Perhaps that was a bad
choice of a word on my part.
| Before people were happier with LOOP, we used to write it like this,
| except I've thrown in a funcall at no extra cost.
| (defun map-pairs (f list)
| (do ((list list (cddr list))
| (result '() (cons (funcall f (first list) (second list)) result)))
| ((null list) (nreverse result))))
| The standard NREVERSE trick keeps the stack small, at the expense that
| the list is backwards. But this uses no extra conses in all serious
| implementations, and it runs in the same O(n) time that the tail recursive
| form does.
But using NREVERSE increases the constant factor of the big-O;
sometimes this increase does not matter, sometimes it does [*]. I
think the NREVERSE trick is somewhat of a mixed blessing, and
sometimes it would be better to use an abstraction that does it by a
(hidden) destructive modification of (REST (LAST RESULT)), like with
difference lists, but I don't have a good concrete suggestion at
hand.
| And, getting back to that elegance issue, DO has the nice property
| that it mirrors the structure of a tail recursion (which is what it
| effectively implements).
There is no need for me to say that is so very true---and I do like
DO, and I do like it more than LOOP---but the non-tail-resursive
two-liner is still more elegant than the DO three-liner, closer to a
Cantoresque paradise, as it were. This is a little paradoxical,
because otherwise mathematically correct but operationally deficient
algorithms and DO are all on the same side of the elegance divide...
[*] Here is some raw material for measurements (just to see the
added overhead of NREVERSE):
(defvar *list* (make-list 4000000)) ;whatever is large enough
(defun foo () ;calls NREVERSE
(dotimes (i 10)
(do ((list *list* (cddr list))
(result '() (cons `(,(first list) ,(second list)) result)))
((endp list) (nreverse result)))))
(defun bar () ;does not call NREVERSE
(dotimes (i 10)
(do ((list *list* (cddr list))
(result '() (cons `(,(first list) ,(second list)) result)))
((endp list) (identity result)))))
(time (foo)) ;repeat several times
(time (bar)) ;ditto
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
In article
<···························@j.kremers4.news.arnhem.chello.nl>,
Joost Kremers <············@yahoo.com> wrote:
> hi all,
>
> i know i can traverse a list with dolist, or use mapcar and family if i
> want to traverse multiple lists simultaneously. however, what if i want to
> traverse one single list, but two elements at a time?
>
> basically, what i want to do is to take a list of the form (a b c d e f)
> and transform it into a list of the form ((a b) (c d) (e f)). i've come up
> with a do-loop that does this, but i have this feeling there must be a
> better way...
>
> TIA
Something like:
(loop for (a b) on list by #'cddr ... )
--
http://lispm.dyndns.org/
Joost Kremers <············@yahoo.com> writes:
> hi all,
>
> i know i can traverse a list with dolist, or use mapcar and family if i
> want to traverse multiple lists simultaneously.
(mapcar (lambda (e1 e2 ... en) ...) l1 l2 ... ln)
(dolist (bunch (mapcar 'list l1 l2 ... ln))
(destructuring-bind (e1 e2 ... en) bunch
...))
> however, what if i want to
> traverse one single list, but two elements at a time?
Apply above with l1=l and l2=(cdr l).
> basically, what i want to do is to take a list of the form (a b c d e f)
> and transform it into a list of the form ((a b) (c d) (e f)).
(defun flip (start)
(let ((flag (not start)))
(lambda (&rest args) (declare (ignore args)) (setf flag (not flag)))))
(let ((list '(a b c d e f)))
(remove-if (flip nil) (mapcar 'list list (cdr list))))
--> ((A B) (C D) (E F))
> i've come up
> with a do-loop that does this, but i have this feeling there must be a
> better way...
Of course, but since you want to restrict yourself to dolist or mapcar...
Use LOOP!
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Of course, but since you want to restrict yourself to dolist or mapcar...
actually, i didn't mean to imply i wanted to restrict myself to that. but
your examples contained some nice things, which i'll keep in mind, even if
they're a bit convoluted for the current problem... ;-)
> Use LOOP!
yeah, as two other posters already suggested, that looks like the best way.
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
On Fri, 11 Jul 2008 18:37:08 +0200, ···@informatimago.com (Pascal J. Bourguignon) said:
| ...
| (defun flip (start)
| (let ((flag (not start)))
| (lambda (&rest args) (declare (ignore args)) (setf flag (not flag)))))
| (let ((list '(a b c d e f)))
| (remove-if (flip nil) (mapcar 'list list (cdr list))))
| --> ((A B) (C D) (E F))
There is also a solution broadly similar to the above which avoids
the side effect in the (FLIP NIL) function; I think it is an
interesting exercise to find it as well.
By the way, the solution quoted above relies on compiler
optimization, e.g. by inlining MAPCAR, in order to reduce consing,
though that is not so important right now. (If the argument list's
length is N, then the essential consing is obviously of 3/2 N
conses.)
* * *
Now, for additional credit, consider a "cousin" of the above problem
(from the array side), namely, to obtain #2A((1 2) (3 4) (5 6) ...)
from #1A(1 2 3 4 5 6 ...). I believe it is rather instructive to
see how the latter can be solved, and compare to the former.
(No spoilers in this post...)
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
Vassil Nikolov <···············@pobox.com> writes:
> On Fri, 11 Jul 2008 18:37:08 +0200, ···@informatimago.com (Pascal J. Bourguignon) said:
> | ...
> | (defun flip (start)
> | (let ((flag (not start)))
> | (lambda (&rest args) (declare (ignore args)) (setf flag (not flag)))))
>
> | (let ((list '(a b c d e f)))
> | (remove-if (flip nil) (mapcar 'list list (cdr list))))
>
> | --> ((A B) (C D) (E F))
>
> There is also a solution broadly similar to the above which avoids
> the side effect in the (FLIP NIL) function; I think it is an
> interesting exercise to find it as well.
>
> By the way, the solution quoted above relies on compiler
> optimization, e.g. by inlining MAPCAR, in order to reduce consing,
> though that is not so important right now. (If the argument list's
> length is N, then the essential consing is obviously of 3/2 N
> conses.)
Well, actually the OP included the familly of mapcar so we could
rather use mapcan:
(let ((list '(a b c d e f)))
(mapcan (lambda (keep first second) (when keep (list (list first second))))
'#1=(t nil . #1#) list (rest list)))
> * * *
>
> Now, for additional credit, consider a "cousin" of the above problem
> (from the array side), namely, to obtain #2A((1 2) (3 4) (5 6) ...)
> from #1A(1 2 3 4 5 6 ...). I believe it is rather instructive to
> see how the latter can be solved, and compare to the former.
(let ((v #1A(1 2 3 4 5 6)))
(make-array (list (truncate (length v) 2) 2) :displaced-to v))
--> #2A((1 2) (3 4) (5 6))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
On Jul 11, 8:50 am, Joost Kremers <············@yahoo.com> wrote:
> hi all,
>
> i know i can traverse a list with dolist, or use mapcar and family if i
> want to traverse multiple lists simultaneously. however, what if i want to
> traverse one single list, but two elements at a time?
>
> basically, what i want to do is to take a list of the form (a b c d e f)
> and transform it into a list of the form ((a b) (c d) (e f)). i've come up
> with a do-loop that does this, but i have this feeling there must be a
> better way...
In Mathematica, you can just partition it first. e.g.
mylist = {1, 2, 3, 4, 5, 6};
Map[·····@# &, Partition[mylist, 2]]
returns {1,3,5}
In FullForm (i.e. lispy form but without lisp's irregularities like
“'#;” stuff), each of the above is:
Set[mylist, List[1,2,3,4,5]]
Map[Function[First[Slot[1]]], Partition[mylist, 2]]
In langs without partition, the basic approach is using mod n. (in our
case, n is 2, so just evenp or oddp)
For elisp, which doesn't have a construct to get the index of element
(and no “for” construct), it's a bit more tedious.
tedious, tedium, problematic. Scheme lisp would be like that. In the
case of Common Lisp, there are easy ways as others are eager to show
but extreme complexity arise.
Xah
∑ http://xahlee.org/
☄
······@gmail.com wrote:
> In Mathematica, you can just partition it first. e.g.
>
> mylist = {1, 2, 3, 4, 5, 6};
> Map[·····@# &, Partition[mylist, 2]]
>
> returns {1,3,5}
which, however, is not what i was interested in...
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
On Jul 12, 6:55 am, Joost Kremers <············@yahoo.com> wrote:
> ······@gmail.com wrote:
> > In Mathematica, you can just partition it first. e.g.
>
> > mylist = {1, 2, 3, 4, 5, 6};
> > Map[·····@# &, 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/
☄
På Sat, 12 Jul 2008 23:53:21 +0200, skrev ······@gmail.com
<······@gmail.com>:
> On Jul 12, 6:55 am, Joost Kremers <············@yahoo.com> wrote:
>> ······@gmail.com wrote:
>> > In Mathematica, you can just partition it first. e.g.
>>
>> > mylist = {1, 2, 3, 4, 5, 6};
>> > Map[·····@# &, 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
Hi John,
you wrote:
«
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))))
»
The thing is, with Mathematica, everything is followed thru as general
and consistant as possible.
See:
http://documents.wolfram.com/mathematica/functions/Partition
here's a copy & paste excerpt. Some image based typeset symbols
(mostly appearing inside {}) becomes empty with this copy & paste, but
gives some idea for those who don't have web access.
• Partition[list, n] partitions list into non-overlapping sublists of
length n.
• Partition[list, n, d] generates sublists with offset d.
• Partition[list, {, , ... }] partitions a nested list into blocks of
size .
• Partition[list, {, , ... }, {, , ... }] uses offset at level i in
list.
• Partition[list, n, d, {, }] specifies that the first element of list
should appear at position in the first sublist, and the last element
of list should appear at or after position in the last sublist. If
additional elements are needed, Partition fills them in by treating
list as cyclic.
• Partition[list, n, d, {, }, x] pads if necessary by repeating the
element x.
• Partition[list, n, d, {, }, {, , ... }] pads if necessary by
cyclically repeating the elements .
• Partition[list, n, d, {, }, {}] uses no padding, and so can yield
sublists of different lengths.
• Partition[list, nlist, dlist, {, }, padlist] specifies alignments
and padding in a nested list.
Xah
∑ http://xahlee.org/
☄