[Openmcl-devel] type specifier '(simple-vector n) in defmethod

[David McClain]

I hate to cause any deviations, but…

Since the 1980’s when SML came along, we have been increasingly influenced by the FPL community. Add to that the work of Carl Hewitt and Actors, and the fact that we now have multi-core machines and SMP, and the fact (which I can strongly defend) that Actors is the way to best utilize multiple cores and SMP…

Perhaps we need an evolution of Lisp to include pattern matching as a fundamental part of the language. More than a Common Lisp as we now know it. CL is great insofar as being a good substrate for implementing all these wonderful new ideas. But patten matching has become so prevalent that is now feels like a serious omission from CL.




> On Jan 5, 2024, at 12:34, Tim McNerney <mc at media.mit.edu> wrote:
> 
> There is value in when you are saying, Nicolas.
> 
> Since Clozure Associates dissolved its LLC and its founders retired,
> it is now up to us as a community to carry the torch and maintain CCL.
> There is no "somebody else" to do it for us.  
> We all have to answer questions.
> We all have to fix bugs.  
> We all have to make sure bug fixes are tested, checked in, and patches created.
> There is an argument that a smaller "core" of maintainers oversee releases,
> but if we keep adding to a regression suite and are diligent about running it,
> anyone should be able to make a release, as long as they keep in communication.
> Where "release" means a carefully curated and extensively tested build.
> 
> As for CCL's "demise being greatly exaggerated," I've been seeing clear evidence that
> there is decreasing opportunity to run a viable business licensing proprietary CLs.
> Open source Common Lisps are the way to go.
> My apologies to the maintainers of SBCL, but it is weighed down by lots of pet projects.
> CCL is a highly optimized, complex-but-lean, "diamond."
> I back the "diamond" approach.
> 
> On 1/5/24 2:13 PM, Nicolas Martyanoff wrote:
>> Ron Garret <ron at flownet.com> <mailto:ron at flownet.com> writes:
>> 
>>>> On Jan 5, 2024, at 5:41 AM, Tim McNerney <mc at media.mit.edu> <mailto:mc at media.mit.edu> wrote:
>>>> 
>>>> It's not too late to fix this flaw. What's the harm? 
>>> Bikeshedding.  If we don't get the M1 port done, CCL is dead.  We need to focus.
>> While I have no doubt that not having a M1 port is a deal breaker for
>> developers working on MacOS, I would argue that the lack of regular
>> releases and the multitude of open issues and pull requests (i.e. the
>> lack of maintenance) is what is killing CCL.
>> 
>> Running on Apple Silicon is not going to fix the multitude of issues you
>> might encounter on any platform. As an example, a couple months ago I
>> try starting to write a patch for CCL, spent way too much time trying to
>> decipher code with no comment or type declaration, then realized that
>> CCL would randomly segfault when rebuilding itself (Linux/x86_64).
>> Google showed me at least one person having encountered the exact same
>> problem before, and zero answers. I went back to SBCL and will probably
>> drop CCL support from my projects because what is the point?
>> 
>> I fully understand that no one at Clozure has the time or money to
>> invest on CCL and I'm not blaming anyone; it is already admirable of
>> them to have built CCL and released it under a free license. But
>> This is just what happens in the Open Source world when no one forks an
>> unmaintained project, especially for a language which while not dead is
>> starting to smell really funny.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20240105/f7d70981/attachment.htm>