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

Groups > comp.lang.forth > #30321 > unrolled thread

Re: Quotations revisited

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

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: Quotations revisited Mark Wills <markwills1970@gmail.com> - 2014-05-13 01:00 -0700
    Re: Quotations revisited Howerd <howerdo@yahoo.co.uk> - 2014-05-13 01:50 -0700
    Re: Quotations revisited Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-13 03:51 -0500
      Re: Quotations revisited Mark Wills <markwills1970@gmail.com> - 2014-05-13 02:25 -0700
        Re: Quotations revisited Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-13 05:08 -0500
          Re: Quotations revisited "Elizabeth D. Rather" <erather@forth.com> - 2014-05-13 07:46 -1000
          Re: Quotations revisited Paul Rubin <no.email@nospam.invalid> - 2014-05-13 11:03 -0700
            Re: Quotations revisited "Elizabeth D. Rather" <erather@forth.com> - 2014-05-13 08:12 -1000
            Re: Quotations revisited Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-13 13:22 -0500
    Re: Quotations revisited stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-13 09:15 +0000
      Re: Quotations revisited Mark Wills <markwills1970@gmail.com> - 2014-05-13 02:39 -0700
        Re: Quotations revisited Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-13 05:10 -0500
        Re: Quotations revisited stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-13 11:47 +0000
        Re: Quotations revisited Laurent Laborde <kerdezixe@gmail.com> - 2014-05-13 19:13 -0700
        Re: Quotations revisited Paul Rubin <no.email@nospam.invalid> - 2014-05-13 19:48 -0700
    Re: Quotations revisited Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-13 03:43 -0700
      Re: Quotations revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-13 12:35 +0000
        Re: Quotations revisited "Alex McDonald" <blog@rivadpm.com> - 2014-05-13 23:56 +0100
          Re: Quotations revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 14:15 +0000
            Re: Quotations revisited "Alex McDonald" <blog@rivadpm.com> - 2014-05-14 20:48 -0400
              Re: Quotations revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-15 14:16 +0000
        Re: Quotations revisited Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-13 23:30 -0700
          Re: Quotations revisited Paul Rubin <no.email@nospam.invalid> - 2014-05-14 00:32 -0700
            Re: Quotations revisited Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-14 02:02 -0700
              Re: Quotations revisited Paul Rubin <no.email@nospam.invalid> - 2014-05-14 08:02 -0700
                Re: Quotations revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 15:10 +0000
            Re: Quotations revisited Mark Wills <markwills1970@gmail.com> - 2014-05-14 02:09 -0700
              Re: Quotations revisited Mark Wills <markwills1970@gmail.com> - 2014-05-14 02:14 -0700
                Re: Quotations revisited Mark Wills <markwills1970@gmail.com> - 2014-05-14 02:15 -0700
                  Re: Quotations revisited Paul Rubin <no.email@nospam.invalid> - 2014-05-14 08:22 -0700
              Re: Quotations revisited Coos Haak <chforth@hccnet.nl> - 2014-05-14 12:04 +0200
          Re: Quotations revisited Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-14 04:11 -0500
          Re: Quotations revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 14:25 +0000
            Re: Quotations revisited Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-14 20:04 +0200
              Re: Quotations revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-15 13:50 +0000
                Re: Quotations revisited Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-15 16:24 +0200
                  Re: Quotations revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-15 14:40 +0000
                    Re: Quotations revisited Mark Wills <markwills1970@gmail.com> - 2014-05-15 10:18 -0700
            Re: Quotations revisited Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-14 21:57 -0700

Page 1 of 2  [1] 2  Next page →

#30321 — Re: Quotations revisited

On Friday, July 20, 2012 12:12:21 PM UTC+1, Stephen Pelc wrote:
> A revised summary, 18 July 2012

[snip]

Well, some 22 months on, I still can't see a use for either closures or quotations. It looks like a lot of added complexity just to be able to do a neat trick, but (to quote Joan Arma-Trading) I'm open to persuasion.

The biggest issue seems to be that one does not know when the XT will finally be executed. Specifically, the XT produced may be carried out of the enclosing parent definition via the stack and executed elsewhere. This is just bonkers. It would be a lot easier if folk just agreed that the XT must be executed within the enclosing definition; but then, you gain nothing over what can currently be obtained within standard Forth.

I've tried to twist things in my mind to try to justify why these things might be useful. Can't. 

Total white elephant. Just stop it!

[toc] | [next] | [standalone]

#30322

Hi Mark,

My take on this is that Forth allows, and even requires, that the programmer is aware of the difference between edit, interpret, compile and execution times.

