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

Groups > comp.lang.forth > #50512

Re: CfV: Quotations

Show all headers | View raw

Bernd Paysan <bernd@net2o.de> writes:
>Am Wed, 24 Aug 2016 15:54:06 +0000 schrieb Anton Ertl:
>
>> And actually you are not using the distinctive feature of OOP: dynamic
>> binding.  What you use, is the current-object pointer.  However, this
>> allows access only to locals from one activation record; that's enough
>> for the man-or-boy test, but not in the general case.  Is the general
>> case needed?  Yes, in particular in curried functions each argument is
>> in a separate activation record.
>
>What about this part of my source code was not clear to you?

What makes you think that it is not clear to me?

>Note that the lambda closures in C++ and Java are syntactic sugar around 
>classes, they aren't implemented the same way as you would do it in Algol 
>60.

Earlier you argued that activation records and objects are the same thing.

I see two differences:

* Objects are connected to dynamic binding of methods, something that
  is not needed for activation records.  But that extra capability
  does not hurt when implementing activation records with objects.

* Object-oriented languages normally have only one current object
  (this or self), while there several activation records can be active
  at the same time, one for each outer function that has local
  variables.  That is what I was pointing out above.

  As a minimal example, consider a curried implementation
  of ROT in a dialect of Forth with full closures:
  
  : crot { x } [: { y } [: { z } y x z ;] ;] ;
  1 2 3 crot execute execute \ now on the stack: 2 3 1
  
  Here you have an activation record containing X, and another
  activation record containing Y, and you cannot keep both of those in
  the current object, but need to implement some additional mechanism
  to perform the access; in cases with read-only locals like this one,
  you can shift the additional work to the definition (by also
  defining a copy of X in the Y activation record, and maybe copies of
  X and Y in the Z activation record). 

  But in cases with locals that are changed, you cannot do that.  The
  classical implementations are to use a static link chain or a
  display, but the C++ syntax suggests keeping the addresses of the
  accessed variables in the later activation records (one can also see
  this as a variation on the display theme).  Anyway, all of this
  requires something that's a bit different from an ordinary
  object-oriented field access.

>C++ overloads the function call to make it happen, which actually 
>means that you can't pass a lambda closure to a function that takes a 
>normal function pointer.
>
>Only lambdas without any captured variables are compatible with function 
>pointers, all others need std::function as type.
>
>http://www.cprogramming.com/c++11/c++11-lambda-closures.html

My guess is that this difference between ordinary function pointers
and std::function is that ordinary function pointers are C-compatible
and don't come with an environment, while std:function includes an
environment.  They apparently did not want to go for trampolines, and,
after all they are C++: Introducing yet another type and then trying
to hide it with overloading is their way of life.

>In Java, it was easier, as Java didn't have any function pointer type to 
>start with.  Now it has one, and it's just calling a specified method of 
>a particular class, something Java's VM can do.

The hard part for Java apparently was to make it fit in the type
system (at least my colleague who is into type systems tells me that).
Fortunately we don't have that problem in Forth.

Anyway, both languages have added lambdas, however implemented,
because they allow expressing programs more succinctly than with just
the object-oriented features they had before.

- 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 2016: http://www.euroforth.org/ef16/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: CfV: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-14 20:52 +0000
  Re: CfV: Quotations hughaguilar96@gmail.com - 2016-08-14 14:42 -0700
    Re: CfV: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-08-14 16:43 -0700
  Re: CfV: Quotations Paul Rubin <no.email@nospam.invalid> - 2016-08-15 22:16 -0700
    Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-16 07:13 +0000
      Re: CfV: Quotations Paul Rubin <no.email@nospam.invalid> - 2016-08-18 15:30 -0700
        Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-19 15:32 +0000
      Re: CfV: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-20 20:46 +0000
        Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-21 09:32 +0000
          Re: CfV: Quotations hughaguilar96@gmail.com - 2016-08-21 11:06 -0700
            Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-24 17:02 +0000
          Re: CfV: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-21 22:52 +0000
            Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-22 13:54 +0000
              Re: CfV: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-22 23:19 +0000
                Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-24 15:54 +0000
                Re: CfV: Quotations Bernd Paysan <bernd@net2o.de> - 2016-08-28 00:43 +0000
                Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-28 09:53 +0000
                Re: CfV: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-28 08:32 -0500
                Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-28 14:38 +0000

csiph-web