@MSGID: <isMgDLLnFWYAwAbcn@bongo-ra.co> e76451b3
@REPLY:
2633b500
@REPLYADDR Spiros Bousbouras <spibou@gmail.com>
@REPLYTO 2:5075/128 Spiros Bousbouras
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: <isMgDLLnFWYAwAbcn@bongo-ra.co>
@RFC-References:
<2bcb3a48-7082-4d29-9496-829749a5403cn@googlegroups.com> <20230607130305.691@kylheku.com>
<nzRJAvWCQBiyNSZoM@bongo-ra.co>
@TZUTC: -0000
@TID: FIDOGATE-5.12-ge4e8b94
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 .

Apart from that , I find your approach interesting. How far are you planning
to develop your language ? How high level is it going to be ? For example
with CL macros , one of the arguments of the macro often is some user
provided code and the macro produces some code of its own and combines it
with the user code to achieve a desired effect. The analogous for your
language would be to pass some user code on the stack. Perhaps the same
effects can be achieved by passing an execution token on the stack , it
depends on what else the language can do.

-- 
How did he find her? Quite simple really. He assumed there was only
one place for a foreigner to stay in Ibusuki-the big international hotel.
So he called there and asked to have himself connected to the Dutch woman`s
room.
  http://www.debito.org/beggarsresults.html
--- FIDOGATE 5.12-ge4e8b94
 * 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