@MSGID: <20230620155304.109@kylheku.com> 2df60312
@REPLY: <isMgDLLnFWYAwAbcn@bongo-ra.co> e76451b3
@REPLYADDR Kaz Kylheku <864-117-4973@kylheku.com>
@REPLYTO 2:5075/128 Kaz Kylheku
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: <20230620155304.109@kylheku.com>
@RFC-References:
<2bcb3a48-7082-4d29-9496-829749a5403cn@googlegroups.com> <20230607130305.691@kylheku.com>
<nzRJAvWCQBiyNSZoM@bongo-ra.co>
<isMgDLLnFWYAwAbcn@bongo-ra.co>
@TZUTC: -0000
@PID: slrn/1.0.3 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
On 2023-06-20, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Mon, 19 Jun 2023 11:41:44 +0200
> albert@cherry.(none) (albert) wrote:
>> In article <nzRJAvWCQBiyNSZoM@bongo-ra.co>,
>> Spiros Bousbouras  <spibou@gmail.com> wrote:
>> >For 2 or more levels of nesting , I find it a lot more readable
>> >to use explicit calls instead of nested backquotes. With the
>> >explicit calls , you push all the quoting to the innermost level
>> >and otherwise the usual evaluation rules apply. It usually is
>> >more verbose but I find it more readable.
>> 
>> I have been experimenting with a reverse polish like language.
>> The main elements are bracket pairs.
>> { } is deferred code
>> { do something } leaves a token that can be "run".
>> Normally code is executed, but you can execute code
>> while in deferred mode by [ ]
>> So you got
>> { [ 1 2 + "addition result:" type . ] "hello world" type }
>> This types the addition result while the line is entered.
>> It leaves a token that can be run to type the "hello world| message.
>> Normally a deferred token is given a name via `:` like so.
>> { "hello world" type } : hellow
>> 
>> The idea is that the brackets can be nested indefinitely.
>> { [ variable x ] .... x ... }
>> {
>>     [
>>         variable x
>>         { 2 * + } : add-a-duplicate
>>     ] .... x add-a-duplicate ...
>> } : do-something
>> 
>> Is that idea related?
>
> It is related to the overall discussion but it is kind of the opposite to
> what I was saying in my post you are directly replying to. I find it harder
> to read where you have nested scopes and , depending on the level of nesting
> , the evaluation happens during translation time or later and that`s the kind
> of thing I aim to avoid. I find your notation better than backquotes and
> commas but basically with something like  { .... }  , you still have to read
> deeper to see if there are any  [ ... ]  and within a  [ ... ]  deeper to see
> if there are any  { ... } and so forth ; whereas with Common Lisp`s QUOTE ,
> you know right away that everything in the scope of QUOTE will be taken as
> is. Actually this isn`t completely accurate because CL also offers read time
> evaluation but I`ve never used it , I don`t think it`s a good idea and I turn
> it off by setting *READ-EVAL* to NIL .

In TXR Lisp there is a macro-time macro. (Such a macro can easily be
written in ANSI CL.) (macro-time expr) evaluates macro during expansion
and substitutes its result, which is quoted to prevent it being
expanded and evaluated as code.

2> (expand `(list (macro-time (uname).sysname) (uname).sysname))
(list "Linux" (slot (uname) `sysname))

But I sense this is not the same as in the languagre above.

The main mechanism for deferrment is the lambda expression.
Implementations of cruft like delay or force, or lazily evaluated
sub-languages generate lambdas.

We can imagine a form of lambda expression which is evaluated as normal,
but in whose body you can perform calculations *now*, rather than later.

For instance

  (let ((x ...))
    (lambda (y)
      (+ [* x 2] y)))

Here {* x 2} is evaluated and reduced at the time the lambda is
evaluated, not at the time when it is called. This could be achieved
by a transformation like this:

  (let ((x ...))
    (let ((#:g0025 (* x 2)))
      (lambda () (+ #:g0025 y)))) ;; same gensym

We have exactly what we want: (* x 2) is evaluated at around the same
time as the lambda (just before). Its value is available through a
a hidden variable that is inserted where the {* x 2} expression
appeared.

In ANSI CL we could make some macro, say dlambda, such that

  (dlambda () (+ (unlambda * x 2) y))

will expand to the above let construction. Then a reader macro provides
the {...} -> [unlambda ...] sugar.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- slrn/1.0.3 (Linux)
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5005/49 5015/255 5019/40 5020/715 848 1042
4441 12000 5030/49 1081
SEEN-BY: 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441