State of structural typing support in Scala 3.3.0

Scala's type system is primarily based on nominal typing. Scala 3 introduces a special type, Selectable, which provides an infrastructure for structural typing. Karlsson and Haller proposed improvements to Selectable to support extensible records. In this paper, we review several Scala 3 projects that involve structural typing. We find that their implementation or usability would benefit from the extensible records proposal from Karlsson and Haller. We investigate the remaining common challenges when working with structural types. In particular, we identify that a dedicated syntax for both record types and record literals would be the most beneficial addition to the language

Challenges, solutions and future directions in the evaluation of service innovations in health care and public health

HeadlineEvaluating service innovations in health care and public health requires flexibility, collaboration and pragmatism; this collection identifies robust, innovative and mixed methods to inform such evaluations.This is the final version of the article. It first appeared from the National Institute for Helath Research via http://dx.doi.org/10.3310/hsdr0416

Web applications engineering : reduce the complexity without loosing control

L'automatisation de certaines tâches et traitements d'information grâce aux outils numériques permet de réaliser des économies considérables sur nos activités. Le Web est une plateforme propice à la mise en place de tels outils : ceux-ci sont hébergés par des serveurs, qui centralisent les informations et coordonnent les utilisateurs, et ces derniers accèdent aux outils depuis leurs terminaux clients (ordinateur, téléphone, tablette, etc.) en utilisant un navigateur Web, sans étape d'installation. La réalisation de ces applications Web présente des difficultés pour les développeurs. La principale difficulté vient de la distance entre les postes client et serveur. D'une part, la distance physique (ou distance matérielle ) entre les machines nécessite qu'une connexion réseau soit toujours établie entre elles pour que l'application fonctionne correctement. Cela pose plusieurs problèmes : comment gérer les problèmes de latence lors des échanges d'information ? Comment assurer une qualité de service même lorsque la connexion réseau est interrompue ? Comment choisir quelle part de l'application s'exécute sur le client et quelle part s'exécute sur le serveur ? Comment éviter aux développeurs d'avoir à résoudre ces problèmes sans pour autant masquer la nature distribuée des applications Web et au risque de perdre les avantages de ces architectures ? D'autre part, l'environnement d'exécution est différent entre les clients et serveurs, produisant une distance logicielle. En effet, côté client, le programme s'exécute dans un navigateur Web dont l'interface de programmation (API) permet de réagir aux actions de l'utilisateur et de mettre à jour le document affiché. De l'autre côté, c'est un serveur Web qui traite les requêtes des clients selon le protocole HTTP. Certains aspects d'une application Web peuvent être communs aux parties client et serveur, par exemple la construction de morceaux de pages Web, la validation de données saisies dans les formulaires, la navigation ou même certains calculs métier. Cependant, comme les API des environnements client et serveur sont différentes, comment mutualiser ces aspects tout en bénéficiant des mêmes performances d'exécution qu'en utilisant les API natives ? De même, comment conserver la possibilité de tirer parti des spécificités de chaque environnement ? Les travaux de cette thèse ont pour but de raccourcir cette distance, tant logicielle que matérielle, tout en préservant la capacité à tirer parti de cette distance, c'est-à-dire en donnant autant de contrôle aux développeurs.Thanks to information technologies, some tasks or information process can be automated, thus saving a significant amount of money. The web platform brings numerous of such digital tools. These are hosted on web servers that centralize information and coordinate users, which can use the tools from several kinds of devices (desktop computer, laptop, smartphone, etc.), by using a web browser, without installing anything. Nevertheless, developing such web applications is challenging. The difficulty mainly comes from the distance between client and server devices. First, the physical distance between these machines requires them to be networked. This raises several issues. How to manage latency ? How to provide a good quality of service even when the network is down ? How to choose on which side (client or server) to execute a computation ? How to free developers from addressing these problems without yet hiding the distributed nature of web application so that they can still benefit from their advantages ? Second, the execution environment is different between clients and servers. Indeed, on client-side the program is executed within a web browser whose API provides means of reacting to user actions and of updating the page. On server-side, the program is executed on a web server that processes HTTP requests. Some aspects of web applications can be shared between client and server sides (e.g. content display, form validation, navigation, or even some business computations). However, the APIs and environments are different between clients and servers, so how to share the same code while keeping the same execution performance as with native APIs ? How to keep the opportunity to leverage the specificities of a given platform ? This work aims at shortening this distance while keeping the opportunity to leverage it, that is while giving developers as much expressive power

