<div dir="ltr">Any plans something along the lines of Scala's proposed Value Types. <div><br></div><div><div style>A path:</div><div style><br></div><div style>Allow for "special" struct: decls (vstruct: ?) where the parent is a limited subset of non structure parent types (base value types such as String, Number). </div>
<div style><br></div><div style>These special structures MUST contain one and only one value of the parent "special" type or it is a compile error. </div><div style>The structure constructor does not construct the wrapping structure but instead passes through the wrapped value, but *always* invokes the validator during pass-thru.</div>
<div style>TR treats the type as a subtype of the base value type.</div><div style><br></div><div style>e.g.</div><div style><br></div><div style>(struct: Identifier String ([value : String])</div><div style> #:methods gen:validator (lambda (thing) ...) ;; is of type (Any -> Boolean : Identifier))</div>
<div style><br></div><div style>(define id (Identifier "myidentifier")) ;; validator invoked, no structure was allocated, `id' is just a String value, is a subtype of String.</div><div style><br></div><div style>
(define uc-id (Identifer (string-upcase id))) ;; validator invoked, as id is a just a string no unboxing in (string-upcase id), in fact no allocations here at all.</div><div style><br></div><div style>Under the covers the Identifier constructor never creates the structure, it acts as a pass through id : (String -> String) function. i.e. the runtime representation of `id' is always as a String so any struct <-> value boxing / unboxing is avoided. I think there is enough machinery in place to get pretty close to this.</div>
<div style><br></div><div style>What is gained?</div><div style><br></div><div style>What is done internally in TR defining Natural, Index, Exact-Positive-Integer can now be done without special internal defining, just another constrained base type. One can start to define things like Age [1 .. 120]. </div>
<div style>Another is IMHO a HUGE source of program error is just not enough time to do proper validation at IO boundries where entering data is of the form Strings and Bytes and it needs to be lifted.</div><br>Consider the following typical use case from Amazon's AWS API, a Tasklist parameter.<br>
<br>Parameter - Tasklist : String[1-256]<br><br>Specifies the task list to poll for activity tasks.<br><br>The specified string must not start or end with whitespace. It must not contain a : (colon), / (slash), | (vertical bar), or any control characters (\u0000-\u001f | \u007f - \u009f). Also, it must not contain the literal string "arn".<br>
<br>Most likely, I'll punt.</div><div><br></div><div style>(: call-it (String ... -> ...))</div><div style>(define (call-it task-list ...)</div><div style><br></div><div style>If I'm ambitious today.</div><div style>
<br></div><div style>;; would prefer (define-new-type Tasklist String)</div><div style>(define-type Tasklist String) ;; tighten things later down the road, <sigh> none type generative</div><div style><br></div><div style>
<div>(: call-it (Tasklist ... -> ...))</div><div>(define (call-it task-list ...)</div></div><div style><br></div><div style>What I'd like to do.</div><div style><br></div><div style>(define-value-type Tasklist String [1 .. 256] (lambda (this) ....)) ;; mad use of regexp in validator fn (Any -> Boolean : Tasklist)</div>
<div><br></div><div style>(call-it (Tasklist "mytasklist") ...)</div><div style><br></div><div style>(call-it (Tasklist "arn:bad/tasklist") ...)</div><div style><br></div><div style>(define-value-type Age Integer [1 .. 120]) ;; no special validation beyond bounds check.</div>
<div style><br></div><div style> </div><div><br></div><div><br></div><div><br></div></div>