[go-nuts] Re: Q on using reflect: how to distinguish methods from functions?

2018-12-21 Thread Jason E. Aten
Hi Max,

gomacro is of course a beautiful work, and I encourage it.  Thank you for 
gomacro. It
is quite alot of work to build these interpreters, but they can be so 
valuable.

The issue I was having stems from the layers of Gijit being 
independent--having
been reused from other projects like the Go compiler frontend, from LuaJIT, 
and 
from the Luar and golua libraries. 

Because of the way that I reused existing libraries, the typechecking info 
(from the gc frontend layer) 
isn't presently available to the golua Lua-to-binary-Go-method-call layer 
that is making the call.

I'm not sure this is of general interest to the group, so feel free email 
me directly or file a github issue if you want to chat 
about the details more.

Warm wishes,
Jason

On Friday, December 21, 2018 at 10:32:09 AM UTC-6, Max wrote:
>
> Hello Jason,
> do you have the time to explain this problem more in detail?
>
> My Go interpreter gomacro (I think you already met it),
> solves the problem of invoking `b.After(a)` as follows at "compile time", 
> i.e. during typecheck and translation:
>
> 1. detects that `b` is a `time.Time`.
> 2. looks up the method "After" in the type `time.Time` (and `*time.Time`, 
> in case the method expects a pointer receiver)
> 3. the returned reflect.Value is a `func (time.Time, time.Time) bool` 
> because when you lookup methods from `reflect.Type`
> the receiver is **not** bound already
> 4. it prepares an assignment `c := b.After` to be executed at runtime - 
> this instead will return a closure `func (time.Time) bool` because the 
> receiver is already bound to `b`
> 5. it prepares a call `c(a)` to be executed at rutime - this will call 
> `b.After(a)`
>
> alternatively, 4. and 5. could become:
> 4alt. it prepares a call `time.After(b, a)` to be executed at rutime by 
> using the reflect.Value returned by looking up the method "After" in the 
> type `time.Time`
>
> In both cases, gomacro detects with a method lookup from `time.Time` that 
> "After" is a method and behaves accordingly at "compile time",
> without waiting for the reflect.Value of `b.After`, which is only 
> available at runtime.
>
> It's not clear to me why you had to resort to distinguish methods vs. 
> functions *after* you obtained the reflect.Value `b.After` instead of 
> distinguishing them *before*
> i.e. during typecheck or a similar phase - can you explain?
>
> Regards,
>
> cosmos72
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Q on using reflect: how to distinguish methods from functions?

2018-12-21 Thread Max
Hello Jason,
do you have the time to explain this problem more in detail?

My Go interpreter gomacro (I think you already met it),
solves the problem of invoking `b.After(a)` as follows at "compile time", 
i.e. during typecheck and translation:

1. detects that `b` is a `time.Time`.
2. looks up the method "After" in the type `time.Time` (and `*time.Time`, 
in case the method expects a pointer receiver)
3. the returned reflect.Value is a `func (time.Time, time.Time) bool` 
because when you lookup methods from `reflect.Type`
the receiver is **not** bound already
4. it prepares an assignment `c := b.After` to be executed at runtime - 
this instead will return a closure `func (time.Time) bool` because the 
receiver is already bound to `b`
5. it prepares a call `c(a)` to be executed at rutime - this will call 
`b.After(a)`

alternatively, 4. and 5. could become:
4alt. it prepares a call `time.After(b, a)` to be executed at rutime by 
using the reflect.Value returned by looking up the method "After" in the 
type `time.Time`

In both cases, gomacro detects with a method lookup from `time.Time` that 
"After" is a method and behaves accordingly at "compile time",
without waiting for the reflect.Value of `b.After`, which is only available 
at runtime.

It's not clear to me why you had to resort to distinguish methods vs. 
functions *after* you obtained the reflect.Value `b.After` instead of 
distinguishing them *before*
i.e. during typecheck or a similar phase - can you explain?

Regards,

cosmos72



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Q on using reflect: how to distinguish methods from functions?

2018-12-14 Thread Jason E. Aten


On Friday, December 14, 2018 at 2:45:44 PM UTC-6, Jason E. Aten wrote:
>
>
>
> On Friday, December 14, 2018 at 2:19:05 PM UTC-6, Kevin Malachowski wrote:
>>
>> Why do you need to figure out whether something is a Method? Usually it 
>> doesn't really matter.
>>
>> (I don't have an answer for you, but if you give more background I or 
>> someone else may be able to be more useful; trying to avoid the X-Y 
>> problem.)
>>
>
> It matters for translating Go calls (method and function) properly into 
> Lua calls:
>
>
> https://github.com/glycerine/luar/commit/eccbbe2e420d5a2cffb2a80e2dca1c31a5b89d7d
>  
>
>
For full context, here is a small example of what gijit/gi -- my Golang 
REPL that uses LuaJIT as its back end -- can do. This is calling back into 
the Go standard libraries such as "time" to use their functionality, even 
after having translated from Go -> Lua.  Go compiled code can be invoked 
from the interpreter, for speed. Even though LuaJIT is quite speedy, 
compiled Go code is usually faster. The fix I pointed to above makes the 
b.After(a) call work. Otherwise the 'a' argument was getting used 
twice/mixed up with 'b'.

~/go/src/github.com/gijit/gi (master) $ gi

gijit: a go interpreter, just-in-time.

https://github.com/gijit/gi
Copyright (c) 2018, Jason E. Aten. All rights reserved.
License: 3-clause BSD. See the LICENSE file at
https://github.com/gijit/gi/blob/master/LICENSE

  [ gijit/gi is an interactive Golang environment,
also known as a REPL or Read-Eval-Print-Loop.]
  [ at the gi> prompt, type ctrl-d to exit.]
  [ at the gi> :?   or :help for help.]
  [ $ gi -h for flag help, when first launching gijit.]
  [ $ gi -q to start quietly, without this banner.]

built: '2018-12-14T15:58:00-0600'
last-git-commit-hash: 'b3294722551defbd98a98ad09965f87b30337af6'
nearest-git-tag: 'v1.9.8'
git-branch: 'master'
go-version: 'go_version_go1.10.3_darwin/amd64'
luajit-version: 'LuaJIT_2.1.0-beta3+jea-int64-additions'
==
Using static prelude.
gi> import "time"

elapsed: '203.041µs'
gi> a := time.Now()

elapsed: '176.173µs'
gi> b := time.Now()

elapsed: '168.676µs'
gi> println(a.After(b))
false

elapsed: '173.885µs'
gi> println(b.After(a))
true

elapsed: '265.616µs'
gi> a
2018-12-14 16:05:16.799067846 -0600 CST m=+5.198567213

elapsed: '202.912µs'
gi>
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Q on using reflect: how to distinguish methods from functions?

2018-12-14 Thread Jason E. Aten


On Friday, December 14, 2018 at 2:19:05 PM UTC-6, Kevin Malachowski wrote:
>
> Why do you need to figure out whether something is a Method? Usually it 
> doesn't really matter.
>
> (I don't have an answer for you, but if you give more background I or 
> someone else may be able to be more useful; trying to avoid the X-Y 
> problem.)
>

It matters for translating Go calls (method and function) properly into Lua 
calls:

https://github.com/glycerine/luar/commit/eccbbe2e420d5a2cffb2a80e2dca1c31a5b89d7d
 



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.