Showing posts with label case. Show all posts
Showing posts with label case. Show all posts

2022-07-04

Amazon CodeWhisperer and Microsoft Github Copilot:

2022.7.4: news.adds/dev/CASE/
Amazon CodeWhisperer and Microsoft Github Copilot:

summary:

. AI is being used for CASE

(computer-assisted software engineering).

. it is being trained on opensource code

and then applies techniques used by that code

to the specific needs of your code.

. the resulting code is free of any licensing agreements

because is considered fair use 

unless the software ideas are protected by patents

rather than merely copyright or copyleft.

. Amazon CodeWhisperer may be able to tell you

the license of the project its ideas were lifted from,

but Microsoft Github Copilot claims all its code

is sourced from and licensed by an AI, 

not from the projects that the AI studied.

refs:

https://aws.amazon.com/codewhisperer/

https://github.com/features/copilot/

https://openai.com/blog/openai-codex/

https://techcrunch.com/2022/06/23/amazon-launches-codewhisperer-its-ai-pair-programming-tool/

https://sfconservancy.org/blog/2022/feb/03/github-copilot-copyleft-gpl/

https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/

https://lists.copyleft.org/pipermail/ai-assist/

https://lists.sfconservancy.org/pipermail/give-up-github/


2012-01-31

addm's case instruction

addm/cstr/case/large domain space issues:
[1.8: intro:
. for a classic case stmt, one ensuring that
no more than one exec'path was activated,
the primary purpose of the variables (and arithmetic)
is to dynamically set the guard ranges .]

if case ranges can be variable expressions,
how does that work at the machine level?
. the alternative execution paths are numbered: 0...n,
so the case stmt is an array 0..n of
pointer to subroutine .
. the pointer could be an offset of the program counter,
so they can be word sized or even byte sized .

