[erlang-questions] -spec tuple variable size

[Siraaj Khandkar]

Conceptually, it sounds like the same thing: you know individual element type,
but not the number of elements - it is a list.

Given the constraints, I don't think you have much choice but to check elements
prior to their entry into the tuple. Otherwise you have to do runtime checks. Or
that template.

May be you can offer an API to store the list but retrieve it as a tuple?


On Nov 29, 2012, at 11:46 AM, Dmitry Kolesnikov <dmkolesnikov@REDACTED> wrote:

> Hello,
> 
> Thanks for your comment, appreciate it.
> Unfortunately, you have missed my use-case.
> 
> I do offer an api to store a tuple. The storage do not concern the tuple cardinality, in similar fashion like ets/dets does. One of my current limitation is that tuple elements MUST be a particular data type. I simply want to validate that client writes tuples with supported data types. I am also fine with generic tuple() data type but it is less error prone.
> 
> - Dmitry
> 
> On Nov 29, 2012, at 6:24 PM, Siraaj Khandkar <siraaj@REDACTED> wrote:
> 
>> Hmmm, IDK, that just seems wrong to me. If what you're offering clients is a
>> variable number of elements, then, semantically, you're offering them a list.
>> If a client wants to optimize lookups, it should be left up to the client app
>> to convert it to a tuple.
>> 
>> If you think about it, you're asking for a static guarantee for something that
>> is only known at runtime, which is not possible.
>> 
>> Alternatively, I guess you can write a template that expands to 4096 elements :)
>> 
>> 
>> On Nov 29, 2012, at 11:08 AM, Dmitry Kolesnikov <dmkolesnikov@REDACTED> wrote:
>> 
>>> Hello,
>>> 
>>> Yes, you are right that tuples are converted into list during the serialisation process. You cannot avoid it but api offered to client uses tuples. 
>>> 
>>> - Dmitry
>>> 
>>> On Nov 29, 2012, at 6:03 PM, Siraaj Khandkar <siraaj@REDACTED> wrote:
>>> 
>>>> I don't know all the technicalities of Erlang's type specs, but in general -
>>>> variable growth is antithetical to the concept of a tuple.
>>>> 
>>>> You'll still need to accumulate the elements in some list before you convert
>>>> it to a tuple, so why not just spec that list?
>>>> 
>>>> 
>>>> On Nov 28, 2012, at 5:10 PM, Dmitry Kolesnikov <dmkolesnikov@REDACTED> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> Thanks for response!
>>>>> Let me explain better what I am trying to achieve.
>>>>> "The shorthand [T,...] stands for the set of non-empty proper lists whose elements are of type T." 
>>>>> I am looking for similar definition but for tuples.
>>>>> 
>>>>> My application serialises tuples into disk. The size of tuple is unbound but tuple elements a fixed to string, binary, number, boolean or undefined. I cannot use " "|" operator to define as many variants as you like" because number of variants is unlimited. Well practically, I do have a hard limit of 4096 elements per tuple but I am lazy to type in 4096 variants :-) 
>>>>> 
>>>>> - Dmitry
>>>>> 
>>>>> On Nov 28, 2012, at 11:50 PM, Motiejus Jakštys <desired.mta@REDACTED> wrote:
>>>>> 
>>>>>> On Wed, Nov 28, 2012 at 9:10 PM, Dmitry Kolesnikov
>>>>>> <dmkolesnikov@REDACTED> wrote:
>>>>>>> but compiler fails syntax error before: ','
>>>>>>> 
>>>>>>> -- CLIP --
>>>>>>> -type value()     :: string() | binary() | number() | boolean() | undefined.
>>>>>>> -type entity()    :: [{atom(), value()}] | {field()}.
>>>>>> 
>>>>>> These should be fine.
>>>>>> 
>>>>>>> -type field()      :: value() | value(), field().
>>>>>> 
>>>>>> Maybe you meant
>>>>>> -type field() :: value() | {value(), field()}.
>>>>>> 
>>>>>> ?
>>>>>> 
>>>>>> In general, if you want to define tuples of different sizes in -spec,
>>>>>> you use the "|" operator to define as many variants as you like.
>>>>>> 
>>>>>> Likely I don't understand what you are trying to define.
>> 
>> -- 
>> Siraaj Khandkar
>> .o.
>> ..o
>> ooo
>> 
> 

-- 

Siraaj Khandkar
-------------------------------------------------------------------------------
.o.
..o
ooo