There is a sizable population of people in these newsgroups that are
much more interested in figuring out ways of using the "industrial
grade" systems that they have than they are in hearing about the
latest techniques you just heard about (that they likely knew of ten
years ago) that you added, then took out because it didn't turn out
well.

In comp.lang.scheme, there are _barrels_ of free implementations out
there that are likely a whole lot more featureful than your language
is at this point.  There are _largely disused_ implementations that
are likely of wider interest.

On comp.lang.lisp, the main dialect of Lisp under discussion is one
that has been fairly well specified since the 1980s, and your language
doesn't hold a candle to it in terms of overall functionality.  Why
SHOULD people on comp.lang.lisp be interested in something that's not
compatible with their favored language, and which lacks a whole lot of
the functionality that they expect and demand.

If you need for people to "care" about your language design
discussion, then perhaps you need to work on a language implementation
that _will_ seem consequential to them.  If you were to add a few
features to CLISP, _that_ would be of some interest to people.  Ditto
for SBCL or CMUCL.  A while back you were looking into Yale T; if you
were to resurrect the code base, and get a compiler running on a
modern Linux or FreeBSD system, I'm _sure_ that would attract some
interest.  (Albeit from a different direction.)

your impression of lisp's syntax seems to be solely based on it being
deviating from the syntax of the languages you used.  in fact, it is
amazingly simple, using only very few rules.  the languages you
mentioned use an algebraic syntax, which is well established for
numeric problems, but tends to become pretty complex once you go
beyond the normal arithmetic operations (how many C programmers do you
know who don't use superfluous parantheses because they have problems
remembering the precedence rules once shift and logical operators
become involved).  once you have become used to the unfamiliar syntax,
you most likely will appreciate its simplicity and consistency.
parantheses are only a problem if you use the wrong editor.  most
editors that are meant for programmers now support lisp and eliminate
the parenthesis problem.  after a while you won't even notice the
parentheses, esp. if you format your code logically.

depending on what examples you have tried so far, the advantages of
lisp might not be that obvious, esp. if you limit yourself to simply
transcribing programs you have written in familiar languages.  i wold
suggest you have a look at books like "paradigms of artificial
intelligence - case studies in common lisp" (norvig) or "the structure
and implementation of computer programs" (abelson/sussman) to get an
appreciation of how simple problems can be expressed in lisp like
languages.

yes, function names carry a lot of historical baggage that often is
troublesome for newcomers, but this is simply something you have to
get used to.  scheme, a language of the lisp family, has made an
attempt to remove some of this historical baggage, i.e. introduced
more consistent naming conventions for the standard functions.  most
people in this newsgroup think that think that this is not enough of
an advantage to give up the advantages common lisp has over scheme.

hs

--

http://www3.telus.net/public/whumeniu/runnerslog-140.exe

Its a self-installing application (shaken at delivery level 5).

Manual is:

http://www3.telus.net/public/whumeniu/Manual.html

I have also posted the source code.  Maybe if you stare at it long enough it will make
some sense and you will get the idea of how to get your ideas down in Lisp.  (Hint:  Just
like in C, a Lisp app is built up of functions and expressions).  Load defs.lisp first and
then see run.lisp for the main functionality. The main entry function is make-running-log

http://www3.telus.net/public/whumeniu/running-140-src.zip

In theory this all runs on LispWorks for Linux, though I have not tried.

Since you already know several traditional procedural languages,
you've noticed that they're all about the same under their skins.
Smalltalk is not like that.
APL is not like that.
Lisp is *definitely* not like that.
The skills you've developed elsewhere will still be useful to you,
but you have an entirely different outlook to acquire
before you can turn those skills to your benefit in Lisp.

Traditional procedural languages
are concerned with managing the memory field of a VonNeumann machine.
Lisp is concerned with construction using some very general ideas,
memory field be damned,
and the realm of what you can construct is considerably larger
that what you're used to thinking about in a traditional language.
Yes, you can do these things in C,
but some of them hurt so much that you'd never think to do them,
and those are often the things that are most useful in real programs.
Higher-order functions are a case in point.

