🚀 go-pugleaf

On Jan 1, 8:04 am, girosenth <girose...@india.com> wrote:
> 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/

girosenth <girosenth@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.

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 {}.

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.

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.

Hi

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

On Jan 1, 6:15 am, "Pascal J. Bourguignon" <p...@informatimago.com>
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 -

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.

>
> 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).

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.


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/

The Quiet Center schrieb:
> %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).

> On Jan 1, 11:08 am, Nathan <nbeen...@gmail.com> wrote:
> > 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.

> 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

The same more explicit and less buggy

grep { if ($_ ne $l) { $l = $_ ; 1 } } LIST

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
    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.

On 01/01/2011 06:56 PM, Pascal Costanza wrote:
> 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

Nathan <nbeenken@gmail.com> writes:
> 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.

On Jan 1, 5:56 pm, The Quiet Center <thequietcen...@gmail.com> wrote:
> 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"]

On Jan 1, 11:36 pm, Nathan <nbeen...@gmail.com> wrote:
> 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.

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.

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

The Quiet Center <thequietcenter@gmail.com> writes:

> 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

D Herring <dherring@at.tentpost.dot.com> writes:

> On 01/01/2011 06:56 PM, Pascal Costanza wrote:
>> 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.

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

In article <m2pqsf9yqg.fsf@ccde007.de.goenninger.net>, 
dg1sbg@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.)

> > No, I'm not proud of that ...
>
> > 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...

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?

In article <ce0f5c3b-bc71-4868-8d2b-5495583ccfa8
@w18g2000vbe.googlegroups.com>, lanx.perl@googlemail.com says...
> 
> 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?

http://codepad.org/eGFuJrHZ

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...

D Herring wrote:

> On 01/01/2011 06:56 PM, Pascal Costanza wrote:
>> 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.

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/

On Jan 2, 6:59 am, Doug Hoffman <glide...@gmail.com> wrote:
> 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!"

LanX <lanx.perl@googlemail.com> writes:
>>    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.

On Jan 3, 6:05 pm, Tim Harig <user...@ilthio.net> wrote:
> On 2011-01-03, Didier Verna <did...@lrde.epita.fr> wrote:
>
> > Nathan <nbeen...@gmail.com> wrote:
>
> >> Matz himself admitted that ???...Ruby is a bad rip-off of Lisp... But it
> >> 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?

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 ]

On 01/03/2011 11:49 PM, rusi wrote:
> 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

rusi <rustompmody@gmail.com> writes:

> On Jan 3, 6:05�pm, Tim Harig <user...@ilthio.net> wrote:
>> On 2011-01-03, Didier Verna <did...@lrde.epita.fr> wrote:
>>
>> > Nathan <nbeen...@gmail.com> wrote:
>>
>> >> Matz himself admitted that ???...Ruby is a bad rip-off of Lisp... But it
>> >> 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?
>
> 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 ]

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.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

On Jan 1, 2:04 pm, girosenth <girose...@india.com> wrote:

> Is there a postfix functional language that also gets rid of parens
> and is not as primitive as FORTH or POSTSCRIPT ?

Joy.

http://en.wikipedia.org/wiki/Joy_(programming_language)

On 2011-01-04, D Herring <dherring@at.tentpost.dot.com> wrote:
>> 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.

Tim Harig <usernet@ilthio.net> writes:

> 	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 Harig <usernet@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?

  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.

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

pineapple wrote:
> On Jan 1, 2:04 pm, girosenth <girose...@india.com> wrote:
>
> > Is there a postfix functional language that also gets rid of parens
> > and is not as primitive as FORTH or POSTSCRIPT ?
>
> Joy.
>
> http://en.wikipedia.org/wiki/Joy_(programming_language)

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.