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
Steve Revilak
>How to improve the readability of (any) LISP or any highlevel
>functional language to the level of FORTH ?
I am not familiar with forth, but I can respond to the general issue
of improving code readability.
>How does one improve readability so that the code is self-commenting ?
I believe that you need to think of the act of writing a program as an
act of *writing*.
Many writers start with an outline, then a first draft, then many
rounds of revision and editing. The goal of the first draft is to get
the basic ideas down. The goal of revision and editing is to polish
the ideas, and to make them easier for the reader to understand. It's
rare for a first draft to be the final version.
Writing a program is no different. The first draft is the first
version that runs without crashing :) The editing and revision process
is where you clean things up, improve structure, and so fourth.
You should also read lots of code, to get ideas from other writers.
In short, the writer influences readability much more than the
language that he or she is writing in.
Steve
prad
> How to improve the readability of (any) LISP or any highlevel
> functional language to the level of FORTH ?
>
having come to lisp from haskell which i thought was very elegant, i was
initially dismayed by the increased verbosity and those
parentheses. however, now haskell looks funny and lisp reads
beautifully, so part of it is no doubt a matter of usage.
i also found that working down rather than across helps a lot. so
instead of
(setq whatever (func1 (func2 x y) (func3 a b))
this sort of thing is often preferable
(setq whatever
(func1 (func2 x y)
(func3 a b)))
--
in friendship,
prad
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
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...
Drew Adams
The `loop' macro is scarcely Lisp ;-). Its syntax is certainly is not very
representative of Lisp's syntax, which is apparently the bugaboo of this thread.
`loop' is to Lisp as `find' is to a UNIX/GNU/Linux shell. `loop' and `find' are
each practically a language unto itself. Each can be useful ... and daunting to
the uninitiated.
If you learn the language of `loop' you might (or might not) like it, but not
liking the language of `loop' has little relation to not liking the language of
Lisp. ;-)
Some might appreciate this:
http://common-lisp.net/project/iterate/doc/index.html#Top
or the short version:
http://common-lisp.net/project/iterate/doc/Don_0027t-Loop-Iterate.html#Don_0027t
-Loop-Iterate
No flames from the Loopite Liberation Legion, if you please. ;-)
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!"
Thien-Thi Nguyen
() Sat, 1 Jan 2011 14:50:52 -0800 (PST)
In comparison to prefix, postfix seems in the order of the action.
Certainly, it starts with the center object moved to the left most.
In another response, someone suggested reading/writing down.
Introducing another dimension is a good start. It's only a
start, however, because it is visible to the programmer and
not to the computer; inserting error-checking or state-stashing
into the mix, while travelling "in to out" (now "down to up")
is still problematical. Imagine an art gallery constructed
only of staircases -- easy to trip, hard to enjoy the paintings
on the walls. (But very straightforward for Hurrying Up.)
So the way forward is to add landings:
you climb, you gawk, you climb some more.
In Emacs Lisp, the landings are made using ‘flet’.
In Scheme, the landings are made from internal procedures.
Build your programs with enough landings and you may find
yourself keeping company with fewer firefighters and more
art snobs. That's the risk you take being an architect.
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.
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
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."
==================================================
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.
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)
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?
jacko
jacko
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.
--
__Pascal Bourguignon__ http://www.informatimago.com/
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:
&g