L Sharp version 1.0 has been released - www.lsharp.org
L Sharp .NET is a powerful lisp-based scripting language and interpreter for
.NET. It uses a Lisp dialect similar to Paul Graham's Arc but tightly
integrates with the Microsoft .NET Framework which provides a rich set of
libraries.
It's working pretty well, but the language and tools are still subject to
change. There is an online reference manual, getting started guide as well
as several examples. It's already good enough to run some sysadmin scripts
at Active Web Solutions, including a site checker and some database mangling
scripts.
I'm particularly interested in Paul Graham's work on Arc,
http://www.paulgraham.com/arc.html and L Sharp draws upon many of those
ideas.
Basically I wanted a good scripting engine on the Microsoft platform and a
way of interactively and incrementally experimenting with the .NET framework
in the Lisp tradition.
The L Sharp core DLL is distributed under the terms of the GNU LGPL, making
it suitable for use as a scripting engine for .NET applications (It can be
incorporated into your C Sharp or VB.Net application with just a few lines
of code and can script your domain specific classes automatically through
reflection).
L Sharp may be of particular interest if you are a Lisp hacker working with
the Microsoft technologies.
For more information please visit www.lsharp.org
L Sharp isn't perfect, but I want to maintain and improve it. I'm
particularly interested in any constructive feedback and ideas
[········@lsharp.org] that you may have. Please report bugs to
[····@lsharp.org]
Regards
Rob Blackwell
"Rob Blackwell" <·············@lsharp.org> writes:
> L Sharp version 1.0 has been released - www.lsharp.org
>
> L Sharp .NET is a powerful lisp-based scripting language and interpreter for
> .NET. It uses a Lisp dialect similar to Paul Graham's Arc but tightly
> integrates with the Microsoft .NET Framework which provides a rich set of
> libraries.
> [...]
> L Sharp isn't perfect, but I want to maintain and improve it. I'm
> particularly interested in any constructive feedback and ideas
> [········@lsharp.org] that you may have. Please report bugs to
> [····@lsharp.org]
I think it would be a big improvement for L# to be compatible with
Common-Lisp.
Then, you could inherit all the Common-Lisp libraries on .NET.
Note that thanks to the Common-Lisp package system, you could still
provide an "ARC" package with more "modern" features.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
> I think it would be a big improvement for L# to be compatible with
> Common-Lisp.
> Then, you could inherit all the Common-Lisp libraries on .NET.
>
> Note that thanks to the Common-Lisp package system, you could still
> provide an "ARC" package with more "modern" features.
Or you could let it grow on its own organically and see how
far its simple, powerful ideas can take you :).
Matt
"Rob Blackwell" <·············@lsharp.org> writes:
> L Sharp version 1.0 has been released - www.lsharp.org
>
> L Sharp .NET is a powerful lisp-based scripting language and interpreter for
> .NET. It uses a Lisp dialect similar to Paul Graham's Arc but tightly
> integrates with the Microsoft .NET Framework which provides a rich set of
> libraries.
[...]
Are you aware of http://weitz.de/rdnzl/ and http://foil.sourceforge.net/ ?
Andras
Rob Blackwell wrote:
> L Sharp version 1.0 has been released - www.lsharp.org
>
> L Sharp .NET is a powerful lisp-based scripting language and
interpreter for
> .NET. It uses a Lisp dialect similar to Paul Graham's Arc but tightly
> integrates with the Microsoft .NET Framework which provides a rich
set of
> libraries.
The .net part sounds great. I really think having a CL# would be a
great idea. However, I do not see what is wrong with CL to justify this
dialect. There may be good reasons to make a CL dialect but it should
be based on principled research including empirical studies of
programming. Arc, for instance, includes design rationales based on
carpal tunnel syndrome and introspection. Given that we are all using
tools such as symbol completion this kind of reasoning should not be
part of language design. If you want to make a nice contribution to
this community implement CL#. If you want to experiment with syntactic
variants of CL use CL macros. It's not that I think CL is perfect.
There are a number of things that could be improved. One of CL's
biggest strengths is that it was a well designed language which has be
standardized and is stable. If you claim that there is a need for a
Lisp dialect you better have a compelling story backed up with some
research. To me, that's missing from Arc. If your reason for a
dialect is most rooted in the implementation complexity of CL simply
start with a CL subset and gradually extend it to be a full CL
implementation.
> ...but it should be based on principled research including empirical
studies of programming.
If we were talking about most subjects other then Lisp, I would
probably agree with that sentiment- But with Lisp, I would argue that
there are already quite a few people doing great rigorous academic
work- Lack of academic rigor never struck me as a weakness of the Lisp
community...
...and other less "disciplined" approaches can also yield some
beneficial ideas. I think we should encourage people trying out ideas
such as L-Sharp.
> Given that we are all using tools such as symbol completion this kind
of reasoning should not be part of language design.
Unless you are of the sentiment that the necessity tools such as
"symbol completion" show inherent weaknesses of the language design.
Admittedly, a pretty unorthodox opinion, but one that I and PG and
(probably) RB agree with.
> If you want to experiment with syntactic variants of CL use CL
macros.
There is a lot of truth in this perspective (and, indeed, I actually
already have my own little mini-Arc that I use based on macros) but I
think using a non CL route has a certain "purity" to it that I think
can be defended as well (but may be an impediment to adoption or to its
utility for the greater CL community, as you have stated) especially
since not all of ARC could be implemented with CL macros (I mean,
without building an ARC interpreter in CL)
I think that even though ARC itself has arguably little rigorous
fundamental theory underlying it (part of PG's bottum-up vs. top-down
mentality) I think PG has pretty clearly described the fundamental
principles for his design process (if not the language itself) and I
hope he sticks to these principles, even if it leads to a system that
is poorly compatible with other architectures. He's an imaginative guy
and I think it will be interesting to see what the end result of his
ambitious development process will be, given the radical nature of his
core principles.
I would view ARC as a great example of what Larry Wall termed a
"post-modern" programming language, as outline in Larry's speech at
http://www.wall.org/~larry/pm.html
CL is more along the lines of Larry's idea of a "modern" language- And
is arguably the best of the bunch (Scheme pretty great too, of course)
Conrad Barski, M.D.
"Alexander Repenning" <·····@cs.colorado.edu> writes:
> programming. Arc, for instance, includes design rationales based on
> carpal tunnel syndrome and introspection. Given that we are all using
> tools such as symbol completion this kind of reasoning should not be
> part of language design. If you want to make a nice contribution to
I seem to understand that, according to Graham, such a design is
closer to the hacker mindset.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface