Five years ago, already. Not so complex. If you want complex, I suggest
TypeScript. But successful :-)
My position remains that type annotations that are unpleasant to write and only
capture a tiny portion of the beauty of R are not going to be adopted.
Consider what TypeScript did for JavaScript.
https://janvitek.org/pubs/oopsla20-r.pdf
oopsla20-r
PDF Document · 759 KB
-jan
Jan Vitek, Professor
Northeastern University
Video chat: https://northeastern.zoom.us/my/jvroom
> On Nov 27, 2025, at 01:04, Simon Urbanek <[email protected]> wrote:
>
> The R5 syntax introduced over 15 years ago it was meant to be minimalistic
> (optional argument types) to have a start at experimenting, however there was
> little interest at the time. Then I remember at one of the useR!’s I think
> someone from Jan Vitek’s group was presenting on a very complex annotation
> system that allowed not only type checking, but also definition of
> constraints etc. (unfortunately I can’t remember the names and so didn't find
> the paper). At that time I was thinking that it’s cool, but this will never
> happen, because once you start exploring all the possible use-cases the scope
> grows exponentially and it will become impossible to agree on any common
> ground: the classic perfect being the enemy of the good. So I suspect that is
> the main problem: it is not a clear feature that has a clear path forward -
> it is just an ill-defined idea (what is the purpose? about arguments? about
> other expressions? constraints? evaluated constraints? return values? what
> will be done with it?). Add to that the obvious: it would be possibly a big
> change to the language, so it really needs to be considered carefully as
> there will be no going back, since R prides itself on very good backward
> compatibility which makes it so useful in practice. Also anything complex
> will have security and performance implications.
>
> I have not seen any serious proposals so far. There have been various
> experimentation in a package space, but those are often opinionated with
> varying levels of thought put into it. Personally, I think the syntax is
> important so I would like to make sure possible syntax changes are considered
> so we’re not just creating an awkward syntax because it is easier in package
> space, but not intuitive to use.
>
> So just like with any improvement (c.f. the ifelse discussion), if there is
> actual interest, then people should start discussing the aspects, starting
> with the key ones such as purpose and requirements. I don't think this topic
> really has been even defined so I wouldn’t run creating packages just yet,
> especially since I think this is more about design than implementation. No
> one has done that work just yet.
>
> Cheers,
> Simon
>
>
>> On 27 Nov 2025, at 05:59, ivo welch <[email protected]> wrote:
>>
>> I am more interested why something like this has not made its way into R
>> core as a first step to type checking *for everyone*. (I could imagine that
>> an option would turn on and off some automatic stopifnot like checking given
>> a standardized annotation form [type, dim].)
>>
>> is it because there is not much wider interest and desirability (so even a
>> basic working implementation would not be pulled into R by the powers that
>> are in charge), or is it because the work is too difficult and no one had
>> time to work on it?
>>
>>
>> On Wed, Nov 26, 2025 at 8:50 AM Hadley Wickham <[email protected]> wrote:
>>
>>> You might be interested in Jim Hester’s old experiment that used ? -
>>> https://github.com/jimhester/types
>>>
>>> Hadley
>>>
>>> On Wednesday, September 17, 2025, IVO I WELCH <[email protected]> wrote:
>>>
>>>>
>>>> Suggestion for Syntax Sugar:
>>>>
>>>> Would it make sense to permit a simple way to allow a coder to document
>>>> the function argument type?
>>>>
>>>> f <- function( a:chr, b:data.frame, c:logi ) { … }
>>>>
>>>> presumably, what comes behind the ‘:’ should match what ‘str’ returns.
>>>>
>>>> however, this need not be checked (except perhaps when a particular
>>>> option is set). catching errors as soon as possible makes code easier to
>>>> debug and error messages clearer.
>>>>
>>>> regards,
>>>>
>>>> /iaw
>>>>
>>>> ______________________________________________
>>>> [email protected] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>
>>>
>>> --
>>> http://hadley.nz
>>>
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> [email protected] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> [email protected] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