C/C++ miss out the interpret time, and the more abstract "high level" languages try to do away with time altogether - everything exists as an idea with no connection to the mechanics of editing, interpreting, compiling and executing.

So these non-Forth languages must fight to get back the functionality that we take for granted in Forth, by using complicated things such as C++ templates (to allow some control at compile time), and quotations (to allow some control somewhere between compile and execute times?).
And of course, Object Oriented programming (every Forth word is an Object).
Most of these concepts are covered in Forth by the words LOAD or INCLUDE , which you can choose to call whenever you want to (even at edit time in colorForth, sort of).

So I agree with you, that these things are not necessary in Forth.
But of course it is good to have them so that we can say that we have them.

BTW I do not include Transactional Memory in this list - I think this is probably useful in Forth too...

Best regards,
Howerd


On Tuesday, 13 May 2014 09:00:56 UTC+1, Mark Wills  wrote:
> On Friday, July 20, 2012 12:12:21 PM UTC+1, Stephen Pelc wrote:
> 
> > A revised summary, 18 July 2012
> 
> 
> 
> [snip]
> 
> 
> 
> Well, some 22 months on, I still can't see a use for either closures or quotations. It looks like a lot of added complexity just to be able to do a neat trick, but (to quote Joan Arma-Trading) I'm open to persuasion.
> 
> 
> 
> The biggest issue seems to be that one does not know when the XT will finally be executed. Specifically, the XT produced may be carried out of the enclosing parent definition via the stack and executed elsewhere. This is just bonkers. It would be a lot easier if folk just agreed that the XT must be executed within the enclosing definition; but then, you gain nothing over what can currently be obtained within standard Forth.
> 
> 
> 
> I've tried to twist things in my mind to try to justify why these things might be useful. Can't. 
> 
> 
> 
> Total white elephant. Just stop it!

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

#30323

Mark Wills <markwills1970@gmail.com> wrote:
> On Friday, July 20, 2012 12:12:21 PM UTC+1, Stephen Pelc wrote:
>> A revised summary, 18 July 2012
> 
> [snip]
> 
> Well, some 22 months on, I still can't see a use for either closures
> or quotations. It looks like a lot of added complexity just to be
> able to do a neat trick, but (to quote Joan Arma-Trading) I'm open
> to persuasion.

Eh?  It's a portable way to create constructs that have been
written in non-portable ways for decades. It extends something that
people have long been doing to standard code in a clean way.

> The biggest issue seems to be that one does not know when the XT
> will finally be executed. Specifically, the XT produced may be
> carried out of the enclosing parent definition via the stack and
> executed elsewhere. This is just bonkers. It would be a lot easier
> if folk just agreed that the XT must be executed within the
> enclosing definition; but then, you gain nothing over what can
> currently be obtained within standard Forth.

It makes no difference whether the XT will be excuted in the scope of
its enclosing definition or not.

> I've tried to twist things in my mind to try to justify why these
> things might be useful. Can't.

You don't like doing these things, okay: it doesn't fit your
programming stayle.  That is all.

Andrew.

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

#30326

On Tuesday, 13 May 2014 09:51:38 UTC+1, Andrew Haley  wrote:
> Eh?  It's a portable way to create constructs that have been
> written in non-portable ways for decades. It extends something that
> people have long been doing to standard code in a clean way.
> 
Is it? In that case, you'll have no problem posting an example of the
before, and the "solved problem" using quotations and/or closures,
will you? Looking forward to it.

> It makes no difference whether the XT will be excuted in the scope of
> its enclosing definition or not.

If does if it's a closure, because the closure has read and write access to the enlosing definitions' locals, so unless you execute the xt right there and then within the parent, it's very difficult to get access to them, especially if your locals are on the return stack. Of course, if you have to execute the xt in the parent definition, then the whole thing is pointless, no requirement for a nested definition/closure at all.

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

#30328

Mark Wills <markwills1970@gmail.com> wrote:
> On Tuesday, 13 May 2014 09:51:38 UTC+1, Andrew Haley  wrote:
>> Eh?  It's a portable way to create constructs that have been
>> written in non-portable ways for decades. It extends something that
>> people have long been doing to standard code in a clean way.
>> 
> Is it? In that case, you'll have no problem posting an example of the
> before, and the "solved problem" using quotations and/or closures,
> will you? Looking forward to it.

No problem.

Here's an example of the word ACTIVATE, which is used to start a task
executing some code:

: monitoring   monitor-task activate  begin  monitor  sleep  again ;