A lot of people complain about it,
but I think the Abelson & Sussman book is a decent piece of work,
and you'll learn some other good stuff along the way.

Here's a guideline you can use in this matter,
regardless of how you pursue it:
as long as you're inclined to complain about all those silly parentheses
and CARs and CDRs and lack of significant syntax,
you haven't yet understood what Lisp is about.
Once you get it, you'll never think the same way about programming again.

I wish I could be more specific,
but there's a change that has to happen in your head,
and the only way I know to make that happen
is to look at some good examples and keep trying to make your own.
It's worth doing.

Steve
--
Steven T Abell
Software Designer
http://www.brising.com

(for (i=0;i<10;i++)
  (for (j=0;j<10;j++)
     (if   i == j
        (printf "i =j\n");
        (printf "i not j\n");
      )
   )
)

Sure you might come across mapcar etc. but they are such powerful
operators that many people will be learning them for the first time
anyway.

But defining new functions with common names doesn't help because the
single namespace forces you to avoid those names in variables (along with
remembering to avoid all the common built in names such as list and
string). The more obvious the function name, the more likely it's going to
bite you.

CLISP:
[1]> (setf list '(this is a list))
(THIS IS A LIST)
[2]> (list "a" "b" "c")
("a" "b" "c")

MZScheme:

You don't have to know any of the function names in Common Lisp to avoid
redefining them as variables. While it's a big language it doesn't get in
your way.

Given Common Lisp's long history the level of historical baggage is
remarkably low. And the more I learn about the language the more I
appreciate the skill of all its designers over the decades.

the only possible relavence in any case will be that it will be the
language I use for my projects.

it does not matter, I had just wondered if anyone would be interested...

http://www.paulgraham.com/lib/paulgraham/acl1.txt

As the language best suited, for example, to work on Genetic
Programming, see section 4.3, pages 71-72 of  "Genetic Programming" by
John R. KOZA: "Reasons for choosing LISP".

As a language to explore fundamental things of math and computer
science, see the book by Grogory J. CHAITIN:
"The limits of Mathematics", pages 31-44
          "Whay I love (pure) LISP" and
          "Proving LISP Programs are elegant")
"The Unknowable".

It have bee said that LISP is a "programmable programing language",
where the programmer has power to define his/her own language for the
problem at hand.

Also, think that the languge has been actively used and developed by a
community of computer scientists, mathmeticians, researches solving
difficult problems, and exploring the challenges of AI, so the time
past from the begginings of LISP doesn't mean obsolescence but
maturity, compared with new languages as Java, even in the Object
Oriented trend, with te power of CLOS.

Best regards,

  That kind of attitude is just so /stupid/ I could scream.  Well, let me
  scream.  THAT ATTITUDE IS SO GODDAMN STUPID!  (Thank you.)

  What you do with your time should be /completely/ unaffected by what other
  people find valuable.  You could not possibly attract anyone with some half-
  assed non-implementation of an idea, so just give that part of the task up
  right now.  What you /can/ do, however, is prove to yourself first, and then
  to others, that you can accomplish something worth accomplishing.  Some
  people prove this with degrees in educational institutions.  Others start
  small companies in their garage with the proceeds of their past successes.

  If you are starting out in life and treat creating a language as a means to
  learn something, which I do not even consider a worthwhile task if you are
  into compiler design, you should not even /ask/ people to care.  You have
  set out to learn something by explicitly rejecting everything that other
  people have done before you.  Create your own language and be on your own.

--
Erik Naggum, Oslo, Norway

