Re: [go-nuts] reflect package: How to create a new slice with an element type discovered at runtime?

[Rémy Oudompheng]

On 2013/3/16 <chrism...@gmail.com> wrote:
> Making the assumption that the reflect.MakeSlice function implemented this
> behavior, I implemented my solution to be disappointed by:
>
> panic("reflect.MakeSlice of non-slice type")
>
>
> The signature is:
>
> reflect.MakeSlice( typ reflect.Type, len, cap int ) reflect.Value
>
>
> Is anyone aware of a solution to my problem? I have been over the reflect
> package a few times without seeing a way to accomplish my goal.

It is not possible to generate a slice type dynamically given the
element type. However, in Go 1.1 it is planned that it becomes
possible, but for the moment the implementation is not complete.

Can you give backgroound on why you need it?

Rémy.

[Ugorji Nwoke]

I think it is possible in Go 1.1.

i.e.

tInt := reflect.TypeOf(int(0))

tIntSlice := reflect.SliceOf(tInt)

rv := reflect.MakeSlice(tIntSlice, 0, 4)

// Russ (I believe) added support for SliceOf, MapOf, ChanOf some time back.

[Rob Pike]

I don't believe it's possible to sort a reflect.Value holding a slice
unless you know the static element type or do something irresponsible
such as convert the elements to strings and sort them. You need to be
able to implement Less.

-rob

[Rob Pike]

I had to try it, stupid and expensive and inflexible though it is, it
was a fun exercise.

http://play.golang.org/p/A6TqPhC9Zp

-rob

[Dan Kortschak]

Dr Frankenstein, a monster is at the door to see you.

http://play.golang.org/p/OrzYd27MSq

[Torben Weis]

Works nice for numbers between 0 and 9, otherwise ....

[2 2 2 3 6 7 9]
[2 2 25 3 6 7 9]

http://play.golang.org/p/4Ifb4lGB0X

... sorting this way is irresponsible, as you said :-)

Torben

2013/3/17 Rob Pike <r...@golang.org>:

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Carlos Castillo]

Since you know the map type, you can pass in a pointer to a slice to be filled (using reflect.Append). This way you don't need to construct the types (works in go1). If the types don't match you get a runtime panic. Here are examples for getting a slice of keys, a slice of values, and a slice of key,value structures.

http://play.golang.org/p/Hn7kLc_Qm6

On Saturday, March 16, 2013 2:15:33 PM UTC-7, chrism...@gmail.com wrote:

There have been two cases where I would like to have this functionality.

The first case was: to abstractly convert a map to a slice. So I would need to be able to discover the map element type and then create the slice from it. Originally, the function was written under the impression that reflect.MakeSlice would handle it. It was an unpleasant surprise to receive the panic.

The second case that came up today is related to the previous one. Once the slice was created, I was going to sort the slice based on its corresponding map key. So sorting using reflection data is the case. Abstractly sorting may still be completely achievable through reflect.Interface, but I have not tried this yet. The one thing that I do not want to do is implement a bunch of different versions of reflect.Interface.

[Rob Pike]

Wait, you thought this was a robust implementation?

-rob

[Kevin Gillette]

Agreed. I catch glimpses of Murphy in every type assertion/switch of an empty interface that can't usefully handle the general case, or that doesn't fall on an output boundary. Certainly doing so is no less safe than a dynamically typed language, but that's still well below the quality of what you'd really want to put in the core of any go algorithm.

Besides which, the notion of ”sorting” an assemblage of arbitrarily typed values is subjective to an application: some may want to sort a []byte with string semantics, while others may only need to sort by the binary representation of the slice header.

Even in these cases, sort.Interface is the most succinct and clean approach for sorting. I've yet to come across any case where making a reflect-based generic utilitarian converter to handle otherwise static types actually saved any reasonable amount of app code, and more importantly, didn't feel ”unclean”

[Torben Weis]

2013/3/17 Rob Pike <r...@golang.org>:

> Wait, you thought this was a robust implementation?

No, just could not resist pointing it out.

Torben

> -rob

[Vova Niki]

http://play.golang.org/p/62uhKwFh1Z

[Jan Mercl]

