unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Julian Graham <joolean@gmail.com>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: [PATCH] ECMAscript: Bind type names to constructor functions in the global env.
Date: Mon, 16 Jan 2017 20:23:58 -0500	[thread overview]
Message-ID: <CANdC_RBk4UHkqvWa4YOJdGnMa118vEBcyvB5fenxTUn14wbszg@mail.gmail.com> (raw)
In-Reply-To: <87bmvgaq22.fsf@pobox.com>

On Mon, Jan 9, 2017 at 4:20 PM, Andy Wingo <wingo@pobox.com> wrote:
> I am happy to include patches like this one.
>
> Yet -- *program-wrappers*, what is that about?  I don't even remember
> any more.  I guess it's for setting a property on a function instance,
> even if the function is a normal Guile function?  I guess I am skeptical
> given that the hash table is doubly weak.

My read is that it's an explicit bridge between a normal Guile
function and a more ECMAScript-y function object representation of
that function. That is to say, an attempt to have one's cake
(functions that act like other JS objects) and eat it, too ("native"
function application). If Guile's ES implementation continues to
develop (and I hope it does!) a good reason may present itself that ES
Functions can't continue to also be native Guile functions under the
hood. But if we agree on the idea behind that table, I don't see why
that change has to happen now.


> Please don't assume that the existing code is good or even correct :) We
> have all learned many things since 2009 -- this flip side of that being
> that I know I was much more ignorant back then :)

Well, I think it works, and it's pretty cheap. Per the above, I think
the alternative is to redesign the ES functions implementation in a
way that makes functions look a lot more like objects, such that they
can no longer be applied "directly." But I was hoping to defer doing
that until the core object implementation and of the behavior of
prototypes was a bit further along, with more test coverage, etc. I
don't know. What do you think?



      reply	other threads:[~2017-01-17  1:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-19 15:44 [PATCH] ECMAscript: Bind type names to constructor functions in the global env Julian Graham
2017-01-09  2:28 ` Julian Graham
2017-01-09 21:20 ` Andy Wingo
2017-01-17  1:23   ` Julian Graham [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANdC_RBk4UHkqvWa4YOJdGnMa118vEBcyvB5fenxTUn14wbszg@mail.gmail.com \
    --to=joolean@gmail.com \
    --cc=guile-devel@gnu.org \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).