Re: Is a new CL standard possible?



On Mar 23, 8:25 pm, Elena <egarr...@xxxxxxxxx> wrote:
On 23 Mar, 09:33, Marco Antoniotti <marc...@xxxxxxxxx> wrote:

On Mar 23, 1:32 am, Elena <egarr...@xxxxxxxxx> wrote:
I'd say that there is already a new Common Lisp standard. Its name is
SBCL:

http://www.lispforum.com/viewtopic.php?f=2&t=140

As soon as the Windows port is stable, I think it will be the
reference implementation for people interested in cross platform
development.

There are already "reference implementations" for Windows.  They are
called Lispworks and AllegroCL.
They offer all you asked for and much much more.

I'd prefer the reference implementation not to be a commercial one:
standards should be free. And I'd like it to be a decent
implementation too. Slower than commercial ones? Nevermind, it's free.
More memory hungry? Nevermind, it's free. With lesser tools?
Nevermind, it's free. I'm not going to complain: it's free. But then I
could use it to build prototypes and if management want a prototype to
just go in production - as we commercial developers know that's often
the case - I could easily reply: "Well, dear boss, it works. I know,
it's slow and memory hungry. We'd have to improve it. We could rewrite
it in Blub, but that would be a chore. A lot of time. Can't we just
shell out a few bucks and buy this faster/slimmer compiler compiler?
I've tried the trial edition: it works. I can release the thing in an
hour. What do you want to do?". Compare that with another scenario:
"Hi PHB, I'd like to try out this new language. A lot of experienced
developers say it boosts productivity. It's not mainstream, no flashy
IDE, I have to say. Licenses start at XXX.". Which would be an easier
sell? Do you see my point?

Don't say: "Just use the trial edition in the first instance".
Wouldn't the PHB say: "Why didn't you asked me if we could afford the
licenses afterward? You fool, rewrite the damn thing in your leisure
time!". Happily, my manager is not a jerk, he is a very kind person,
but still he is a manager. And other programmers could be less lucky.

Look. These arguments have been hashed and rehashed here many many
time before. People here are all aware of them. Solving them is
another problem altogether.

The problem is that you need consensus, especially from the commercial
vendors.

Commercial vendors will do what their customers want. If a free
implementation takes the lead, they'll have to follow it.

It has not happened yet, and it does not look like it will happen any
time soon. Did you have a look at Allegro documentation? (And no. I
do not have a license).

If you look carefully at SBCL and CMUCL you will see that they
implement the SIMPLE-STREAM protocol by Franz (up to a point).  So,
innovation has started there. Franz also expanded on the
'environment' interface of CLtL2.  LW has not followed suite and it is
unclear what the "free" implementations are implementing something
similar.  The best GUI framework for CL is CAPI by LW full stop (not
LTk, at least until you can do away with MAINLOOP; and - at least -
you should consider CLG).

Nothing wrong with that. I'm not against commercial implementations at
all. They have their role. If I were a skilled professional lisper,
I'd go with them. But then I'd also understand that newbies have to
face a lot of challenges to promote Common Lisp - I'm there now - and
I'd like to help them as much as I can.

That is good (or bad...) but that is also a matter of perspective.
What makes you think that what is out there is not good enough?

"Fixing CL" is not an easy task.  Renaming functions is practically
pointless.

I agree on the fixing issue. Renaming functions pointless? I don't
think so, but please show me I'm wrong. Here is a test: write a few
lines of code to search a project for lines which have side effects,
including lines calling lisp code you don't have the source (I don't
know if the last sentence makes sense for Lisp). My solution for a
project with an appropriate naming convention would be a shell one
liner. What about yours? Second challenge: write an Emacs macro which
highlights with a different face lines with side effects, same
conditions as before. Again, my solution is few lines long. What about
yours?

You seem to ignore that CL has very well defined rules for most of its
naming conventions. Some of them are quaint and old-smelling, but
they are there. As for your question, it is me who gives out
homeworks here :) especially to the Ruby guy. Show me your code first
and I'll show you mine; I'd bet it would not be as short as you
think. But before you have to define better what you want. What is a
"side effect" for you?
As per CL, you just have to collect those forms that have a SETF
inside plus a handful of peculiar operators (those starting with N,
PUSH, PUSHNEW, POP, whatever)

Why? I think that functional programming can help me improve my
programming and I want - I've said "I want" - my tools to help me as
much as possible. Isn't Lisp all about programming any way you want? I
know I could do OOP in bare C, but C wouldn't help me to that.

CL is not a pure functional language. You'd have to try Haskell if
you want something really along those lines.


(I'm just trying to show my reasons, I don't mean to be hostile)

Just an extra note for you Elena...  Your renaming of == to 'eq' and !
= to 'ne' in C++ calls for a mob of angry C/C++ programmers with
pitchforks and torches.  Do you also do

#define BEGIN {
#define END }

#define R_U_SERIUOS :)

?

I'm serious. I was not that serious at all when I was throwing jokes
at my colleagues who had to spend the evening in their cubicles just
before a deadline, trying to debug stupid issues I've had fixed a long
time ago with my "weird" tricks.

Only lately I'm realizing I've always been a lisper in disguise. I
hope I will manage to become a lisper in full light.

Anyway, you've given me a cool idea. Tomorrow morning I'm going to
write into an header:

#ifdef LISP_RULEZ
#   define PROGN     {
#   define END_PROGN }
#endif

And of course I'm going to define LISP_RULEZ :-)))))

Cheers ^_^

Alright. Have fun with your colleagues. :)

Cheers
--
Marco



.