ACTIVATE returns immediately from MONITORING after starting
MONITOR-TASK, which executes the rest of MONITORING asynchronously.
This construct has been around since the early days of Forth.

Given START, which takes an address to execute and a task,
ACTIVATE can be written (very) non-portably on some systems as

: activate   r> ( Some magic here to turn the return address into an XT) start ;

With quotations, you can achieve the same effect with no non-portable
trickery, and no need for the word ACTIVATE:

: monitoring    monitor-task [: begin  monitor  sleep  again ;] start ;

There is a similar notational advantage with CATCH:

: foo ( - code)   begin  [: foo bar danger ;]  catch ?dup until ;

And, if you really want to make sure that some code is executed in
DECIMAL base and that base is restored:

: in-decimal ( xt)   base @ >r  decimal  catch  r> base !  throw ;

used as:

   [:  fred ?  bill ?  foo .  ;] in-decimal

And yes, all this could be achieved with auxiliary definitions.  Of
course it could: a quotation is just an unnamed definition.  A
quotation is a simple thing to define, and a simple thing to use.
It's not an overwhelming addition to the power of the language: it's a
small thing that makes programs easier to read and write.

>> It makes no difference whether the XT will be executed in the scope of
>> its enclosing definition or not.
> 
> If does if it's a closure,

Quotations are not closures.

Andrew.

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

#30338

On 5/13/14 12:08 AM, Andrew Haley wrote:
...
> Here's an example of the word ACTIVATE, which is used to start a task
> executing some code:
>
> : monitoring   monitor-task activate  begin  monitor  sleep  again ;
>
> ACTIVATE returns immediately from MONITORING after starting
> MONITOR-TASK, which executes the rest of MONITORING asynchronously.
> This construct has been around since the early days of Forth.
>
> Given START, which takes an address to execute and a task,
> ACTIVATE can be written (very) non-portably on some systems as
>
> : activate   r> ( Some magic here to turn the return address into an XT) start ;
>
> With quotations, you can achieve the same effect with no non-portable
> trickery, and no need for the word ACTIVATE:
>
> : monitoring    monitor-task [: begin  monitor  sleep  again ;] start ;
>
> There is a similar notational advantage with CATCH:
>
> : foo ( - code)   begin  [: foo bar danger ;]  catch ?dup until ;
>
> And, if you really want to make sure that some code is executed in
> DECIMAL base and that base is restored:
>
> : in-decimal ( xt)   base @ >r  decimal  catch  r> base !  throw ;
>
> used as:
>
>     [:  fred ?  bill ?  foo .  ;] in-decimal
>
> And yes, all this could be achieved with auxiliary definitions.  Of
> course it could: a quotation is just an unnamed definition.  A
> quotation is a simple thing to define, and a simple thing to use.
> It's not an overwhelming addition to the power of the language: it's a
> small thing that makes programs easier to read and write.
>
>>> It makes no difference whether the XT will be executed in the scope of
>>> its enclosing definition or not.
>>
>> If does if it's a closure,
>
> Quotations are not closures.

Thank you, Andrew, that's the first really good example of this that I 
have seen!

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#30341

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> ACTIVATE returns immediately from MONITORING after starting
> MONITOR-TASK, which executes the rest of MONITORING asynchronously. ..
> ACTIVATE can be written (very) non-portably on some systems as
> : activate   r> ( Some magic here to turn the return address into an XT) start ;

