I don't know --- sometimes I think Racket is the less popular Lisp in
here. When you guys look at libraries like syntax-parse, don't you feel
like switching to Racket for good?
Some other day someone said --- why isn't Racket a thinner layer on top
of POSIX? Maybe that's one of the reasons?
On 2024-01-04, Julieta Shem <[email protected]> wrote:
I don't know --- sometimes I think Racket is the less popular Lisp in
here. When you guys look at libraries like syntax-parse, don't you feel
like switching to Racket for good?
Some other day someone said --- why isn't Racket a thinner layer on top
of POSIX? Maybe that's one of the reasons?
I don't have much interest in Racket because I made myself something
called TXR Lisp. That /is/ actually a thinner layer on top of POSIX.
It is spiritually connected to CL more than anything else.
To fool C and Unix people, I pitched this language as a command line
tool similar to Awk and what have you, and made sure it is documented by nothing but a single man page. The one thing that gives the ruse is
that the man page grew to over 950 pages (in PDF form).
About Racket, a Common Lisp vs. Racket article from 2022 recently
appeared on HackerNews:
https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1ca7ac
The author argues that Racket is substantially less dynamic.
If he is right, that could be something that turns away Common Lisp
people.
However, note that this newsgroup has always been Common-Lisp-oriented,
even though it's not comp.lang.lisp.common or comp.lang.comon-lisp.
Discussions of other Lisps are not off topic, but just don't happen.
It doesn't speak to anything other than what this newsgroup is.
Julieta Shem <[email protected]> writes:
I don't know --- sometimes I think Racket is the less popular Lisp in
here.
Well technically since Racket is a member of the Scheme family, you
should probably be using comp.lang.scheme for talking about it. Many
years ago that would have definitely been correct since comp.lang.scheme
was gatewayed to an active Scheme mailing list. But the Scheme mailing
list has been dead for years, and comp.lang.scheme now gets almost no
traffic other than announcements.
But there was never a Common-Lisp-only newsgroup, so the Common Lisp
folks gathered here. The Scheme folks went to comp.lang.scheme, and the Emacs Lisp folks went someplace I no longer remember.
I suppose that these days if you're weird enough to be using both Usenet _and_ and some flavor of Lisp, you're in such sufficiently small company
that you might as well come here.
Aren't the cool kids all off using some social media web site to talk
about Racket?
Is TXR able to use all libraries from CL?
Some other day someone said --- why isn't Racket a thinner layer on
top of POSIX? Maybe that's one of the reasons?
On 2024-01-04, Julieta Shem <[email protected]> wrote:
Is TXR able to use all libraries from CL?
None. It's possible to port some things, but it requires work.
I ported only one: CL-WHO, which is named TL-WHO:
https://www.kylheku.com/cgit/tl-who/about/
It was interesting.
I don't know --- sometimes I think Racket is the less popular Lisp in
here. When you guys look at libraries like syntax-parse, don't you feel
like switching to Racket for good?
Some other day someone said --- why isn't Racket a thinner layer on top
of POSIX? Maybe that's one of the reasons?
Racket is derived from Scheme (which also is NOT Lisp).
On Thu, 04 Jan 2024 21:28:14 -0500, George Neuner wrote:
Racket is derived from Scheme (which also is NOT Lisp).
There is the distinction between “Lisp2” (including Common Lisp and other >traditional LISPs) and “Lisp1” (typified by Scheme). I take it Racket is a >“Lisp1”-type language?
Racket is derived from Scheme (which also is NOT Lisp).
Racket evolved from PLT Scheme - which WAS a Scheme.
The European Lisp Symposium is a premier forum for the
discussion and dissemination of all aspects of design,
implementation, and application of any of the Lisp dialects,
including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket,
ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet,
uLisp, Picolisp, Gamelisp, TXR, and so on.
The first post to comp.lang.lisp was in November of 1986; _Common
Lisp, The Language_ was published in 1984.
Oh, that's just an artifact of the Great Renaming, which was 1986-7. comp.lang.lisp is the new name of the old net.lang.lisp. The first
message was there can be found at http://groups.google.com/groups?hl=en&group=net.lang.lisp&scoring=d&as_drrb=b&as
_mind=1&as_minm=1&as_miny=1981&as_maxd=10&as_maxm=6&as_maxy=1982&selm=anews.Aucb
arpa.997
And is dated 1982-03-27 23:56:29 PST.
It's by John Foderaro. The first sentence is:
"The net.lang.lisp newsgroup is for the discussion of any and all lisp dialects."
I'm not trying to join a debate on loop. I just wanted to present
the other side of [the issue so that] the intelligent people can
then weigh the arguments on both sides.
I'm not suggesting that loop can be fixed either by adding
parenthesis or coming up with ways of indenting it to make it
understandable. It's a lost cause.
...
Another great example from kmp:
=== from kmp
For example, you might think
(loop with i = (random 100) for x from 1 to 10 do (print (list i x)))
and
(loop for i = (random 100) for x from 1 to 10 do (print (list i x)))
meant the same in English, [but they don't do the same thing in loop]
=== end kmp
loop lulls you into thinking that you understand the program since
you understand English. Make no mistake about it, loop is its
own language. If you use it you condem everyone who reads the
code to also learn the loop language.
Better:
On 1/4/2024, George Neuner wrote:
Racket is derived from Scheme (which also is NOT Lisp).
Racket evolved from PLT Scheme - which WAS a Scheme.
That's not even a proper sentence.
Better:
Racket evolved from PLT Scheme, which was a Scheme.
+++
"Scheme is a dialect of the Lisp family of programming
languages." — Wikipedia
On Tue, 28 May 2024 08:04:38 -0000 (UTC), De ongekruisigde (ds.) wrote:
"Scheme is a dialect of the Lisp family of programming
languages." — Wikipedia
Worth noting the fundamental split between “Lisp-1” members of the family and “Lisp-2”. Traditional Lisps (as embodied by Common Lisp) are “Lisp-2”
Lisps, while Scheme is the originator of the “Lisp-1” branch.
Worth noting the fundamental split between “Lisp-1” members of the family
and “Lisp-2”. Traditional Lisps (as embodied by Common Lisp) are “Lisp-2”
Lisps, while Scheme is the originator of the “Lisp-1” branch.
I always thought Racket via Scheme was the Lisp-1 branch and the
other ones the Lisp-2 branch. ;-)
For any non initiated it's just as incomprehensible as a speech
impediment.
On 1/4/2024, George Neuner wrote:
Racket is derived from Scheme (which also is NOT Lisp).
The following code snippet runs under both Gauche Scheme and
SBCL, and the output is identical:
Does this tend to prove that Scheme is not a Lisp?
Those who program in CL (COBOL-Like) are using the Loop language,
which is not a dialect of Lisp. Furthermore, they are forcing those
who read their code to learn the Loop language.
Let's just say that Scheme is a better Lisp than CL (COBOL-Like) is.
One of Lisp's most obvious defining features is its homoiconicity. This wasn't always appreciated. Lisp 2 wanted an Algoloid surface syntax; I
don't know how this would have worked, but probably it would have
abandoned homoiconicity, and I probably wouldn't think of it as a Lisp.
This is not true in Scheme. The R4RS appendix introduced a hygienic
macro system which is incompatible with homoiconicity as demonstrated
through `quote'.
On Thu, 30 May 2024 15:20:50 +0100, Mark Wooding wrote:
One of Lisp's most obvious defining features is its homoiconicity. This
wasn't always appreciated. Lisp 2 wanted an Algoloid surface syntax; I
don't know how this would have worked, but probably it would have
abandoned homoiconicity, and I probably wouldn't think of it as a Lisp.
Perhaps look at Python as the closest we have managed to come to “Lisp 2”.
It still allows for homoiconicity to some degree.
Lawrence D'Oliveiro <[email protected]d> writes:
Perhaps look at Python as the closest we have managed to come to “Lisp
2”. It still allows for homoiconicity to some degree.
Can you give an example of Python's homoiconicity?
On Fri, 31 May 2024 23:48:37 -0300, Julieta Shem wrote:
Lawrence D'Oliveiro <[email protected]d> writes:
Perhaps look at Python as the closest we have managed to come to “Lisp >>> 2”. It still allows for homoiconicity to some degree.
Can you give an example of Python's homoiconicity?
Sure. Have a look at this library <https://gitlab.com/ldo/seaskirt/>. It’s a set of wrappers around the various management APIs available for the Asterisk telephony engine.
I wanted to create both synchronous and asynchronous versions of each of
the wrapper classes. For example,
def func(...) :
...
res = net_call(...)
...
#end func
versus
async def func(...) :
...
res = await net_call_async(...)
...
#end func
but I didn’t want to write out the “...” parts (which made up about 90% of
the code) twice. So what I actually wrote looked like this:
async def func(...) :
...
if ASYNC :
res = await net_call(...)
else :
res = net_call(...)
#end if
...
#end func
That “ASYNC” is not defined anywhere: it’s just a placeholder. But after
the code is compiled to AST form, I run a preprocessor which looks for
those conditionals, and expands the alternatives inline, generating two versions of the code which correspond, in source form, to the two versions
I avoided writing explicitly.
One fun thing is, I also figured out I could do class instantiations asynchronously.
So even though the macro preprocessing system adds about 160 lines to the module, I estimated the whole thing is still over 500 lines smaller than
it would be if I had written out all the code by hand. That’s 500 less lines for bugs to occur in, and for me to maintain.
What's your definition of homoiconicity?
On Sat, 01 Jun 2024 10:23:53 -0300, Julieta Shem wrote:
What's your definition of homoiconicity?
The AST can be represented in language objects.
On Sat, 01 Jun 2024 10:23:53 -0300, Julieta Shem wrote:
What's your definition of homoiconicity?
The AST can be represented in language objects.
I'd argue that it's by necessity: it's an uninteresting (and fairly ill-defined) concept.
That seems like an uninteresting definition.What's your definition of homoiconicity?The AST can be represented in language objects.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 165:00:54 |
| Calls: | 12,096 |
| Calls today: | 4 |
| Files: | 15,001 |
| Messages: | 6,517,803 |