Re: [go-nuts] Generic symbol metaproposal
IMHO uppercase, single letter for denoting generic types would be a nice
syntax / convention.
Sure, that would limit to 26 generic types per function ("enough for
everybody"?), and probably break some bizarro existing code (using
uppercase single-letter characters for parameter names) -- thought said
code probably deserves to be broken.
Add constraints after each generic type (at the moment of first
appearance), and serve to taste.
Another thing I like in old languages is the extra space afforded for
metadata, variables, constraints (e.g. pre/postconditions) and definitions,
e.g.
Eiffel:
local
l_file: PLAIN_TEXT_FILE
sorted: STRING
empty_list: LINKED_LIST
[STRING
]
Ada:
procedure Put (Position : Anagrams.Cursor) is
First : Boolean := True;
List : Set renames Element (Position);
PL/I:
word_test: proc options (main);
declare words (5) character (20) varying,
frequency (5) fixed binary;
declare word character (20) varying;
declare (i, k, wp, most) fixed binary (31);
In general, not being constrained to have the list of arguments, modifiers,
and metadata about the function inside a single pair of parenthesis.
On Mon, Jul 27, 2020 at 3:07 AM Michael Jones
wrote:
> I'm never sure how much detail to share. The colorForth idea is a perfect
> example of the thought about "another dimension" of specification. (Albeit
> difficult to implement in practice). The upper/lower case signal is a good
> one, and easy; it is limiting, but not terribly, and offers easy
> frictionless specification.
>
> The earlier comment about ";" being everywhere and nowhere in Go is
> important. It leads to the question "what can we intuit?" That is a fine
> starting place. For example, if the generic specification requires "()" or
> "[]" or whatever around type-concretization lists, but the parser will add
> them for you, then you'll never see either except in "pedantic" machine
> generated code or the rareish case of a generic type list that needs
> another generic type list as an element (the inner ones need delimiters).
>
> I vote for this whatever symbol is chosen.
>
> On Fri, Jul 24, 2020 at 3:16 PM David Riley wrote:
>
>> On Jul 24, 2020, at 5:50 PM, Ian Lance Taylor wrote:
>> >
>> > On Fri, Jul 24, 2020 at 2:22 PM wrote:
>> > >
>> > > On 7/23/20, Michael Jones wrote:
>> > > ...
>> > > > Another delight is the uppercase signal for external.
>> > > >
>> > > > Maybe the “how to signal it” aspect of type instantiation could
>> look to
>> > > > these approaches as well—make the automatic understanding so
>> magical that
>> > > > the complete specification is unnecessary in most all cases, or the
>> > > > signaling so intrinsic to the variables that no identification
>> Symbol or
>> > > > BracketedPair is necessary.
>> > >
>> > > Maybe braille?
>> > > ⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙
>> > >
>> https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG
>> > >
>> > > ⠊⠞ ⠊⠎ ⠑⠁⠎⠽
>> >
>> > I've always felt that color is underused in modern programming
>> languages.
>> >
>> > func Max(T)(s []T) T
>>
>> Perhaps there could be some cross-pollination with ColorForth, wherein
>> color actually is semantically meaningful.
>>
>> https://colorforth.github.io
>>
>>
>> - Dave
>
>
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>
> --
> 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/CALoEmQz%3D5WA0K8OV5q_ONpxESzP7wEtkBZtF32AMT08bvFR0DQ%40mail.gmail.com
>
> .
>
--
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/CAACdnTAmQt-8%3Dv%3DdB3Q2pT2dKY_O0Ug2C1uyzDwrV1gFpup94Q%40mail.gmail.com.
Re: [go-nuts] Generic symbol metaproposal
I'm never sure how much detail to share. The colorForth idea is a perfect example of the thought about "another dimension" of specification. (Albeit difficult to implement in practice). The upper/lower case signal is a good one, and easy; it is limiting, but not terribly, and offers easy frictionless specification. The earlier comment about ";" being everywhere and nowhere in Go is important. It leads to the question "what can we intuit?" That is a fine starting place. For example, if the generic specification requires "()" or "[]" or whatever around type-concretization lists, but the parser will add them for you, then you'll never see either except in "pedantic" machine generated code or the rareish case of a generic type list that needs another generic type list as an element (the inner ones need delimiters). I vote for this whatever symbol is chosen. On Fri, Jul 24, 2020 at 3:16 PM David Riley wrote: > On Jul 24, 2020, at 5:50 PM, Ian Lance Taylor wrote: > > > > On Fri, Jul 24, 2020 at 2:22 PM wrote: > > > > > > On 7/23/20, Michael Jones wrote: > > > ... > > > > Another delight is the uppercase signal for external. > > > > > > > > Maybe the “how to signal it” aspect of type instantiation could look > to > > > > these approaches as well—make the automatic understanding so magical > that > > > > the complete specification is unnecessary in most all cases, or the > > > > signaling so intrinsic to the variables that no identification > Symbol or > > > > BracketedPair is necessary. > > > > > > Maybe braille? > > > ⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙ > > > https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG > > > > > > ⠊⠞ ⠊⠎ ⠑⠁⠎⠽ > > > > I've always felt that color is underused in modern programming languages. > > > > func Max(T)(s []T) T > > Perhaps there could be some cross-pollination with ColorForth, wherein > color actually is semantically meaningful. > > https://colorforth.github.io > > > - Dave -- *Michael T. jonesmichael.jo...@gmail.com * -- 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/CALoEmQz%3D5WA0K8OV5q_ONpxESzP7wEtkBZtF32AMT08bvFR0DQ%40mail.gmail.com.
Re: [go-nuts] Generic symbol metaproposal
On Jul 24, 2020, at 5:50 PM, Ian Lance Taylor wrote: > > On Fri, Jul 24, 2020 at 2:22 PM wrote: > > > > On 7/23/20, Michael Jones wrote: > > ... > > > Another delight is the uppercase signal for external. > > > > > > Maybe the “how to signal it” aspect of type instantiation could look to > > > these approaches as well—make the automatic understanding so magical that > > > the complete specification is unnecessary in most all cases, or the > > > signaling so intrinsic to the variables that no identification Symbol or > > > BracketedPair is necessary. > > > > Maybe braille? > > ⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙ > > https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG > > > > ⠊⠞ ⠊⠎ ⠑⠁⠎⠽ > > I've always felt that color is underused in modern programming languages. > > func Max(T)(s []T) T Perhaps there could be some cross-pollination with ColorForth, wherein color actually is semantically meaningful. https://colorforth.github.io - Dave -- 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/5C8F0D0D-0D9D-45E4-8B68-E78C59505550%40gmail.com.
Re: [go-nuts] Generic symbol metaproposal
On Fri, Jul 24, 2020, 23:50 Ian Lance Taylor wrote: > On Fri, Jul 24, 2020 at 2:22 PM wrote: > > > > On 7/23/20, Michael Jones wrote: > > ... > > > Another delight is the uppercase signal for external. > > > > > > Maybe the “how to signal it” aspect of type instantiation could look to > > > these approaches as well—make the automatic understanding so magical > that > > > the complete specification is unnecessary in most all cases, or the > > > signaling so intrinsic to the variables that no identification Symbol > or > > > BracketedPair is necessary. > > > > Maybe braille? > > ⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙ > > https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG > > > > ⠊⠞ ⠊⠎ ⠑⠁⠎⠽ > > I've always felt that color is underused in modern programming languages. > > func Max(T)(s []T) T > > Ian > Who came up with the idea of "begin with Lu for exported symbols"? Maybe there are other better ideas where that came from. -- 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/CA%2BctqrqO%2ByYsW%3D%3D%3DQk87_%3D0qPiVmFTDyBgA4xyBdw6a95EpHYw%40mail.gmail.com.
Re: [go-nuts] Generic symbol metaproposal
On Fri, Jul 24, 2020 at 2:22 PM wrote: > > On 7/23/20, Michael Jones wrote: > ... > > Another delight is the uppercase signal for external. > > > > Maybe the “how to signal it” aspect of type instantiation could look to > > these approaches as well—make the automatic understanding so magical that > > the complete specification is unnecessary in most all cases, or the > > signaling so intrinsic to the variables that no identification Symbol or > > BracketedPair is necessary. > > Maybe braille? > ⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙ > https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG > > ⠊⠞ ⠊⠎ ⠑⠁⠎⠽ I've always felt that color is underused in modern programming languages. func Max(T)(s []T) T 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/CAOyqgcUmcQy0h_sYYfmYny2n-5nDJR4qakFN4MGZX0VX0yLmAw%40mail.gmail.com.
Re: [go-nuts] Generic symbol metaproposal
On 7/23/20, Michael Jones wrote: ... > Another delight is the uppercase signal for external. > > Maybe the “how to signal it” aspect of type instantiation could look to > these approaches as well—make the automatic understanding so magical that > the complete specification is unnecessary in most all cases, or the > signaling so intrinsic to the variables that no identification Symbol or > BracketedPair is necessary. Maybe braille? ⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙ https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG ⠊⠞ ⠊⠎ ⠑⠁⠎⠽ -- 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/CA%2BctqroajJ_JzGs5sAcmVOAjAPaaucRZsZ_XGqE%3DJV%2BbuuRTbw%40mail.gmail.com.
[go-nuts] Generic symbol metaproposal
One interesting fact of go is that semicolons are required at the end of
statements. A fact forgotten perhaps because of the automatic ‘we’ll insert
one for you’ process. This duality, required but auto-supplied in nearly
every case is a delightful outcome.
Another delight is the uppercase signal for external.
Maybe the “how to signal it” aspect of type instantiation could look to
these approaches as well—make the automatic understanding so magical that
the complete specification is unnecessary in most all cases, or the
signaling so intrinsic to the variables that no identification Symbol or
BracketedPair is necessary.
Do I have a perfect example? No. Imperfect, sure.
Choice a: leading upper case means an exported symbol, all upper case means
generic type. (Not Go 1 promise consistent) no special syntax/keyword
needed!
Choice b: struct name a=int, b=MyType {...}
No parse issue about ‘struct name’ followed by an identifier, right?
Choice c: leading and trailing underscore on generic placeholder
identifiers. Func MySqrt(x _t_)
These Examples are not deep thoughts. But the notion of no keyword or funky
symbol In the 99.99% of cases is a deep thought.
Michael
--
*Michael T. jonesmichael.jo...@gmail.com *
--
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/CALoEmQwX5S70Zf5dwRCjaSO3Pppm2WpbD%3Dsrp9VLhD5UTO7srQ%40mail.gmail.com.
