From: David Flanagan <david@...>
Date: 2007-08-31T15:35:09+09:00
Subject: Pragmas in Ruby 1.9

Hi,

In a previous thread about String.encoding and related changes to 
String, Matz revealed that Ruby 1.9 will parse comments on the first 
line (or second line if there is a shebang on the first line) in order 
to determine the encoding of the source file.

Matz acknowledges that these are pragmas, and promises at least three 
legal syntaxes for specifying an encoding:

> I will
> relax this as Python coding pragma (as in PEP-263).  
> 
>   # -*- coding: <encoding name> -*-
> 
> or
> 
>   # coding=<encoding name>
> 
> or, even
> 
>   # vim: set fileencoding=<encoding name> :
> 

I appreciate the compatibility with Python, emacs and vi.  And I 
understand that the determination of encoding may well be a special case 
in which the parser *must* be able to find an encoding on the first or 
second line.

However, if we're going to call these magic comments pragmas, then 
people will want to be able to define other pragmas in comments. (And 
indeed, a framework for accepting pragmas with names other than "coding" 
is already in place in parse.y.)  This is what has me concerned.  If 
we're going to have a general pragma facility in the language, I suggest 
that it ought to be *part of the language* and not a magic 
comment-processing hack.

So, I have two suggestions:

1) Let's not ever refer to these comment-based encoding directives as 
pragmas.  Note that Python's PEP 263 cited by Matz does not call them 
pragmas either.

2) If we need to introduce more general pragmas, I suggest overloading 
Kernel.require.  It should behave as usual if passed a string.  But it 
can handle pragmas if passed a hash.  Some possible examples (using Ruby 
1.9 hash syntax):

   require encoding: "utf-8"
   require unsafe: "fibers"
   require thread-model: "concurrent"
   require version: 1.9
   require decimal: true
   require strict: true

David