? MOST-POSITIVE-FIXNUM
536870911

On a MacIvory:

Command: most-positive-fixnum
2147483647

Checkpoint Firewall-1 uses S-expressions to store the firewall
configuration that you (are supposed to :-) generate using a
relatively nice GUI.

I think Confluent's "Visual Thought" drawing package also uses a Lispy
representation of its drawings.

    Simon> Checkpoint Firewall-1 uses S-expressions to store the firewall
    Simon> configuration that you (are supposed to :-) generate using a
    Simon> relatively nice GUI.

    Simon> I think Confluent's "Visual Thought" drawing package also uses a Lispy
    Simon> representation of its drawings.

Add to that Rational Rose.  It looks like the entire UML model is
stored in some Lispy representation, including window position
information.

  geez, why do you care?  Common Lisp doesn't _have_ sizes of such things.
  implementations do.  C and C++, however, _do_ have sizes of such things.
  C/C++ have the problem you allude to.  Common Lisp just runs with a
  little less consing on a machine with bigger machine integers.

| Why can't Lisp become more popular?

  why can't opera be more popular?  why can't football be less popular?

| What's stopping it?

  people like you.

| You can't do sockets or threads in CL without a hell of a lot of #+ and
| #- and have it work in any CL providing access to these features.

  just because you can't doesn't many other people can't.  the simplest way
  to do this is to write a thin veneer, perhaps using compiler macros, to
  present a uniform, standard interface to the underlying implementation
  (which, by the way, differs between _socket_ implementations, too), stuff
  this in a file that is loaded only on the platform it applies to.
  porting your system is a matter of making a new copy of this file.  this,
  by the way, is how intelligent people _implement_ real portability.  only
  if the differences are very small and very localized does it make sense
  to use #- and #+.  personally, I use #- and #+ only in configuration
  files and in DEFSYSTEMs.

  feel free to complain that this veneer isn't standardized.  I fully
  expect you to, but also that you will complain about whatever you get,
  the same way people complain about the pathname abstraction prohibiting
  them from running the whole gamut of file system options and operations
  on their particular implementation.

/Jon

* cba...@2xtreme.net (Christopher R. Barry)
| It's crippled, and you must pay if you want to use it commercially.

  sigh.  what _are_ the other crippled features of this version?  that you
  can't use it for a full-fledged commercial projects?  why do you expect
  to be able to do that?  the Java freebies are _marketing_ stunts, not
  technical arguments.  do you have any idea how much money has been sunk
  into Java and when the break-even time is expected to be?  do you not
  realize that it is an instrument of mass market destruction to reduce
  Microsoft's hegemony and that Common Lisp doesn't fight that kind of wars?

  and I find it slightly amusing that you, too, keep adding conditions that
  make you not choose Common Lisp, no matter how people answer your gripes.

| I would feel dishonest if I contacted Franz about getting an evaluation
| copy of CLIM. I know that no matter how much I liked it, I could not at
| this point in my life afford it.

  yeah, and I'm sure this is CLIM's fault.  you said "Swing, unlike CLIM,
  doesn't cost $4000-$7000 to even try out on Unix."  which was an outright
  lie, so now you would feel dishonest if you asked for a demo version, but
  you didn't feel dishonest when you lied to begin with?

