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:
>>> 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.
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.
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
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 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).
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.
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 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)
Jonathan Groll
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>
> > In comp.lang.forth Xah Lee <xah...@gmail.com> wrote:
> >>
> >> 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
> >
> > Given that the article even manages to confuse Polish notation and
> > Reverse Polish notation, I strongly recommend that everyone avoid it.
>
> As most of what he writes...
Indeed. Most people think that because it is published on the internet
it must be right.
Cheers,
Jonathan
--
jjg: Jonathan J. Groll : groll co za
has_one { :blog => "http://bloggroll.com" }
Reine, reine gueux éveille
Gomme à gaine, en horreur, taie.
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
Pascal J. Bourguignon
> 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.
Now, as a Forth programmer, ask yourself what you would have to do, to
call an operator with a variable arity?
In Postscript, there is a mark operator, to push a mark on the stack, so
that a next operator of variable arity may collect a variable number of
arguments, up to that mark.
Then, as a Forth programmer, ask yourself what you would need to be able
to parse a Forth expression containing unknown operators, ie. operators
of unknown (possibly fixed, but also variable) arity?]
If you consider a separate table giving the arity of the operators, then
it is not unknown anymore. The only solution I know, is to use mark
systematically:
MARK MARK MARK MARK MARK b FNEGATE FDUP F* MARK 4e a c F* F- FSQRT F+
MARK 2e a F* F/
Then, we may add some syntactic sugar, replacing call the MARK operator
'(', and adding gratuituous balanced ')' after each operator:
(((((((b -) FDUP) f*) (4e a c F*) F-) FSQRT) F+) (2e a F*) F/)
Finally, we may apply mechanically a recursive reverse:
(defun rrev (x)
(if (listp x)
(mapcar 'rrev (reverse x))
x))
(rrev
'(((((((b -) FDUP) f*) (4e a c F*) F-) FSQRT) F+) (2e a F*) F/))
(F/ (F* a 2e)
(F+ (FSQRT (F- (F* c a 4e)
(F* (FDUP (- b)))))))
so it becomes readable again and you can see there's a bug in the Forth
expression. Since the syntax become suddenly much simplier, we don't
need to prefix operators with 'F' anymore. So we can write merely:
(/ (* a 2)
(+ (sqrt (- (* c a 4)
(* (dup (- b)))))))
Anyways, the great thing now, is that we have homoiconicity
(notice how I used the parenthesised source expression as data passed
to rrev), and we can process expressions without knowing the arity of
the operators (the operators may even not be defined before we process
expressions using them!). For example, we could now write:
(derivate '(/ (* a 2)
(+ (sqrt (- (* c a 4)
(* (dup (- b)))))))
'a)
and get:
--> (- (/ 2 (sqrt (- (* 4 a c) (* b b))))
(/ (* 4 a c) (expt (sqrt (- (* 4 a c) (* b b))) 3/2)))
and since this is one of the first applications of Lisp, you can see now
the reasons and advantages why lisp has these parentheses. Of course,
that doesn't preclude writing in lisp symbolic mathematic programs like
maxima, providing the mathematical user with a more usual infix input
and 2D output:
http://www.informatimago.com/images/example-maxima.png
> 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)'
> ;
There are also infix-to-lisp utilities to embed infix expressions in
lisp program. If you had to implement a program with a lot of
mathematical formula to copy from a book, I guess these utility would
come handy.
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 ?
some basics that might be helpful.
〈What's Function, What's Operator?〉
http://xahlee.org/math/function_and_operators.html
--------------------------------------------------
What's Function, What's Operator?
Xah Lee, 2010-12-14, 2011-01-06
Typically, we understand what “function” and “operator” mean, but
programer may have a hard time explaining them, and mathematician may
never thought about it. Here, we clarify a bit on the meaning of the
word “function” and “operator”, their context, their relation.
--------------------------------
Function is a Mathematical Concept
Function you probably understand. A function takes a input, and output
a value for a given input. The inputs are called “parameters”. A
specific set of input is called “arguments”. The number of parameters
of a function is called the function's “arity”. So, for example, the
function “sin” has arity 1. A constant, such as 35, π, can be
considered as functions of no parameter, so they are functions of
arity 0. A function of 2 parameters, such as f(x,y) := x+y has arity
2.
Function is a mathematical concept. Viewed in another way, it's a map
from one space (aka set) to another.
--------------------------------
Operator is About Notation
A operator, is less of a mathematical concept, but more of a concept
of notation. Or, in computer language contexts, a element of syntax. A
“operator” is a symbol (or symbols) that are written to indicate
operations. For example, we write 1+2, the “+” is a operator, and the
“1” and “2” are its “operands”. Mathematically, operator is a function
that acts on its operands. The operands are the arguments of the
function.
--------------------------------
Binary Operators
Typically, operators takes 2 arguments, the left and right of the
symbol. e.g. 2×3, 3/4, 2^3, union {3,4}∪{2,4,1}, etc.
--------------------------------
Unary Operators
But there are also 1-argument operators. For example the minus sign
-3, and the logical not ¬ sign, the factorial 3!, square root √3.
--------------------------------
Multi-symbol Operators
Operators can also involve other forms with more symbols. For example,
the absolute sign |-3|, floor ⌊3.8⌋ uses a bracket, summation ∑ takes
4 arguments, a expression, a variable, and start and end values. The
anti-derivative (aka indefinite integral) ∫ takes 2 arguments, a
expression and a symbol. In traditional notation, the integration
operator involves 2 symbols, ∫ and ⅆ. For example, we write ∫ sin(x)
ⅆx .
--------------------------------
Implicit Operators
Operator can be a bit complicated. For example -3 can be interpreted
in several ways. We can think of the minus sign as unary operator
acting on the argument 3. So, mathematically, it is a function of 1
arity that returns the addictive inverse of the element 3. Or, we can
interprete it as one single entity, a element of Reals denoted -3.
When we write 3-2, the ways to interprete it gets a bit more complex.
One way to think of it as a notation shorthand for 3 + (-2). The -2
part can be thought of as before. Another way is to think of - as a
binary operator on 3 and 2, but this seemingly simple interpretation
is a bit complex. Because, what is math definition of the minus binary
function? I'm not sure how it can be defined in terms of algebra
without ultimately thinking of it as additon of 2 elements, one being
a addictive inverse. The other way is to think of it as a real line,
moving the first argument to the left by a distance of the second
argument. Of course ultimately these are equivalent, but i can't think
of a simple, direct, interpretation that can serve as a math
foundation. Also, this is directly related to how does one interprete
division, such as 3/2.
The multiplication operator also gets complicated. For example, when
we write 3 x, it usually means 3*x. The space acts as implicit
multiplication sign. But when we write 3 +2, the space there has no
significance. When we write 3x, even there is no space nor any
operator, but we mean 3*x. As a computer language syntax based on
traditional notation, the parsing rule is not trivial.
Operator Stickiness
There's also the concept of “operator stickiness” (aka “operator
precendence”) at work that makes expressions with operators more
concise. When we write3△4▲5, how do you know it's (3△4)▲5 or 3△(4▲5)?
The concept of operator stickiness is needed to resolve that.
Otherwise, you'll need to always write 3+(4*5) instead of the simpler
3+4*5. But this again, also introduced more complexity. When you have
a expression of tens of different operators, it becomes a problem of
remembering the stickiness grammar for each operator. (in practice,
when you are not sure about the procedence, you usually just use
explicit priority indicator by parens. This often happens in
programing with logic operators (e.g. and &&, or ||, not !.)
Forgetting Operator Precedence is a common error in programing. In
written math for human communication, it is prone to
miscommunication.)
--------------------------------
Operator is tied to Notation
Because the concept of “operator” more has to do with syntax and
notation, and when considering traditional math notation of writing in
“2-dimensions”, also the fact that traditional math notation has a lot
ambiguities, it gets a bit complicated and not as imprecise as we
like. (See: The Problems of Traditional Math Notation)
Mathematically, operator and function are the same thing.
Math function in traditional notation has the form e.g. sin(x),
f(x,y), where the things inside the paren are its parameter/arguments,
and function name is placed to the left.
Operators are useful because writing everything out in full function
notation gets very cumbersome and hard to read. For example, we write
3+4*5 instead of plus(3,times(4,5)) or +(3,*(4,5)).
Here's a example of traditional notation using operators:
-b+√(b^2-4 a c)/(2 a)
If you don't allow space as implicit multiplication sign, then you
have to write:
-b+√((b^2)-4*a*c)/(2*a)
If you don't allow the the concept of operator precedence, then you
have to write:
(-b)+(√((b^2)-((4*a)*c))/(2*a))
If you prefer the structural clarity of the traditional function
notation f(x), you have to write:
/(+(-(b),√(+(^(b,2),-(*(4,a,c))))),*(2,a))
If you prefer words than symbols, as traditionally practiced when
writing out functions, you have to write:
divide(add(minus(b),sqrt(add(power(b,
2),minus(times(4,a,c))))),times(2,a))
The notation using operators is much concise, readable, but at the
cost of relatively complex lexical grammar. The full functional
notation is precise, grammatically simple, but difficult to read.
In math context, it's best to think of functions instead of operator,
and sometimes also use a uniform function notation, where all
arguments are explicitly indicated in one uniform way.
Here's what Wikipedia has to say about operators: Operation
(mathematics). Quote:
An operation ω is a function of the form ω : X1 × … × Xk → Y. The
sets Xj are called the domains of the operation, the set Y is called
the codomain of the operation, and the fixed non-negative integer k
(the number of arguments) is called the type or arity of the
operation.
Note that it doesn't really speaks of “operators”, but speaks of
“operations”, and flatly defines operation as a function.
--------------------------------
Traditional Function Notation sin(x) Isn't Perfect
Note that, even the functional notation such as sin(x), isn't perfect.
Problem of Functions Returning Functions
Normally, with full function notation, you'd expect that execution
order of operations clearly corresponds to the nesting structure. For
example, in our example before:
divide(add(minus(b),sqrt(add(power(b,
2),minus(times(4,a,c))))),times(2,a))
The inner-most parts are evaluated first.
But there's a problem when a function returns a function. For example,
the derivative takes a function and returns a function. We might
write:
derivative(f)
Now, if we want to evaluate the result at 3, then we might write:
derivative(f)(3)
You can see that the notation no longer nests. The operator precedence
issue is back. Now, you need to have a slightly more complex notion of
precedence to work out the notation.
One solution to this is the lisp language's syntax. In lisp syntax,
everything is written inside a paren. The first element is the
function name, the rest is its arguments. So, sin(x) would be written
as (sin,x). (comma is used for separator) Our derivative example would
then be:
((derivative,f),3)
In this way, the syntax remains a pure nested form, and provides the
utmost precision.
Our formula example in fully nested syntax be:
(/,(+,(-,b),(√,(+,(^,b,2),(-,(*,4,a,c))))),(*,2,a))
We could change the comma separator to space. So, it would look like
this:
(/ (+ (- b) (√ (+ (^ b 2) (- (* 4 a c))))) (* 2 a))
(Note: actual lisp language's syntax is not 100% regular. Many of its
syntax does not have the form (a b c ...). See: Fundamental Problems
of Lisp.)
--------------------------------
Syntax Design for Computer Languages
Mixing Operator Syntax with Full Function Notation Syntax
In most computer language, they allow both the operator and full
function syntax. For example, you can write (sin(x))^2+3. (almost all
languages do this; e.g. C, C++, C#, Java, Pascal, Perl, Python, Ruby,
Bash, PowerShell, Haskell, OCaml. The only exception is lisps.)
(Though, almost all computer languages does not have a regular syntax,
in fact, non of any major computer lang has a syntax specification.
The closest one that has a somewhat regular and simple syntax grammar
is Mathematica. See: The Concepts and Confusions of Prefix, Infix,
Postfix and Fully Nested Notations ◇ Math Notations, Computer
Languages, and the “Form” in Formalism.)
Mixed form is normal, and most flexible. Because, not all functions
have a associated operator symbol. And, writing everything in nested
brackets is not readible and hard to write too. The question is, is it
possible to design a syntax, that is fully regular with a very simple
lexical grammar, and easy to read and write?
Xah ∑ http://xahlee.org/ ☄
w_a_x_man
wrote:
> so it becomes readable again and you can see there's a bug in the Forth
> expression. Since the syntax become suddenly much simplier, we don't
> need to prefix operators with 'F' anymore.
Since Forth is a low-level language, operators aren't overloaded.
"F+" adds two floats, "+" adds two integers.
Xah Lee
On Jan 5, 8:21 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Given that the article even manages to confuse Polish notation and
> Reverse Polish notation, I strongly recommend that everyone avoid it.
Hi man,
if you are not familiar with RPN, please see:
http://xahlee.org/prog/hp28s/hp28s.html
there are several free progs writting in RPN language. Among which, is
a music chord generating prog, could be fun to play with.
if you in college, you could show it to your friends and be
impressive.
Also, you might want to pickup emacs. In it, you can type 【Alt+x】,
Enter, then type “calc”, then you can play with RPN. My own pet peeve
about emacs calc is about its doc... due to that, i never actually
done much with it in the past decade of emacs-using other than simple
arithemitcs with Reals. Though, am aware of the fact that it can very
much do vector and matrix — even solving equations — arithemitcs, as
well as complex.
Xah
w_a_x_man
> 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]
(defun compress (stuff)
(mapcon #'(lambda (x)
(if (and (> (length x) 1) (eql (car x) (cadr x)))
nil
(list (car x))))
stuff))
Jan Burse
This is quite funny to write a tractate about operator definitions
to comp.lang.prolog. Prolog has already for some time operator
definitions. But some other programming language do have also.
Best Regards
See also:
http://cs.union.edu/~striegnk/learn-prolog-now/html/node82.html#sec.l9.operators
from http://www.learnprolognow.org/
Xah Lee schrieb:
> programing with logic operators (e.g. and&&, or ||, not !.)
Doug Hoffman
> Doug Hoffman<glid...@gmail.com> writes:
>
>> 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.
>
> Now, as a Forth programmer, ask yourself what you would have to do, to
> call an operator with a variable arity?
One way to handle a variable number of input parameters is to precede
them with a count. There is at least one ANS Forth word that does this.
I've seen the technique used a lot elsewhere in Forth code. Supplying
a "mark" is also something I've seen.
If I am going to apply a single operator to a list of many items, in
Forth I would likely put the items in a list, perhaps a list of objects
depending on the nature of the items, and then iterate over the list.
Just to be clear, so we don't get sidetracked on a Lisp vs Forth
tangent: I commented that I believed the Lisp example is somewhat
readable to someone unfamiliar with Lisp, Forth is not readable to
someone unfamiliar with Forth. The standard "Fortran/spreadsheet"
syntax version is the most readable for this example regardless of
language familiarity, again in my opinion.
[snip]
> (F/ (F* a 2e)
> (F+ (FSQRT (F- (F* c a 4e)
> (F* (FDUP (- b)))))))
>
> so it becomes readable again and you can see there's a bug in the Forth
> expression.
No, I can't see any bug in the Forth example. Could you point it out
more clearly?
-Doug
Andrew Haley
> wrote:
>> Given that the article even manages to confuse Polish notation and
>> Reverse Polish notation, I strongly recommend that everyone avoid it.
>
> Hi man,
>
> if you are not familiar with RPN, please see:
>
> http://xahlee.org/prog/hp28s/hp28s.html
Thank you, Xah. If I ever forget about RPN, I'll be sure to come
straight to you for a refresher. In the meantime, I suggest you fix
that article.
Andrew.
Xah Lee
wrote:
thanks. corrected, with credit.
Xah
WJ
MAPCON works quite well for this.
Tweeked:
(defun compress (stuff)
(mapcon #'(lambda (x)
(if (and (rest x) (eql (first x) (second x)))
nil
(list (first x))))
stuff))
m_l_g3
> How to improve the readability of (any) LISP or any highlevel
> functional language to the level of FORTH ?
...
>
> How do you make it readable ?
...
>
> (f (g (h (j (k (l ops)))...)))
(e
(f
(g (h i)
(j k l)
)
(m (n o (p q))
(r (s t) u)
) ) )
The rule: if you don't see the closing paren moving the eyes down,
it's on the right.
But it either to the right or down, no other option.
Since closing parens are visually identical, there's no need to one
line per paren;
this is shown at the last line (yes, their visual and logical
orderings are different,
but they are identical parens otherwise worth only counting!).
> Is there a postfix functional language that also gets rid of parens
> and is not as primitive as FORTH or POSTSCRIPT ?
There is a prefix/infix one: Haskell with its ($) and (.) operators
and... well... monads.
As to Forth, you may try to layout control structures on the right,
as if RPN is not enough:
: MAX 2dup > if
drop else
nip then
;
: foo
10 0 do
i 3 mod 0= if
i . then loop
;
Doug Hoffman
> On Jan 1, 10:04 am, girosenth<girose...@india.com> wrote:
>> How to improve the readability of (any) LISP or any highlevel
>> functional language to the level of FORTH ?
>
> ...
>>
>> How do you make it readable ?
> ...
>>
>> (f (g (h (j (k (l ops)))...)))
>
> (e
> (f
> (g (h i)
> (j k l)
> )
> (m (n o (p q))
> (r (s t) u)
> ) ) )
>
> The rule: if you don't see the closing paren moving the eyes down,
> it's on the right.
> But it either to the right or down, no other option.
I would assume that Lispers would use a source editor that automatically
hilights corresponding parens (e.g., selct a left paren and the right
paren becomes bold or whatever) and checks for missing parens
automatically before compilation is attempted.
> As to Forth, you may try to layout control structures on the right,
> as if RPN is not enough:
>
> : MAX 2dup> if
> drop else
> nip then
> ;
I agree with vusual "aligning" for control words. But I would do it
differently (stack comment please!). The above suggests to me that ELSE
is consuming the result of the DROP and THEN is consuming the result of
the NIP.
Better, IMHO:
: MAX ( n1 n2 -- max )
2dup > IF drop
ELSE nip
THEN ;
Read in English as " <condition> iftrue DROP, otherwise NIP, then continue".
-Doug
rupert...@googlemail.com
> This is quite funny to write a tractate about operator definitions
> to comp.lang.prolog. Prolog has already for some time operator
> definitions.
Yes, and you can define infix operators with it too! Making your code
nice and easy to read, and avoiding all this Neanderthal RPN stuff. I
guess some people just like to do things the hard way?
Jan Burse
Reminds me of the HP-41C
http://en.wikipedia.org/wiki/HP-41C
But still the Haskell people have for example even put more
into operators, than Prolog did. You can write things like:
(+ 4)
Or
x $ y z
Right? I guess the current lack of a concept of lambda
expressions in Prolog is the cause.
Bye
Jan Burse
D. J. Penton
I LOVE Lisp, Scheme, Haskell, OCaml, C, Objective-C, Perl, and java. Really! I love them all. If I were to learn Ruby or Python I would probably love them too. I have a hard time loving C++ , but I'll bet I could learn to love it. Soon I shall try my hand at Prolog and Forth.
My choice of languages depends on what I am trying to program. I am not equally expert in all of the languages I use, but they all have their uses. My deepest love is for Common Lisp. But the others are very, very good too.
In past times I used VIM. Now I use emacs. I love them both. I also adore Xcode, Visual Studio, Netbeans, and Eclipse. Flowers in a garden!
When I encounter a flame war or debate about programming languages, I mentally gather my dear bouquet of languages around me and bask in the delight of choice.
Best wishes to all,
- Dave -