Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.lisp > #60301 > unrolled thread

Re: Writing HG LISP in Python, kind of

Started byLawrence D'Oliveiro <ldo@nz.invalid>
First post2025-04-14 23:43 +0000
Last post2025-09-25 05:50 +0000
Articles 14 — 7 participants

Back to article view | Back to comp.lang.lisp

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Writing HG LISP in Python, kind of Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 23:43 +0000
    Re: Writing HG LISP in Python, kind of "B. Pym" <Nobody447095@here-nor-there.org> - 2025-06-10 07:53 +0000
    Re: Writing HG LISP in Python, kind of Aidan Kehoe <kehoea@parhasard.net> - 2025-09-23 20:28 +0100
      Re: Writing HG LISP in Python, kind of Jeff Barnett <jbb@notatt.com> - 2025-09-23 17:22 -0600
      Re: Writing HG LISP in Python, kind of Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-24 09:11 +0000
        Re: Writing HG LISP in Python, kind of Madhu <enometh@meer.net> - 2025-09-24 16:55 +0530
          Re: Writing HG LISP in Python, kind of tpeplt@gmail.com - 2025-09-24 14:59 -0400
          Re: Writing HG LISP in Python, kind of Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-24 20:34 +0000
            Re: Writing HG LISP in Python, kind of Aidan Kehoe <kehoea@parhasard.net> - 2025-09-25 06:07 +0100
              Re: Writing HG LISP in Python, kind of Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-25 05:49 +0000
        Re: Writing HG LISP in Python, kind of Aidan Kehoe <kehoea@parhasard.net> - 2025-09-24 14:03 +0100
          Re: Writing HG LISP in Python, kind of Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-24 20:33 +0000
            Re: Writing HG LISP in Python, kind of Aidan Kehoe <kehoea@parhasard.net> - 2025-09-25 05:58 +0100
              Re: Writing HG LISP in Python, kind of Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-25 05:50 +0000

#60301 — Re: Writing HG LISP in Python, kind of

FromLawrence D'Oliveiro <ldo@nz.invalid>
Date2025-04-14 23:43 +0000
SubjectRe: Writing HG LISP in Python, kind of
Message-ID<vtk6iu$2cj23$4@dont-email.me>
On 14 Apr 2025 09:56:26 GMT, Stefan Ram wrote:

> Lisp's cons cells are conceptual, not just syntax.

Is that why Lisp needs the separate concept of multi-value return, instead 
of doing simple destructuring assignment as both Python and JavaScript are 
able to do?

[toc] | [next] | [standalone]


#60323

From"B. Pym" <Nobody447095@here-nor-there.org>
Date2025-06-10 07:53 +0000
Message-ID<1028o9h$14c2i$1@dont-email.me>
In reply to#60301
Lawrence D'Oliveiro wrote:

> On 14 Apr 2025 09:56:26 GMT, Stefan Ram wrote:
> 
> > Lisp's cons cells are conceptual, not just syntax.
> 
> Is that why Lisp needs the separate concept of multi-value return, instead 
> of doing simple destructuring assignment as both Python and JavaScript are 
> able to do?

Gauche Scheme

gosh> (apply (^(a b c) (list c b a)) '(3 4 5))
(5 4 3)

gosh> (define three (values 3 4 5))
three
gosh> three
3

[toc] | [prev] | [next] | [standalone]


#60713

FromAidan Kehoe <kehoea@parhasard.net>
Date2025-09-23 20:28 +0100
Message-ID<87ms6lc6jw.fsf@parhasard.net>
In reply to#60301
 Ar an ceathrú lá déag de mí Aibreán, scríobh Lawrence D'Oliveiro: 

 > On 14 Apr 2025 09:56:26 GMT, Stefan Ram wrote:
 > 
 > > Lisp's cons cells are conceptual, not just syntax.
 > 
 > Is that why Lisp needs the separate concept of multi-value return, instead
 > of doing simple destructuring assignment as both Python and JavaScript are
 > able to do?

Lisp’s #'destructuring-bind is available. But the stack is right there (for
most people, most of the time), why not make use it as a cheap way to return
multiple values?

-- 
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

[toc] | [prev] | [next] | [standalone]


#60714

FromJeff Barnett <jbb@notatt.com>
Date2025-09-23 17:22 -0600
Message-ID<10ava48$3alem$1@dont-email.me>
In reply to#60713
On 9/23/2025 1:28 PM, Aidan Kehoe wrote:
> 
>   Ar an ceathrú lá déag de mí Aibreán, scríobh Lawrence D'Oliveiro:
> 
>   > On 14 Apr 2025 09:56:26 GMT, Stefan Ram wrote:
>   >
>   > > Lisp's cons cells are conceptual, not just syntax.
>   >
>   > Is that why Lisp needs the separate concept of multi-value return, instead
>   > of doing simple destructuring assignment as both Python and JavaScript are
>   > able to do?
> 
> Lisp’s #'destructuring-bind is available. But the stack is right there (for
> most people, most of the time), why not make use it as a cheap way to return
> multiple values?
CL provides multi-value-setq as a macro I think) and it does the obvious 
thing. Since the head of this thread has been lopped off, I don't know 
if this form was previously discussed.
-- 
Jeff Barnett