Ingénierie des applications Web : réduire la complexité sans diminuer le contrôle

Thanks to information technologies, some tasks or information process can be automated, thus saving a significant amount of money. The web platform brings numerous of such digital tools. These are hosted on web servers that centralize information and coordinate users, which can use the tools from several kinds of devices (desktop computer, laptop, smartphone, etc.), by using a web browser, without installing anything. Nevertheless, developing such web applications is challenging. The difficulty mainly comes from the distance between client and server devices.First, the physical distance between these machines requires them to be networked. This raises several issues. How to manage latency? How to provide a good quality of service even when the network is down? How to choose on which side (client or server) to execute a computation? How to free developers from addressing these problems without yet hiding the distributed nature of web application so that they can still benefit from their advantages?Second, the execution environment is different between clients and servers. Indeed, on client-side the program is executed within a web browser whose API provides means of reacting to user actions and of updating the page. On server-side, the program is executed on a web server that processes HTTP requests. Some aspects of web applications can be shared between client and server sides (e.g. content display, form validation, navigation, or even some business computations). However, the APIs and environments are different between clients and servers, so how to share the same code while keeping the same execution performance as with native APIs? How to keep the opportunity to leverage the specificities of a given platform?This work aims at shortening this distance while keeping the opportunity to leverage it, that is while giving developers as much expressive power.Our first contribution consists of an architecture pattern to build interactive and collaborative web applications handling on-line and off-line modes. Our pattern captures the client-server synchronization concern, thus giving developers a simpler programming model.Our second contribution shows how to use a delayed evaluation mechanism to build high-level abstractions that can be shared between client and server sides and that generate efficient code leveraging the specificities of each platform. We observed that the size of the code written using our abstractions is similar to code that uses high-level libraries, and 35% to 50% smaller than low-level code, while execution performance are similar to low-level code and 39% to 972% faster than high-level code.Our third contribution makes it easier to use the web browser’s API from a statically typed language. Indeed, this API is designed to be used with the dynamically typed language JavaScript, and some functions are hard to encode in a static type system. Current solutions either loose type information, requiring users to perform unsafe typecasts or reduce the expressive power. We show two ways to encode challenging web browser’s functions in a static type system by leveraging parameterized types and dependent types. Our approach is typesafe and keeps the same expressive power as the native API.L’automatisation de certaines tâches et traitements d’information grâce aux outils numériques permet de réaliser des économies considérables sur nos activités. Le Web est une plateforme propice à la mise en place de tels outils : ceux-ci sont hébergés par des serveurs, qui centralisent les informations et coordonnent les utilisateurs, et ces derniers accèdent aux outils depuis leurs terminaux clients (ordinateur, téléphone, tablette, etc.) en utilisant un navigateur Web, sans étape d’installation. La réalisation de ces applications Web présente des difficultés pour les développeurs. La principale difficulté vient de la distance entre les postes client et serveur.D’une part, la distance physique (ou distance matérielle) entre les machines nécessite qu’une connexion réseau soit toujours établie entre elles pour que l’application fonctionne correctement. Cela pose plusieurs problèmes : comment gérer les problèmes de latence lors des échanges d’information ? Comment assurer une qualité de service même lorsque la connexion réseau est interrompue ? Comment choisir quelle part de l’application s’exécute sur le client et quelle part s’exécute sur le serveur ? Comment éviter aux développeurs d’avoir à résoudre ces problèmes sans pour autant masquer la nature distribuée des applications Web et au risque de perdre les avantages de ces architectures ?D’autre part, l’environnement d’exécution est différent entre les clients et serveurs, produisant une distance logicielle. En effet, côté client, le programme s’exécute dans un navigateur Web dont l’interface de programmation (API) permet de réagir aux actions de l’utilisateur et de mettre à jour le document affiché. De l’autre côté, c’est un serveur Web qui traite les requêtes des clients selon le protocole HTTP. Certains aspects d’une application Web peuvent être communs aux parties client et serveur, par exemple la construction de morceaux de pages Web, la validation de données saisies dans les formulaires, la navigation ou même certains calculs métier. Cependant, comme les API des environnements client et serveur sont différentes, comment mutualiser ces aspects tout en bénéficiant des mêmes performances d’exécution qu’en utilisant les API natives ? De même, comment conserver la possibilité de tirer parti des spécificités de chaque environnement ?Les travaux de cette thèse ont pour but de raccourcir cette distance, tant logicielle que matérielle, tout en préservant la capacité à tirer parti de cette distance, c’est-à-dire en donnant autant de contrôle aux développeurs.La première contribution concerne la distance matérielle. Nous proposons un modèle d’architecture pour les applications interactives et collaboratives fonctionnant en mode connecté et déconnecté. Notre modèle isole la préoccupation de synchronisation client-serveur, offrant ainsi un modèle de développement plus simple pour les développeurs.La seconde contribution concerne la distance logicielle. Nous nous appuyons sur un mécanisme d’évaluation retardée, permettant à un même programme d’être exécuté côté client ou serveur, pour bâtir des abstractions, offrant un modèle de programmation homogène et haut-niveau, produisant du code tirant parti des spécificités des environnements client et serveur. Nous avons observé que la taille du code écrit avec nos outils est du même ordre de grandeur que celle d’un code utilisant des bibliothèques haut-niveau existantes et 35% à 50% plus petite que celle d’un code bas-niveau, mais les performances d’exécution sont du même ordre de grandeur que celles d’un code bas-niveau et 39% à 972% meilleurs qu’un code haut-niveau.Une troisième contribution s’adresse aux adeptes du typage statique. En effet l’API du navigateur est conçue pour un langage dynamiquement typé, JavaScript, et certaines de ses fonctions peuvent être difficiles à exposer dans un langage statiquement typé. En effet, les solutions actuelles perdent en général de l’information, contraignant les développeurs à effectuer des conversions de type contournant le système de typage, ou proposent des fonctions avec un pouvoir d’expression réduit. Nous proposons deux façons d’exposer ces fonctions dans des langages statiquement typés, en nous appuyant respectivement sur les types paramétrés ou les types dépendants. Notre approche, tout en étant bien typée, permet de réduire le nombre de fonctions exposées aux développeurs tout en conservant le même pouvoir d’expression que l’API native