On Sun, Mar 17, 2013 at 2:29 PM, Vova Niki <vov...@gmail.com> wrote:
> http://play.golang.org/p/62uhKwFh1Z

I think a reflection based dynamic Go interpreter is just behind the corner.

-j

[Rob Pike]

Now try adding a struct. Or a pointer to a struct.

[Kevin Gillette]

@Jan: please elaborate or add context. Can't tell if that's tongue-in-cheek about this thread, or a prediction about go itself

[Jan Mercl]

On Sun, Mar 17, 2013 at 6:37 PM, Kevin Gillette
<extempor...@gmail.com> wrote:
> @Jan: please elaborate or add context. Can't tell if that's tongue-in-cheek about this thread, or a prediction about go itself

Sad, reflective sarcasm, of course. Sorry for the noise.

-j

[Rob Pike]

No, not all sorts, only some sorts.

-rob

[Dan Kortschak]

Worse, I think we have the basis for a php implementation... oh right.

[Jan Mercl]

https://groups.google.com/d/msg/golang-nuts/nqljw9P9KWU/UZ4IAgYnty8J

-j

[Sebastien Binet]

Jan,

yes, is that a bad thing ? :)
the playground is great.
go run is great.
the various go-repls which compile+run on-the-fly are great.

...but, for some kind of work, a real interpreter is just better.

-s

[Jan Mercl]

On Wed, Mar 27, 2013 at 12:57 PM, Sebastien Binet <seb....@gmail.com> wrote:
> yes, is that a bad thing ? :)

Well, IMO yes ;-)

> the playground is great.

Yes. And it's not an interpreter.

> go run is great.

go run is a handy tool. It is heavily abused for things completely
different than what is was intended for.

> the various go-repls which compile+run on-the-fly are great.

I know one C REPL. I know zero people which ever used it. Both C and
Go are statically type checked
compiled-to-machine-code-for-great-performance languages. No serious
developer is probably developing anything substantially more complex
than hello_world.c in a C REPL. Why should be Go any different?

Frankly, I consider the idea of simulating (to some extent) Go REPL by
"compile+run on-the-fly" even uglier than a proper REPL per se.

> ...but, for some kind of work, a real interpreter is just better.

Sure. I guess there might be legitimate use cases for it. Cannot
imagine any single one ATM, though.

-j

PS: It doesn't matter what do I think about it. It will appear sooner
or later anyway, probably.

[Sebastien Binet]

Jan,

On Wed, Mar 27, 2013 at 1:49 PM, Jan Mercl <0xj...@gmail.com> wrote:
> On Wed, Mar 27, 2013 at 12:57 PM, Sebastien Binet <seb....@gmail.com> wrote:
>> yes, is that a bad thing ? :)
>
> Well, IMO yes ;-)
>
>> the playground is great.
>
> Yes. And it's not an interpreter.
>
>> go run is great.
>
> go run is a handy tool. It is heavily abused for things completely
> different than what is was intended for.
>
>> the various go-repls which compile+run on-the-fly are great.
>
> I know one C REPL. I know zero people which ever used it. Both C and
> Go are statically type checked
> compiled-to-machine-code-for-great-performance languages. No serious
> developer is probably developing anything substantially more complex
> than hello_world.c in a C REPL. Why should be Go any different?

high energy physics people would beg to differ.
CERN has a long history of developing interpreters (COMIS for FORTRAN,
CINT for C/C++ and more recently (and less buggy) CLing for C/C++
(based on LLVM/CLang))
interpreters have been the "bread and butter" of scientific investigatory work.
you somehow load your data file, write little functions to inspect,
iteratively refine and plot data, or create new analysis algorithms to
extract information(s) out of the TB of data: that's best done in an
interpreter where you can iteratively inspect and modify the state of
your program.
(of course, theoretically, one could save/dump the state of a serie of
programs, analysis-step-00-to-01, -01-to-02,... saving the interesting
data for later re-use, and the reflect+json/gob/whatever do make this
job easy, but that's a lot of scaffolding you get for (almost) free
with an interpreter)