| It would be nice if it could be obtained under the same terms as the
| Allegro CL Linux Trial Edition, where you can use it as long as you like,
| and not feel obligated to purchase it.

  you can't use it as long as you like.  can't you even read licenses?
  (yeah, I'm expecting another silly gripe, now.)

  you clearly confused what "would be nice" with what people think they
  might one day be able to profit from providing you.  there ain't no such
  thing as a free lunch, remember?

| After having been able to use Allegro CL so extensively, I know that at
| some point in the future I would definately buy it if using Common Lisp
| for a big project.

  good for you.  I won't hold my breath.

| When it comes down to it, I still _definitely_ do not prefer Java over CL.

  are you desperate for reasons to use Common Lisp?   is that why you bitch
  and moan and invent "flaw" after "flaw" as your previous "flaws" have
  proven not to be flaws?  it sure doesn't look constructive to me.

| There are a number of things that Java gets right though, like knowing
| how to actually get a little mind share.

  yes, by lying, overstating, hyping, misrepresenting the facts, etc.
  somehow, I prefer to buy from Common Lisp sales people, not used car
  sales people who jumped on the Java bandwagon.

| Well, certainly not disgusted yet....

  you will, and the company that'll bring you to it: AT&T.¹

It's just *that* much more of an (IMO) unnecessary inconvenience.

Wasn't the whole point of Common Lisp that a lot of implementations
were providing largely equivalent functionality with a slightly
different interface? Everyone does sockets and threads these days and
a lot of the extension functions across implementations do almost the
exact same stuff. Are there any large, sophisticated, real-world apps
that are written these days in CL that don't do threads?

I should mention that CL-HTTP includes a lot of functions and macros
that unite some of the extension features found in all the CLs and
I've found it very useful and it's saved me a lot of time already. It
was obviously a lot of work to put all of that together and it would
be nice if this stuff could just always be relied upon to be there.

But the most important point is, that the size of FIXNUMs in CL
matters only for points of speed, which is as it should be.  In CL you
don't worry about integer bittyness, unless you really need to, which
is either for speed or data-layout reasons, where you get the tools
for doing what needs to be done. And this doesn't change one jota even
if your plattform evolves.  You just get the benefits, without the
hassles.

The standard doesn't have to change in any way to accomodate 2^n
plattforms for n>16.

It seems to me that much of Java's "success" stems from the fact, that
current users/programmers prefer an application that gives you
internet access, draws pretty pictures, is slow as hell even on the
most modern machines, insecure and so buggy that it crashes
about every 5-10 minutes to a program that works reliably and
stand-alone on reasonable machines and is rock solid.  Mostly because
the first application is "cool", and the other one isn't[1].

Of course CL will never be able to match Java in coolness, since
coolness and reliability are mutually exclusive in the real world,
where resources are limited, and will be distributed according to
priorities.  Dito for Ada.  Is this a bad thing?  Not in my book.

As long as the value-system and priorities of the masses are so at
odds with my priorities, I don't want the languages and tools I choose
to go mainstream and get popular.  We don't have to change CL to make
it popular[2], we have to change popular priorities and value-systems.
Then popularity will follow naturally.

Regs, Pierre.

Footnotes:
[1]  Just look at WWW browsers to see a real world example of this.

[2]  We may of course see the need to change and expand CL to meet
demands of its user community, w.r.t to certain features or
clarifications.  There are enough things to think about, but
popularity is not the driving force here.

a) Unless you actively prohibit this, FIXNUM arithmetic will overflow
   correctly and automatically into BIGNUMs, so that a wrong estimate
   on your part on the size of FIXNUMs will only cause performance
   degradation and not wrong results.

b) There are additional type-specifiers that allow you to clearly
   specify types based on your range and/or bit bestimates, so that
   none of that "long int is 32bit, long int is 64bit, ..." guessing
   is needed.

Regs, Pierre.

For more details on why C's int and CL's FIXNUM are not in any way
comparable, see my previous postings.

If it is so, that all available threading and socket-based networking
APIs differ only in minor details, then taking this area into the
standard might be possible and sensible.  Otherwise, the other vendors
and members of the comittee will surely object ;)

There are so many things that would be nice.  The art of engineering
is dividing up the nice from the essential and then providing the
essential.  If any resources are left over, you provide as much of the
nice as seems reasonable.

Regs, Pierre.

cba...@2xtreme.net (Christopher R. Barry) writes:

< You could write applets in CL and basically gain all the advantages
< and cross-platform functionality Java has. You can't do sockets or
< threads in CL without a hell of a lot of #+ and #- and have it work in
< any CL providing access to these features. And many are reluctant to
< ship source code.
<
< Christopher

Actually I just saw the neatest idea for handling the `#+' in the
scigraph program. It uses a reader macro called `#FEATURE-CASE'.
Really made things easier to read.

  I'm baffled.  have you _read_ the specifications?  a fixnum is simply a
  more efficient integer, and some implementation-defined limits are less
  than or equal to MOST-POSITIVE-FIXNUM, but you have know your compiler
  real well before (+ fixnum fixnum) does not cause a bignum when needed.
  what, precisely, is you gripe with the size of FIXNUM, anyway?  methinks
  you just have a fixation that you're trying blame Common Lisp for.

| > | Why can't Lisp become more popular?
| >
| >   why can't opera be more popular?  why can't football be less popular?
|
| I think your analogy is not the most suitable one. I think using Lisp
| over C or Java boils down to more than just personal taste and factors
| analogous to your analogy.

  my point was that you ask a useless question that has no useful answer.
  it is rare that you can explain why something is popular at any given
  time.  (and "marketing" begets the question "why did it work?", which all
  marketing people will tell you is not something you sit down and predict.)