[toc] | [prev] | [next] | [standalone]


#60715

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-09-24 09:11 +0000
Message-ID<10b0cks$3i6j6$1@dont-email.me>
In reply to#60713
On Tue, 23 Sep 2025 20:28:19 +0100, Aidan Kehoe wrote:

> Ar an ceathrú lá déag de mí Aibreán, scríobh Lawrence D'Oliveiro:
> 
>> Is that why Lisp needs the separate concept of multi-value return,
>> instead of doing simple destructuring assignment as both Python and
>> JavaScript are able to do?
> 
> Lisp’s #'destructuring-bind is available. But the stack is right
> there (for most people, most of the time), why not make use it as a
> cheap way to return multiple values?

That’s an implementation issue, which is irrelevant to the way the 
language works. Python lets you write

    a, b = b, a

as an easy way to swap the values of variables, for example.

[toc] | [prev] | [next] | [standalone]


#60716

FromMadhu <enometh@meer.net>
Date2025-09-24 16:55 +0530
Message-ID<m3ikh82iub.fsf@pison.robolove.meer.net>
In reply to#60715
* Lawrence D’Oliveiro <10b0cks$3i6j6$1@dont-email.me> :
Wrote on Wed, 24 Sep 2025 09:11:56 -0000 (UTC):
> On Tue, 23 Sep 2025 20:28:19 +0100, Aidan Kehoe wrote:
>> Lawrence D'Oliveiro:

>>> Is that why Lisp needs the separate concept of multi-value return,
>>> instead of doing simple destructuring assignment as both Python and
>>> JavaScript are able to do?
>>
>> Lisp’s #'destructuring-bind is available. But the stack is right
>> there (for most people, most of the time), why not make use it as a
>> cheap way to return multiple values?
>
> That’s an implementation issue, which is irrelevant to the way the
> language works. Python lets you write
>
>     a, b = b, a
>
> as an easy way to swap the values of variables, for example.

What does this non-sequitur have to do with bindings (either
destructuring or multiple values)?

Mutation of bindings is handled in lisp through generalized references
("places") in a uniform way.

(let ((a 10) (b 20)) (rotatef a b) (list a b))

https://www.lispworks.com/documentation/HyperSpec/Body/m_shiftf.htm
https://www.lispworks.com/documentation/HyperSpec/Body/05_a.htm

[toc] | [prev] | [next] | [standalone]


#60718

Fromtpeplt@gmail.com
Date2025-09-24 14:59 -0400
Message-ID<87zfajad8m.fsf@gmail.com>
In reply to#60716
Madhu <enometh@meer.net> writes:

>>
>> That’s an implementation issue, which is irrelevant to the way the
>> language works. Python lets you write
>>
>>     a, b = b, a
>>
>> as an easy way to swap the values of variables, for example.
>
> What does this non-sequitur have to do with bindings (either
> destructuring or multiple values)?
>
> Mutation of bindings is handled in lisp through generalized references
> ("places") in a uniform way.
>
> (let ((a 10) (b 20)) (rotatef a b) (list a b))
>
> https://www.lispworks.com/documentation/HyperSpec/Body/m_shiftf.htm
> https://www.lispworks.com/documentation/HyperSpec/Body/05_a.htm
>

Did you mean to reference the documentation for ROTATEF?

‘m_shiftf.htm’ is the page that documents the macro SHIFTF.

‘m_rotatef.htm’ is the page that documents the macro ROTATEF.

At the www.ai.mit.edu website, they have expanded the ‘m_’
to ‘mac_’ to provide a longer hint that a page documents a
macro:

http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_rotatef.html

-- 
The lyf so short, the craft so long to lerne.
- Geoffrey Chaucer, The Parliament of Birds.

[toc] | [prev] | [next] | [standalone]


#60720

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-09-24 20:34 +0000
Message-ID<10b1kle$3tbca$2@dont-email.me>
In reply to#60716
On Wed, 24 Sep 2025 16:55:16 +0530, Madhu wrote:

> * Lawrence D’Oliveiro <10b0cks$3i6j6$1@dont-email.me> :
>>
>>     a, b = b, a
> 
> What does this ... have to do with bindings (either
> destructuring or multiple values)?

Structuring on the RHS, destructuring on the LHS. All happens 
automatically, without you even having to think about it.

Maybe more obvious if you put in the optional parentheses, to make 
explicit that there is only a single expression on the RHS:

    (a, b) = (b, a)

[toc] | [prev] | [next] | [standalone]


#60722