[1.8: case method depends on domain size:
. typically for each exec'path,
there is either a list of literals,
or else a pair of possibly variable expressions
delimiting a range .
. next there are 2 cases of domain space:

# small:
. the expression being cased is less than a byte,
or certainly not more than a 16bit word .
. in this case there is a direct mapping
from enum to exec'path number .
. we sort the literal cases,
thus allowing for a binary search during run-time .
. for the case ranges, a..b, c..d, ...,
we need the if/else if ... list:
case => a and case <= b ?
  goto ...
else case => c and case <= d ?
  goto ...
else ... .

# huge: ... ]
large domain space issues:
. how do the cases map to 0..n
when not enum literals?
that's when it loses the efficiency
that case stmt's are known for:
. it's eval'ing every exec'path guard expression
as well as the expression being cased,
then it might be reduced to crawling through
a huge {if/else if ...} list;
what it checks first might depend on profiling:
in the past eval's of this case stmt,
what percentage of time was each case chosen?

1.8: hashing intro:
. the expression is larger than small;
in this case, hashing might work?
in a hash the typical problem is
associating a name with an id# .
. when you find the name,
then you need to replace it with the id#;
you could place the string in a sorted container
in which the insertion operation was cheap;
and then do a binary search to find it,
or you could use the hash method:
. if you expect n strings,
then use an algorithm to turn the string into
a number that can range of n values;
eg, if there are less than 2*^16  values,
then your hash function should return 16bit ints .
. if 2 strings result in the same number
then they both go in the same bucket,
so when your search finds a bucket,
it has to crawl as with the binary search .

1.8: back to the casing problem:
. if the expression being cased is a huge number or string,
then with the literals used in the guard
we build a hash table,
and then hash the value being cased .
. when we find the match,
it's associated with the exec'path number we need .

variable case ranges

1.5: adda/cstr/case/variable case ranges:
. if the cases can be variable expressions
how does that work? how useful is that?
it does seem to suit a parallel case,
which would entail this equivalence:
e? # a: ;;; # b: ;;; # c: ;;; #; <=>
eval'd in parallel:
{ e= a? (;;;)
, e= b? (;;;)
, e= c? (;;;)
}
. the general characteristic required for
a non-parallel case stmt
is that it select no more than one of the
alternative execution paths .
. one useful example of variable case ranges
is when the use of variables and simple arithmetic
still provide a partition of the codomain,
ie, none of the case ranges are overlapping;
eg,
here are examples of simply shifting
the location of the boundaries between
exec'path guard partitions:
reals from a..d can vary to effect the outcome
of the following case .
e ?
#[a...b): proc1;
#[b...c): proc2;
#[c...d]: proc3 #;
and likewise for these variable integer ranges:
{a..b}, {b+1..c}, {c+1..d} .
. another use of such arithmetic
would provide case-range restrictions,
so that a varying set of cases are going to
the {others, do-nothing} execution paths .

adda's case stmt evolves

1.2: adda/cstr/case/
similar to goto labels not function points list:
[1.5: intro:
. the case stmt was seen to share the same structure as
that of the param'list, record'literal,
and the function points list:
( domain-elements,,,: codomain-element
,  d,d,d,d: cod
) -- if a domain element is followed by a comma,
then it's part of a list of domain elements
all sharing the same codomain element .
. however,
the colon character is also used for identifying address labels:
( label,,,: ; ;;;
label:
...)
-- the c lang's fall-through case stmt has similar syntax
in that it's reusing label syntax * .
. the case doesn't need commas like the function points list;
because, it can work like other labels; [1.31:
(the case stmt does still use commas for the domain lists;
ie, for when multiple cases having the same target ).]

. the usual (;) vs (,) priority is exemplified by the matrix, eg:
( el, el, el,
; el, el, el,
; el, el, el ),
[1.31: this is contrast to the list of statement's
in which declaration stmt's use commas in the domain list:
( v1, v2, v3: shared-type
; v1, v2, v3: shared-type
; stmt; stmt; stmt
);]

. a case list (the list of control paths being offered)
has elements that include sequences (of stmt's);
so, we have to make sure that the context always tells us
which situation you're going into:
 a list of lists, (as seen in a matrix) versus
 a list of sequences .
. if a sequence of stmts is an element in matrix
it creates ambiguity if unparenthesized:
(,,,
; ,,, ;;; ,
; ,,,
) .
*: [1.31:
. actually, a key feature of c's case syntax,
is the case-prefixing used within the body-container of
switch ( expression ) body-container:
switch ( expression )
{    declaration stmts ;;; -- adda instead has inline decl's .
case a:  -- the case label is like a stmt but terminated by (:);
case b: stmt; stmt; -- a's and b's target stmts .
default: stmt .
} .
. the adda case stmt differs from c's in that
it is like its other conditional stmt (the if):
truth ? stmt else stmt; -- the if-else;
truth ? #true: stmt; #false: stmt; #; -- the case .
. like c, however, adda tries to minimize syntax;
and, towards that end,
notice the cases wouldn't need paren's around them if
the final case keyword was followed by the (;);
conversely, the (#.) is not needed if
the case stmt or its body are in paren's;
however, always having a case-terminal at the end of case
might help syntax errors involving enclosures;
or else it could be thought of as a type of enclosure:
( ,,, ; ,,, ; ,,, . ,,, ; ,,, ; ,,, ) -- for the data
#a: s;s;s; #b: s;s;s; #; -- for the cases .
. if preferring english over symbols, (case) = (#):
truth ?
case true: stmt;
case false: stmt;
case;  ]-1.31

1.2: adda/cstr/case/
supporting c's fall-through style:
. should the case like c's be called fallthru?
how could it be called jmp or goto?
it should include the usual syntax shared by
all conditional stmt's .
[... but that syntax is about to change:]
[@] adda/cstr/case/similar to goto labels not function points list
fallthru e ? (e, ,,, : s; s; s; e,,,: s;;; );
--
. the inside of a case stmt looks just like a stmt block .
. fallthru is a control function of 1 arg:
fallthru(case.stmt).stmt;
it expects its arg to be a case stmt .

1.5: inverting the default:
. a more intuitive use of the fallthru keyword
would be to have it used for
meaning just the opposite of the c lang's break stmt:
. when you wanted to fall-through,
then the fallthru stmt would be used to override
the default behavior .

1.5: minimize reserved words:
. instead of fallthru as a keyword
it might be better to reuse what we have,
such as (enter next),
-- "(next) doesn't have to be a reserved word,
because it's still local to the arg of function"enter --
or generalize it like this: [1.8:
enter case [some label within the case stmt] ].

adda/cstr/case/
only fallthru's need an exit stmt:
1.2:
. in a fallthru, the break is called exit,
just as in the loops,
when loops and case stmts are nested
you can specify where you want to exit to:
ie, "(exit loop)  vs "(exit fallthru) .
. if it's a normal (non-fallthru) case stmt,
then there is no need for an exit stmt
so mentioning exit
would apply to a surrounding loop or fallthru .
1.5: not true:
. that's actually debatable;
because, a case could want to bail out early?;
conversely,
while an exit may be useful for some,
it could be inconvenient for many,
as it is very common have a case within a loop,
so if the case's use of exit could apply to itself
instead of the surrounding loop,
then that use of the exit stmt would have to specify
whether it referred to the {case stmt, loop stmt},
and the default target for an exit from a case stmt
would intuitively be exit case,
whereas in most cases the exit loop was desired;
then again,
it would be simpler, and more readable,
to have no default,
and then you could let coders have maximal freedom,
exiting anything from anywhere .
. furthermore,
even fall-through case stmts rarely do a fall-through;
they usually have more break stmt's than not;
so, the default behavior at the end of a case (case.stmt`branch)
should be (exit case) rather than (fallthru)
and if you mean otherwise, use an (enter next case).stmt
only at the end of the particular case
that needs to fall through .

1.2: adda/cstr/case/
supporting c's fall-through style:

. should the case like c's be called fallthru?
how could it be called jmp or goto?
it should include the usual syntax shared by
all conditional stmt's .
[... but that syntax is about to change:]
[@] adda/cstr/case/similar to goto labels not function points list
fallthru e ? (e, ,,, : s; s; s; e,,,: s;;; );
--
. the inside of a case stmt looks just like a stmt block .
. fallthru is a control function of 1 arg:
fallthru(case.stmt).stmt;
it expects its arg to be a case stmt .

1.5: inverting the default:
. a more intuitive use of the fallthru keyword
would be to have it used for
meaning just the opposite of the c lang's break stmt:
. when you wanted to fall-through,
then the fallthru stmt would be used to override
the default behavior .

1.5: minimize reserved words:
. instead of fallthru as a keyword
it might be better to reuse what we have,
such as (enter next),
-- "(next) doesn't have to be a reserved word,
because it's still local to the arg of function"enter --
or generalize it like this: [1.8:
enter case [some label within the case stmt] ].

adda/cstr/case/
the cases need not be literals:
1.2:
. whether the labels need to be const's,
being enums they eval to self,
so generally the case guard can always be eval'd;
you can also use expressions as literal cases
by quoting them, which supresses eval;
in that case,
the expr being cased should eval to etree;
because, a quoted expression is always an etree .