But "executes the rest of MONITORING asynchronously" instead of using an
xt (in an aux definition if quotations aren't available) just seems
hideous.  Was it aversion to xt's that led to that construction?

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

#30342

On 5/13/14 8:03 AM, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> ACTIVATE returns immediately from MONITORING after starting
>> MONITOR-TASK, which executes the rest of MONITORING asynchronously. ..
>> ACTIVATE can be written (very) non-portably on some systems as
>> : activate   r> ( Some magic here to turn the return address into an XT) start ;
>
> But "executes the rest of MONITORING asynchronously" instead of using an
> xt (in an aux definition if quotations aren't available) just seems
> hideous.  Was it aversion to xt's that led to that construction?
>

In Andrew's example, the point is that the sequence of words being 
passed to MONITOR-TASK just exists in this one place; it's not code that 
will be called from multiple places. To get an xt for it requires 
setting it up as a separate definition (or :noname), and using ACTIVATE 
in this way is cleaner and simpler. As Andrew shows, doing it with the 
quotation is just as clean, if you have that mechanism available.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#30343

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> ACTIVATE returns immediately from MONITORING after starting
>> MONITOR-TASK, which executes the rest of MONITORING asynchronously. ..
>> ACTIVATE can be written (very) non-portably on some systems as
>> : activate   r> ( Some magic here to turn the return address into an XT) start ;
> 
> But "executes the rest of MONITORING asynchronously" instead of
> using an xt (in an aux definition if quotations aren't available)
> just seems hideous. 

It reads nicely, for much the same reason as DOES> reads nicely:
there's less syntactic noise.  I prefer it.

> Was it aversion to xt's that led to that construction?

I wasn't there.  Elizabeth probably was.  :-)

Andrew.

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

#30324

On Tue, 13 May 2014 01:00:56 -0700 (PDT), Mark Wills
<markwills1970@gmail.com> wrote:

>On Friday, July 20, 2012 12:12:21 PM UTC+1, Stephen Pelc wrote:
>> A revised summary, 18 July 2012
>
>[snip]

>I've tried to twist things in my mind to try to justify why these things mi=
>ght be useful. Can't.=20
>
>Total white elephant. Just stop it!

You forget that programming is actually a branch of the fashion
industry. Every decade or so, someone tries out one of the
more revolting fashion disasters of the past.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#30327

On Tuesday, 13 May 2014 10:15:13 UTC+1, Stephen Pelc  wrote:
> You forget that programming is actually a branch of the fashion
> industry. Every decade or so, someone tries out one of the
> more revolting fashion disasters of the past.

Spot on. Closures being the flared trousers of programming!
No. Make that kaftans!

Like I say, I'm willing to be persuaded, but so far, I can't see 
a need for them. I can't think of anything that they're needed for,
that can't be done already. Examples cited earlier in the thread by
Paul looked like neat tricks - cool, but ultimately superflous,
since the same thing could be implemented in a different way, 
without having the compiler do a herculean amount of work behind 
the scenes to facilitate it.

The whole issue becomes a joke when looking at the machinations
and gyrations a Forth compiler would have to do to provide read/write
access to parents' locals. To have a Forth system that has native, 
built-in support for the latest, greatest features such as closures 
and quotations, and yet doesn't support arrays is a sick joke.

Just stop it!

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

#30329

Mark Wills <markwills1970@gmail.com> wrote:
> Like I say, I'm willing to be persuaded, but so far, I can't see 
> a need for them.

I don't believe you're willing at all.  

> Just stop it!

No.  No matter how loudly you shout.

Andrew.

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

#30332

On Tue, 13 May 2014 02:39:19 -0700 (PDT), Mark Wills
<markwills1970@gmail.com> wrote:

>To have a Forth system that has native, 
>built-in support for the latest, greatest features such as closures 
>and quotations, and yet doesn't support arrays is a sick joke.

What's an array? ... rhetorical question

Andrew's examples are notationally neat and solve one problem
that is important to me. At present we have no way of telling 
a Forth compiler that a definition is split into two or more
parts - only DOES> gives this information. All, or at least
the vast majority, of these situations can be covered by 
quotations and EXECUTE or CATCH.

The VFX Forth file Examples/quotations.fth provides 
implementations of quotations for SwiftForth, bigForth, gforth,
and VFX Forth. I will happily add iForth's version and others
as they are contributed.

The implementations are definitely for the system implementer,
but quotations can solve a need that would be visually ugly
done in other ways. That they also solve a compiler boundary
problem makes them a candidate for any toolmaker's toolbox.

Closures, however, are something else. We can leave those to people
who wear mountain boots every day in case a mountain springs up
next to them.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#30347

On Tuesday, May 13, 2014 11:39:19 AM UTC+2, Mark Wills wrote:
> On Tuesday, 13 May 2014 10:15:13 UTC+1, Stephen Pelc  wrote:
> 
> > You forget that programming is actually a branch of the fashion
> > industry. Every decade or so, someone tries out one of the
> > more revolting fashion disasters of the past.
> 
> Spot on. Closures being the flared trousers of programming!
> No. Make that kaftans!
> 
> Like I say, I'm willing to be persuaded, but so far, I can't see 
> a need for them. I can't think of anything that they're needed for,
> that can't be done already. Examples cited earlier in the thread by
> Paul looked like neat tricks - cool, but ultimately superflous,

Anything higher-level than a macro assembler is superfluous :p

-- 
Ker2x

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

#30348

Mark Wills <markwills1970@gmail.com> writes:
> Spot on. Closures being the flared trousers of programming!...
> Like I say, I'm willing to be persuaded, but so far, I can't see 
> a need for them. I can't think of anything that they're needed for,
> that can't be done already. Examples cited earlier in the thread by
> Paul looked like neat tricks - cool, but ultimately superflous

I don't remember what examples of closures I cited, but I've haven't
seen any serious proposal for having them in Forth, where they don't
really make sense in the absence of pervasive GC.

In Scheme and related languages, they are used all the time, for example
as the implementation mechanism for object-oriented programming.  You
make a closure that closes over some surrounding locals as instance
variables, then dispatches on its arguments when you call it, to act
like a method call.

You can read about them in SICP:  

  http://mitpress.mit.edu/sicp/full-text/book/book.html

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

#30330

On Tuesday, May 13, 2014 12:00:56 PM UTC+4, Mark Wills wrote:
> 
> The biggest issue seems to be that one does not know when the XT will
> finally be executed. Specifically, the XT produced may be carried out
> of the enclosing parent definition via the stack and executed
> elsewhere. This is just bonkers. It would be a lot easier if folk just
> agreed that the XT must be executed within the enclosing definition;
> but then, you gain nothing over what can currently be obtained within
> standard Forth.

As far as I understand the basic problem with time of a quotation
execution is caused with complexity of handling local variables in that
case. There is no problem if a quotation doesn't use locals from the
enclosing definition. Perhaps, the practical solution is just to claim
that it is OK to use the quotations without access to parent's locals
outside the parent's definition, but it is undefined behaviour if the
quotations access the locals.

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

#30333

Alexander Skobelev <al.skobelev@gmail.com> writes:
>As far as I understand the basic problem with time of a quotation
>execution is caused with complexity of handling local variables in that
>case. There is no problem if a quotation doesn't use locals from the
>enclosing definition.

Right.  That's why quotations don't support access not outer
locals and thats why we call them quotations, not closures.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#30346

on 13/05/2014 13:35:54,  wrote:
> Alexander Skobelev <al.skobelev@gmail.com> writes:
>>As far as I understand the basic problem with time of a quotation
>>execution is caused with complexity of handling local variables in that
>>case. There is no problem if a quotation doesn't use locals from the
>>enclosing definition.
> 
> Right.  That's why quotations don't support access not outer
> locals and thats why we call them quotations, not closures.
> 
> - anton

Calling them quotations would be clearer if we abandon the de facto
standard of [: ;] . It looks too much like a full definition or a
closure. We use ['] name for a single token xt. I would propose [' '] as
better matching the name of the concept and its effect.

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

#30370

"Alex McDonald" <blog@rivadpm.com> writes:
>on 13/05/2014 13:35:54,  wrote:
>> Right.  That's why quotations don't support access not outer
>> locals and thats why we call them quotations, not closures.
>> 
>> - anton
>
>Calling them quotations would be clearer if we abandon the de facto
>standard of [: ;] . It looks too much like a full definition or a
>closure.

What makes you think so?  I know no programming language where [: ;]
denotes a closure.  Also, if we can implement full closures (upward
funargs in Lisp terminology) or downward funargs without changing the
syntax, I would do so.  The difference is just in which locals are
visible (quotations vs. closures), and how long the xt is valid
(upward vs. downward funargs), and there is no point in changing the
syntax for that.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#30390

on 14/05/2014 10:15:01,  wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>>on 13/05/2014 13:35:54,  wrote:
>>> Right.  That's why quotations don't support access not outer
>>> locals and thats why we call them quotations, not closures.
>>>
>>> - anton
>>
>>Calling them quotations would be clearer if we abandon the de facto
>>standard of [: ;] . It looks too much like a full definition or a
>>closure.
> 
> What makes you think so?  I know no programming language where [: ;]
> denotes a closure.  Also, if we can implement full closures (upward
> funargs in Lisp terminology) or downward funargs without changing the
> syntax, I would do so.  The difference is just in which locals are
> visible (quotations vs. closures), and how long the xt is valid
> (upward vs. downward funargs), and there is no point in changing the
> syntax for that.
> 
> - anton

I was seriously jetlagged when I wrote that. It was a mess. Let me
attempt to clarify. I meant no attempt to change or expand on the
definition of a quotation; just the characters that are used to bracket
the quotation.

[' '] seems (to me anyhow) to visually better express what we're doing
here with a quotation. It's the multi part equivalent of ['] <name> which
also produces an xt, doesn't permit locals and has an identical lifespan.
For example (contrived)

.. ['] over ... 
.. [' >r dup r> swap '] ...  

would seem clearer than 
.. [: >r dup r> swap ;] ...

If ever closures were required, then [: ;] would seem to (visually again)
be more consistent with an unnamed equivalent to a full : ; definition. 

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web