Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 187

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 188

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 189

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 194

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 195

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 196

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 197

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 241

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 264

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 269

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 275

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 285

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 286

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 296

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 297

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 298

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 308

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 309

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 310

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 311

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 321

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 322

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 323

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 324

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 325

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 497

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 527

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 540

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 587

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 626

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 670

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 673

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 682

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 688

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 693

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 699

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 272

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 110

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 130

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 295
Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff. 2024-01-31T17:45:28+00:00 Didier Verna urn:md5:a22c53786aff986a2da4c770c233a8f9 Dotclear urn:md5:e0812f09dafade8f30cb198e46a3b5d5 Wednesday, August 5 2015 Wednesday, August 5 2015 Didier Verna Lisp Common LispconferenceECOOPOptional TypesSTOPWeak Typing <p>I was watching the discussion between Gilad Bracha and Matthias Felleisen on gradual typing this afternoon (it's available on <a href="https://youtu.be/JBmIQIZPaHY" hreflang="en">YouTube</a>). This was the last event at the STOP workshop, part of ECOOP 2015 in Prague. I couldn't attend it because I was somewhere else (Curry On) at the time. The discussion is interesting, but if you go all the way, in the last 10 minutes or so, you will notice that Matthias seems to be completely obsessed with what he calls the "Return of the SegFaults".</p> <p>Basically, the point is the following. Mathias dislikes the optional types in Common Lisp because it's opening the door to unsafety. Initially, any dynamic language has a sound type system (all type errors are caught; at run-time, yes, but they are caught). As soon as you introduce an optional type system ala Lisp, the compiler implementors are "pushed" to use the provided type information for optimization, hence weakening the type system and breaking soundness. It's the "return of segfauts".</p> <p>Of course, I agree with that, at least on the principle. Yes, Common Lisp's weak, optional type system is an antiquated thing. However, it seems to me that Matthias is forgetting two important things on the practical level:</p> <ol> <li>by default in many implementations that I know, if not all of them, introducing type declarations doesn't actually break the soundness of the type system but leads to even more type checking. For example, <code>(defun plus (a b) (+ a b))</code> works on every possible numerical value, but add <code>(declare (type fixnum a b))</code> in there and it will suddenly stop working on anything else but integers. It's only if you require the compiler to optimize for <code>speed</code> at the expense of <code>safety</code> that you effectively weaken your type system.</li> <li>In practice, the risk of re-introducing segfaults in your application may be mitigated by the interactive aspect of the development (TDD made easier, simultaneous write / compile / run / test / debug phases etc.).</li> </ol> <p>So my impression is that Matthias is largely exaggerating the problem, but I'm not really qualified to tell. That's why I would like to know from you guys, working with Lisp in the industry, writing large applications, lots of type annotations, and <code>(declaim (optimize (speed 3) (safety 0) (debug 0))</code> (EDIT: that's exaggerated of course, I really mean breaking safety for performance reasons): how much of a problem the "return of the segfaults" really is in practice ?</p> <p>As a side note, this reminds me of the dynamic vs. lexical scoping debate. Many people were and still are strongly opinionated against dynamic scoping by default. Of course, I too, at least in principle. But how dangerous dynamic scoping really is in practice (EDIT: I'm not talking about expressiveness, e.g. closures, here. Only unsafety.)? What I can tell you is that in the 15 years I was actively maintaining the XEmacs codebase, I may have run into name clashes due to dynamic scoping... twice.</p> https://www.didierverna.net/blog/index.php?post/2015/08/05/The-Return-of-Segfaults#comment-form https://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/138 urn:md5:d08cb8b4174370f23b16ca5e8ec6adf0 Sunday, March 24 2013 Sunday, March 24 2013 Didier Verna Miscellaneous conferenceCOPECOOPworkshop <pre> Call for Papers COP'13 Fifth International Workshop on Context-Oriented Programming Worokshop in conjunction with ECOOP, ECMFA, and ECSA 2013 Montpellier, France, July 2nd, 2013 http://www.fos.kuis.kyoto-u.ac.jp/COP13/ https://www.easychair.org/conferences/?conf=cop13 Overview -------- Context information plays an increasingly important role in our information-centric world. Software systems must adapt to changing contexts over time, and must change even while they are running. Unfortunately, mainstream programming languages and development environments do not support this kind of dynamic change very well, leading developers to implement complex designs to anticipate various dimensions of variability. Starting from this observation, Context-Oriented Programming (COP) has emerged as a solution to directly support variability depending on a wide range of dynamic attributes, making it possible to dispatch run-time behaviour on any property of the execution context. The goal of the 5th International Workshop on Context-Oriented Programming (COP’13) is to further establish context orientation as a common thread to language design, application development, and system support. Several researchers are working on Context-Oriented Programming and related ideas, and implementations ranging from prototypes to mature platform extensions used in commercial deployments have illustrated how multi-dimensional dispatch can indeed be supported effectively to achieve expressive run-time behavioural variations. Topics of interest include but are not limited to: - Interesting application domains and scenarios - Programming language abstractions for context-oriented programming (e.g. dynamic scoping, roles, traits, prototype-based extensions) - Theoretical foundations for context-oriented programming (e.g., semantics, type systems) - Configuration languages (e.g. feature description interpreters, transformational approaches) - Interaction between non-functional programming concerns and context-oriented programming (e.g. security, persistence, concurrency, distribution) - Modularization approaches for context-oriented programming (e.g. aspects, modules, layers, plugins) - Guidelines to include context-oriented programming in programs (e.g. best practices, patterns) - Runtime support for context-oriented programming (e.g. reflection, dynamic binding) - Tool support Important dates --------------- * Paper submission: April 19, 2013 * Notification: May 8, 2013 * Final papers due: May 22, 2013 (to be confirmed) * Early registration: May 31, 2013 Submission guidelines --------------------- COP invites submissions of high-quality papers reporting original research, or describing innovative contributions to, or experience with context-oriented programming, its implementation, and application. Papers that depart significantly from established ideas and practices are particularly welcome. Submissions must not have been published previously and must not be under review for any another refereed event or publication. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. It is planned to publish accepted papers in the ACM Digital Library, unless the authors choose not to. In case of publication in the ACM Digital Library, authors must transfer copyright to ACM upon acceptance (for government work, to the extent transferable), but retain various rights (see ACM Copyright Policy. Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Papers should be submitted electronically via EasyChair (URL TBA) in PDF format. Submissions must be written in English (the official language of the workshop) and must not exceed 6 pages. They should use the ACM SIGPLAN 10 point format, templates for which are available at http://www.acm.org/sigs/sigplan/authorInformation.htm Program Committee ----------------- Tomoyuki Aotani, Japan Advanced Institute of Science and Technology, Japan Pascal Costanza, Intel, USA Carl Friedrich Bolz, Heinrich-Heine-Universität Düsseldorf, Germany Sebastián González, UCLouvain, Belgium Atsushi Igarashi (Chair), Kyoto University, Japan David Lorenz, Open University of Israel, Israel Didier Verna, EPITA Research and Development Laboratory (LRDE), France Organising committee -------------------- Malte Appeltauer, SAP Innovation Center, Germany Sebastián González, UCLouvain, Belgium Robert Hirschfeld, Hasso-Plattner-Institut, Germany Atsushi Igarashi, Kyoto University, Japan (primary contact) Hidehiko Masuhara, University of Tokyo, Japan More information ---------------- See the workshop website at http://www.fos.kuis.kyoto-u.ac.jp/COP13/ </pre> https://www.didierverna.net/blog/index.php?post/2013/03/24/COP-13-5th-international-workshop-on-context-oriented-programming#comment-form https://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/113 urn:md5:9a206541113a6dad045fec664543c553 Thursday, June 24 2010 Thursday, June 24 2010 Didier Verna Miscellaneous CCSharpdynamic typingECOOPrant When the C++ guys announced support for lambda expressions in the upcoming version of the standard (assuming there's one), I refrained from blogging on the "better 30 years late than never" melody.<br /><br />Now I got big news for you guys. Today, everybody likes dynamic types. They even dare saying so at ECOOP (which means that ECOOP now accepts those papers, yeah things change).<br /><br />This year, we had a short introduction to an empirical study about the positive (or at least not negative -- one step at a time, this is still ECOOP --) impact of dynamic typing on the development process. And, cherry on the cake, we had this Microsoft guy who presented a paper about... <strong>supporting dynamic types in C#</strong> !!<br /><br />In short, the guy said that he wants to be as fashionable and cool as the people doing all sorts of fancy stuff with their scripting languages (he also said that this was a demand from the C# community).<br /><br />So that's it. A couple years ago, people suddenly realized that functional programming and, in particular, lambda expressions were a good thing. Today, people are also starting to realize that dynamic typing is a good thing.<br /><br />So after having endured 30 years of sarcasm about our dynamic types, it's only fair that we, the dynamic languages community, get to be sarcastic now.<br /> https://www.didierverna.net/blog/index.php?post/2010/06/24/Dynamic-typing-30-years-later#comment-form https://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/17