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
<https://www.google.com/search?q=site%3Ahttp%3A%2F%2Fdocs.eiffel.com%2Feiffelstudio%2Flibraries+plain_text_file&btnI=I%27m+Feeling+Lucky>
sorted: STRING
<https://www.google.com/search?q=site%3Ahttp%3A%2F%2Fdocs.eiffel.com%2Feiffelstudio%2Flibraries+string&btnI=I%27m+Feeling+Lucky>
empty_list: LINKED_LIST
<https://www.google.com/search?q=site%3Ahttp%3A%2F%2Fdocs.eiffel.com%2Feiffelstudio%2Flibraries+linked_list&btnI=I%27m+Feeling+Lucky>
[STRING
<https://www.google.com/search?q=site%3Ahttp%3A%2F%2Fdocs.eiffel.com%2Feiffelstudio%2Flibraries+string&btnI=I%27m+Feeling+Lucky>]
Ada:
procedure Put (Position : Anagrams.Cursor) is
First : Boolean := True;
List : Set renames Element (Position);
PL/I:
word_test: proc options (main);
declare words (50000) character (20) varying,
frequency (50000) 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 <michael.jo...@gmail.com>
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 <fraveyd...@gmail.com> wrote:
>
>> On Jul 24, 2020, at 5:50 PM, Ian Lance Taylor <i...@golang.org> wrote:
>> >
>> > On Fri, Jul 24, 2020 at 2:22 PM <fge...@gmail.com> wrote:
>> > >
>> > > On 7/23/20, Michael Jones <michael.jo...@gmail.com> 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 <michael.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
> <https://groups.google.com/d/msgid/golang-nuts/CALoEmQz%3D5WA0K8OV5q_ONpxESzP7wEtkBZtF32AMT08bvFR0DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
