> On Aug 29, 2017, at 14:31, Slava Pestov <[email protected]> wrote:
>
>
>>> On Aug 29, 2017, at 2:21 PM, David Sweeris <[email protected]> wrote:
>>>
>>>
>>>> On Aug 29, 2017, at 1:49 PM, Slava Pestov <[email protected]> wrote:
>>>>
>>>>
>>>> On Aug 29, 2017, at 11:03 AM, David Sweeris via swift-dev
>>>> <[email protected]> wrote:
>>>>
>>>> Hi everyone! I'm trying to implement literal values as generic types.
>>>
>>> Can you briefly explain what you mean by this?
>>>
>>> Are you referring to let-polymorphism, like
>>>
>>> let fn = { $0 }
>>> let f1: (Int) -> Int = fn
>>> let f2: (Float) -> Float = fn
>>
>> No, I mean so that a vector's or matrix's dimensions can be part of its type
>> (strawman syntax and protocol name, but this is pretty much what I'll be
>> trying to support, at least at first):
>
> I think instead of modeling these generic parameters as types, you should
> look into generalizing GenericSignatures to contain ‘literal requirements’.
> Right now, we have four kinds of requirements:
>
> - A is a subclass of B
> - A conforms to B
> - A is the same type as B
> - A has a known layout
>
> All of these except for the last one have a generic parameter as their right
> hand side. All of them have a generic parameter on their left hand side. I
> think what you want is to add a new ‘value parameter’ that is not a type, but
> instead has a value. Requirements would be placed on these to constrain them
> to known kinds of literals (integers, strings, etc).
Thanks, will do!
>
>> struct Vector<T: ExpressibleByIntegerLiteral, L: IntegerLiteralExpr> {
>> var elements: [T]
>> init() {
>> elements = [T](repeating: 0, count: L)
>> }
>> }
>>
>> let vect = Vector<Int, 5>()
>>
>> And, once that's working, I'm going to add support simple "type functions":
>> func join <T, L1, L2> (_ lhs: Vector<T, L1>, _ rhs: Vector<T, L2>) ->
>> Vector<T, L1 + L2 > {...}
>> I think restricting the supported "type functions" to expressions that could
>> be evaluated by the compiler's "constant folding" code would be a reasonable
>> place to start,
>
> The compiler’s constant folding operates on SIL instructions, not Exprs
> directly. However constant folding is not generally what you want for this,
> because constant folding is a ‘best effort’ kind of optimization (it may or
> may not fold your calculation down to a constant) and also it produces code
> that evaluates the result (even if its a constant) and not the result itself.
Yeah, I didn't mean I was going to literally use constant-folding (is that a
pun? The world may never know...) for exactly the reasons you mentioned. I just
meant "the kinds of expressions that constant-folding would reasonably be
expected to probably optimize". The only two that I think are pretty much
necessary are "+" and "-" on integer literals, so that functions can combine
and break-up types like "vector" and "matrix". String concatenation with "+"
seems pretty reasonable, too. Speaking of which...
> I think if you want to explore type-level computation like this, you should
> define a very small subset of the language which can be computed by the type
> checker like this.
I do want to do that. My initial thoughts on the matter is that such a subset
would probably essentially be "any function that can be evaluated a
compile-time and returns a type", but then that requires having a good notion
of "pure" / "constexpr" / "whateverWeCallIt", and I'm not sure I want to open
two cans of worms at once.
That said, I'm a huge fan of the approach the core team has taken WRT defining
everything in the stdlib and minimizing "compiler magic". It might be more than
I want to bite off in a single proposal, but getting the supported functions
out of the compiler and allowing user-defined functions to get a type is an
obvious next step.
- Dave Sweeris
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