Play framework essentials

This book targets Java and Scala developers who already have some experience in web development and who want to master Play framework quickly and efficiently. This book assumes you have a good level of knowledge and understanding of efficient Java and Scala code

Current Evidence for Immune Checkpoint Inhibition in Advanced Hepatocellular Carcinoma

The treatment of advanced unresectable HCC (aHCC) remains a clinical challenge, with limited therapeutic options and poor prognosis. The results of IMbrave150 and HIMALAYA have changed the treatment paradigm for HCC and established immune checkpoint inhibition (ICI), either combined with anti-angiogenic therapy or dual ICI, as preferred first-line therapy for eligible patients with aHCC. Numerous other combination regimens involving ICI are under investigation with the aim of improving the tumour response and survival of patients with all stages of HCC. This review will explore the current evidence for ICI in patients with advanced HCC and discuss future directions, including the unmet clinical need for predictive biomarkers to facilitate patient selection, the effects of cirrhosis aetiology on response to ICI, and the safety of its use in patients with impaired liver function

Efficient high-level abstractions for web programming

International audienceWriting large Web applications is known to be difficult. One challenge comes from the fact that the application's logic is scattered into heterogeneous clients and servers, making it difficult to share code between both sides or to move code from one side to the other. Another challenge is performance: while Web applications rely on ever more code on the client-side, they may run on smart phones with limited hardware capabilities. These two challenges raise the following problem: how to benefit from high-level languages and libraries making code complexity easier to manage and abstracting over the clients and servers differences without trading this ease of engineering for performance? This article presents high-level abstractions defined as deep embedded DSLs in Scala that can generate efficient code leveraging the characteristics of both client and server environments. We compare performance on client-side against other candidate technologies and against hand written low-level JavaScript code. Though code written with our DSL has a high level of abstraction, our benchmark on a real world application reports that it runs as fast as hand tuned low-level JavaScript code