The NiCORE persistent object system is essentially a subset of CLOS,
and may be of interest for non-web applications.  
It can be used independent of the web server as it is
distributed/packaged in the engineering release.

-Kelly Murray   k...@niclos.com  

What is NiCLOS?

  NiCLOS is a new platform for quickly developing, deploying, and
evolving powerful and scalable web applications. Using a single
high-level dynamic persistent object language, the full range of
server-based web applications can be
developed and evolved quickly and easily.

  The key advantage of NiCLOS is the dynamic persistent object system,
which
  supports major changes in the application object structure after the
application has
  been deployed.

As I think you'll go anyway with this, you should put a big sign saying
`THIS IS NOT LISP', otherwise we'll have to deal with more people saying
that Lisp has a confusing (and now verbose) syntax.

--
Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

If we aren't going to go around accusing Dylan of confusing people
about the "true nature" of Lisp, we shouldn't be doing this with
NiCLOS either, IMHO.

(Not that I particularly like NiCLOS's syntax, although I find it
easier on the mind than e.g. Dylan's new syntax.  And I still think
that those who blame Lisp's syntax for it's non-acceptance are
essentially misguided, in that e.g. AutoLisp is probably more widely
used by non-hardcore-lispers than many other dialects, yet still has
the "horrible" Lisp syntax, and it even has a lot of other defects.)

BTW: The technology itself seems fairly interesting, and nice work.
And since the author of CL-HTTP seemingly isn't interested in wider
distribution of his work, maybe Lisp can make further impact in a sexy
application area...

Regs, Pierre.

And McCarthy's Lisp 1.5, MacLisp and Interlisp should probably be
banned in retrospect as well...  And maybe we need to excorcize Common
Lisp's loop construct, too.  Oh, and if I see it correctly, then
NiCLOS' syntax can be/is achieved through a normal CL and the
read-table, so arguably, this is either Common Lisp syntax, or most
everyone should be banned from changing the read-table.

IMHO this whole deal about not giving misimpressions to the newbies is
ill-conceived.  We have far better areas to worry about, than this
small opportunity for misunderstanding.  Indeed, I'd think that if KEM
put up a large sign at the website, saying "This is NOT (Common)
Lisp", I think that _more_ people would get misimpressions about the
thinks that can be derived from NiCLOS w.r.t. Common Lisp[1].  And it
would thus probably harm both NiCLOS and Common Lisp more.

Regs, Pierre.

PS: I also think that Common Lisp has no right to set precedents for
what constitutes "Real Lisp Syntax(tm)".  Under these grounds loop
would never have happened, and now you need to support it to be "The
Real Thing!(tm)"?!?

Footnotes:
[1]  That is because those who are apt to draw wrong conclusions from
evidence, are mostly not thinking logically to begin with...

I guess it needs to be repeated once again that Lisp is not a language,
it is a family of languages.  Common Lisp is one of those (in fact,
it has three varieties now: 1st and 2nd edition CL, and ANSI CL).
Others include (in no particular order) Scheme, Emacs Lisp, Autolisp;
Lisp 1.5, Maclisp, Interlisp, Zetalisp, *Lisp, Franz Lisp, Portable Lisp,
etc.

--
Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

However, it seems like a bad idea to invent a new dialect of Lisp at this
point.  Why not embed one of the existing, popular dialects rather than
needlessly branching off?

The only other dialect of Lisp that has been invented in recent years was
ISLisp.  It was created to solve a problem of international politics, not
for any good technical reason.

I still feel that new dialects should not be created on a whim.  Don't
create a new Lisp dialect just because you don't like the esthetics of IF
and backquote.  There should be a stronger reason to force people to learn
a new dialect and lose compatibility with an existing code base.  And
dialects that are "almost but not quite" like one of the existing dialects
are a big problem, IMHO -- programmers with experience in the the existing
dialect will easily lose track of the small number of differences.  If you
look at the Lisp family, you see vast differences between the popular
dialects, which makes sense (the more differences, the harder it is to port
existing software and expertise to some other dialect, so the old dialect
is hard to kill).

(loop with <var> = <value>
      for <var2> = (random <var>)
      if (evenp <var2>) collect (/ <var2> 2) else collect (/ (1+ <var2>)))

Sorry, but I don't think this kind "the one true syntax" discussion is
getting anywhere.  Now I don't think that NiCLOS' syntax is all that great,
and I really doubt whether it is going to advance the easy of use of NiCLOS,
since IMHO it just stands in the way of consistency (both internal and
external). But I really don't think argueing about the "one true syntax of
Lisp" is any useful reaction to that, especially since CL has provided the
precedent in this area.

Regs, Pierre.

But SilkScript is much MORE than just syntax differences.

In my view, 98% of web application developers do not know
Common Lisp, and thus SilkScript is specifically designed
to be a simpler language than CL that will be easier to document
and I predict easier to learn and become proficient with.
(Note that if you're selling CL, it makes sense to want
 the world to learn CL, but that is not our business.
 As a further note, why is it that there does not exist
 ANY CL third-party tools vendors?)

I don't think NiCLOS web apps need Complex Numbers, or Defstruct
or Deftype or Load or Compile-File or even Intern and Defpackage.
It would be a very bad business decision to throw copies
of ANSI Common Lisp manuals to our prospective developers
as documentation on how to develop web apps.
Lispers argue that Lisp is great for creating new
domain-specific languages -- that is what SilkScript is,
a web-app-specific language.

Notice that the CL Community already has CL-HTTP, which as far as I know
has not been very successful, despite being available for free
and including all the source code.

I would be most pleased if CL-compatibility is worth something
 --- show me CL programmers that are developing
commercial web applications that will pay for a NiCLOS license,
and I will continue to argue to my business partners why
we shouldn't have a VB or Java or Perl or TCL or XML extension language
in the server like other competing products in the marketplace.

-Kelly Murray   k...@niclos.com

However, if you've subsetted it as far as the above paragraph indicates,
compatibility probably isn't much of an issue.  As I said, I was more
concerned with dialects that are "almost but not quite like" an existing
dialect.  It does sound like you've staked out your own point on the
continuum.

I don't know why this should be the case.  (Indeed, I don't even know
that it's actually true.)  I certainly don't think that it's a good idea
to go around reinventing the same things all the time.

In the case of CL, I could see people thinking that they don't want to
embed a product in something they have to pay a license for, but given
Eclipse, flexible options from other vendors, and indeed, the existance
of CMUCL, GCL, etc., I don't think this argument holds water.  And why
do people keep reimplementing Scheme in order to base products?

Here we are beating up on Kelly for doing the right thing -- starting
with a standardized Lisp as an implementation substrate and embedding a
domain-specific language in it.  That's what Lisp is for, damn it.  (We
can argue over his choices for that domain-specific language, and I
think that's what Barmar is saying.)  Suppose Kelly had implemented
everything in Java, creating yet another Lisp implementation in the
process.  This new Lisp language, would indeed be a different dialect.
Would we be happier?

Even if you wanted to forgive NiCLOS because of TAGBODY
and classic LOOP, `then' and `else' in NiCLOS are not tags. You can't say (goto
then). And if you could, wouldn't that be a _Bad_Thing_?

