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
Tag - ECOOP - Didier Verna's Scientific Blog
About Lectures Research Software Blog
Musical Site
MySpace
Facebook

Moods Blog

Dojo Shin Kaï

RSS Feed
Thank you!

XHTML 1.0 conformant
CSS 2.0 conformant
Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff.

Tag - ECOOP

Entries feed - Comments feed

Wednesday, August 5 2015

The Return of Segfaults

I was watching the discussion between Gilad Bracha and Matthias Felleisen on gradual typing this afternoon (it's available on YouTube). 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".

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".

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:

  1. 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, (defun plus (a b) (+ a b)) works on every possible numerical value, but add (declare (type fixnum a b)) in there and it will suddenly stop working on anything else but integers. It's only if you require the compiler to optimize for speed at the expense of safety that you effectively weaken your type system.
  2. 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.).

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 (declaim (optimize (speed 3) (safety 0) (debug 0)) (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 ?

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.

Sunday, March 24 2013

COP'13 - 5th international workshop on context-oriented programming

			   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/ 

Thursday, June 24 2010

Dynamic typing 30 years later

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.

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).

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... supporting dynamic types in C# !!

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).

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.

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.
French Flag English Flag
Copyright (C) 2008 -- 2018 Didier Verna didier@lrde.epita.fr