Thank you for this thoughtful response. It helpful and inspires new
thoughts.
When I was a boy learning C (1976 or 1977, UNIX 6th Edition at Bell Labs
via "learn") the definition of qsort() was a new idea for me. The exposure
of base and stride so nakedly (after BASIC and FORTRAN and LISP and SAIL
On Fri, Mar 31, 2017 at 6:19 PM Michael Jones
wrote:
> There is part of the topic that has always been slightly beyond my grasp.
> (Maybe I do understand...but just lack absolute certainty.) Maybe others
> know the answer...
>
> In a template system (which is what I prefer but that's not the poin
On Sat, Apr 1, 2017 at 12:11 AM, Egon Elbre wrote:
> On Sat, Apr 1, 2017 at 1:42 AM, Will Faught wrote:
>
>>
>>> For example []GenericElement could be boxed as:
>>>
>>> struct{ itab ptr; ... data []struct{elem ptr} }
>>> or
>>> []struct{itab, elem ptr}
>>>
>>>
>> Can you explain in more detail w
In a previous life, this was one of the problems we had with
generate-and-execute.
In lisp, you could almost always create correct code and run it. With C, I
could generate library interposers by the ton, but they only *usually*
worked, so I had to generate unit tests, too. Fortunately I had
On Friday, 31 March 2017 19:20:26 UTC+3, Michael Jones wrote:
>
> There is part of the topic that has always been slightly beyond my grasp.
> (Maybe I do understand...but just lack absolute certainty.) Maybe others
> know the answer...
>
> In a template system (which is what I prefer but that's n
On Fri, Mar 31, 2017 at 6:20 PM Michael Jones
wrote:
> I recalled it i the sort case because I wanted to kinds of typed clients
for "<", the kind where !Less(a,b)&&!Less(b,a) === Equal(a,b), and the kind
where that is not the case--and ideally--a way to have instantiation for
the first kind use p
yes
On Fri, Mar 31, 2017 at 12:30 PM, Ian Davis wrote:
> On Fri, 31 Mar 2017, at 05:19 PM, Michael Jones wrote:
>
> There is part of the topic that has always been slightly beyond my grasp.
> (Maybe I do understand...but just lack absolute certainty.) Maybe others
> know the answer...
>
> In a t
On Fri, 31 Mar 2017, at 05:19 PM, Michael Jones wrote:
> There is part of the topic that has always been slightly beyond my
> grasp. (Maybe I do understand...but just lack absolute certainty.)
> Maybe others know the answer...
>
> In a template system (which is what I prefer but that's not the p
There is part of the topic that has always been slightly beyond my grasp.
(Maybe I do understand...but just lack absolute certainty.) Maybe others
know the answer...
In a template system (which is what I prefer but that's not the point of
this email) we have the notion of the TYPE(s) being a forma
On Friday, 31 March 2017 09:02:09 UTC+3, Will Faught wrote:
>
> >Because it can also be implemented in other ways.
>
> Do you mean interface{} can be implemented in other ways? I couldn't make
> out your meaning.
>
There are multiple ways of implementing "boxing generics" and
"interface{}". Impl
>Because it can also be implemented in other ways.
Do you mean interface{} can be implemented in other ways? I couldn't make
out your meaning.
>As said... there is a performance upside for some other approaches.
The other approaches have downsides, or at least generation does. Compared
to usin
On Thursday, 30 March 2017 03:15:33 UTC+3, Will Faught wrote:
>
> Egon:
>
> >See
> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
>
> I don't see the Implicit Boxing section point out that this is what
> happens now when you shoehorn ev
Egon:
>See https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-
HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
I don't see the Implicit Boxing section point out that this is what happens
now when you shoehorn everything into interface{}. In this sense, I don't
see a performance downside
On Tuesday, 28 March 2017 07:56:57 UTC+3, Will Faught wrote:
>
> Something I've never seen addressed in the generics tradeoffs debate (not
> saying it hasn't been, but I haven't see it personally)
>
See
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=
Something I've never seen addressed in the generics tradeoffs debate (not
saying it hasn't been, but I haven't see it personally) is that without
generics, you're forced to use interface{}, which just boxes the values
anyway. So you're already paying a performance cost for type-agnostic code
wi
I can't speak to the staging process, but I became all too aware of how
to cause cache misses on a SPARC (:--)
In a mature, sane and well-debugged program, write #define debug()
macros so they always caused a cache miss even when not turned on, then
sprinkle enthusiastically throughout all the
In addition, there are also the notion of "staging meta-compilation" as
witnessed in e.g., BER-MetaOCaml.
The idea is that if you want the best program efficiency, no compiler is
able to carry out the needed optimizations. So you start meta-compiling by
staging the compiler and generating code at
Folks, is this something that we should do with a template processor?
More topically, is this a set of somethings that we should prototype each
of, using templates?
I'd love to see actual experiments in computer "science" (;-)) and a debate
about the tradeoffs based on code.
--dave
On Monda
Another dimension is "intellectual complexity." Where that is smaller,
everything else is better for coding, documenting, debugging, testing,
reading, using, and maintaining.
It is a critical measure for maintaining the 'Go' of Go.
On Sun, Mar 26, 2017 at 11:40 PM Egon wrote:
> On Monday, 27 Ma
On Monday, 27 March 2017 04:06:17 UTC+3, Mandolyte wrote:
>
> I agree that it makes the suitable trade-offs. And Linq is doing pretty
> well without generics (https://github.com/ahmetb/go-linq); not familiar
> with Rx.
>
> When I consider the dilemma, the two things I don't want are slow
> progr
I agree that it makes the suitable trade-offs. And Linq is doing pretty
well without generics (https://github.com/ahmetb/go-linq); not familiar
with Rx.
When I consider the dilemma, the two things I don't want are slow
programmers and slow execution, leaving "slow compilers and bloated
binarie
On Sunday, 26 March 2017 15:30:30 UTC+3, Mandolyte wrote:
>
> @Bakul - is your approach documented in Egon's collection? I think it is
> essentially the same as Egon's at
> https://groups.google.com/d/msg/golang-nuts/JThDpFJftCY/1MqzfeBjvT4J
>
> Perhaps your syntax is cleaner, simpler. I also like
@Bakul - is your approach documented in Egon's collection? I think it is
essentially the same as Egon's at
https://groups.google.com/d/msg/golang-nuts/JThDpFJftCY/1MqzfeBjvT4J
Perhaps your syntax is cleaner, simpler. I also like this general approach.
In Egon's document, this approach has nearly
On Sunday, 26 March 2017 05:15:10 UTC+3, Bakul Shah wrote:
>
> The simplest design I can think of (that does what you seem to
> want) is to add parameterized packages. Here's a
> stereotypical example:
>
>
> package stack(T)// parameterized on stack element type
> import "f
The simplest design I can think of (that does what you seem to
want) is to add parameterized packages. Here's a
stereotypical example:
package stack(T)// parameterized on stack element type
import "fmt"
type Type struct { rep []T
func New() *Type { &T{} }
func (stk *Type)Push(t
Hmmn, we may be thinking different things... I *think* I'm looking for a
way to say "an X of Y", and see composition as a possible approach.
I just don't know if it will be a, the, or not the answer (;-))
--dave
On 24/03/17 11:21 PM, Michael Jones wrote:
I think I was saying that what I seem
I think I was saying that what I seem to want personally is the "simple,
weak, slight" thing that you likely see as failure.
The opposite end of that--where everything is a list and can be composed
without special regard (lisp) or everything is an object that can receive
any message (smalltalk) ar
We still don't understand genrality: the current generics are unimpressive.
The proposals for Go are typically "let's do something that has failed
already, in hopes that trying it agin will have a different result". That,
alas, is one of the definitions of insanity.
Due caution is advised!
-
28 matches
Mail list logo