Regarding `set', there's one point that is probably of little relevance.
Traditional SET evaluates both arguments. That's where SETQ
comes from.

this is the old problem of choosing between a "scripting language" and a
real language for extensions.

in http://www.goems.com/~sds/tool.html I argue that an extension
language should be a full-fledged high-level mature language with a
well-developed library since whenever a good application has an
extension language, people start writing *EVERYTHING* in that language,
and there is no reason to constrain them.

the bottom line is: you don't know what your users will want.

It seems pretty clear to me that NiCLOS is simply a thin layer of sugar on
top of a Web Server and an Object Store. I don't think Kelly went and
"removed" all of those things he mentioned, he's just not going to document
them in his product.

What's important here isn't the candy coating the Kelly has placed on top of
Lisp, but how well does his Web Server and Object Store work? All you need
to know is how to read the sugar he's added. Nothing forces you to use it.

The only other thing that he may have done is used an object system that
isn't CLOS. He's mentioned that before, mostly for performance, but perhaps
ACL 5 is fast enough that he didn't bother. But, he have done it anyway to
support his Object Store.

Some day, someone is going to look at NiCLOS and say "Boy, this sure looks a
whole bunch like Lisp". At that point, Kelly mails them the HyperSpec URL
with the subject "Congratulations! Your probing insite wins you a cookie!".
Then the secret gets out.

I think from a programming POV, the use of (set XXX = XXX) in NiCLOS
should not be judged differently from the use of (loop with XXX = XXX
do <body>) in CL, just because CL inherited this from MacLisp, and KEM
invented it in NiCLOS.

Rather (set XXX = XXX) and (loop with XXX = XXX) should each be judged
according to the usual standards for syntax, in the context of their
respective languages:

- Is it unambiguous?
- Is it succinct?
- Is it consistent within the language?
- Does it allow for the anticipated and real-world usage patterns?
- Is it easy to learn/remember, and more importantly (IMHO) is it easy
  to use?
- Is it not error-prone?
- ...

In my very humble and tentative opinion as a non-user of NiCLOS, and
thus extrapolating from CL, (set XXX = XXX) suffers from many of the
same problems that LOOP suffers from, with the addition of providing
questionable benefits to the experienced user (whereas LOOP is the
only standard way of doing descriptive iteration in CL, and thus
does offer functionality other constructs lack).

So the "only" reason I see for set&co. in NiCLOS is KEM's conjecture
that his intended audience will find this syntax easier to learn.  I
can't pass judgement on the validity of this conjecture, lacking any
serious knowledge about his intended audience.  But let me observe
that from the sample programs in NiCLOS that I've seen, I think KEM's
changes to NiCLOS's syntax are *too few*, so that inner consistency
suffers.  And I think that missing inner consistency is a hurdle
towards ease of learning in any audience.

Regs, Pierre.

Regs, Pierre.

If you mean to say a "real" language needs all of Common Lisp,
then you must not consider "C" or "Scheme" or "Dylan"
to be a "real" language because they don't have all this stuff
that CL has.

But with an implementation base of CL,
it is possible to "give" just about anything
if it turns out it is really necessary.

-Kelly Murray  k...@niclos.com  http://www.niclos.com

  but it is.  you want the world _not_ to (have to) learn Common Lisp.

| As a further note, why is it that there does not exist ANY CL third-party
| tools vendors?)

  this is actually a good question.  here's my take on it: in order for
  there to be a huge market for something, you need publicity, and in order
  to get publicity, you need to have serious flaws and problems that make
  people want to talk about your product.  when people talk about flaws and
  problems, some people will see a market for their own third-party tools
  and packages, just as some people see a market for magazines and news
  coverage of the players in the third-party tools market.  in order to get
  this ball rolling, your product obviously has to be quite useful or have
  the potential of becoming quite useful or people won't put up with the
  flaws and start talking about them or, better yet, try to fix them for
  you.  so, to be successful, you need something that is obviously useful
  so people will use it and obviously broken so people will fix it after
  they have started to use it.  now, if you're really smart, your fixes are
  _also_ half-assed, and you hook people into the con game by offering new
  and improved fixes, and the primary vendor offers new and improved shit
  that has different flaws and problems, so the third-party tools vendors
  also stay in business.  on top of this, if you can pull it off without
  anyone noticing it, allow nasty viruses to take advantage of you product
  and voilà, you have publicity in the media and an air of responsibility
  when you take charge to plug security holes, and you create business for
  people who plug security holes for you while you also ensure that a lot
  of criminally-minded idiots will use your system for their activities.

  Common Lisp doesn't have the "obviously broken" property, so it doesn't
  get popular because programmers can't share stories.  it's damn hard to
  fix Common Lisp, so people don't.  you can't really make a living out of
  writing about complaints about Common Lisp, so the magazines don't spring
  into existence.  you won't have any fun writing viruses for Common Lisp
  systems, either, so you neither get publicity nor the attention of the
  criminal world.  all in all, you lose if you don't peddle broken shit.

  all in all, I think it's a wonderful situation that there are no third-
  party tools vendors for Common Lisp.  :)

| I don't think NiCLOS web apps need Complex Numbers, or Defstruct or
| Deftype or Load or Compile-File or even Intern and Defpackage.  It would
| be a very bad business decision to throw copies of ANSI Common Lisp
| manuals to our prospective developers as documentation on how to develop
| web apps.

  why?  have you seen what the other "apps" come with?  _tomes_ with what
  passes for reference material.  and not just crappy Windows cruft, but
  serious stuff like Oracle databases or cisco systems routers/firewalls.

| Lispers argue that Lisp is great for creating new domain-specific
| languages -- that is what SilkScript is, a web-app-specific language.

  I'm sure it is that, too, but changing the syntax of core operators is
  not what people usually associate with domain-specific languages.

| Notice that the CL Community already has CL-HTTP, which as far as I know
| has not been very successful, despite being available for free and
| including all the source code.

  the reasons for this are very complex, and should not be taken as
  arguments for a particular differing view.

| I would be most pleased if CL-compatibility is worth something --- show
| me CL programmers that are developing commercial web applications that
| will pay for a NiCLOS license, and I will continue to argue to my
| business partners why we shouldn't have a VB or Java or Perl or TCL or
| XML extension language in the server like other competing products in the
| marketplace.

  this is _really_ not how you attract people's attention.  you just told
  me, in effect, that I can't trust the stability of your product and that
  I'd be foolish to invest any time in learning SilkScript or developing
  "apps" in it, because you're competing out in the open with those crappy
  languages that have all the obviously-broken properties they can possibly
  get their hands on, and are therefore guaranteed success.  you should
  instead focus on telling me that I should be able to trust you to stay
  around, to capitalize on the existing skills and that I can expand my
  skills into the Common Lisp third-party tools market, if I use NiCLOS.

  on the other hand, people _are_ talking about NiCLOS because it is
  obviously broken in the "gratuitously changed syntax" department.