usually, the little functions end up being PhD theses and eventually
also end up in the physics experiment's official code (which, for
obvious reasons of performances, has to be compiled)
not having to write your prototyping code in one language and then the
production-ready one in another one is just plainly nice (physicists
usually can't be bothered to learn one programming language, so, 2 ?!)

to be completely honest, it is true that thanks to completely
effortless way of compiling 3rd-party packages provided by go get and
the Go ecosystem in general, the tediousness of the compile-run-edit
cycle one is familiar with in C/C++ does not hold in Go (and so is a
rather enjoyable experience, IMHO)

>
> Frankly, I consider the idea of simulating (to some extent) Go REPL by
> "compile+run on-the-fly" even uglier than a proper REPL per se.

I can't say I disagree.

-s

[Jan Mercl]

On Wed, Mar 27, 2013 at 2:13 PM, Sebastien Binet <seb....@gmail.com> wrote:
> high energy physics people would beg to differ.
> CERN has a long history of developing interpreters (COMIS for FORTRAN,
> CINT for C/C++ and more recently (and less buggy) CLing for C/C++
> (based on LLVM/CLang))
> interpreters have been the "bread and butter" of scientific investigatory work.
> you somehow load your data file, write little functions to inspect,
> iteratively refine and plot data, or create new analysis algorithms to
> extract information(s) out of the TB of data: that's best done in an
> interpreter where you can iteratively inspect and modify the state of
> your program.
> (of course, theoretically, one could save/dump the state of a serie of
> programs, analysis-step-00-to-01, -01-to-02,... saving the interesting
> data for later re-use, and the reflect+json/gob/whatever do make this
> job easy, but that's a lot of scaffolding you get for (almost) free
> with an interpreter)

Usage cases for _interpreted_ languages are legitimate, of course. If
one needs to write a simple script, there are so many scripting
languages available out there. What's the advantage of scripting in
FORTRAN or C/C++?

> usually, the little functions end up being PhD theses and eventually
> also end up in the physics experiment's official code (which, for
> obvious reasons of performances, has to be compiled)
> not having to write your prototyping code in one language and then the
> production-ready one in another one is just plainly nice (physicists
> usually can't be bothered to learn one programming language, so, 2 ?!)

Ah, so here's is the reason. A particularly bad one, IMHO. Debugging
statically typed compiled languages by an interpreter is IMO a pretty
non standard approach. Sometimes simply unusable (too slow program
progress).

And last but no least: Debugging in Go is particularly easy compared
to anything I ever coded in. I used to use clewn (a gdb wrapper) few
times while Go hacking, but it didn't yet happened to me this year at
all.

Everyone is totally free to find and use tools which make things done
for him. It's just IMO this specific (interpreter middle ware)
approach get things done later than the common (compiler, debug prints
and/or gdb) way.

> to be completely honest, it is true that thanks to completely
> effortless way of compiling 3rd-party packages provided by go get and
> the Go ecosystem in general, the tediousness of the compile-run-edit
> cycle one is familiar with in C/C++ does not hold in Go (and so is a
> rather enjoyable experience, IMHO)

Yep, that's what I observe here as well ;-)

-j

[Nico]

I think one of most important reasons why some would like to see an REPL
is to explore the use of well documented libraries, the same way people
do with python.

Up to certain extend, the playground has covered this need. though not
fully.


Nico

[atomly]

Are you really trying to argue that debug prints are better than a REPL?

Also, a REPL can be immensely useful for things that have nothing to do with debugging code that you're writing. They are great for testing out ideas, composing objects in new and interesting ways, etc.

They are also incredibly useful for doing things like interacting with a data store. Let's say you have a DAO layer that lets you save a user object. You can fire up your REPL and use this to create all the necessary data in your DB instead of trying to do a bunch of inserts by hand. Or you can use a REPL to, for example, clear stale data out of your cache.

I wouldn't say that a REPL is 100% necessary to a language, but I find that it will often save a lot of time and prove incredibly useful in myriad situations.

:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.347.692.8661 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...

[Jan Mercl]

On Mar 28, 2013 1:03 AM, "atomly" <ato...@gmail.com> wrote:
>
> Are you really trying to argue that debug prints are better than a REPL?

Are you really trying to argue that using CINT is better than GDB? ;-)

-j

[Sebastien Binet]

having suffered from using CINT during my PhD (before python became a
tool blessed by the community) I can say that nobody should never ever
say that :P
besides, you always have to have GDB around to debug CINT...

-s