| > | What's stopping it?
| >
| >   people like you.
|
| Okay, what can I realistically do to make it more popular?

  you can stop posting drivel and actually go read the specification and
  ask questions instead of posting wrong answers to questions people don't
  ask.  you see, people are _detracted_ from a gravitation towards Lisp as
  they gain experience in their field and want self-improvement.  this is
  not at all the path you get if you ask about or measure popularity.

| Has anyone done this already?  Can I download a pre-done layer of
| documented macro definitions from somewhere that will at least work
| across CMUCL and Allegro CL?  If I have to do it myself, not a huge deal
| as long as I only do it for functions I use and not everything, but
| standardization just makes it *that* much easier.

  I think your doing it yourself is a valuable exercise in understanding
  (1) how this stuff should have been implemented, (2) the effort that goes
  into standardization, and (3) the effort that goes into sharing quality
  code with other people.  maybe then you will realize what you're asking
  for when you want everything for free.

| A little while back before my homework caught up with me I actually kinda
| started to work on making a uniform interface between the ext: and excl:
| file operation functions of Allegro and CMU Common Lisp which provide a
| lot of the same functionality so that I could write some intelligent
| Debian package management utilities for my personal use to make up for
| where Apt and dpkg don't get it right for my purposes.  I don't want to
| commit to using only CMUCL or Allegro CL for this or anything else just
| yet.

  this at least explains your problems.  what you're doing is a waste of
  time, although the purpose and goal is clear, so consider this: what you
  sit down and design because CMUCL and Allegro CL do not agree on some
  interface design is something you barely know how works and what you will
  actually need from it once it does work.  once it works well enough for
  you to build something on top of, you will need to redesign it after you
  have started to build something.  only if you chose one implementation
  and got enough stuff working to start feeding data back into the design
  process can you hope to get the design right.  what you're doign is
  premature abstraction without an actual purpose or goal.  "to make it
  work in both Allegro CL and CMUCL" should not be a goal, it should fall
  out your efforts as a result.

| It's just *that* much more of an (IMO) unnecessary inconvenience.

  programming is all _about_ "unnecessary inconveniences", and every step
  of progress tries to reduce their number.  that's why good programmers
  choose languages that have less unnecessary inconveniences than other
  languages, but if you think you can avoid unnecessary inconveniences, I
  think you should consider death and taxation first.

| Wasn't the whole point of Common Lisp that a lot of implementations were
| providing largely equivalent functionality with a slightly different
| interface?

  yes, historically, this was the motivation for the standardization, as it
  is with most good standardization, incidentally.

| Everyone does sockets and threads these days and a lot of the extension
| functions across implementations do almost the exact same stuff.

  also true, but standards are basically removing functionality from the
  market.  the issue changes from "do you support FOO" to "do you conform
  to the specification of FOO".  the former is a feature if true, but
  otherwise draws a blank.  the latter draws a blank if true, and is
  otherwise a reportable bug.  to make standards work, all vendors must
  agree to stop considering their features features, and start viewing them
  as requirements.  incidentally, this process parallels your Java vs CL
  attitude: you argue against CL because you regard features in Java as
  requirements of CL.  this is, to put it mildly, hopelessly naive.

| Are there any large, sophisticated, real-world apps that are written
| these days in CL that don't do threads?

  I cannot imagine otherwise.  why do you?

| I should mention that CL-HTTP includes a lot of functions and macros that
| unite some of the extension features found in all the CLs and I've found
| it very useful and it's saved me a lot of time already.  It was obviously
| a lot of work to put all of that together and it would be nice if this
| stuff could just always be relied upon to be there.

  well, you have the CL-HTTP sources, and it is apparently not a problem
  for you that you cannot use it commercially (which was a gripe you had
  with Common Lisp implementations, so I have a minor problem understanding
  what your actual and real concerns are).

Just like that. It felt *nice*. It's so *easy* to learn as well. It's
like I have 15 million classes to choose from I can just strap
together a neat little app in 10 minutes that I could also probably do
without difficulty in CL but I'd have to write like 10 different
classes first.

All the other people in my Java class have pretty much only seen C,
VB, C++ or whatever and they're probably liking Java a lot more than
even I am.... They'll never learn to think Lisp.

  AFAIK, that was the whole idea, but since I don't use GUIs, I'm not
  entirely sure what it can do.  but why not try to read what Franz Inc
  writes about this and ask them directly?  on the Net, people argue about
  whether year 2000 is a leap year or not, so it's not as if you can rely
  on the answers you get.

