How to improve the readability of (any) LISP or any highlevel functional language to the level of FORTH ?
girosenth
functional language to the level of FORTH ?
There are many people who have trivia complaints about parens in lisp,
but I dont.
LISP is a prefix notation.
sequence of operations would look like this on operands (ops) :
(f ops (g ops (h ops (j ops (k ops (l ops ))...))))
How do you make it readable ?
How do you home to the center or centers ?
(f (g (h (j (k (l ops)))...)))
is easy to read or
ops l k j h g f
???
Which is linear reading from L->R ? LISP or FORTH ?
AND, if I must break the nested function structure, will I not be
visiting the forbidden territory of imperative programming ?
(setq L (l ops))
(setq K (k L ))
....
....
(setq F (f G ))
If I use setq, I am using globals, atleast in elisp.
If I use let*, I have limited options as I am constrained inside the
rigid structure of let*
(let*
((L (l ops))
(K (k L ))
....
(F (f G )))
some more
)
Is there a postfix functional language that also gets rid of parens
and is not as primitive as FORTH or POSTSCRIPT ?
What are the syntax advantages of ERLANG, ML, CAML, OCAML, HASKELL,
PROLOG, RUBY over LISP ?
How does one improve readability so that the code is self-commenting ?
girosenth
Elena
> Is there a postfix functional language that also gets rid of parens
> and is not as primitive as FORTH or POSTSCRIPT ?
Factor? http://factorcode.org/
Pascal J. Bourguignon
> How to improve the readability of (any) LISP or any highlevel
> functional language to the level of FORTH ?
>
> There are many people who have trivia complaints about parens in lisp,
> but I dont.
>
> LISP is a prefix notation.
>
> sequence of operations would look like this on operands (ops) :
>
> (f ops (g ops (h ops (j ops (k ops (l ops ))...))))
>
> How do you make it readable ?
> How do you home to the center or centers ?
>
> (f (g (h (j (k (l ops)))...)))
>
> is easy to read or
>
> ops l k j h g f
>
> ???
I think we can call you a troll.
Is it not obvious how you home to the center?
http://www.informatimago.com/~pjb/bulleye.png
Is it not a flagrant proof that lisp is the most easy to read?
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Nathan
into Ruby. I know personally that Ruby syntax was a big turn off to me
for several weeks (kind of like Lisp) but once you learn it, it
becomes the easiest to read of any programming language I've ever
experimented with. No contest.
Matz himself admitted that “...Ruby is a bad rip-off of Lisp... But it
is nicer to ordinary people.”
Though every language I've worked in, I've never been half as
productive as when I'm coding in Ruby. There are so many built in
methods to help you with common day to day tasks, and the end result
of your code will be simpler and clearer to read than you can have it
in any other language.
The downside of course is that Ruby lends itself to the efficient
production of very inefficient code. You'll be plagued with strict
evaluative breath first traversals that glut on your memory. You'll
find yourself cursing a global interpreter lock that makes Ruby's
simple method for handling threads meaningless in most situations.
In my hands, Ruby's nature seems to lend itself to the design of
inefficient code, but that can be overcome with a little attention.
Overall, I left Ruby because the community support was somewhat less
than I wanted. In particular, cross platform GUI application
development seemed poor.
If you want to develop webpages, or bang out quick one time scripts,
Ruby is hard to beat. For use at home, console applications are
probably a tolerable price to pay for the incredible development speed
and fantastic ease of maintenance Ruby will give your code.
If you give it an hour a day for two months, I guarantee you will be
head over heals in love with the Ruby language. If you're not, please
send me an email and tell me what language you prefer because I want
to try it out.
Ruby is just a blast to code in. If it had stronger GUI support, no
global interpretor lock, and either lazy evaluation or preemptive
multi-threading (with a strong preference toward the latter), I'd be
content to settle down with that for the rest of my life. But then,
this is from a guy who's learning Lisp only for the sake of mastering
a superior abstraction model. You might want to take me with a grain
of salt.
Jan Burse
I am responding from comp.lang.prolog.
Nathan schrieb:
> Ruby is just a blast to code in. If it had stronger GUI support, no
> global interpretor lock,
I think a global interpreter lock can be avoided by combining
the following approaches in logic programming languages:
0) Actual parameter data structures (of a thread running in the
interpreter) should be immune to concurrency problems.
1) Conversions between actual parameter data structures, and
global data structures (of the interpreter).
2) No exposure of global data structures,
only access via the interpreter.
3) When exposure of global data structures, then access via
thread safe methods.
Interestingly 0) and 1) is automatically assured by Prolog
implementations. Actual parameters are not visible between
threads, and clause instantiation can be viewed as producing
actual parameter data structures from global data structures,
whereas asserting a clause can be viewed as producting global
data structures form actual parameter data structures.
Point 2) and 3) depend on the API design for a Prolog implementation.
For point 2) it is assumend that a multi-threaded interpreter will
not have any problems accessing its global data structures, for
example in the case of Prolog clauses, concurrently. For 3) it
is assumed that corresponding access can be encapsulated in
thread safe methods.
There are a couple of Prolog system implementations around
that support multi threading. For example SWI Prolog. Or
Jekejeke Prolog. In Jekejeke Prolog mostly the approach 2)
has been followed by the API on purpose.
> and either lazy evaluation or preemptive multi-threading (with a
> strong preference toward the latter),
The threads deployed by multi-threading Prologs are preemptive.
They typically don't follow the cooperative model, because
coopertaive threads have only limited applications. SWI
Prolog has preemptive threads (*), Jekejeke Prolog inherits
the property from the threads of the Java VM.
Best Regards
(*)
http://hcs.science.uva.nl/projects/SWI-Prolog/articles/iclp-03.pdf
girosenth
wrote:
> girosenth <girose...@india.com> writes:
> > How to improve the readability of (any) LISP or any highlevel
> > functional language to the level of FORTH ?
>
> > There are many people who have trivia complaints about parens in lisp,
> > but I dont.
>
> > LISP is a prefix notation.
>
> > sequence of operations would look like this on operands (ops) :
>
> > (f ops (g ops (h ops (j ops (k ops (l ops ))...))))
>
> > How do you make it readable ?
> > How do you home to the center or centers ?
>
> > (f (g (h (j (k (l ops)))...)))
>
> > is easy to read or
>
> > ops l k j h g f
>
> > ???
>
> I think we can call you a troll.
Factually, such a level of prejudice is not good for health, intellect
or discussion.
> Is it not obvious how you home to the center?http://www.informatimago.com/~pjb/bulleye.png
> Is it not a flagrant proof that lisp is the most easy to read?
There are things that I was hoping experienced programmers would fill
in that I forgot to state.
In a one liner which is an accurately represented by the subsets your
image displays, it is infact true that the center(s) are immediately
obvious. But if each of the f,g,h,...k,l are huge functions (in the
definitions) then they may occupy parts of a screen and the whole may
occupy several screens, or several tens of screens. Note also that I
have ops only before , but they can be everywhere. Function
(definition) enclosures have a 1-1 correspondence with trees as any
hierarchical objects and may look like a herringbone tree.
Sphagetti code which was promoted by a goto was brought under control
by "structured" programming which had only 3 forms (thus removing the
need for a flow chart) ie sequence, selection and iteration.
Functional language adds another useful form which is recursion and
(as a side comment) recursion is not representable by a flowchart.
The sequence, which is the simplest of the construct is essentially
imperative in nature. Sequence of state changes.
A purely functional program would have a single huge nested function.
One could say that a huge function can be broken into simpler
functions. Logic could always be chased LINE BY LINE by a determined
reader with unlimited time, but for most of us, programming efficiency
is an issue. However, to break a several screen or even a smaller set
of computation, I am faced with how to break it into parts due to
coupling in its parts. I was doing it inside let* to avoid setq
(fair ?) but I have a function that must return a number or a string
depending on if a regex was found and its index or a message that it
was not found.
(string-match REGEXP STRING &optional START)
inside a (cond) I return a string or the number
I am constrained to write like this because I wrote a quick and dirty
working and structurally (in the sense of structured) readable code
but WITHOUT taking care of failures or errors. Now I am trying to
modify it to take care of errors.
I must test it as soon as string match what type of regexp was not
found.
As I started modifying it, I lost track of its structure. I could
understand it at the write time but I know that after forgetting, at
the read time I will not understand it in the linear sense of the size
increase.
Even as I explained to a friend, I realized that I need to home in to
the center and reading was not linear as FORTH promises and any
postfix language with action words (functions) reads. The reading is
not linear.
I realized that you can read infix notation or standard function
notation f(x) of (f x) only because they are simpler functions, not
the recursive type functions of McCarthy. Those functions have if then
else logic embedded that is not apparent as you start reading it.
Our math functions are very simple, and most often single letters.
That is why algebraic notation is easy for them.
In comparison to prefix, postfix seems in the order of the action.
Certainly, it starts with the center object moved to the left most.
One gentleman has advocated ruby. The thread will be enriched by
perspectives from other functional languages. Suppose, I want to stick
to elisp and then move to CL (since almost everyone who has not taken
a course in lisp or scheme and who starts with linux comes to emacs
and elisp first) instead of ruby, then it appears to me that macros
which are being discussed without any examples in elisp or even CL
might be an answer to take care of sphagetti code or highly coupled
code. I was considering making a huge MIMO function that takes in many
bits and makes an output to be used by others. Atleast, the main
program would be readable. Such a function would have no analogy to
the real world object or operation and thus built on fictional lines
and unstable in construction and likely to be challenged by then next
exception that I would encounter in my build-fix method and thus beg
for recoding and re-reading again. Readability then is an issue.
I read your post somewhere with your example of flatten. I was
honestly not impressed with readability. All that you did was to
compress cond and also to use push/pop which would be indicated by a
text comment as clearly. Admitted that the code took smaller part of
the screen.
In modern IDE's there is a feature which allows code to be collapsed.
I am using older version of emacs I dont know if RMS and his team has
copied such features from eclipse and other IDEs into emacs and
debugged them or a bold adventurer would be on their mercy.
In the hygenic macro thread currently in progress, I want to ask them
to show me how macros can be written to prove their claims assuming
that I have good grasp of basics like quote, backquote, unquote and
splice.
I know some of these might sound unpleasant to commercial entities
with so much invested in it but for us, honest discussion and support
of claims by demonstration example is what really counts.
girosenth
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> A bad day in () is better than a good day in {}.- Hide quoted text -
>
> - Show quoted text -
The Quiet Center
> If you want a easy to read self-documenting functional language, look
> into Ruby. I know personally that Ruby syntax was a big turn off to me
> for several weeks (kind of like Lisp) but once you learn it, it
> becomes the easiest to read of any programming language I've ever
> experimented with. No contest.
>
Well, Python was chosen over Ruby for MIT's rework of their intro to
cs course because Python is multi-paradigm, whereas Ruby claims
everything is an object.
How would you code this simple list compression problem in Ruby:
1.08 (**) Eliminate consecutive duplicates of list elements.
If a list contains repeated elements they should be replaced with
a single copy of the element. The order of the elements should not be
changed.
Example:
?- compress([a,a,a,a,b,c,c,a,a,d,e,e,e,e],X).
X = [a,b,c,a,d,e]
> Matz himself admitted that “...Ruby is a bad rip-off of Lisp... But it
> is nicer to ordinary people.”
yeah I guess the LOOP macro is where I got stuck in doing Lisp.
>
> Though every language I've worked in, I've never been half as
> productive as when I'm coding in Ruby.
I've done Perl at corporate level for 10 years and I've heard seasoned
Perl developers say the same thing.
>
> In particular, cross platform GUI application
> development seemed poor.
yeah, wxPython is the only thing for any scripting languages that
seemed to make very professional desktop UI programs.
>
> If you want to develop webpages, or bang out quick one time scripts,
> Ruby is hard to beat. For use at home, console applications are
> probably a tolerable price to pay for the incredible development speed
> and fantastic ease of maintenance Ruby will give your code.
yeah sinatra.rb looks nice for web dev and ruby on rails was a runaway
hit for awhile.
By the way, here's the Prolog solution to the compression problem I
posted earlier:
% http://sites.google.com/site/prologsite/prolog-problems/1
% Problem 1.08 - compress consecutive duplicates into a single
% list element
compress([], []).
compress([X,Y], [X,Y]) :- X \= Y.
compress([X,Y], [X]) :- X = Y.
% problems writing other clauses (thanks RLa)
compress([X,Y|Z], [X|Z1]) :- X \= Y, compress([Y|Z], Z1).
compress([X,Y|Z], Z1) :- X = Y, compress([Y|Z], Z1).
Pascal Costanza
> How to improve the readability of (any) LISP or any highlevel
> functional language to the level of FORTH ?
I'm rather wondering how we can improve the readability of (any) English
to the level of German.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Jan Burse
> %http://sites.google.com/site/prologsite/prolog-problems/1
>
> % Problem 1.08 - compress consecutive duplicates into a single
> % list element
>
> compress([], []).
> compress([X,Y], [X,Y]) :- X \= Y.
> compress([X,Y], [X]) :- X = Y.
>
> % problems writing other clauses (thanks RLa)
>
> compress([X,Y|Z], [X|Z1]) :- X \= Y, compress([Y|Z], Z1).
> compress([X,Y|Z], Z1) :- X = Y, compress([Y|Z], Z1).
>
The above code does not work fully correct. Here is a
counter example (try yourself):
?- compress([a],X).
No
In a Prolog introductory course I would anyway use:
% compress(+List,-List)
compress([X,X|L],R) :- !, compress([X|L],R).
compress([X|L],[X|R]) :- compress(L,R).
compress([],[]).
No reason to use (\=)/2, which is anyway not declarative,
and no reason to avoid the cut !/0.
Bye
P.S.: On sites.google.com I find the following solution,
correct, but also avoids the cut !/0:
% 1.08 (**): Eliminate consecutive duplicates of list elements.
% compress(L1,L2) :- the list L2 is obtained from the list L1 by
% compressing repeated occurrences of elements into a single copy
% of the element.
% (list,list) (+,?)
compress([],[]).
compress([X],[X]).
compress([X,X|Xs],Zs) :- compress([X|Xs],Zs).
compress([X,Y|Ys],[X|Zs]) :- X \= Y, compress([Y|Ys],Zs).
LanX
> > Matz himself admitted that “...Ruby is a bad rip-off of Lisp... But it
> > is nicer to ordinary people.”
Matz himself admitted in the earliest sources that Ruby is basically
Perl's semantics melted with Smalltalk's OOP syntax. All influences
from LISP come via Perl and many things criticized in Perl derive from
Larry's dedication to stay close to LISP in contrast to Guido who
breaks a lot in Python, e.g limiting lambdas to single expressions.
For sure Perl's scoping rules are much closer to eLISP's.
So in order to emulate eLISP I would rather chose a Perl or JavaScript
1.7 (with the additional "let"-command) but with the need of extra
macro functionality.
The problem are rather the datatypes which are far more static in
eLISP,
i.e.
1. no autocasting eLisp
2. hashes and arrays have only fixed length in eLisp
3. OTOH linked linked lists are not a native type in most mainstream
languages.
> How would you code this simple list compression problem in Ruby:
>
> 1.08 (**) Eliminate consecutive duplicates of list elements.
> If a list contains repeated elements they should be replaced with
> a single copy of the element. The order of the elements should not be
> changed.
>
> Example:
> ?- compress([a,a,a,a,b,c,c,a,a,d,e,e,e,e],X).
> X = [a,b,c,a,d,e]
>
in Perl:
DB<1> my $l; print grep { $l = $_ if $_ ne $l }
(a,a,a,a,b,c,c,a,a,d,e,e,e,e);
abcade
from 5.10 one can use feature "state" to avoid an extra scope to make
$l lexical.
or define an explicit compress function:
DB<2> sub compress { my $l; grep { $l = $_ if $_ ne $l } @_ }
DB<3> print compress(a,a,a,a,b,c,c,a,a,d,e,e,e,e);
abcade
(Nota bene, no explicit return needed like in LISP)
I suppose one can translate those approaches directly to Ruby, Python
or PHP. Newer JS versions call "grep" rather "filter" like in Python.
LanX
> DB<1> my $l; print grep { $l = $_ if $_ ne $l } (a,a,a,a,b,c,c,a,a,d,e,e,e,e);
> abcade
The same more explicit and less buggy
grep { if ($_ ne $l) { $l = $_ ; 1 } } LIST
vanekl
Nota bene, Lisp doesn't require an explicit RETURN.
CUBE> (defun compress (list)
"Compress consecutive list element duplicates."
(iter (for elem in list)
(for p-elem previous elem)
(unless (equal p-elem elem)
(collect elem))))
COMPRESS
CUBE> (compress '(a a a a b c c a a d e e e e))
(A B C A D E)
And, no, the macroexpansion doesn't contain a RETURN.
Nathan
functionality you've been asking about in Ruby.
my_list = [1, 1, 1, 1, 2, 3, 3, 1, 1, 4, 5, 5, 5, 5]
print my_list.reduce([]){|x, y|
if x.empty? or x[x.length-1] != y then
x + [y]
else
x
end
}
As is typical of functional languages, this returns a value rather
than modifying the list in place. I recommended Ruby because you were
asking about a functional programming language that still reads in an
sequential manner like imperative languages, which Ruby does.
Ruby is a purely object oriented language, however there is no need
for new developers to write code in an object oriented manner. Your
code will be put into objects whether you specify those objects or not
simply for the sake of providing metadata.
I am familiar with Python, I use it more than Ruby these days. I've
found function/method names and locations to be less consistent than
in Ruby. I've found that far too many routines modify data in place -
rather than return the result- to make it a serious functional
language. That being the case, it's very usable.
It is my belief that every language possesses some piece of the light.
None are prefect; every one needs to learn from every other one.
Whether it's Ruby, Python, Java, C#, Lisp, or Perl; there are always
developers in the community that believe their language is beyond
improvement. I pity them.
Generally I consider the issue of readability to be a question of how
closely a new syntax matches what one is accustomed to reading. Many
people prefer sequential program flow over nested simply because
English, and every other spoken language I'm aware of, is sequential
in nature.
Thus, something can be considered "simple" and "intuitive" only when
it builds off what a person already knows; and since that knowledge
base changes dramatically between individuals... Simple and intuitive
are also in the eye of the beholder. In the end, what's important is
that your solution work for you.
There are many languages because there are many types of people and
there are many ways of thinking and recording thought. I believe that
greatness in thought is not about "having the prefect way of doing
things" or "finding some ultimate", to me it's about having many ways
of doing something and recognizing when to use each one.
Just like any other tool, programming languages have their strengths
and weaknesses. If one wanted, one could probably build an entire
house using nothing but a hammer. I will prefer to use a hammer only
for the nails, but that's me.
D Herring
> On 01/01/2011 08:04, girosenth wrote:
>> How to improve the readability of (any) LISP or any highlevel
>> functional language to the level of FORTH ?
>
> I'm rather wondering how we can improve the readability of (any)
> English to the level of German.
The classic response:
http://www.users.globalnet.co.uk/~choh/german.htm
I haven't a clue where this originated.
- Daniel
Paul Rubin
> functionality you've been asking about in Ruby.
>
> my_list = [1, 1, 1, 1, 2, 3, 3, 1, 1, 4, 5, 5, 5, 5]
> print my_list.reduce([]){|x, y|
> if x.empty? or x[x.length-1] != y then
> x + [y]
> else
> x
> end
> }
That is pretty ugly; in Haskell you could write
my_list = [1, 1, 1, 1, 2, 3, 3, 1, 1, 4, 5, 5, 5, 5]
main = print [head xs | xs <- group my_list]
That uses a Python-like list comprehension since you mentioned Python,
but more idiomatic would be
my_list = [1, 1, 1, 1, 2, 3, 3, 1, 1, 4, 5, 5, 5, 5]
main = print . map head . group $ my_list
There is probably a function like "group" available in Ruby. Python has
itertools.groupby but it's a little bit brittle.
w_a_x_man
> On Jan 1, 11:08 am, Nathan <nbeen...@gmail.com> wrote:
>
> > If you want a easy to read self-documenting functional language, look
> > into Ruby. I know personally that Ruby syntax was a big turn off to me
> > for several weeks (kind of like Lisp) but once you learn it, it
> > becomes the easiest to read of any programming language I've ever
> > experimented with. No contest.
>
> Well, Python was chosen over Ruby for MIT's rework of their intro to
> cs course because Python is multi-paradigm, whereas Ruby claims
> everything is an object.
>
> How would you code this simple list compression problem in Ruby:
>
> 1.08 (**) Eliminate consecutive duplicates of list elements.
> If a list contains repeated elements they should be replaced with
> a single copy of the element. The order of the elements should not be
> changed.
>
> Example:
> ?- compress([a,a,a,a,b,c,c,a,a,d,e,e,e,e],X).
> X = [a,b,c,a,d,e]
>
"aaaabccaadeeee".squeeze
==>"abcade"
p=nil; %w(a a a b c c a a d e e e).select{|x| x!=p && p=x}
==>["a", "b", "c", "a", "d", "e"]
w_a_x_man
> Well, to answer the question simply, this code will provide the
> functionality you've been asking about in Ruby.
>
> my_list = [1, 1, 1, 1, 2, 3, 3, 1, 1, 4, 5, 5, 5, 5]
> print my_list.reduce([]){|x, y|
> if x.empty? or x[x.length-1] != y then
Instead of x[x.size-1], use x[-1] or x.last.
> x + [y]
> else
> x
> end
>
> }
Another way using reduce:
%w(a a a b c c a a d e e e).reduce([]){|a,x| a[-1]==x ? a : a<<x}
==>["a", "b", "c", "a", "d", "e"]
This assumes nils aren't allowed in the source array.
Doug Hoffman
> How to improve the readability of (any) LISP or any highlevel
> functional language to the level of FORTH ?
>
> There are many people who have trivia complaints about parens in lisp,
> but I dont.
>
> LISP is a prefix notation.
>
> sequence of operations would look like this on operands (ops) :
>
> (f ops (g ops (h ops (j ops (k ops (l ops ))...))))
>
> How do you make it readable ?
> How do you home to the center or centers ?
>
> (f (g (h (j (k (l ops)))...)))
>
> is easy to read or
>
> ops l k j h g f
[snip]
> Is there a postfix functional language that also gets rid of parens
> and is not as primitive as FORTH or POSTSCRIPT ?
Forth remains only as primitive as you want it to be.
Consider the list compression example later in this thread:
Example:
?- compress([a,a,a,a,b,c,c,a,a,d,e,e,e,e],X).
X = [a,b,c,a,d,e]
To solve this using Forth I took an existing dynamic string library
class and added one method as follows:
\ Create a subclass of string with a compress method
:class string++ <super string+
\ compress: will return a new string object
:m compress: ( -- newStr )
self heap: ( newStr) 0 self at: { newStr lastChar }
0 0 newStr new:
lastChar newStr +:
self size: 1
?DO i self at: dup lastChar <>
IF dup newStr +: THEN
to lastChar
LOOP newStr ;m
;class
string++ s \ declare a string object named s
\ 1st copy&paste the input list from the Example
\ and place it into s
s" a,a,a,a,b,c,c,a,a,d,e,e,e,e" s new:
\ 2nd, remove all commas
s" ," 0 0 s replall:
\ 3rd, do the compression and save the output object in x
s compress: value x
\ We are done:
x p:
abcade \ Q.E.D
\ Or, if one insists on pretty printing
: e ( idx -- ) x at: emit ;
: print ( obj -- )
[char] [ emit 0 e
size: 1 DO [char] , emit i e LOOP
[char] ] emit ;
x print
[a,b,c,a,d,e] \ Q.E.D
\ return heap memory
s free:
x free:
If I find the compress method to be repeatedly useful in various
problems I would keep it as part of my class library. I may code a
compress method that is more general and perhaps also for ordered
collections. I am confident that there are (many) other solutions to
the above using more "primitive" Forth techniques.
We also have some extensive postfix arithmetic routines that prove
useful when translating, for example, Fortran equations. But I won't
get into that here.
-Doug
Frank GOENNINGER
> On Jan 1, 11:08�am, Nathan <nbeen...@gmail.com> wrote:
>> If you want a easy to read self-documenting functional language, look
>> into Ruby. I know personally that Ruby syntax was a big turn off to me
>> for several weeks (kind of like Lisp) but once you learn it, it
>> becomes the easiest to read of any programming language I've ever
>> experimented with. No contest.
>>
>
> Well, Python was chosen over Ruby for MIT's rework of their intro to
> cs course because Python is multi-paradigm, whereas Ruby claims
> everything is an object.
>
> How would you code this simple list compression problem in Ruby:
>
> 1.08 (**) Eliminate consecutive duplicates of list elements.
> If a list contains repeated elements they should be replaced with
> a single copy of the element. The order of the elements should not be
> changed.
>
> Example:
> ?- compress([a,a,a,a,b,c,c,a,a,d,e,e,e,e],X).
> X = [a,b,c,a,d,e]
>
>> Matz himself admitted that �...Ruby is a bad rip-off of Lisp... But it
>> is nicer to ordinary people.�
>
> yeah I guess the LOOP macro is where I got stuck in doing Lisp.
Simple:
? (defun compress (list)
(let ((last-element)
(result))
(loop for element in list
when (not (equal last-element element))
do
(progn
(setq last-element element)
(push element result)))
(reverse result)))
COMPRESS
? (setq list (list 'a 'a 'a 'a 'b 'c 'c 'a 'a 'd 'e 'e 'e 'e))
(A A A A B C C A A D E E E E)
? (compress list)
(A B C A D E)
'compress can be done in much more terse way in Lisp but this is just an
example using the Loop macro.
Frank
Frank GOENNINGER
Must be the proposal of Mr Oettinger, the German politican now being EU
Commisioner for Energy. Hearing him speaking English very closely
assemble the "Modern English" as outlined on that page ...
http://www.youtube.com/watch?v=icOO7Ut1P4Y
No, I'm not proud of that ...
Frank
Jerome Baum
dg1...@googlemail.com says...
> Must be the proposal of Mr Oettinger, the German politican now being
EU
> Commisioner for Energy. Hearing him speaking English very closely
> assemble the "Modern English" as outlined on that page ...
>
> http://www.youtube.com/watch?v=icOO7Ut1P4Y
>
> No, I'm not proud of that ...
>
> Frank
You just have to love the comment:
"I understand only train station"
(To put it into context, that's the text on an ad run by some English
training business over here in Germany.)
LanX
>
> > Frank
>
> You just have to love the comment:
>
> "I understand only train station"
come on guys, he speaks better English than more than 90% of all Anglo-
Saxon politicians speak any other foreign language...
LanX
Paul Rubin schrieb:
> That is pretty ugly; in Haskell you could write
>
> my_list = [1, 1, 1, 1, 2, 3, 3, 1, 1, 4, 5, 5, 5, 5]
> main = print [head xs | xs <- group my_list]
does this really produce the desired output?
Will the second 1 really be printed?
And why do you guys switch to operate on digits instead of strings?
Jerome Baum
@w18g2000vbe.googlegroups.com>, lanx...@googlemail.com says...
import List
my_list = ["one", "one", "one", "one", "two", "three", "three", "one",
"one", "four", "five", "five", "five", "five"]
main = print [head xs | xs <- group my_list]
Output:
["one","two","three","one","four","five"]
Works fine for me...
Raymond Wiker
http://www.english-zone.com/index.php?page=1114&pid=81
--- I think this is the original version.
Bernd Paysan
The version I know stated at the end that the Germans zot zis vas a
viktory, and zey achived zeir original goal.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
w_a_x_man
> On 1/1/11 2:04 AM, girosenth wrote:
>
> > How to improve the readability of (any) LISP or any highlevel
> > functional language to the level of FORTH ?
>
> > There are many people who have trivia complaints about parens in lisp,
> > but I dont.
>
> > LISP is a prefix notation.
>
> > sequence of operations would look like this on operands (ops) :
>
> > (f ops (g ops (h ops (j ops (k ops (l ops ))...))))
>
> > How do you make it readable ?
> > How do you home to the center or centers ?
>
> > (f (g (h (j (k (l ops)))...)))
>
> > is easy to read or
>
> > ops l k j h g f
>
> [snip]
>
> > Is there a postfix functional language that also gets rid of parens
> > and is not as primitive as FORTH or POSTSCRIPT ?
>
> Forth remains only as primitive as you want it to be.
>
That is equally true of assembly language.
Forth is a low-level language used primarily for programming embedded
applications such as controlling the flushing of a toilet.
"Forth, the toilet-flusher!"
w_a_x_man
This doesn't seem to work under gcl:
>>(defun compress (list)
"Compress consecutive list element duplicates."
(iter (for elem in list)
(for p-elem previous elem)
(unless (equal p-elem elem)
(collect elem))))
COMPRESS
>>(compress '(a a a a b c c a a d e e e e))
Error: The function ITER is undefined.
And ITER isn't found here:
http://www.ida.liu.se/imported/cltl/clm/index.html#SECTION003800000000000000000
>>(let ((p nil))
(remove-if
(lambda(x &rest y)(setq y p)(setq p x)(eql x y))
'(a a b c a d d e e)))
w_a_x_man
>
> >>(let ((p nil))
>
> (remove-if
> (lambda(x &rest y)(setq y p)(setq p x)(eql x y))
> '(a a b c a d d e e)))
>
> (A B C A D E)
>>(let ((prv)(tmp))
(remove-if (lambda(x)(setq tmp prv prv x)(eql x tmp))
w_a_x_man
(let ((prv))
(remove-if (lambda(x)(eql x (shiftf prv x)))
Paul Rubin
>> main = print [head xs | xs <- group my_list]
>
> does this really produce the desired output?
> Will the second 1 really be printed?
Yes. "group" is a very useful function, that transforms a list into a
list-of-lists which collapses identical elements:
group [1, 1, 1, 1, 2, 3, 3, 1, 1, 4, 5, 5, 5, 5]
is
[[1,1,1,1], [2], [3,3], [1,1], [4], [5,5,5,5]]
The list comprehension
[head xs | xs <- group my_list]
simply collects the first element of each of those sub-lists.
There is also groupBy, which lets you supply your own equality
predicate. If there's not already a Lisp library similar to Python's
itertools module and Haskell's List module, it's probably worth writing
one.
Nicolas Neuss
> ? (defun compress (list)
> (let ((last-element)
> (result))
> (loop for element in list
> when (not (equal last-element element))
> do
> (progn
> (setq last-element element)
> (push element result)))
> (reverse result)))
>
> COMPRESS
>
> ? (setq list (list 'a 'a 'a 'a 'b 'c 'c 'a 'a 'd 'e 'e 'e 'e))
> (A A A A B C C A A D E E E E)
>
> ? (compress list)
> (A B C A D E)
>
> 'compress can be done in much more terse way in Lisp but this is just an
> example using the Loop macro.
If you want to show how to use LOOP, you should use it better:
(defun compress (list)
(loop for element in list
and last-element = nil then element
unless (equal last-element element)
collect element))
Nicolas
RG
Nicolas Neuss <last...@kit.edu> wrote:
(loop for (a b) on list unless (eql a b) collect a)
rg
Chip Eastham
wrote:
[snip]
> A bad day in () is better than a good day in {}.
Ah, at last the meaning of your .sig dawns on me!
regards, chip
w_a_x_man
> In article <87vd27gema....@ma-patru.mathematik.uni-karlsruhe.de>,
Much better.
Adapted to MatzLisp:
(list+[nil]).each_cons(2).select{|a,b| a!=b}.map{|a,b| a}
==>["A", "B", "C", "A", "D", "E"]
Cesar Rabak
I _think_ it is a reheated version of a parody from Mark Twain "A Plan
for the Improvement of English Spelling"
http://design.caltech.edu/erik/Misc/Twain_english.html
w_a_x_man
(list+[nil]).each_cons(2).select{|a,b| a!=b}.map &:first
Elizabeth D Rather
>> Forth remains only as primitive as you want it to be.
>>
>
> That is equally true of assembly language.
>
> Forth is a low-level language used primarily for programming embedded
> applications such as controlling the flushing of a toilet.
>
> "Forth, the toilet-flusher!"
I actually know of no toilet-control applications of Forth. But I do
know some applications controlling satellite tracking antennas,
large-scale electric power-distribution systems, satellite
instrumentation, scientific instruments, and quite a few other pretty
non-trivial applications.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Nicolas Neuss
> (loop for (a b) on list unless (eql a b) collect a)
Very nice. This is really showing LOOP's power! One line compared to
about 8 from the original code - not to mention the nastities which have
disappeared.
Nicolas
Didier Verna
> AND, if I must break the nested function structure, will I not be
> visiting the forbidden territory of imperative programming ?
Why do you think imperative programming is forbidden in Lisp ?
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
Didier Verna
> Matz himself admitted that “...Ruby is a bad rip-off of Lisp... But it
> is nicer to ordinary people.”
Which of course is a very sorry thing to say. Ruby is not nicer to
ordinary people. It's nicer to people having already been brainwashed by
languages full of syntax noise. At most, he could have said "to the
majority of people".
There is litterature and evidence out there that Lisp is just good
enough for ordinary people as well, when it's their first programming
experience.
This misconception that you must be exceptionally clever to learn and
use Lisp really hurts the language and the community.
MarkWills
Er, no.
Forth has been/is used for:
* Controlling radio telescopes
* Performing the data acquisition on radio telescopes
* Cargo bay loading system on space shuttle
* Controlling CNC machines in metal finishing
* Controlling DC rectifiers in metal finishing
* Dosing controllers in metal finishing
* Anodising controllers in metal finishing
* Distributed control system in factories
* Airport management
* Rain gauge data acquisition in environmental applications
* Flow meter monitoring (data acquisition) and reporting in water/
sewage applications
* Subsea data acquisition and control (in progress)
* Real-time telemetry in Formula 1 cars (still ongoing)
* Initialising PC mother boards all over the world
* OLPC laptop
Note that, contrary to your bizarre assertion, I personally know of no
instance where a Forth system has been used to flush a toilet. It
would be a bit over the top, since a 555 timer and a relay would do
the job quite nicely, as we used to do in the 80's with that exact
application, and similarly with industrial washer detergent dosing
systems.
I know you're a troll and I shouldn't 'feed you' but Forth is still
used, and is still a valuable programming language.
Nicolas Neuss
>> (loop for (a b) on list unless (eql a b) collect a)
>>
>> rg
>
> Adapted to MatzLisp:
>
> (list+[nil]).each_cons(2).select{|a,b| a!=b}.map{|a,b| a}
> ==>["A", "B", "C", "A", "D", "E"]
Hmm, looking at your code I don't think that Ruby is something for the
faint of heart.
Nicolas
Tamas K Papp
Before I found Lisp, I tried to learn Ruby (from "Why's poingnant
guide"). I got tired of syntax like the above very quickly. I am
puzzled why w_a_x_man posted this: ostensibly, his hobby is promoting
Ruby on c.l.l, but I fail to see how this example serves that purpose.
Best,
Tamas
Tim Harig
>> is nicer to ordinary people.???
>
> This misconception that you must be exceptionally clever to learn and
> use Lisp really hurts the language and the community.
What hurts the LISP community far more is the zealotry of its members,
their insistance that LISP is the *only* tool for *every* job, and their
agressiveness in trying to push it off on to everybody else -- whether
everybody else happens want it or not. Whether this is indicitive
of the entire community or simply the result of those most apparent,
I cannot say; but, it leads to the overall impression that the LISP
community is narrowminded and neophobic. Who would want to be part of
such a community?
LanX
> On Jan 2, 7:14 pm, w_a_x_man <w_a_x_...@yahoo.com> wrote:
> I know you're a troll and I shouldn't 'feed you' but Forth is still
> used, and is still a valuable programming language.
indeed!
LanX
> p=nil; %w(a a a b c c a a d e e e).select{|x| x!=p && p=x}
> ==>["a", "b", "c", "a", "d", "e"]
and by translating my perl code you also inherited it's restrictions
p=nil; ["a","a","b",false,false,"e"].select{|x| x!=p && p=x}
=> ["a", "b", "e"]
José A. Romero L.
(...)
> of computation, I am faced with how to break it into parts due to
> coupling in its parts. I was doing it inside let* to avoid setq
> (fair ?) but I have a function that must return a number or a string
(...)
Can't you simply use setq inside let?:
(setq blah 1)
(let ((blah))
(setq blah 2) ;; <-- This is not blah! ;)
(message "blah is %s" blah))
Cheers,
--
José A. Romero L.
escherdragon at gmail
"We who cut mere stones must always be envisioning cathedrals."
(Quarry worker's creed)
Pascal J. Bourguignon
You're both wrong:
CL-USER> (loop for (a b) on '(t t t nil nil nil) unless (eql a b) collect a)
(T)
irb(main):003:0> list=[:t,:t,:t,nil,nil,nil]
[:t, :t, :t, nil, nil, nil]
irb(main):004:0> (list+[nil]).each_cons(2).select{|a,b| a!=b}.map{|a,b| a}
[:t]
CL-USER> (let ((list '(t t t nil nil nil)))
(loop for (a b) on (cons (gensym) list) unless (eql a b) collect b))
(T NIL)
--
__Pascal Bourguignon__ http://www.informatimago.com/
jacko
I'm developing a language called pHone which is just starting to be
formalized.
Try
http://sites.google.com/site/jackokring/phone-language/looking-in-2011
For a look at the core definition, before symbol processing and
numerics have been added.
Cheers Jacko
jacko
> On 01/01/2011 08:04, girosenth wrote:
>
> > How to improve the readability of (any) LISP or any highlevel
> > functional language to the level of FORTH ?
>
> to the level of German.
>
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
That's a worthy endeavour, but how would you translate chauser?
Nicolas Neuss
>> Hmm, looking at your code I don't think that Ruby is something for the
>> faint of heart.
>
> Before I found Lisp, I tried to learn Ruby (from "Why's poingnant
> guide"). I got tired of syntax like the above very quickly. I am
> puzzled why w_a_x_man posted this: ostensibly, his hobby is promoting
> Ruby on c.l.l, but I fail to see how this example serves that purpose.
Yes, I have also thought about if his advocacy might not be deliberately
anti-Ruby.
Nicolas
jacko
>
> > > How to improve the readability of (any) LISP or any highlevel
> > > functional language to the level of FORTH ?
>
> > > but I dont.
>
> > > LISP is a prefix notation.
>
> > > sequence of operations would look like this on operands (ops) :
>
> > > (f ops (g ops (h ops (j ops (k ops (l ops ))...))))
>
> > > How do you make it readable ?
> > > How do you home to the center or centers ?
>
> > > (f (g (h (j (k (l ops)))...)))
>
> > > is easy to read or
>
> > > ops l k j h g f
>
> > [snip]
>
> > > Is there a postfix functional language that also gets rid of parens
> > > and is not as primitive as FORTH or POSTSCRIPT ?
>
> > Forth remains only as primitive as you want it to be.
>
> That is equally true of assembly language.
>
> Forth is a low-level language used primarily for programming embedded
> applications such as controlling the flushing of a toilet.
>
> "Forth, the toilet-flusher!"
C the toilet contents...
jacko
Pascal J. Bourguignon
It is really anti-Ruby, granted, but it is as misdirected as it is
misaddressed.
For Ruby can be used in a nice way.
See for example:
Of course, there remains a lot of spurrious syntactic characters
required and random rules to apply, and it's not homoiconic, but I find
it slightly more acceptable, than eg. InteLib.
rusi
> On 2011-01-03, Didier Verna <did...@lrde.epita.fr> wrote:
>
There are more mundane reasons -- like unsuitability of lisp as a
distribution platform
[See http://www.newartisans.com/about-me.html where John Wiegley
explains why he switched from lisp to C++ for his program ledger ]
D Herring
> On Jan 3, 6:05 pm, Tim Harig<user...@ilthio.net> wrote:
>> What hurts the LISP community far more is the zealotry of its members,
>> their insistance that LISP is the *only* tool for *every* job, and their
>> agressiveness in trying to push it off on to everybody else -- whether
>> everybody else happens want it or not. Whether this is indicitive
>> of the entire community or simply the result of those most apparent,
>> I cannot say; but, it leads to the overall impression that the LISP
>> community is narrowminded and neophobic. Who would want to be part of
>> such a community?
Like the dark days of apple, bsd, and linux, there can be some bizarre
fanboyism in the lisp community. Geeks are always technical but often
not personable.
> There are more mundane reasons -- like unsuitability of lisp as a
> distribution platform
> [See http://www.newartisans.com/about-me.html where John Wiegley
> explains why he switched from lisp to C++ for his program ledger ]
First he says "It was originally written in C++, but lately I�ve been
porting it to Common Lisp, since I�ve realized how much simpler � and
more powerful � many of its aspects will become."
Then there's a cryptic "I found Common Lisp unsuitable as a
distribution platform."
Trying not to sound fanboyish, but there are numerous ways to
distribute lisp apps. There have been a couple notable improvements
in the last year; but several implementations have always offered to
spit out an ordinary, standalone executable.
I think many readers in the other cross posted newsgroups have seen
similar come-and-go users leave their favorite language.
- Daniel
Pascal J. Bourguignon
I saw no explanation, only the statements that he "found Common Lisp
unsuitable as a distribution platform."
Perhaps it was just him being unable to find an implementation of Common
Lisp suitable as distribution platform. I've got the impression a lot
of people are able to find such implementations of Common Lisp, to
distribute and deploy their applications, be it free software
implementations or commercial implementation.
In anycase, he gives no justification.
pineapple
> Is there a postfix functional language that also gets rid of parens
> and is not as primitive as FORTH or POSTSCRIPT ?
Joy.
Tim Harig
>> On Jan 3, 6:05 pm, Tim Harig<user...@ilthio.net> wrote:
>>> What hurts the LISP community far more is the zealotry of its members,
>>> their insistance that LISP is the *only* tool for *every* job, and their
>>> agressiveness in trying to push it off on to everybody else -- whether
>>> everybody else happens want it or not. Whether this is indicitive
>>> of the entire community or simply the result of those most apparent,
>>> I cannot say; but, it leads to the overall impression that the LISP
>>> community is narrowminded and neophobic. Who would want to be part of
>>> such a community?
>
> Like the dark days of apple, bsd, and linux, there can be some bizarre
> fanboyism in the lisp community. Geeks are always technical but often
> not personable.
1. You imply that the worst of the zealotry for Apple, BSD, and Linux is
over. When is it going to be over for LISP?
2. While I would agree that the listed groups have zealots among their
ranks; but, in my experience, most of them have resigned to the
fact that they often have to work with other systems. I would
suspect that most of their members are at least as knowledgable
about using Windows as most dedicated Windows users. Most of
them, when push comes to shove, will even admit that there
are things which they admire about other operating systems,
including Windows.
LISP users on the other hand, never seem to be able to let
go of LISP when the situation requires it. To be fair, most
newcomers to any given language will tend to let the idioms
from their previous language bleed into the new language.
This is an familiarity issue and most will gradually assimilate
into the mainstream as their knowledge and experience with the
language grows. Ultimately their knowledge and experience in
both langauges improves their overall abilities no matter what
language they may happen to be using. LISP users never seem
to do that. They seem to be unable, or unwilling, to learn
anything new.
Nicolas Neuss
> LISP users on the other hand, never seem to be able to let
> go of LISP when the situation requires it. To be fair, most
> newcomers to any given language will tend to let the idioms
> from their previous language bleed into the new language.
> This is an familiarity issue and most will gradually assimilate
> into the mainstream as their knowledge and experience with the
> language grows. Ultimately their knowledge and experience in
> both langauges improves their overall abilities no matter what
> language they may happen to be using. LISP users never seem
> to do that. They seem to be unable, or unwilling, to learn
> anything new.
Could you provide a reference? Of a respected Lisp user who is
unwilling to learn anything new if the situation requires it? In my
experience people who proselytize Lisp are very often semi-newbies who
do not stay long.
Nicolas
Tim Bradshaw
> LISP users on the other hand, never seem to be able to let
> go of LISP when the situation requires it.
I think this probably is not the case. It may be the case that the
Lisp users *you hear from* often have this view, but I don't think
those people are necessarily very representative of Lisp users as a
whole. Of course I can't really infer much about the ones you don't
hear from other than in a sort of dark-energy way - implementors are
probably the only people who might have a chance of knowing about them
in any reliable way.
For instance, I've been berated by the users you hear from for saying I
write (and like writing) Perl and (but not like very much) Java. I
don't think that makes me an atypical Lisp user, I just think it makes
me one of the few who are in the subset of Lisp users that you hear
from and who will admit to using other langages.
Didier Verna
> What hurts the LISP community far more is the zealotry of its members,
> their insistance that LISP is the *only* tool for *every* job, and
> their agressiveness in trying to push it off on to everybody else --
> whether everybody else happens want it or not. Whether this is
> indicitive of the entire community or simply the result of those most
> apparent, I cannot say; but, it leads to the overall impression that
> the LISP community is narrowminded and neophobic. Who would want to be
> part of such a community?
Not sure which lispers you've been talking to. I don't see any more
zealotry in the Lisp community than in any other one. I see, however,
things like Racket in which Lispers put a lot of efforts learning about
the cool stuff that comes from other languages and incorporating them
into their Lisp dialect (static typing, contracts, to name a few). Is
that narrowminded? Is it wrong to try to improve your preferred language
instead of switching to another one? These are the Lispers you should
talk to.
About the "*only* tool for *every* job" thing, there is often a
confusion between Lisp -- The Idea, and Lisp -- The Language(s). Lispers
usually like Lisp for its extreme customizability, something that is
closely related to Lisp -- The Idea (code is data, structural
reflexivity, the Lisp macros etc.). However, no programming language is
perfect, not even Lisp -- The Language(s). Common Lisp is far from
perfect, it's not perfect to have a gazillion Scheme dialects, let alone
Emacs Lisp.
The other thing that puzzles me is why you would be annoyed by people
trying to "push it off" on you. Maybe (just maybe ;-) I would try to
push off Lisp -- The Idea on you, but I wouldn't dare to try to push off
*any* language on you, because I don't know your background, your needs,
your interests etc. If somebody does that on me, I just ignore them.
w_a_x_man
> On Jan 2, 2:30 pm, w_a_x_man <w_a_x_...@yahoo.com> wrote:
>
> > On Jan 2, 2:17 pm, w_a_x_man <w_a_x_...@yahoo.com> wrote:
>
> > > >>(let ((p nil))
>
> > > (remove-if
> > > (lambda(x &rest y)(setq y p)(setq p x)(eql x y))
> > > '(a a b c a d d e e)))
>
> > > (A B C A D E)
> > >>(let ((prv)(tmp))
>
> > (remove-if (lambda(x)(setq tmp prv prv x)(eql x tmp))
> > '(a a b c a d d e e)))
>
> > (A B C A D E)
>
> (let ((prv))
> (remove-if (lambda(x)(eql x (shiftf prv x)))
> '(a a b c a d d e e)))
>
> (A B C A D E)
One final tweek.
(let (prv)
(remove-if (lambda(x)(eql x (shiftf prv x)))
'(a a b c a d d e e)))
(A B C A D E)
Tim Harig
> On 2011-01-04 08:02:35 +0000, Tim Harig said:
>
>> LISP users on the other hand, never seem to be able to let
>> go of LISP when the situation requires it.
>
> I think this probably is not the case. It may be the case that the
> Lisp users *you hear from* often have this view, but I don't think
> those people are necessarily very representative of Lisp users as a
> whole. Of course I can't really infer much about the ones you don't
> hear from other than in a sort of dark-energy way - implementors are
> probably the only people who might have a chance of knowing about them
> in any reliable way.
The loudest voices in the crowd tend to characterize the crowd.
Unfortunately, to my point, those vocal zealots in the LISP community
are not doing it any favors.
Perhaps I am alone in this, but I don't much appreciate being part of
communities that are too openly negative towards others. It really puts
a poor taste in my mouth. I am a right tool for the right job kind
of person and I prefer communities that are open enough to be able to
properly evaluate the role of their chosen tools compared to others.
Tim Bradshaw
> The loudest voices in the crowd tend to characterize the crowd.
They characterize how it *appears*, but only that.
Tamas K Papp
It would be great if you could substantiate your points with examples
(eg links to discussions on newsgroups or mailing lists). I have been
following c.l.l for years now, but I haven't seen the kind of zealotry
that you describe. Perhaps this is because Lisp zealots go to other
forums: this is of course possible, but I would be interested in
seeing examples of lispers being "openly negative towards others"
before entertaining the idea that this is some sort of general
tendency.
I don't believe that it is possible to have a meaningful discussion
about this question unless you are a lot more specific about your
claims.
Best,
Tamas
Tim Harig
No doubt; but, when somebody evaluates the language, their impressions
will be based far more on appearences then objective reality. My point
is, that simply offering assertions against the languages misconceptions
and/or touting the languages benefits may not be effective in generating
interest for the language -- even among those who might have strong use
cases for the LISP language.
In many instances, I think it would be more useful for the community
to appear be a little more open minded, inviting, and respectful of
other languages that a prospective LISP user might already have an
appreciation for. To do that, it needs to mitigate those negative voices
within the community that are carrying the furthest and providing the
negative contribution to the communities appearance.
Tim Bradshaw
> No doubt; but, when somebody evaluates the language, their impressions
> will be based far more on appearences then objective reality.
People who make decisions like that are pretty much doomed from the outset.
Also, when you talk about "the community" do you mean "people who post
in CLL?". Usenet is kind of dead: I doubt many people interested in
any language look for newsgroups now.
P.M.Lawrence
Not quite; that does use bracketing around chunks of code, as much as
anything for quoting purposes to allow lazy evaluation.
The problem with a completely postfix notation for a functional
language is that parameters are evaluated as they turn up, without
regard to the operation that needs them (as, without lookahead that
would destroy the gains from postfix notation, it isn't yet known what
will be needed). That appears to enforce strict evaluation, unless the
postfix notation is loosened with some quoting system.
However, I did some work on this myself for my Furphy project (see
http://users.beagle.com.au/peterl/furphy.html - but so far it's only a
prototype/testbed, and still quite "primitive"). I found an
indirection mechanism that gave lazy evaluation without a quoting
system, which I implemented with the complementary keywords FREEZE and
THAW. Even so, a quoting system is so convenient that I added one back
in - only, now it is a layer of syntactic sugar rather than an
alternative treatment of the source. I wanted to avoid that
alternative treatment so that inconsistencies wouldn't develop from
going in and out of postfix notation - I was even able to make keyword
naming postfix. P.M.Lawrence.
Raffael Cavallaro
> I saw no explanation, only the statements that he "found Common Lisp
> unsuitable as a distribution platform."
He also says he likes Mac OS X so maybe he was looking for a native Mac
OS X distribution option. Unless he was writing about a very recent
experience, the best free option, Clozure CL64/32, was not yet mature
enough that many would want to use it to distribute an application
(imho it is now).
The other option for native Mac apps has been available for years -
LispWorks - but it is not free. Never underestimate people's ability to
allow the desire for a no-cost solution to override better judgement.
Clearly, he thinks lisp is superior; he thinks Mac OS X is superior;
until recently, you had to pay to distribute this combination in a
native app using a mature implementation and IDE.
warmest regards,
Ralph
--
Raffael Cavallaro
Barry Fishman
> CL-USER> (let ((list '(t t t nil nil nil)))
> (loop for (a b) on (cons (gensym) list) unless (eql a b) collect b))
> (T NIL)
But:
* (let ((list '(nil nil nil t t t)))
(loop for (a b) on (cons (gensym) list) unless (eql a b) collect b))
(nil t nil)
Maybe:
* (defun xfilter (list)
(loop for b = (gensym) then a and for a in list unless (eql a b) collect a))
XFILTER
* (xfilter '(nil nil nil t t t nil nil nil))
(NIL T NIL)
* (xfilter '(t t t nil nil nil t t t))
(T NIL T)
* (xfilter '(a b c d e))
(A B C D E)
--
Barry Fishman
Mario S. Mommer
Great!
Well, one could argue that if all those smart, experienced people are
lead astray by loop in such subtle ways, then the evidence shows rather
clearly that loop is at least somewhat evil.
I tend to stay clear of it except for the simple cases, as I find its
more advanced features brittle, and not worth the effort needed to
figure them out and remember them.
Why not like this?
(defun xfilter (list &key (test #'eql) (key #'identity))
(let ((tsil (list (car list))))
(dolist (x (cdr list) (nreverse tsil))
(unless (funcall test
(funcall key (car tsil))
(funcall key x))
(push x tsil)))))
Christophe Rhodes
> Why not like this?
>
> (defun xfilter (list &key (test #'eql) (key #'identity))
> (let ((tsil (list (car list))))
> (dolist (x (cdr list) (nreverse tsil))
> (unless (funcall test
> (funcall key (car tsil))
> (funcall key x))
> (push x tsil)))))
(xfilter '())
Christophe
Tim X
I would add that it is a mistake to judge a community of users based on
a single forum. For example, many have complained about comp.lang.lisp
and it is often viewed as being the lisp community. In reality, it is
only a very small representation of lisp users from a single forum.
There are many other lisp forums with varying levels of acceptance,
hostility, dogma, experience, cynicism etc.
Judging the lisp community by what goes on in c.l.l is like stopping at
some remote town in the hills where everyone has the same nose and
concluding it is a national trait.
Personally, I enjoy c.l.l as I can easily recognise the threads to kill
and those which are likely to have some interesting information. Sure,
we may throw a few fists and end up rolling around in the pig shit from
time to time and sometimes one of the cousins may drink a bit much
'shine and probably should'nt pull out the shotgun, but what can you do,
its family.
--
tcross (at) rapttech dot com dot au
Tim Harig
>> On 2011-01-04 08:02:35 +0000, Tim Harig said:
>>
>>> LISP users on the other hand, never seem to be able to let
>>> go of LISP when the situation requires it.
>
> a single forum. For example, many have complained about comp.lang.lisp
> and it is often viewed as being the lisp community. In reality, it is
I don't subscribe to c.l.l. I came across this post in c.l.f and my post
is a general statement not really directed to the topic or poster but
merely to the comment about what is detrimental to the LISP community.
Most of my experience with LISP advocates comes from bleedthrough to
other groups or aquaintences in meat-space. I would expect advocacy in a
group dedicated to the language. In groups that are language agnostic,
I would expect a more sympathetic attitude towards other languages.
I certainly wouldn't expect them to spam groups dedicated to other
languages with LISP propoganda.
Tim X
> Barry Fishman <barry_...@acm.org> writes:
>> "Pascal J. Bourguignon" <p...@informatimago.com> writes:
>>> CL-USER> (let ((list '(t t t nil nil nil)))
>>> (loop for (a b) on (cons (gensym) list) unless (eql a b) collect b))
>>> (T NIL)
>>
>> But:
>>
>> * (let ((list '(nil nil nil t t t)))
>> (loop for (a b) on (cons (gensym) list) unless (eql a b) collect b))
>>
>> (nil t nil)
>>
>> Maybe:
>>
>> * (defun xfilter (list)
>> (loop for b = (gensym) then a and for a in list unless (eql a b) collect a))
>> XFILTER
>> * (xfilter '(nil nil nil t t t nil nil nil))
>> (NIL T NIL)
>> * (xfilter '(t t t nil nil nil t t t))
>> (T NIL T)
>> * (xfilter '(a b c d e))
>> (A B C D E)
>
> Great!
>
> Well, one could argue that if all those smart, experienced people are
> lead astray by loop in such subtle ways, then the evidence shows rather
> clearly that loop is at least somewhat evil.
>
I'm not convinced that loop was the problem here. I suspect the same
type of errors would have occured in many languages using a looping
solution. The problem was in simplistic modeling of possible input.
> I tend to stay clear of it except for the simple cases, as I find its
> more advanced features brittle, and not worth the effort needed to
> figure them out and remember them.
I've certainly found learning loop to be a challenge. However, I cannot
say I've ever found its solution brittle. I've found I've misunderstood
some of its advanced features, which has resulted in unexpectred
results. However, once I have got it right, it works reliably and
consistently.
One thing I do find with loop is that once you have managed to express
what you want, it is very clear and concise. Yes, learning how to
express your meaning using its language is tough initially, but once
you do, your intention is very clear.
>
> Why not like this?
>
> (defun xfilter (list &key (test #'eql) (key #'identity))
> (let ((tsil (list (car list))))
> (dolist (x (cdr list) (nreverse tsil))
> (unless (funcall test
> (funcall key (car tsil))
> (funcall key x))
> (push x tsil)))))
Yep seems pretty straight forward and I may have written something
similar. However, I still find the intent of the loop based solution to
be clearer in the sense it took me less conscious effort to parse.
Tim
Tim Bradshaw
> I would add that it is a mistake to judge a community of users based on
> a single forum. For example, many have complained about comp.lang.lisp
> and it is often viewed as being the lisp community. In reality, it is
> only a very small representation of lisp users from a single forum.
> There are many other lisp forums with varying levels of acceptance,
> hostility, dogma, experience, cynicism etc.
I think it's almost universally a mistake to judge anything by usenet
news, not just CLL. Newsgroups have always been odd and fierce places,
and (without evidence) I think usenet must be close to dead as a
discussion forum (as opposed to a media distribution mechanism where
it seems to be thriving).
Nicolas Neuss
> Why not like this?
>
> (defun xfilter (list &key (test #'eql) (key #'identity))
> (let ((tsil (list (car list))))
> (dolist (x (cdr list) (nreverse tsil))
> (unless (funcall test
> (funcall key (car tsil))
> (funcall key x))
> (push x tsil)))))
Here is a (hopefully) rather perfect version using LOOP (it is more
complicated as the versions before because of the additional TEST and
KEY parameters[*]):
(defun compress (list &key (test #'eql) (key #'identity))
(loop for a in list
and key-of-a = (funcall key a)
and key-of-b = nil then key-of-a
and firstp = t then nil
unless (or firstp (funcall test key-of-a key-of-b))
collect a))
There are several reasons why I would not prefer your version:
1. I find the multiple uses of LIST not very nice (i.e. if I can avoid
it without any costs I do it). Here "list" occurs even in a reversed
form as "tsil".
2. It uses CAR/CDR instead of FIRST/REST on standard lists. (I know
that this is a matter of taste.)
3. It uses destructive operations (PUSH) which I avoid if possible.
4. It does an unnecessary reversal of the result.
[5. It contains the error pointed out by Christophe (which could be
corrected, of course, making it probably longer).]
[6. It evaluates KEY twice on each element which means that it might be
two times slower in standard use cases. Again, this improvement
could be put into your version as well (making it longer).]
7. Most important: Show both code snippets to average programmers and
you will observe that 95% of them prefer the LOOP version.
Nicolas
[*] For making sure that no newbie puts the above in a utility function
library: Please use the built-in function DELETE-DUPLICATES!
Nicolas Neuss
> I don't subscribe to c.l.l. I came across this post in c.l.f and my
> post is a general statement not really directed to the topic or poster
> but merely to the comment about what is detrimental to the LISP
> community.
It is a severe reproach and should therefore be substantiated.
> Most of my experience with LISP advocates comes from bleedthrough to
> other groups or aquaintences in meat-space. I would expect advocacy
> in a group dedicated to the language. In groups that are language
> agnostic, I would expect a more sympathetic attitude towards other
> languages. I certainly wouldn't expect them to spam groups dedicated
> to other languages with LISP propoganda.
So is Xah Lee or Robert Maas your problem or is it someone else? Sorry,
but we can probably not help you there since these are unmoderated
newsgroups and we cannot stop trolls from posting and cross-posting.
Luckily, such messages can be identified easily. An interesting
possibility is to avoid any cross-posted threads.
Nicolas
Tim Harig
> Tim Harig <use...@ilthio.net> writes:
>
>> I don't subscribe to c.l.l. I came across this post in c.l.f and my
>> post is a general statement not really directed to the topic or poster
>> but merely to the comment about what is detrimental to the LISP
>> community.
>
> It is a severe reproach and should therefore be substantiated.
It isn't meant as a reproach. It is meant as a simple piece of advice
for those who would like to make an inviting community, which seems to
have been a goal in the post where I originally replied. If that is
not your goal, then you may safely ignore my remarks. They are merely
provided as feedback.
>> Most of my experience with LISP advocates comes from bleedthrough to
>> other groups or aquaintences in meat-space. I would expect advocacy
>> in a group dedicated to the language. In groups that are language
>> agnostic, I would expect a more sympathetic attitude towards other
>> languages. I certainly wouldn't expect them to spam groups dedicated
>> to other languages with LISP propoganda.
>
> So is Xah Lee or Robert Maas your problem or is it someone else? Sorry,
I was going to say that I wasn't targeting anybody specific; but, since
you mentioned him, I do notice that Xah Lee might have been one of
my examples. Somewhere along the line he landed in my killfile/scorefile.
> but we can probably not help you there since these are unmoderated
> newsgroups and we cannot stop trolls from posting and cross-posting.
> Luckily, such messages can be identified easily. An interesting
> possibility is to avoid any cross-posted threads.
That is true for trolls that are not actually part of your community.
Frankly, since I don't follow c.l.l, or any other LISP specific
group, I don't know who is and who isn't a part of that community.
Other languages, however, seem to keep the appearence of being far
less interested in advocacy. I would seem that the culture of those
communities promotes an open
Note that, it isn't just a matter of my reading and ignoring LISP
advocacy. Frankly, I could care less. I just ignore it; but, then
I don't post many questions to usenet which, for better or worse, has
merely become a question and answer arena in the technical forums.
I have seen examples where questions posted in language agnostic groups
have been answered using LISP after the poster has indicated they
have no familiarity with language. The message seems to be: if you
don't share my choice of language, then you don't deserver an answer.
I can sympathize with people who have received that response. Trying to
learn a new concept is often trouble enough without having to learn a
new language to comprehend the given examples.
For my own part, when posting in language agnostic groups/forums, I
try to answer in psuedocode or as an English sequence of instructions.
That way, I am not forcing the receiver to use my language of choice
for solving the problem. If it isn't possible to answer the question
in general terms; then, I will try to answer in a language that is as
close as possible to the language the OP indicates he or she is using.
If all else fails, I try to use a language that most programmers are
probably familiar with and/or should be able to follow even if they come
from a very different language. (Javascript being a common example.)
I simply consider that to be a common courtesy and a boon to advancing
the communication of the discussion.
Nicolas Neuss
>> So is Xah Lee or Robert Maas your problem or is it someone else? Sorry,
>
> I was going to say that I wasn't targeting anybody specific; but, since
> you mentioned him, I do notice that Xah Lee might have been one of
> my examples. Somewhere along the line he landed in my killfile/scorefile.
>
>> but we can probably not help you there since these are unmoderated
>> newsgroups and we cannot stop trolls from posting and cross-posting.
>> Luckily, such messages can be identified easily. An interesting
>> possibility is to avoid any cross-posted threads.
>
> That is true for trolls that are not actually part of your community.
No troll is "part" of any reasonable community.
> I have seen examples where questions posted in language agnostic
> groups have been answered using LISP after the poster has indicated
> they have no familiarity with language.
How can I help then at all? :-)
You know, I have even seen questions _for Common Lisp code_ answered by
Ruby, OCaml, etc code. However, I don't blame the respective
communities for this.
Nicolass
Tim Bradshaw
> It isn't meant as a reproach. It is meant as a simple piece of advice
> for those who would like to make an inviting community, which seems to
> have been a goal in the post where I originally replied. If that is
> not your goal, then you may safely ignore my remarks. They are merely
> provided as feedback.
As regards CLL: it's been at least as fierce as it is now for a very
long time (at least 10 years: I don't really remember so well how
fierce it was in the 10 years before that any more, but I think it was
much the same), despite occasional discussions like this. So it's
almost certainly the case that you're wasting your time: if you want to
modify the behaviour of a Lisp community, CLL isn't the one to try.
Which I guess might lead one to wonder why you are investing all this
effort into something so obviously doomed.
Tim Harig
>> groups have been answered using LISP after the poster has indicated
>> they have no familiarity with language.
>
> How can I help then at all? :-)
>
> You know, I have even seen questions _for Common Lisp code_ answered by
> Ruby, OCaml, etc code. However, I don't blame the respective
> communities for this.
You keep assuming that I blame somebody. I don't. I have merely made
an observation. I am not even saying that is the right thing to do
because I don't know what the LISP communities goals are. Sometimes
communities degrade as they grow larger. I am merely saying, that *if*
the LISP community would like to draw more people to the LISP language,
which the poster seemed interesting in doing, it might help to improve
the appearance of the community at large.
Every group has is vocal advocates; but, some groups seem to be louder
then others. The community has no control over trolls and little over
its own members. It can however set an example and direction. If the
example that it sets is that it should be more open for the benefit
of the community, then those who truely value that community should
follow suit. No, it wouldn't stop all of the problems; but, I would
think making an effort to improve what is possible must be better then
simply doing nothing because you cannot comletely solve the problem.
Every little bit helps.
Xah Lee
On Dec 31 2010, 11:04 pm, girosenth <girose...@india.com> wrote:
> How to improve the readability of (any) LISP or any highlevel
> functional language to the level of FORTH ?
>
> There are many people who have trivia complaints about parens in lisp,
> but I dont.
>
> LISP is a prefix notation.
Note that calling lisp syntax as “prefix” is misleading.
When you say “prefix” or “postfix” notation, implied in the word is
use of operators and their general ordering characteristics.
lisp syntax does not use operators, or rather, it primarily relies on
one single match-fix operator the parenthesis. And as a match-fix
operator, the word “pre-fix” doesn't make much sense because that word
is primarly for operators used in a linear (none nested) way.
for detail, see:
〈The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations〉
http://xahlee.org/UnixResource_dir/writ/notations.html
> sequence of operations would look like this on operands (ops) :
>
> (f ops (g ops (h ops (j ops (k ops (l ops ))...))))
>
> How do you make it readable ?
> How do you home to the center or centers ?
>
> (f (g (h (j (k (l ops)))...)))
>
> is easy to read or
>
> ops l k j h g f
>
> ???
>
> Which is linear reading from L->R ? LISP or FORTH ?
>
> AND, if I must break the nested function structure, will I not be
> visiting the forbidden territory of imperative programming ?
>
> (setq L (l ops))
> (setq K (k L ))
> ....
> ....
> (setq F (f G ))
>
> If I use setq, I am using globals, atleast in elisp.
>
> If I use let*, I have limited options as I am constrained inside the
> rigid structure of let*
>
> (let*
> ((L (l ops))
> (K (k L ))
> ....
> (F (f G )))
>
> some more
> )
>
> Is there a postfix functional language that also gets rid of parens
> and is not as primitive as FORTH or POSTSCRIPT ?
you might get some tips about this from this article:
〈What's Point-free Programing? (point-free function syntax)〉
http://xahlee.org/comp/point-free_programing.html
i've thought about a syntax that does not use any match-fix operators
(nesting of symbols) whatsoever. But my current conclusion is that
• strictly no nesting whatsoever is not a desired property.
• when done to a large extend yet not 100% (e.g. APL and derivatives),
you sacrifice several advantages in syntax and also some semantic
possibilty in the lang.
also note, reduction or elimination of match-fix operators in so-
called stack
based lang such as Forth, does not really qualify as a syntactical
solution. It
rids of match-fix by a semantic solution. (i.e. there's implicit
hiding of
arguments, they went into a “stack”). Another way to view this is
that, when we
look at Forth (which am not familiar) or HP-28s calculator's language
(which i'm
familiar), or if we look at so-called “reverse polish notation” RPN,
the RPN is
not a complete syntx system on its own right, but relies on a language
system... (not sure if anyone see what i mean here... i need to do a
lot more
thinking to express this in some “formal” way, so as to clearly
indicate the
properties differences)
> What are the syntax advantages of ERLANG, ML, CAML, OCAML, HASKELL,
> PROLOG, RUBY over LISP ?
that's a loaded question of course.
but my own pet peeves is that there is to-date no major general
purpose comp lang that actually have a lexical grammar. The awareness
of the concept of a grammar for syntax is little known among
programers. Each lang basically create a bunch of ad hoc syntax, that
are not consistent nor well defined. In fact, no major general purpose
languages even have a lexical grammar per se. (what we have are just
tools that helps define and parse)
The only close exception is XML, but of course it is just a markup
lang.
for some detail, see:
• 〈Math Notations, Computer Languages, and the “Form” in Formalism〉
http://xahlee.org/cmaci/notation/lang_notation_formalism.html
• 〈Pattern Matching vs Lexical Grammar Specification〉
http://xahlee.org/cmaci/notation/pattern_matching_vs_pattern_spec.html
> How does one improve readability so that the code is self-commenting ?
it's a common myth among programers that certain lang's syntax is so
clear that it is “self-documenting”. For example, lisp coders said it
in 1970s or earlier when sexp and the idea of a lang that reflex math
directly is new. Mathematica literature said it in 1990s because
pattern matching is a good fit for symbolic manipulation. Haskeller
has said it because they think Haskell code is so much a direct mirror
of traditional math notation (and this is quite laughable when
compared to Mathematica). And Ruby coder said it because they feel how
the syntax mirror programing algorithms so clearly and concisely.
Perl mongers to various degree also thinks of that of their lang,
because how the perl idioms allow ommision of many syntactical details
and quite flexible and they think it reflect the way human uses
natural lang (e.g. english).
so, sometimes in discussion, someone show you a line of code without
any comment or explanation. To you, you are perplexed at what the code
does. When you ask, you find out that they are honestly surprised
because they think that the code's meaning is so plain and obvious
that any additional explanation actually complicate it.
part of all these feelings is due to the fact that when you are
familiar with a lang, it becomes part of your thinking, a written
language to express your thoughts. Especially so if you don't know
much of other langs. You are too familiar with the lang to realize the
fact that different languages have always been a barrior to
communication. The more expert you are with a lang, and the less the
number of other langs you actually work with in depth, the more likely
you forgot that different langs are just different. What's obvious to
you, even just a short line, is really just a string of gibberish
symbols mixed together in weird ways to another who are not familiar
with your lang.
So, your question «How does one improve readability so that the code
is self-commenting ?» has many answers depending what you really want.
Comp lang syntax readability is a subject in the context psychology
and linguistics. Among comp lang forums among programers, they knew
nothing of it, and what you read there usually is utter garbage. But
to take a general programer practioners's point of view, for example,
Python is considered very readable, and the primary reason for sayig
so is actually just code formatting (i.e. short lines, and all neatly
indented), and the reason python code are well formatted because the
formatting is worked into the language's syntax.
take a complete different perspective, there's Mathematica. For
example, what do you think if comp lang source code are like
traditional math notation that's so-call 2-dimentional notation? e.g.
you have 「x^3」 with the 3 raised, you have 1/2 with 1 on top of a bar
and 2 below the bar, etc. And when the expression gets complex, e.g.
-b + Sqrt[b^2-4 a c]/(2 a)
it becomes much easier to read when in traditional math notation. In
Mathematica, its syntax system is such that, it can display the source
code in 2-dimentional notation automatically, if you want. you can see
some example here, also in PDF format
〈Math Typesetting, Mathematica, MathML〉 http://xahlee.org/math/typesetting_Mathematica_mathML.html
The same expression in lisp style you get this
/(+(-(b) √(+(^(b 2) -(*(4 a c))))) *(2 a))
is it readable? Many lispers insist that its the most readable syntax.
See also:
• 〈What's Function, What's Operator?〉 http://xahlee.org/math/function_and_operators.html
Xah ∑ http://xahlee.org/ ☄
Andrew Haley
>
> lisp syntax does not use operators, or rather, it primarily relies on
> one single match-fix operator the parenthesis. And as a match-fix
> is primarly for operators used in a linear (none nested) way.
>
> for detail, see:
>
> Nested Notations?
> http://xahlee.org/UnixResource_dir/writ/notations.html
Given that the article even manages to confuse Polish notation and
Reverse Polish notation, I strongly recommend that everyone avoid it.
Andrew.
BruceMcF
> also note, reduction or elimination of match-fix operators in
> qualify as a syntactical solution.
Precisely ~ qualifying as being a syntactical solution is a purely
academic issue that is often tangential to the solution of actual
problems, while having an excess of syntax in the base of Forth would
get in the way of converting it into the specialized application
language that fits the problem at hand. So eliminating the need for
syntax is quite often the design approach adopted for the core
language.
Duane Rettig
> On 2011-01-05, Nicolas Neuss <lastn...@kit.edu> wrote:
>
> > Tim Harig <user...@ilthio.net> writes:
>
> >> I don't subscribe to c.l.l. I came across this post in c.l.f and my
> >> post is a general statement not really directed to the topic or poster
> >> but merely to the comment about what is detrimental to the LISP
> >> community.
>
> > It is a severe reproach and should therefore be substantiated.
>
> It isn't meant as a reproach. It is meant as a simple piece of advice
> for those who would like to make an inviting community, which seems to
> have been a goal in the post where I originally replied. If that is
> not your goal, then you may safely ignore my remarks. They are merely
> provided as feedback.
This is ignorant advice. It assumes that the Lisp community can be
equated with c.l.l or that c.l.l has a goal. Well, a newsgroup
certainly has goals, stated in its creation, but it is the members of
the newsgroup which determines the direction it takes, and so only a
moderated newsgroup stands any chance of not being taken over by
others whose agenda don't match the goals of the newsgroup. That also
includes the agenda of a poster who has his own wisdom to impart on
the unwashed masses of that newsgroup.
> > but we can probably not help you there since these are unmoderated
> > newsgroups and we cannot stop trolls from posting and cross-posting.
> > Luckily, such messages can be identified easily. An interesting
> > possibility is to avoid any cross-posted threads.
>
> That is true for trolls that are not actually part of your community.
> Frankly, since I don't follow c.l.l, or any other LISP specific
> group, I don't know who is and who isn't a part of that community.
Careful; you are in danger of becoming the very kind of troll you
would place in your kill-file. I had originally written you off as
what I call a "hit and run" troll: many newsgroups have people pop in
an back out saying something like "I don't read this newsgroup, but I
have this to say; don't bother replying because I won't see your
reply". Happily, I've seen that since you are answering others the
"hit and run" portion does not apply, and also since you seem to be
honestly trying to answer people's responses, I'm now considering you
not to be a troll (but only by a hair; very much more insistence on
making your single point will drive you back over the line...)
> Other languages, however, seem to keep the appearence of being far
> less interested in advocacy. I would seem that the culture of those
> communities promotes an open
Unfinished thought here? Or simple attention deficit?
Other languages may have their only source of advocacy in their
newsgroups. Lisp (and especially Common Lisp, since it has no
specific newsgroup) is so much bigger than c.l.l. that it needs not
beat against the wall of attempted advocacy in an unmoderated
newsgroup.
> Note that, it isn't just a matter of my reading and ignoring LISP
> advocacy. Frankly, I could care less. I just ignore it; but, then
> I don't post many questions to usenet which, for better or worse, has
> merely become a question and answer arena in the technical forums.
Well, there you have it. If a language had vendors who maintained
excellent mailing lists for support and such questions to be answered,
then you would indeed expect that its "newsgroup" would become less
bound up in those kinds of discussions, and thus left over would be
the kinds of conversations like the one we're having now. Who'd-a-
thunk?
> I have seen examples where questions posted in language agnostic groups
> have been answered using LISP after the poster has indicated they
> have no familiarity with language. The message seems to be: if you
> don't share my choice of language, then you don't deserver an answer.
> I can sympathize with people who have received that response. Trying to
> learn a new concept is often trouble enough without having to learn a
> new language to comprehend the given examples.
Of course, any advocacy will be done in the manner in which the
advocate likes to present. Some such advocacy is effective, and other
kinds are less effective. I read comp.arch, and have in the past
posted there, including Common Lisp code. But my code almost always
includes one or more calls to disassemble, so that the readers can see
what the code is doing without ambiguity. This seems effective.
> For my own part, when posting in language agnostic groups/forums, I
> try to answer in psuedocode or as an English sequence of instructions.
If you are posting pseudocode, then you are advocating that
pseudocode, and the reader still has to decipher what you had meant,
because in many cases the pseudocode is not precise enough for a
discussion of the details. But many people, even those who don't
actually use Lisp, consider Lisp to be its own pseudocode, which is
one reason why you often see it in examples.
> That way, I am not forcing the receiver to use my language of choice
> for solving the problem.
> If it isn't possible to answer the question
> in general terms; then, I will try to answer in a language that is as
> close as possible to the language the OP indicates he or she is using.
In this paragraph, this statement above is the only one I agree with.
See below.
> If all else fails, I try to use a language that most programmers are
> probably familiar with and/or should be able to follow even if they come
> from a very different language. (Javascript being a common example.)
> I simply consider that to be a common courtesy and a boon to advancing
> the communication of the discussion.
I don't know Javascript, so you'd better not use that as an example
around me (at least, if you want to see me understand it, or not gloss
over it as just a bit of language-specific code to ignore). Really,
you don't know what language someone knows or not, so it's a crap
shoot as to whether you're really going to connect with the reader
_unless_ you use the language of the stated forum. In c.l.l that
language is Lisp (any lisp). Go with the native language of the forum
and you will indeed reach the most readers.
Duane
Elena
> The same expression in lisp style you get this
>
> /(+(-(b) √(+(^(b 2) -(*(4 a c))))) *(2 a))
>
> is it readable? Many lispers insist that its the most readable syntax.
And here is why: http://blo.udoidio.info/2008/09/lisp-syntax-is-great.html
Xah Lee
oops, a typo. Copied the wrong line. The correct form is
(/ (+ (- b) (√ (+ (^ b 2) (- (* 4 a c))))) (* 2 a))
article on my blog now
http://xahlee.blogspot.com/2011/01/whats-most-readable-computer-language.html
Xah
Pascal J. Bourguignon
As most of what he writes...
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Pascal J. Bourguignon
He's wrong, the most readable is:
(divide (minus (square-root (minus (square b) (* 4 a c)))
b)
2 a)
or, for wanbees:
(/ (- (sqrt (- (square b) (* 4 a c))) b)
2 a)
Tim Harig
> On Jan 5, 5:24 am, Tim Harig <user...@ilthio.net> wrote:
>> On 2011-01-05, Nicolas Neuss <lastn...@kit.edu> wrote:
>> That is true for trolls that are not actually part of your community.
>> Frankly, since I don't follow c.l.l, or any other LISP specific
>> group, I don't know who is and who isn't a part of that community.
>
> Careful; you are in danger of becoming the very kind of troll you
> would place in your kill-file. I had originally written you off as
> what I call a "hit and run" troll: many newsgroups have people pop in
> an back out saying something like "I don't read this newsgroup, but I
> have this to say; don't bother replying because I won't see your
> reply". Happily, I've seen that since you are answering others the
> "hit and run" portion does not apply, and also since you seem to be
> honestly trying to answer people's responses, I'm now considering you
> not to be a troll (but only by a hair; very much more insistence on
> making your single point will drive you back over the line...)
I wouldn't blame you for considering me a troll from this thread alone. If
you question whether or not I am a troll, you should probably look at my
posting history in an archive.
I follow far more groups then I actually post to. For instance, I follow
c.l.ada; but, I have never posted there because of the extreme negativity
that they hold towards C programmers. I do like the Ada language and I
occassionally learn from what is posted.
I don't subscribe to c.l.lisp but I do follow c.l.functional where
this was cross-posted. I am rather new to the concepts of functional
programming so I subscribed and have been monitoring this ng in the hopes
of learning functional programming idioms and techniques. I don't post
much 1. because this ng doesn't receive a lot of traffic and 2. because
my limited knowledge in this area means I wouldn't have much constructive
to say anyway even if it did.
Actually, now that I think about it, I have posted to c.l.functional before:
> Message-ID: <icgs0h$6se$1...@speranza.aioe.org>
http://groups.google.com/group/comp.lang.functional/msg/b8f6221d18f6baee?dmode=source
>> Other languages, however, seem to keep the appearence of being far
>> less interested in advocacy. I would seem that the culture of those
>> communities promotes an open
>
> Unfinished thought here? Or simple attention deficit?
Yes, it was unfinished. Sorry. I have been running on limited sleep for
the past few days so I am a little lupy.
>> For my own part, when posting in language agnostic groups/forums, I
>> try to answer in psuedocode or as an English sequence of instructions.
>
> If you are posting pseudocode, then you are advocating that
> pseudocode, and the reader still has to decipher what you had meant,
> because in many cases the pseudocode is not precise enough for a
> discussion of the details. But many people, even those who don't
> actually use Lisp, consider Lisp to be its own pseudocode, which is
> one reason why you often see it in examples.
I am sure that everybody considers their own language preferences to be
its own psuedocode. The truth is often far from the case.
Basic concepts such as algorithms or data structures can often be described
in language inspecific terms. A linked list works pretty equivilantly in
any language containing pointers or references even though the syntax for
accessing the next node might vary significantly.
>> If all else fails, I try to use a language that most programmers are
>> probably familiar with and/or should be able to follow even if they come
>> from a very different language. (Javascript being a common example.)
>> I simply consider that to be a common courtesy and a boon to advancing
>> the communication of the discussion.
>
> I don't know Javascript, so you'd better not use that as an example
> around me (at least, if you want to see me understand it, or not gloss
> over it as just a bit of language-specific code to ignore). Really,
I am not a big fan of Javascript myself; but, it is one of the most
widely known languages. I have seen reports which suggest that it
is one of the most common first programming languages because of its
association with the web. It shares a similar syntax to the so-called
and widely distributed curly brace languages so anybody with a C/Java/etc
background should be able to make heads or tails of it. It also has well
as a strong functional (but not purely functional) background so it is
possible to demonstrate functional concepts as well as imperative ones.
Implementations are also available without having to install additional
software (compilers, interpreters, etc) on almost every major network
platform; so, it is possible for the user to experiment with the
example code. I cannot think of a language that is more likely to be
recoginized and available, even if there are people like you who may
not understand it. It is simply a matter of probability. That is why I
might default to Javascript for examples.
> you don't know what language someone knows or not, so it's a crap
> shoot as to whether you're really going to connect with the reader
> _unless_ you use the language of the stated forum. In c.l.l that
What exactly is the "stated language" for forums such as comp.programming
or c.l.functional? Sometimes the poster states their language and
sometimes they provide example code to help describe their problem.
Sometimes I provide a list of the languages I know and simply ask
them which language they would prefer the example in. I generaly find
a language with enough common concepts to a language that the poster
knows to to be able to communicate -- even when we don't share a single
common language.
Paul Rubin
> (let ((tsil (list (car list))))
Recursive implementation seems simplest if you don't mind the stack
consumption. No fancy macros, just straightforward COND:
(defun xfilter (xs)
(cond
((null xs) nil)
((null (cdr xs)) xs)
((eq (car xs) (cadr xs)) (xfilter (cdr xs)))
(t (cons (car xs) (xfilter (cdr xs))))))
* (xfilter '(1 2 3 3 3 4 4 3))
(1 2 3 4 3)
Pascal J. Bourguignon
> m_mo...@yahoo.com (Mario S. Mommer) writes:
>> (defun xfilter (list &key (test #'eql) (key #'identity))
>> (let ((tsil (list (car list))))
>> (dolist (x (cdr list) (nreverse tsil)) ...
>
> Recursive implementation seems simplest if you don't mind the stack
> consumption. No fancy macros, just straightforward COND:
Which is a macro. Perhaps not fancy, but still a macro.
DEFUN too is a macro, by the way.
> (defun xfilter (xs)
> (cond
> ((null xs) nil)
> ((null (cdr xs)) xs)
> ((eq (car xs) (cadr xs)) (xfilter (cdr xs)))
> (t (cons (car xs) (xfilter (cdr xs))))))
>
> * (xfilter '(1 2 3 3 3 4 4 3))
> (1 2 3 4 3)
Macroless lisp is more like assembler.
Try it again with TAGBODY and GO.
Doug Hoffman
> Elena<egar...@gmail.com> writes:
>
>> On Jan 5, 3:58 pm, Xah Lee<xah...@gmail.com> wrote:
>>> The same expression in lisp style you get this
>>>
>>> /(+(-(b) √(+(^(b 2) -(*(4 a c))))) *(2 a))
>>>
>>> is it readable? Many lispers insist that its the most readable syntax.
>>
>> And here is why: http://blo.udoidio.info/2008/09/lisp-syntax-is-great.html
>
> He's wrong, the most readable is:
>
> (divide (minus (square-root (minus (square b) (* 4 a c)))
> b)
> 2 a)
>
> or, for wanbees:
>
> (/ (- (sqrt (- (square b) (* 4 a c))) b)
> 2 a)
Without getting into the issues of the proper way to handle the
quadratic (this has been thoroughly hashed thru on comp.lang.forth) and
sticking with just the simple equation as presented (I'll ignore the
issue of taking the square root of negative numbers) I would make the
following observations:
1)
> (divide (minus (square-root (minus (square b) (* 4 a c))) b) 2 a)
This may be very readable for Lispers. For others not so much.
2) The following is one way (of many) to approach this in standard Forth:
: quad f{ a b c -- root }
b FNEGATE b FDUP F* 4e a c F* F* F- FSQRT F+ 2e a F* F/
;
-2e 7e 15e quad f.
-1.500000
Is it readable? Unless you're a Forther I would say no. But notice the
complete lack of parentheses and operator precedences to resolve. Any
competent Forther could quickly see exactly what is going on.
3) We have available in Forth a FORmula TRANslator utility (it is not
part of the official ANS Forth standard). It could be applied in this
situation as follows:
: quad2 f{ a b c -- root }
f' (-b + sqrt(b^2 - 4*a*c))/(2*a)'
;
-2e 7e 15e quad2 f.
-1.500000
Is it readable? I would say yes. Note that it compiles *exactly* the
same Forth code as quad in 2).
4) I am able to do a copy/paste of
=(-b + sqrt(b^2 - 4*a*c))/(2*a)
into an Excel spreadsheet and with the variables a, b, and c defined
the spreadsheet gives the expected results.
-Doug
Edmunds Cers
> 3) We have available in Forth a FORmula TRANslator utility (it is not
> part of the official ANS Forth standard). It could be applied in this
> situation as follows:
>
> : quad2 f{ a b c -- root }
> f' (-b + sqrt(b^2 - 4*a*c))/(2*a)'
> ;
>
> -2e 7e 15e quad2 f.
> -1.500000
>
> Is it readable? I would say yes. Note that it compiles *exactly* the
> same Forth code as quad in 2).
In fact, there is the infix package for Common Lisp that defines the #I
reader macro which does just that. With the infix package one would
simply write
#I( (-b + sqrt(b^^2 - 4*a*c))/(2*a) )
which expands to
(/ (+ (- B) (SQRT (- (EXPT B 2) (* 4 A C)))) (* 2 A))
as expected.
Nicolas Neuss
> Here is a (hopefully) rather perfect version using LOOP (it is more
> complicated as the versions before because of the additional TEST and
> KEY parameters[*]):
>
> (defun compress (list &key (test #'eql) (key #'identity))
> (loop for a in list
> and key-of-a = (funcall key a)
> and key-of-b = nil then key-of-a
> and firstp = t then nil
> unless (or firstp (funcall test key-of-a key-of-b))
Unfortunately, my hope was unjustified because this line should read:
unless (and (not firstp) (funcall test key-of-a key-of-b))
> collect a))
Nicolas
Nicolas Neuss
Still not correct (I admit, LOOP can be a beast:-). Here is my final
word:
(defun compress (list &key (test #'eql) (key #'identity))
(loop for a in list
for key-of-a = (funcall key a)
and key-of-b = nil then key-of-a
and firstp = t then nil
when (or firstp (not (funcall test key-of-a key-of-b)))
collect a))
Better use DELETE-DUPLICATES!
Nicolas
Barry Fishman
> Paul Rubin <no.e...@nospam.invalid> writes:
>
>> m_mo...@yahoo.com (Mario S. Mommer) writes:
>>> (defun xfilter (list &key (test #'eql) (key #'identity))
>>> (let ((tsil (list (car list))))
>>> (dolist (x (cdr list) (nreverse tsil)) ...
>>
>> Recursive implementation seems simplest if you don't mind the stack
>> consumption. No fancy macros, just straightforward COND:
>
> Which is a macro. Perhaps not fancy, but still a macro.
> DEFUN too is a macro, by the way.
He did say fancy macros. I don't think cond is all that fancy.
>> (defun xfilter (xs)
>> (cond
>> ((null xs) nil)
>> ((null (cdr xs)) xs)
>> ((eq (car xs) (cadr xs)) (xfilter (cdr xs)))
>> (t (cons (car xs) (xfilter (cdr xs))))))
>>
>> * (xfilter '(1 2 3 3 3 4 4 3))
>> (1 2 3 4 3)
>
> Macroless lisp is more like assembler.
> Try it again with TAGBODY and GO.
If you want recursion, you might as well make it tail recursive
which at least some lisps can do effiently.
(defun xfilter (list &optional (result nil))
(if (null list)
(nreverse result)
(if (and (cdr list) (eql (car list) (cadr list)))
(xfilter (cdr list) result)
(xfilter (cdr list) (cons (car list) result)))))
Without a nasty cond. If you don't like the &optional, you
can move the body into a labels.
--
Barry Fishman