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.

Didier Verna:

> 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.

Thomas Bushnell wrote:

> > 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."

The following code snippet runs under both Gauche Scheme and
SBCL, and the output is identical:

(let* ((step1 2)
(step2 (cons (* step1 1000) 47)))
(do ((i 1 (+ i step1))
(j 40 (+ j (case (mod i 3)
((0 1) (car step2))
((2) (cdr step2)))))
(sum 0 (+ sum (cond ((= 0 (mod j 2)) j)
((= 3 i) 500)
('else (* i 2.125))))))
((> i 22) (values sum j))))

===>
36664.375
16181

Does this tend to prove that Scheme is not a Lisp?

Paul Graham, May 2001:

A hacker's language is terse and hackable. Common Lisp is not.

The good news is, it's not Lisp that sucks, but Common Lisp.

Paul Graham:

I consider Loop one of the worst flaws in CL, and an example
to be borne in mind by both macro writers and language designers.

From: John Foderaro <jkf@unspamx.franz.com>
Newsgroups: comp.lang.lisp
Subject: Re: the "loop" macro
Date: Sun, 26 Aug 2001 10:51:26 -0700

> 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.

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.

On Mon, 27 May 2024 23:39:30 -0000 (UTC), B. Pym wrote:

> Better:

That’s not even a proper sentence.

On 2024-05-28, B. Pym <No_spamming@noWhere_7073.org> wrote:
> 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.

"The Racket language is a modern dialect of Lisp and a descendant
of Scheme. Scheme is a dialect of the Lisp family of programming
languages." — Wikipedia

"Lisp is like a phoenix; it rises from its own ashes and
therefore never dies." — De ongekruisigde (ds.)

Also xkcd: https://xkcd.com/297/

> +++

--
De Kerk van Roodkapje (KvR) belijdt de enige ware religie! De
Rode Macht van Roodkapje is wetenschappelijk onderzocht en
bevestigd (google roodverschuiving).

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.

On 2024-05-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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.

I always thought Racket via Scheme was the Lisp-1 branch and the
other ones the Lisp-2 branch. ;-)

--
De Kerk van Roodkapje (KvR) belijdt de enige ware religie! De
Rode Macht van Roodkapje is wetenschappelijk onderzocht en
bevestigd (google roodverschuiving).

Some entity, AKA "De ongekruisigde (ds.)" <ongekruisigde@gekruisigden.invalid>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

>> 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. ;-)

It does not matter whether you call it another dialect or language.
For any non initiated it's just as incomprehensible as a speech
impediment.

73's
Cor
--

Any marginally usable programming language approaches an ill
defined barely usable re-implementation of half of common-lisp
- 'someone

"De ongekruisigde (ds.)" <ongekruisigde@gekruisigden.invalid> writes:

> I always thought Racket via Scheme was the Lisp-1 branch and the
> other ones the Lisp-2 branch. ;-)

scheme is a more pure language. common lisp recognizes years of
accumulated code from different machines.

scheme is a nice language, it focuses more on concepts and math. CL just
defgeneric.

On Wed, 29 May 2024 21:08:41 +0000, Cor wrote:

> For any non initiated it's just as incomprehensible as a speech
> impediment.

PHP user?

"B. Pym" <No_spamming@noWhere_7073.org> writes:

> 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?

I think you're looking in the wrong place.

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.

Lisp, as we understand it now, starts out by defining a syntax for
literal data: symbols, numbers, strings, arrays, and, of course, cons
cells and lists. As a next step, it defines semantics for a subset of
these data items as a programming language. The result is a language
which is particularly good at thinking about itself.

One standard feature of Lisp languages is the special operator `quote'.
In a properly homoiconic Lisp, `quote' is /trivial/: if X is any datum,
then the result of evaluating (quote X) is X itself.

(Aside: am I alone in thinking that (quote X Y ... Z) ought to be
defined, and equivalent to (values (quote X) (quote Y) ... (quote Z))?)

This is not true in Scheme. The R4RS appendix introduced a hygienic
macro system which is incompatible with homoiconicity as demonstrated
through `quote'. For example:

(define-syntax demo
(syntax-rules ()
((_ form)
(begin (write (quote form)) (newline) form))))

(let ((x 1))
(let-syntax ((whoops
(syntax-rules ()
((_ y)
(let ((x 2))
(demo (values y x)))))))
(whoops x)))
; -| (values x x)
; => 1 2

If we're to believe `quote', then the form being evaluated is
(values x x), which should return two copies of the same value. But it
actually returns two different values -- how can this be?

Maybe `write' isn't up to the job and the two `x' symbols in that list
aren't actually the same.

(define-syntax inspect
(syntax-rules ()
((_ (expr . vals) form . body)
(let ((expr (quote form)))
(call-with-values (lambda () form) (lambda vals . body))))))

(let ((x 1))
(letrec ((show (lambda (which what x)
(display which)
(write-char #\space)
(display what)
(display " = ")
(write x)
(newline)))
(compare (lambda (what whats x y)
(show "first" what x)
(show "second" what y)
(display whats)
(display #\space)
(display (if (eq? x y) "equal" "unequal"))
(newline)))
(report (lambda (expr a b)
(compare "argument" "arguments"
(cadr expr) (caddr expr))
(compare "value" "values"
a b)
(values a b))))
(let-syntax ((gotcha
(syntax-rules ()
((_ y)
(let ((x 2))
(inspect (expr a b) (values y x)
(report expr a b)))))))
(gotcha x))))
; -| first argument = x
; -| second argument = x
; -| arguments equal
; -| first value = 1
; -| second value = 2
; -| values unequal
; => 1 2

That seems conclusive: `eq?' thinks that the two `x's are the same
symbol, but they sure don't behave the same.

Of course, what's going on here is that Scheme's hygienic macros don't
see /symbols/: they see /identifiers/ which maintain additional
information about which scope they're bound in, and `quote' strips this
information away. Which means that `quote' is nontrivial, and Scheme is
heteroiconic.

I think R3RS Scheme was a Lisp. However, the report describes
expression syntax in terms of /characters/ rather than in terms of
Scheme data items which, in retrospect, should have been seen as a
warning.

> 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.

Nobody forces you to use `loop' in Common Lisp, and it's not like it's
particularly hard to read. I could understand if the hill you wanted to
die on was Common Lisp's `format' syntax (though I'm a fan, and you'll
have to prise `format' out of my cold, dead hands), but `loop' is just
not that big a deal.

About the only thing it has which isn't obviously available elsewhere is
a means for building lists efficiently in order.

> Let's just say that Scheme is a better Lisp than CL (COBOL-Like) is.

No. Scheme is not a Lisp.

-- [mdw]

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.

> This is not true in Scheme. The R4RS appendix introduced a hygienic
> macro system which is incompatible with homoiconicity as demonstrated
> through `quote'.

So if you don’t use that hygienic macro system, Scheme retains its
homoiconicity?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> 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.

Can you give an example of Python's homoiconicity?

On Fri, 31 May 2024 23:48:37 -0300, Julieta Shem wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> 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.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Fri, 31 May 2024 23:48:37 -0300, Julieta Shem wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> 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 2024-06-01, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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.

Good guess, now go look it up.

Homoiconic refers to storing the program in the same representation that
the programmer works with.

The POSIX shell is homoiconic because funtions can be listed using
the "set" command, with no arguments. They appear in the same form,
modulo reformatting.

In Common Lisp, the ED function, an optional feature, support for
whcih is implementation-defined, provides homoiconicity.

ED can be used to edit the textual representation of a function.

The 1960's TRAC project in which "homoiconic" originated similarly
had definitions that could be recalled at run-time and edited.

Line-numbered BASIC, like what appeared on 8 bit microcomputers
in the 1970s and 80s, is also homoiconic. The lines of the program
can be listed and edited. (They are typically tokenized, so not
stored exactly as entered, but it still lands under homoiconic.)

"Homoiconic" is a tangential, useless concept in the code-is-data
debate, which is exhibited by low-brow garbage languages like BASIC and
POSIX shell.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> 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.

That seems like an uninteresting definition. Any language whose data
objects are /insufficient/ to represent an abstract syntax tree is
clearly too weak to do much of any use. (Exercise: work out how to
represent trees in traditional Bourne shell.)

My definition, which I gave by implication earlier, is that the language
is /embedded/ in its own data values. That is, the source code that you
write is interpreted /first/ as data values, and then /those data
values/ are evaluated or compiled according to semantics assigned to
them by the language definition.

Common Lisp is homoiconic by this definition. Consider:

(defun fib (n)
(let ((a 0) (b 1))
(do ((i (1- (integer-length n)) (1- i)))
((minusp i) a)
(let ((aa (* a a)))
(psetf a (+ aa (* 2 a b))
b (+ aa (* b b))))
(when (logbitp i n)
(psetf a (+ a b)
b a)))))

This is a list of four elements: two symbols, `defun' and `fib'; and two
lists, `(n)' and `(let ...)'. If you evaluate or compile this list,
then you get a function named `fib' which computes the Nth Fibonacci
number, given a nonnegative integer N, but that's strictly secondary.

The non-Lisp homoiconic language which springs most immediately to my
mind is Tcl. Interestingly, Tcl lacks a direct analogy to Lisp's
`quote': Tcl procedures are essentially fexprs, and they always receive
their arguments unevaluated. A procedure must explicitly evaluate an
argument if that's what it wants. Complicating things a little, Tcl has
at lest /two/ evaluation schemes for its values: arithmetic evaluation
via `expr', and command evaluation via `eval' or (more commonly)
`uplevel'.

Perhaps the strongest objection to this classification is that Tcl's
only data types are strings and associative arrays: the latter lack a
literal syntax, and the former are too trivial to embed a language into
in an interesting way. Except that Tcl can reinterpret its strings in
multiple ways. This used to be in implementation detail for the
commands concerned, but Tcl 8 introduced `dual-ported' variables, which
are converted lazily between the strings which are the apparent values,
and internal formats defined by interpreter extensions. The most
interesting such interpretation is as a `list'. Tcl lists are split
into items at whitespace, except where prevented by double quotes or
matching braces.

For example:

package require math::bignum
foreach name {bits testbit add mul} {
namespace import ::math::bignum::$name
}

proc fib {n} {
set n [::math::bignum::fromstr $n]
set a 0; set b 1
set w [bits $n]

for {set i [expr {$w - 1}]} {$i >= 0} {incr i -1} {
set aa [mul $a $a]
set ab [mul $a $b]
set twice_ab [add $ab $ab]
set a [add $aa $twice_ab]
set b [add $aa [mul $b $b]]

if {[testbit $n $i]} {
set t $a
set a [add $a $b]
set b $t
}
}
return [::math::bignum::tostr $a]
}

This file contains four lists, though the third is empty. The first has
three elements: `package', `require', and `math::bignum'. The second
has four elements: `foreach', `name', `bits testbit add mul' (itself a
list of four elements), and `newline import ::math::bignum::$name' (with
some extraneous whitespace elided).

Command evaluation clearly can be seen as acting on Tcl lists.
(Internally, the interpreter actually maintains a compiled
representation of the code, but I don't see that as significant.)
Expression evaluation, somewhat sadly, does not, and isn't homoiconic in
any interesting sense.

-- [mdw]

>>> What's your definition of homoiconicity?
>> The AST can be represented in language objects.
> That seems like an uninteresting definition.

I'd argue that it's by necessity: it's an uninteresting (and fairly
ill-defined) concept.

Stefan

* Stefan Monnier <jwvle3jjpuy.fsf-monnier+comp.lang.lisp@gnu.org> :
Wrote on Wed, 05 Jun 2024 12:51:52 -0400:
> I'd argue that it's by necessity: it's an uninteresting (and fairly
> ill-defined) concept.

because your preferred "lisps" don't do it (for whatever ill-conceived
reasons)