| Hmm... sigh.  Another assumption on my part.  I'll have to get around to
| reading that license.  Sometime.

  before your next gripe about it would be a good value of "sometime".

| They've got to get us using their products while we're young and still in
| school so we know to tell our managers that we want to use CL for a
| project once we're hired instead of thinking only in terms of how to
| implement a solution using C++, Perl or Java.

  does the medical profession provide kids with scalpels and syringes while
  still in school so they get used to using them by the time some of them
  will enter medical school?  if not, why not?

  seriously, I wonder where this wacky idea of yours comes from.  lots of
  people think that you have to accomodate kids, novices, and idiots in
  order to _succeed_.  that isn't quite true -- you need to do that to make
  a mass market with millions of users.  this always has enormous costs in
  what you have to do to attract them.  e.g., you think in terms of
  "unnecessary inconveniences" instead of understanding that programming is
  all about removing inconveniences that arise in your particular
  application, and you want people to give you things instead of creating
  them.  that's lazy in the wrong way.

| All the other people in my Java class have pretty much only seen C, VB,
| C++ or whatever and they're probably liking Java a lot more than even I
| am.... They'll never learn to think Lisp.

  oh, they will, in time.  people come to Lisp for reasons of their own.
  you can't push Lisp on people -- you can't push good taste on people.

I'd just like to point out that I think it's a good motto to
stay away from fixnum declarations until your profiler suggests you
to consider using them.  CLs general integers has saved lisp programmers
from a *lot* of problems, and will still do (-> the 2038 problem).

--

  there's a nuance here that seems to get lost all the time.  first, some
  people _believe_ in prototyping (in another language), i.e., they do it
  whether it makes sense or not.  sometimes, it makes sense to do it.
  second, "throwing the first version away" is something you do if you need
  to, not something you should out to do, because then you'll end up maybe
  having to throw the second version away, too.

  my argument against what you're doing is that you involve yourself in
  low-level stuff long before you know how to do either low-level or
  high-level stuff.  you will learn the wrong thing from this experiment
  and will retain whatever was reasonably simple to implement, not what is
  good design.  simplifying the design is sometimes necessary when the cost
  of implementing it proves too costly.  if you implement it in one of the
  environments at a time, you may call it prototyping.  if you implement it
  in both, you're trying to evolve production code.  this will fail.

| I was imagining being able to do this in an CL though kinda like with
| Java, "imagining" being the operative word.  Sigh.

  well, maybe Java has a place in the grand order of things, but to make
  Java really work, I want serious protocol engine support, since the Java
  applet is going to talk to a server, and it'd be nice if that was using a
  reasonably standard protocol.  as far as I know, CORBA support is not
  "standard" in Java, and despite it's cost and the introduction of yet
  another language (IDL) is the most promising way to deal with this mess.

however, what if i actually *want* a wrap around.  i do not want an
integer but a number from the ring Z_n.

this is not an idle question.  i could actually use this.  for
example, i am measuring angles on a satellite dish pedestal and my
sensor equipment maps the angle to a number from 0 to 65535.  it'd be
nice to wrap around automatically, since the concept i am trying to
handle - angles - do this.

i.e., (+ angle1 angle2) should return a new angle in the canonical
angle format 0 to 65535.

other times it'd be nice to have a wrapping integer type is for
periodic time-varying filter operations in a modem.

the books i have seen are a little weak on the number crunching, bit
banging side of the house.  i hear that lisp can be as fast as fortran
on numeric problems.  i have come to lisp out of disgust with C++ and
i am finding that i like lisp.  but is they any information on how to
solve those problems which are traditionally done in fortran or C?

1. That is a function of the Java Virtual Machine (JVM), and not a
feature of the Java programming LANGUAGE.  Other languages could use the
JVM, too, if it worked right.

2. I don't believe that your statement is correct -- you can't reliably
run it anywhere.  Anecdotaly, I read this week about some drug maker
that had a lot invested in some client-server apps.  They used a Java
applet on the client side, and ALL THEIR CLIENT MACHINES WERE RUNNING
WINDOWS.  Unfortunately, the Windows implementation of the JVM was
broken and the app didn't run.  They had to have someone (Oracle?) build
them a special JVM for Windows.

Now instead of having an application that was written once and running
on all platforms, they have an application that was written more than
once and running only on one.  And this BECAUSE OF, not despite, the
fact that they relied on the univerality of the JVM.

Now this is just one story, and I can't even recall the source
(Performance Computing???)  Furthermore, I get a lot of free magazines
and they're worth every penny I pay.  So take this all with a grain of
salt.