FromAidan Kehoe <kehoea@parhasard.net>
Date2025-09-25 06:07 +0100
Message-ID<87a52jce82.fsf@parhasard.net>
In reply to#60720
 Ar an ceathrú lá is fiche de mí Méan Fómhair, scríobh Lawrence D’Oliveiro: 

 > On Wed, 24 Sep 2025 16:55:16 +0530, Madhu wrote:
 > 
 > > * Lawrence D’Oliveiro <10b0cks$3i6j6$1@dont-email.me> :
 > >>
 > >>     a, b = b, a
 > > 
 > > What does this ... have to do with bindings (either
 > > destructuring or multiple values)?
 > 
 > Structuring on the RHS, destructuring on the LHS. All happens automatically,
 > without you even having to think about it.

Well, you need to know the syntax.

Lisp does not have infix operators. That’s a basic design decision. Once you’ve
accepted that, (multiple-value-setq (a b) (values b a)) is not any less elegant
than your example above.

 > Maybe more obvious if you put in the optional parentheses, to make explicit
 > that there is only a single expression on the RHS:
 > 
 >     (a, b) = (b, a)

-- 
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

[toc] | [prev] | [next] | [standalone]


#60723

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-09-25 05:49 +0000
Message-ID<10b2l5u$428i$1@dont-email.me>
In reply to#60722
On Thu, 25 Sep 2025 06:07:09 +0100, Aidan Kehoe wrote:

> Lisp does not have infix operators. That’s a basic design decision.

Which is entirely separate from the issue of destructuring assignment.

[toc] | [prev] | [next] | [standalone]


#60717

FromAidan Kehoe <kehoea@parhasard.net>
Date2025-09-24 14:03 +0100
Message-ID<87ikh8c89f.fsf@parhasard.net>
In reply to#60715
 Ar an ceathrú lá is fiche de mí Méan Fómhair, scríobh Lawrence D’Oliveiro: 

 > On Tue, 23 Sep 2025 20:28:19 +0100, Aidan Kehoe wrote:
 > 
 > > Ar an ceathrú lá déag de mí Aibreán, scríobh Lawrence D'Oliveiro:
 > > 
 > >> Is that why Lisp needs the separate concept of multi-value return,
 > >> instead of doing simple destructuring assignment as both Python and
 > >> JavaScript are able to do?
 > > 
 > > Lisp’s #'destructuring-bind is available. But the stack is right
 > > there (for most people, most of the time), why not make use it as a
 > > cheap way to return multiple values?
 > 
 > That’s an implementation issue, which is irrelevant to the way the 
 > language works.

I used to think this back I took an interest in comp.lang.c, where people were
unwilling to discuss aspects of the common implementations that did not fall
under the standards. I thought they were 100% in the right.

With time and maturity I have come to the realisation that there is *always* an
underlying machine and an underlying language implementation, absent irrelevant
Gedankenexperimente where software does not have to run. If the software
written is multiplatform, there are more important (more used) and less
important (less used) platforms.

What can be implemented, and what can be implemented in a performant way,
guides language design. Language design guides how a language works.

 > Python lets you write
 > 
 >     a, b = b, a
 > 
 > as an easy way to swap the values of variables, for example.

Madhu has followed this up fairly comprehensively.

-- 
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

[toc] | [prev] | [next] | [standalone]


#60719

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-09-24 20:33 +0000
Message-ID<10b1ki9$3tbca$1@dont-email.me>
In reply to#60717
On Wed, 24 Sep 2025 14:03:40 +0100, Aidan Kehoe wrote:

> With time and maturity I have come to the realisation that there is
> *always* an underlying machine and an underlying language
> implementation ...

With popular languages, there are typically multiple implementations, 
often built on very different implementation concepts.

This is the case with Python, just for example.

[toc] | [prev] | [next] | [standalone]


#60721

FromAidan Kehoe <kehoea@parhasard.net>
Date2025-09-25 05:58 +0100
Message-ID<87ecrvcelu.fsf@parhasard.net>
In reply to#60719
 Ar an ceathrú lá is fiche de mí Méan Fómhair, scríobh Lawrence D’Oliveiro: 

 > On Wed, 24 Sep 2025 14:03:40 +0100, Aidan Kehoe wrote:
 > 
 > > With time and maturity I have come to the realisation that there is
 > > *always* an underlying machine and an underlying language
 > > implementation ...
 > 
 > With popular languages, there are typically multiple implementations, 
 > often built on very different implementation concepts.

And very few of them have no stack, or no heap, or are implemented on
drum-memory computers, or use an underlying integer representation that is
other than twos’ complement.

 > This is the case with Python, just for example.

-- 
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

[toc] | [prev] | [next] | [standalone]


#60724

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2025-09-25 05:50 +0000
Message-ID<10b2l7g$428i$2@dont-email.me>
In reply to#60721
On Thu, 25 Sep 2025 05:58:53 +0100, Aidan Kehoe wrote:

> Ar an ceathrú lá is fiche de mí Méan Fómhair, scríobh Lawrence
> D’Oliveiro:
>
>> With popular languages, there are typically multiple
>> implementations, often built on very different implementation
>> concepts.
>
> And very few of them have no stack, or no heap, or are implemented
> on drum-memory computers, or use an underlying integer
> representation that is other than twos’ complement.

Or have no register file, nowadays, while we’re at it.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.lisp


csiph-web