Re: Modernizing Common Lisp

From: Will Hartung (willh_at_msoft.com)
Date: 05/07/04


Date: Thu, 6 May 2004 15:34:40 -0700


> What is this "different standard"? People coding in Java don't have to
> worry about the idiosyncrasies of their vendor's network API or threads
> API. Java is not a single implementation language. I'm sure you can
> think of plenty of similar examples.

No, they only have to worry about the idiosyncracies of their network or
threads IMPLEMENTATION. While a "standard" API is all peachy and wonderful,
there's nothing to stop someone from having crappy implementations
underneath that shroud of "compatability". Java has had a long and sordid
history with regards to threads (who's API has, in fact, changed in the
past).

> Well, I don't want you to be confused by my subtle implications, so I'll
> spell it out. ANY LANGUAGE, IN 2004, WHICH PURPORTS TO BE GENERAL
> PURPOSE YET HAS NO STANDARD NETWORK API IS INFERIOR IN THAT RESPECT, AND
> INDEED BLIGHTED. Do you disagree?

Just to be clear that you consider C, C++, FORTRAN, Ada, Delphi, and, of
course, probably the most recently standardized of languages, arguably the
most "modern" mainstream language, C#, on those same grounds. None of those
lanaguages have a "standard" network API. Popular ones? De Facto ones? Sure.
Oh, wait, so does CL!

In fact, you can have a compliant JVM that has no support for networking as
well. OMG! I see your Standard and raise you an Implementation.

> Is there something specific about the CL community that makes my hopes
> unrealistic? Because other languages have standardized these things, and
> other languages have ongoing standardization processes. Why do YOU hold
> CL to a lower standard in this regard?

We don't. That's the point. We know the difference between a Language and an
Implementation. We know that Common Lisp can be used for a HUGE domain of
problems, many of which don't even come near these APIs you're fixated on.
We know that Common Lisp can be tuned, bent, hammered, and tweaked to
support domains in areas that we haven't even considered yet. We know that
when They(tm) started the Standardization process, They(tm) actually took
into consideration not simply the language, but the implementations
available, the trials and tribulations of implementing CL, the hows and whys
it could be implemented, and the variety of architectures it could be
implemented upon. There is quite a bit of thought in the CL Standard, things
that implementors of todays languages do not even think about.

If anything, we hold CL to a higher standard to let us concoct any API that
suits us to facilitate the task at hand.

Regards,

Will Hartung
(willh@msoft.com)



Relevant Pages

  • Re: CRT and Win32 SDK
    ... However, it might give a reader an impression that when doing embedded programming one typically has a full-fledged language at hand, where in effect the runtime library implements what the OS would provide on e.g. a PC. ... The C and C++ standards differentiate between hosted and free-standing implementation to deal with the special constraints of embedded programming, where free-standing doesn't need to provide all of the language's standard library, but even that distinction does in practice not go far enough: it might be that fundamental language features such as static variables and exceptions are not available on the embedded platform's language implementation. ... Both the user-mode Win32 API and the kernel ... The documentation remarks are very important parts of that documentation and form the main part of it. ...
    (microsoft.public.vc.language)
  • Re: Making class attributes non-case-sensitive?
    ... The application's API is ... I'm not sure if it is standard for Microsoft or just the ... VBScript was the most common scripting language used while anything ... now Python is considered standard. ...
    (comp.lang.python)
  • Re: GoTo in Java
    ... When I invoked the C++ standard ... obviously it doesn't include an X11 API, ... GUI scripting language. ... open-source implementations hasn't dissuaded C programmers ...
    (comp.lang.cobol)
  • Re: Recover/defrag memory API
    ... > It is a concept beyond anything supported in the language, ... Hence wy i asked for an API, not a standard C++ function. ... > It is also not clear how memory can be "recovered". ...
    (microsoft.public.vc.mfc)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)