[go-nuts] Re: [ANN] CGo-free sqlite database/sql driver 1.4.0 for linux/amd64 released

2020-08-27 Thread Andrey T.
Jan,

This is fantastic news! Congratulation on hitting such a milestone!

(patiently waiting for the windows and macos)

Andrey

On Wednesday, August 26, 2020 at 3:52:13 PM UTC-6, Jan Mercl wrote:
>
> From the change log (https://godoc.org/modernc.org/sqlite#hdr-Changelog)
>
> 2020-08-26 v1.4.0:
>
> First stable release for linux/amd64. The database/sql driver and its 
> tests are CGo free. Tests of the translated sqlite3.c library still require 
> CGo.
>
> $ make full
>
> ...
>
> SQLite 2020-08-14 13:23:32 
> fca8dc8b578f215a969cd899336378966156154710873e68b3d9ac5881b0ff3f
> 0 errors out of 928271 tests on 3900x Linux 64-bit little-endian
> WARNING: Multi-threaded tests skipped: Linked against a non-threadsafe Tcl 
> build
> All memory allocations freed - no leaks
> Maximum memory usage: 9156360 bytes
> Current memory usage: 0 bytes
> Number of malloc()  : -1 calls
> --- PASS: TestTclTest (1785.04s)
> PASS
> ok  modernc.org/sqlite  1785.041s
> $
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5b41b279-a1fa-4167-86bd-b7ecc75f7417o%40googlegroups.com.


[go-nuts] Re: [Generics] Simplified syntax to sidestep the bracket arguments

2020-07-21 Thread Andrey T.
I have tried to propose something like this in 
https://groups.google.com/forum/#!topic/golang-nuts/W3fSnH0w1G0 (and 
earlier I was dancing around that idea in 
https://groups.google.com/forum/#!topic/golang-nuts/Rp3yUUy2nS8 ), but 
somehow it did not get any serious attention.

I still think that @, $ or # or could be an interesting approach, be that 
spiritually following ' (apostrophe) in Lisp, or * (star) as a pointer to a 
type T to be read $T as "meta-T"

Thanks,
  Andrey


On Tuesday, July 21, 2020 at 10:51:21 AM UTC-6, Kh Af wrote:
>
> Forgive me for making a new thread, I felt the older ones had run their 
> course, and I had trouble deciding who to reply to.
>
> I would like to propose a simpler syntax which looks a bit more Go-like 
> (to me) 
> is more terse, has no ambiguity and does not require any new bracket 
> types. Here it goes:
>
> // generic type variables are always prefixed by an `@` symbol
> type Heap(@T) struct {
> data []@T
> head, tail uint
> }
>
> // this is how it is instantiated:
> var myHeapInt Heap@(int)
> var myHeapSomeType Heap@(SomeType)
>
> // No need to specify the type variable in functions, they should just 
> match the declaration.
> // Easy for the compiler and humans to follow. There's practically no new 
> syntax other
> // than the generic type specifier.
> func (h *Heap) Push(v @T) bool {
> ...
> }
>
> // Complex example with multiple type specifiers.
> // What if one wants explicit order of instantiation?
> type S(@V, @U, @T) struct {
> P1 @T
> P2 @U
> P3 @V
> }
>
> // instantiation is always the same syntax
> var myS S@(int, string, float)
>
> // what if attributes are of generic type themselves?
> // This equates to: S2> 
> // which can be simplified to S2 where S exists
> type S2(@T, @U, @V) struct {
> P1 S(@T, @U, @V)
> }
>
> // can be instantiated the usual way
> var myS2 S2@(int, string, float)
>
> // for a function, which constraints are set for the input types
> func Max(v ...@T) @T
> where @T: int | uint | int8 | ... | float32 | float64, // T can be of 
> multiple types, which helps to avoid defining a new interface for everything
> // @V : ... multiple where clauses can be added here for different type 
> variables
> {
> ...
> }
>
> 
> //
> // Examples lifted from the official proposal:
> //
> 
>
> // Smallest returns the smallest element in a slice.
> // It panics if the slice is empty.
> func Smallest(s []@T) @T 
> where @T: Ordered 
> {
> r := s[0] // panics if slice is empty
> for _, v := range s[1:] {
> if v < r {
> r = v
> }
> }
> return r
> }
>
> // Map calls the function f on every element of the slice s,
> // returning a new slice of the results.
> func Map(s []@F, f func(@F) @T) []@T {
> r := make([]@T, len(s))
> for i, v := range s {
> r[i] = f(v)
> }
> return r
> }
>
> // NewPair returns a pair of values of the same type.
> func NewPair(f1, f2 @F) *Pair(@F) { ... }
>
> To me this looks simpler and more clear to read than the official 
> proposal, and practically all other generics syntax that I know of.
> The `@` symbol will immediately signal `generic type` to the reader, there 
> isn't too much to type, retype or read. 
> You will also never see a generic type without its `@` prefix anywhere in 
> the code, which significantly helps with readability.
> It's vague neither to humans nor machines, and can be read as `Heap at int 
> (-land!)` during instantiation which while not 
> idiomatic English, still communicates the purpose.
>
> What do you think?
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3a2f119f-7ff0-4942-acb5-8387e06bd4fao%40googlegroups.com.


Re: [go-nuts] [generics] cannot use generic type list.Element(type TElem) without instantiation

2020-07-01 Thread Andrey T.
Ian,

continuation question -- does `type intElement list.Element(int)` introduce 
a new type just like `type myInt int` does? If so, in a previous example, 
these 2 maps are not of the same type, am I right?

Thank you very much,
  Andrey

On Wednesday, July 1, 2020 at 10:50:07 AM UTC-6, Ian Lance Taylor wrote:
>
> On Wed, Jul 1, 2020 at 9:39 AM > 
> wrote: 
> > 
> > Is this expected? 
> > 
> > import "list" // for 'std' list.go2 
> > 
> > func main() { 
> > type intElement list.Element(int) 
> > _ = make(map[int]intElement) // ok: compiles 
> > 
> > // nok 
> > _ = make(map[int]list.Element(int)) // cannot use generic type 
> list.Element(type TElem) without instantiation 
> > } 
> > 
> > I don't think it is, but in case it is, how would I instantiate a 
> make(map[int]intElement) without having to typedef a generic type before. 
>
> From the parser's perspective the argument to make is an expression, 
> so in this case you need parentheses to keep this from looking like a 
> type conversion. 
>
> make(map[int](list.Element(int))) 
>
> Ian 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/651e60c9-323f-481a-8eb1-a15e20e0f68do%40googlegroups.com.


Re: [go-nuts] [generics] Syntax feedback

2020-06-28 Thread Andrey T.
Tyler,
May I humbly suggest 
https://groups.google.com/d/msg/golang-nuts/W3fSnH0w1G0/JbMkJrKICAAJ for an 
additional item for your list?

Thank you very much,
  Andrey

On Saturday, June 27, 2020 at 11:46:23 AM UTC-6, Tyler Compton wrote:
>
> Hi Rob,
>
> This topic has been discussed many times on this list, so it's probably 
> best to look at and post in one of those threads. Let me take this chance 
> to collect as much information about this issue as I can in a single post.
> Unfortunately, discoverability can sometimes be hard on mailing lists so I 
> don't blame you for not seeing all these.
>
> Responses on the subject:
> Design draft talking about alternative syntax: 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
> Ian's justification for taking a wait-and-see approach to this syntax 
> issue: https://groups.google.com/g/golang-nuts/c/Rumm5HFhg_Q
>
> Threads:
> Use "<>": https://groups.google.com/g/golang-nuts/c/LvkOBA2D_Bk
> Use "<>": https://groups.google.com/g/golang-nuts/c/B1Q1dsLa5rk
> Use "::" and other suggestions: 
> https://groups.google.com/g/golang-nuts/c/b0GydCIn7T0
> Use "(<>)": https://groups.google.com/g/golang-nuts/c/tYwWeiMztiI
> Use "<>" before the name of the type being defined: 
> https://groups.google.com/g/golang-nuts/c/TJWGbrx2o34
> Put type parameters in the regular arguments list with a ":type" suffix: 
> https://groups.google.com/g/golang-nuts/c/K7s-5MeXuzM
> Use "<>", with some kind of additional syntax to make parsing easier: 
> https://groups.google.com/g/golang-nuts/c/SaDkSQdgF9g
> Use "<>": https://groups.google.com/g/golang-nuts/c/coi7YS0KPgQ
> Use "<>": https://groups.google.com/g/golang-nuts/c/ydySSqZqi-0
> Use ":[]": https://groups.google.com/g/golang-nuts/c/zGQq_I5r2jg
> No specific suggestion: 
> https://groups.google.com/g/golang-nuts/c/mY_36VU5ij8
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/32da9686-d144-4d35-924f-b2bb1de7d9b3o%40googlegroups.com.


[go-nuts] Re: [generics] Use decorators ($, or @, or #) to specify that the type is a generic type.

2020-06-25 Thread Andrey T.
Good point. Without some additional rules to "freeze" it once seen in a 
declaration, that would become "apples" to "oranges" very fast.

Well, I guess scratch point 3 off the list then :)

On Wednesday, June 24, 2020 at 10:55:10 PM UTC-6, haskell...@yahoo.de wrote:
>
> On Thursday, 25 June 2020 06:17:24 UTC+2, Andrey T. wrote:
>  
>
>> 3. Ability to use decorated interface name as spec for type constrains 
>>
>>func (type T Comparable) Max(a... T) (result T) {...}
>>
>>might become
>>
>>func Max(a... $Comparable) (result $Comparable) {...}
>>
>
> I don't see how this is equivalent. The point of the T constraint is that 
> both T are the *same* Comparable type and not just any two Comparables.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/39519adc-0af7-46b2-89e8-817b531fc183o%40googlegroups.com.


[go-nuts] [generics] Use decorators ($, or @, or #) to specify that the type is a generic type.

2020-06-24 Thread Andrey T.

The idea: Use decorators ($, or @, or #) to specify that the type is a 
generic type.

(Syntax is vaguely follows to * "it is a pointer", so $T becomes a "it is a 
generic type")

1. Readability - Immediately visible which type is a generic type.

2. Readability - Less braces. Compare

   func (type T) RandomItem(a ...T) T { ... }

   becomes

   func RandomItem(a ...$T) $T { ... }

3. Ability to use decorated interface name as spec for type constrains 

   func (type T Comparable) Max(a... T) (result T) {...}

   might become

   func Max(a... $Comparable) (result $Comparable) {...}

4. It does not prevent usage of type keyword if wanted/needed.

Thanks, 
  Andrey

PS. 
it is a distill of my previous post 
https://groups.google.com/forum/#!topic/golang-nuts/Rp3yUUy2nS8, which 
asked a different question about "How often do we have to specify type 
during invocation", and this idea got a bit lost in it.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/32b8046a-0719-43c0-845c-3a3eaffebfcco%40googlegroups.com.