If you decided to revive the T implementation, personally I'd
definitely comment on it, and one part of my comment would be `thank
you very much'.

But I found your language design really frustrating.  You seemed to
want to combine some aspects of Python, Scheme and Common Lisp.  It
didn't seem at all promising to me and I thought silence would be the
most charitable response.

You should realize that good self-image comes from accomplishment.  If
you do something good, you WILL become world famous.  I kid you not.
That's just the way the Internet is.  You will get messages from all
over the world either praising you or asking for free upgrades. :-)

So you've got a lot of time on you hands: pick a project and see it
through.  Then put it out there.  Repeat until satisfied.

On the contrary, I think this is a valuable exercise -- but its end is
not producing a useful language, especially not one that will be
useful to other people, but in learning about why things are done the
way they are in a particular language.  When I was an undergraduate, I
looked at the dozen languages I had been exposed to, and decided that
I didn't like any of them completely, and that I could do a lot better
if I designed a language on my own.  I was wrong; my pet language
wound up looking a lot like Objective-C, but I learned an enormous
amount about language design in the process.

All computer languages -- indeed, all engineering decisions -- involve
choices among various sets of tradeoffs.  Sometimes the best way to
understand this principle, as well as to see it in action, is to
explicitly reject all existing solutions and to design one from the
ground up.  The ancients were wise, but they were also foolish or
short-sighted; how many things in computer languages are there because
of historical precedent?  If we were designing LISP today, would we
have functions named car and cdr?  If we were designing C++ today,
would we put such immense importance on avoiding run-time typing
decisions?  

And even then, designing a new language does not necessarily mean
rejecting all that has gone before.  Did Bertrand Meyer discard what
he had learned from other languages when he designed Eiffel?  Did
Bjarne Stroustrup discard what he had learned from other languages
when he started down the path that led to C++?  Did Kernighan,
Ritchie, and Thompson discard what they had learned when they created
C?  Of course not.  All of them saw deficiencies in the existing
languages, and created a new language with what they considered
strengths and with as few weaknesses as possible.

Still, it's hardly surprising that comp.lang.lisp doesn't care.  I
wouldn't expect it to; the language is neither LISP nor LISP-like, and
it doesn't seem to address any need I might have that isn't already
addressed by a more mature language.

  After you know what has gone before, you can be more intelligently creative
  than when you start out from scratch.

| Did Bertrand Meyer discard what he had learned from other languages when he
| designed Eiffel?  Did Bjarne Stroustrup discard what he had learned from
| other languages when he started down the path that led to C++?  Did
| Kernighan, Ritchie, and Thompson discard what they had learned when they
| created C?  Of course not.

  Of course not.  Were they 18-year-old whining loners who craved attention
  for their inventions created in a vacuum?  Of course not.  Do you know
  anything worth beans to anyone else when you are 18?  Of course not.

| Still, it's hardly surprising that comp.lang.lisp doesn't care.

  So far, the willingness to listen does not even extend to Paul Graham's Arc.
  Novices with a desire to reinvent the world before they know what it is like
  should take notice of this.  Improving on Common Lisp is /very/ hard.  And
  most of the "improvements" on Scheme are neither improvements nor Scheme.

--
Erik Naggum, Oslo, Norway

And then you can check out
http://www.bagley.org/~doug/shootout/

Well and got and idea that a Lisp solution must not look much
different from a C solution.

Just an very simple example. Write down different ways to "sum up
elements". Write it C-ish, write it a functional way, and and

  - avoiding shadowing a function name is only of importance if
    you're intending to use that function (in a lexically enclosed
    scope).

  - if you don't know some function exists then you're not likely
    use it, or care if it gets shadowed.

I gusss the exception to this is if you use some macro that expands to a
function you don't know about, and accidentally shadowed.  Which would
be a problem in CL (butfor the two namespaces), but isn't in a language
with hygienic macros, such as Scheme or Dylan.

By the way, I've come to realise that my initial emphasis of a few months
ago that Lisp symbols should be case sensitive was misplaced. There's also
a nice discussion about case sensitivity in Ian Joyner's C++ Critique:
http://www.elj.com/cppcv3/s4/#s04-12

Still it would be nice if the information wasn't just thrown away but was
instead available as some aspect of a symbol's property.

As I understand it symbols have a number of properties associated with
them. It would be nice if one of those properties was information about
the original case of the symbol (e.g. it may be helpful when trying to
generate case sensitive markup such as XML or be especially helpful when
trying to make foreign interface calls that require the use of
StudlyCaps).

It would seem to be a modest and compatible addition to the language that
would not break any existing code. The drawback would be the manipulation
and storage of extra strings.

I am aware that the read table can be set to case sensitive and the
inplications for existing code and development environments breaking.

It's clear that software is more powerful than hardware - you can start
a program and this virtually turns your computer into a new machine. The
reason for this power lies in the fact that inside the computer,
programs and data are treated in the same way. So starting a program X
means that a different program, part of the operating system, loads  X
into main memory - here X is treated as pure data being loaded from hard
disk - and then arranges for the CPU to treat X like a program.

Turing machines are a theoretical means to abstract away from concrete
hardware issues but still retain this notion: data on a Turing tape can
either be treated as raw data or can be interpreted as instructions to
be carried out by the Turing machine. This is one possible basis for a
theory of computation.

The core of Lisp is another abstraction of this notion of treating data
and programs uniformly. However, the difference to Turing machines is
that Lisp is an executable "theory" of computation. The core of Lisp can
be defined in terms of itself, just because in Lisp data and programs
are essentially the same. Moreover, Lisp can be efficiently implemented
and it is relatively handy in order write serious programs in it. So
consequently and by definition, with Lisp you can make use of all the
power software provides. (By the way, you will quickly realize that
Lisp's apparently strange syntax is also a consequence of the unified
treatment of data and programs. You might even appreciate it by then. ;)

Almost all other languages deliberately restrict this power for several
reasons. Especially the unified treatment of data and programs is cut
from other languages in order to make them one or more of the following:
more safe, more intuitive, more efficient, more suited to particular
domains, and so on. However, there's always a price to pay for these
qualities and there is always a chance that you might run into problems
because of these deliberate limitations.

There's a lot to learn from Lisp about computer science as a whole. If
you understand Lisp's essentially ingredients - like closures,
higher-order functions, macros and so on - it's very likely that no
other programming language will ever surprise you again. For example, by
understanding Lisp, you will also have the means to understand in a
short amount of time concepts like inner classes and dynamic proxy
classes in Java, the essential ingredients of Dylan, Python or Ruby,
what Generative Programming in C++ is all about, what the strengths of
ML, CAML or Haskell are, and so on. In short, it will make you a better
programmer in general.

Pascal

If you want case sensitivity, but still want to use lower-case, then use
:invert (and probably some implications on *print-case* as well, and
will cause problems when using existing code, etc.)

I don't do this, but I wonder if this (or something similar) is what
people who want a case-sensitive CL do.

In your example above you didn't go all the way. You should also have
removed all semicolons and replace them with parentheses, etc. Making
everything look the same has lots of advantages, but some
disadvantages. The equivalent C code would look like:

for ( i=0; i<10; i++ )
  for ( j=0; i<10; j++ )
    if (i==j)
      printf( "i=j\n" );
    else
      printf( "i not j\n" );

This is a very mild example, BTW. In C++ and C99, for example,
variable definitions (although properly nested) don't have to be
defined at the beginning of scope. The following C++ program would
look like parentheses soup in LISP:

{
  File reader( ... parameters... );
  ...do something with reader...
  File writer( ... parameters... );
  ...do something with both reader and writer...

With due respect for your enthusiasm, I don't think that a few weeks worth
of thinking can bring any significant innovation. The tough part is not to
understand why a new feature may be useful, but to realize why it may not
be a good idea.

It takes much, much more to get a Lisper notice something "new", let alone
get excited about it.

If you are interested in language design and compilers, why you don't
contribute to improving the ANSI compliance of existing Lisp
implementations?