Ruby-dev summary 27393-27541

ruby-talk
1

Hi all,

This is a summary of ruby-dev #27393-27541.

[ruby-dev:27406] Ripper.new("").parse blocks

  Akira Tanaka reported that Ripper.new("").parse blocks. This is because:

   1. Ripper.new checks #gets method for the argument.
   2. rb_respond_to() returns true for private methods.
   3. Ripper.new calls String#gets, which is equivalent to private
      method Kernel#gets.
   4. Kernel#gets reads data from $stdin, it blocks.

  To solve this problem, nobu posted a patch to change rb_respond_to()
  behavior, and the patch is incorporated. Now rb_respond_to() returns
  true only for public methods.

[ruby-dev:27417] selector namespace

  Shugo Maeda proposed a new language feature, "selector namespace".
  Matz also noted this topic in his key note at Ruby Conference 2005.

  Selector namespace is a namespace of selector (method name). This
  function is useful to replace methods temporarily. For example,
  current jcode.rb replaces String#chop itself, which effects globally.
  But with selector namespace, it effects only in "jcode" namespace.

    class String
      def jcode$chop # define #chop method in jcode namespace
        ...
      end
    end

    # "\244\242\244\244" is Japanese characters 'A'+'I' in EUC-JP
    p "\244\242\244\244".chop # "\244\242\244" # wrong result
    p "\244\242\244\244".jcode$chop # "\244\242" # right result

  You can omit namespace specifier ("jcode$") by using "using" syntax:

    class String
      def jcode$chop() ... end
    end

    using jcode
    p "\244\242\244\244".chop # "\244\242" # right result

  There are still many arguments, for example:

    * whether "using" effects statically or dynamically
    * '$' is ugly
    * scope of "using" (file level / module level / method level)
    * whether spaces are allowed around '$'

[ruby-dev:27424] value of BEGIN block

  Nobuyoshi Nakada posted a patch to get a value of BEGIN block, like
  following code:

    val = BEGIN { 2 ** 345 }

  You can utilise this function like `once' method provided by Eiffel
  programming language:

    # p is executed 5000 times but 2**345 is calculated only once
    5000.times do
      p(BEGIN { 2 ** 345 })
    end

  This issue is still open.

[ruby-dev:27449] --without-foo

  Usaku Nakamura posted a patch to add new configure options to select
  compiling extension libraries. For example, you can disable Win32API
  library and io/wait library by following options:

    $ ./configure --without-Win32API --with-io/wait=no

  This patch is incorporated to CVS trunk HEAD.

[ruby-dev:27470] def Foo::Bar.baz

  Shyouhei URABE claimed that "def Foo::Bar.baz" should be valid:

    ~ % ruby -ce 'def Foo::Bar.baz() end'
    -e:1: syntax error, unexpected '.', expecting ';' or '\n'
    def Foo::Bar.baz() end
                 ^
    -e:1: syntax error, unexpected kEND, expecting $end

  Matz rejected this claim because we cannot add this syntax without
  any (yacc's) conflict.

[ruby-dev:27548] ruby 1.8.4 preview 1 released

  Matz released ruby 1.8.4 preview 1.

  ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.4-preview1.tar.gz
  MD5 sum: cfb6e4c53369c016ebb4061c240c493d

-- Minero Aoki
ruby-dev summary index: http://i.loveruby.net/en/ruby-dev-summary.html

2

Selon Minero Aoki <aamine@loveruby.net>:

  There are still many arguments, for example:

    * whether "using" effects statically or dynamically
    * '$' is ugly
    * scope of "using" (file level / module level / method level)
    * whether spaces are allowed around '$'

For the "'$' is ugly" argument, what about a syntax putting the namespace
*after* the method name, and with an '@' in between (i.e. chop@jcode here)? It
fits quite well with the "at" meaning that '@' has taken from things like
e-mail And namespaces are different enough from classes and modules that I
don't see why they should be put in front of method calls like those. And
reading it becomes quite easy and fitting:

class String
  def chop@jcode # "define chop at jcode"
  ...
  end
end

I'd think spaces should be disallowed around the '@' in that case, but it's just
an aesthetic opinion.

Also, how one would access the "namespaced" method using something like send,
without using "using" first? I mean, "send(jcode$:chop)" just looks wrong, and
"send(:jcode$chop)" doesn't look right either. Using my syntax,
"send(:chop@jcode)" is a bit nicer (at least ":chop" stays together without
clashes of symbols), but I'm still not sure I like it myself. Maybe a "send"
with an optional second parameter for the namespace...

By the way, are namespaces in their own namespace? (pardon the repetition)

Anyway, just my two cents about this interesting feature.

[ruby-dev:27470] def Foo::Bar.baz

  Shyouhei URABE claimed that "def Foo::Bar.baz" should be valid:

    ~ % ruby -ce 'def Foo::Bar.baz() end'
    -e:1: syntax error, unexpected '.', expecting ';' or '\n'
    def Foo::Bar.baz() end
                 ^
    -e:1: syntax error, unexpected kEND, expecting $end

  Matz rejected this claim because we cannot add this syntax without
  any (yacc's) conflict.

First the block default arguments, now this... It's indeed time to get rid of
yacc or patch it... Don't look at me! I can't do C :(( ...

···

--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

3

Hi --

···

On Wed, 2 Nov 2005, Minero Aoki wrote:

   class String
     def jcode$chop # define #chop method in jcode namespace
       ...
     end
   end

   # "\244\242\244\244" is Japanese characters 'A'+'I' in EUC-JP
   p "\244\242\244\244".chop # "\244\242\244" # wrong result
   p "\244\242\244\244".jcode$chop # "\244\242" # right result

You can omit namespace specifier ("jcode$") by using "using" syntax:

   class String
     def jcode$chop() ... end
   end

   using jcode
   p "\244\242\244\244".chop # "\244\242" # right result

There are still many arguments, for example:

   * whether "using" effects statically or dynamically
   * '$' is ugly
   * scope of "using" (file level / module level / method level)

How about block level?

   using jcode do
     p "\244\242\244\244".chop
   end

David

--
David A. Black
dblack@wobblini.net

4

i don't see why the above cannot be

   class String
     def jcode::chop
     end
   end

   p "\244\242\244\244".jcode::chop

   using String::jcode (i assume that was what was meant - surely String's
                        jcode is not exported to the top level or we'd have
                        many clashing namespaces!)

'::' is non-ambiguous in all these situations. this syntax also suggests

   class String
     namespace jcode
       def chop
       end
       namespace util
         ...
       end
       namespace const
         ...
       end
     end
   end

in otherwords, namespaces may be declared in a nested way.

now i suppose yacc will be the problem... ;-(

-a

···

On Wed, 2 Nov 2005, Minero Aoki wrote:

[ruby-dev:27417] selector namespace

Shugo Maeda proposed a new language feature, "selector namespace". Matz
also noted this topic in his key note at Ruby Conference 2005.

Selector namespace is a namespace of selector (method name). This function
is useful to replace methods temporarily. For example, current jcode.rb
replaces String#chop itself, which effects globally. But with selector
namespace, it effects only in "jcode" namespace.

   class String
     def jcode$chop # define #chop method in jcode namespace
       ...
     end
   end

   # "\244\242\244\244" is Japanese characters 'A'+'I' in EUC-JP
   p "\244\242\244\244".chop # "\244\242\244" # wrong result
   p "\244\242\244\244".jcode$chop # "\244\242" # right result

You can omit namespace specifier ("jcode$") by using "using" syntax:

   class String
     def jcode$chop() ... end
   end

   using jcode
   p "\244\242\244\244".chop # "\244\242" # right result

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
anything that contradicts experience and logic should be abandoned.
-- h.h. the 14th dalai lama

===============================================================================

5

Minero Aoki wrote:

Hi all,

Hi Aoki-san - Thank you.

[ruby-dev:27417] selector namespace

  Shugo Maeda proposed a new language feature, "selector namespace".
  Matz also noted this topic in his key note at Ruby Conference 2005.

    class String
      def jcode$chop # define #chop method in jcode namespace
        ...
      end
    end

  [...]

  def jcode:>chop

  a = ns:>Foo::Bar.baz

Really easy to type :slight_smile:

    * whether spaces are allowed around [':>']

Follow rules of quad (::slight_smile:

class A; class B; C5 = 5; end; end

#-> 5

#-> C:/TEMP/rb8125.TMP:4: uninitialized constant C5 (NameError)

daz

···

A::b::C5
A::B :: C5

6

Minero Aoki wrote:

Hi all,

This is a summary of ruby-dev #27393-27541.

<snip>

[ruby-dev:27417] selector namespace

  Shugo Maeda proposed a new language feature, "selector namespace".
  Matz also noted this topic in his key note at Ruby Conference 2005.

  Selector namespace is a namespace of selector (method name). This
  function is useful to replace methods temporarily. For example,
  current jcode.rb replaces String#chop itself, which effects globally.
  But with selector namespace, it effects only in "jcode" namespace.

    class String
      def jcode$chop # define #chop method in jcode namespace
        ...
      end
    end

    # "\244\242\244\244" is Japanese characters 'A'+'I' in EUC-JP
    p "\244\242\244\244".chop # "\244\242\244" # wrong result
    p "\244\242\244\244".jcode$chop # "\244\242" # right result

  You can omit namespace specifier ("jcode$") by using "using" syntax:

    class String
      def jcode$chop() ... end
    end

    using jcode
    p "\244\242\244\244".chop # "\244\242" # right result

  There are still many arguments, for example:

    * whether "using" effects statically or dynamically
    * '$' is ugly
    * scope of "using" (file level / module level / method level)
    * whether spaces are allowed around '$'

For those interested, Sydney will accomplish selector namespaces via Behaviors. The exact syntax isn't settled yet, but you can look at http://www.livejournal.com/users/djberg96/50830.html for some ideas (and follow the link at the bottom to see the actual code).

I definitely prefer a block level approach. I think Evan is leaning towards the "object.method using :namespace" syntax.

Regards,

Dan

7

Selon Christophe Grandsire <christophe.grandsire@free.fr>:

class String
  def chop@jcode # "define chop at jcode"
  ...
  end
end

I know it's not nice to reply to one's own mail, but looking at it again I
realised that putting the namespace after the method allows one to use
namespaces for class and singleton methods without syntax problems. On can
simply write:

def obj.method@namespace
...
end

without having to wonder whether the namespace should come before or after the
object name (yes, I know using "class <<obj; def method@namespace ... end; end"
solves the problem also, but it's nicer if the namespace syntax can easily
support *all* existing syntaxes :slight_smile: ).

Now the only problem would be how difficult it would be to parse my proposal...

···

--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

8

Selon "David A. Black" <dblack@wobblini.net>:

How about block level?

   using jcode do
     p "\244\242\244\244".chop
   end

Nice idea. Maybe block level when one gives a block, and module or method level
when one doesn't (not unlike how "private" and "public" behave, depending on
whether they receive a parameter or not).

···

--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

9

Hi,

At Wed, 2 Nov 2005 22:02:05 +0900,
Christophe Grandsire wrote in [ruby-talk:163734]:

I'd think spaces should be disallowed around the '@' in that case, but it's just
an aesthetic opinion.

Not just aesthets. The difference has a big impact to its
implementation.

Also, how one would access the "namespaced" method using something like send,
without using "using" first? I mean, "send(jcode$:chop)" just looks wrong, and
"send(:jcode$chop)" doesn't look right either. Using my syntax,
"send(:chop@jcode)" is a bit nicer (at least ":chop" stays together without
clashes of symbols), but I'm still not sure I like it myself. Maybe a "send"
with an optional second parameter for the namespace...

I thought only second, :jcode$chop. That is, it is just an name.

By the way, are namespaces in their own namespace? (pardon the repetition)

I don't think they can be nested.

···

--
Nobu Nakada

10

HI,

At Wed, 2 Nov 2005 22:17:45 +0900,
David A. Black wrote in [ruby-talk:163736]:

How about block level?

   using jcode do
     p "\244\242\244\244".chop
   end

I had asked Shugo the question in [ruby-dev:27419], and his
answer is that he prefers one-line construct, since he doesn't
like to deepen indent level more.

···

--
Nobu Nakada

11

Quoting Christophe Grandsire <christophe.grandsire@free.fr>:

> Matz rejected this claim because we cannot add this syntax
> without any (yacc's) conflict.

First the block default arguments, now this... It's indeed time
to get rid of yacc or patch it... Don't look at me! I can't do
C :(( ...

Seconded. I really don't think letting yacc dictate the shape of
the language (in ways contrary to human expectation) is a good
thing. Once that starts happening, it urgently needs to go...

It'd be different if we were, say, hitting the limits of what could
be expressed as a context-free grammar, but in this case -- as far
as I know -- we're simply getting bitten by the limits of a
particular LALR(1) parser generator.

Unfortunately, the only authoritative specification I've been able
to find for Ruby's syntax is the YACC grammar. Makes replacing
YACC a bit hard.

If somebody wanted to do that, though, I guess the first few steps
(all doable in pure Ruby) would be something like:

1. write a grammar for Ruby in some neutral format like EBNF

2. write a simple parser generator for this format

3. write a mapping from the raw parse tree to Ruby AST

4. test the grammar against real Ruby ASTs obtained via MetaRuby

(to an extent, these steps can be done incrementally and in
parallel)

Once the neutral grammar's been defined, anyone can take it as a
basis for a real parser in C (or really any language... I imagine
JRuby would find it helpful too -- perhaps the JRuby folks have
already done some of this?), and then lobby for Matz's approval.

But, hopefully there would be ongoing work to keep the neutral
grammar in sync with language developments, so it could also form
the basis of a more comprehensive language specification.

Now, I am relying on the rest of you to tell me what is wrong with
this idea.

-mental

12

Hi --

···

On Thu, 3 Nov 2005, Daniel Berger wrote:

For those interested, Sydney will accomplish selector namespaces via Behaviors.

Not to be confused with my Ruby Behaviors, I guess? :slight_smile:

David

--
David A. Black
dblack@wobblini.net

13

Hi --

Selon "David A. Black" <dblack@wobblini.net>:

How about block level?

   using jcode do
     p "\244\242\244\244".chop
   end

Nice idea. Maybe block level when one gives a block, and module or method level
when one doesn't (not unlike how "private" and "public" behave, depending on
whether they receive a parameter or not).

That's similar to what I did in Ruby Behaviors, but with an "off"
switch for the non-block version:

   # Block
   b.adopt do
     ...
   end

   # No block
   b.adopt
   ...
   b.desist

(where b is a Behavior object)

Of course, Ruby Behaviors had some issues, especially thread safety --
which is what got the discussion going about selector namespaces at
RubyConf 2001 :slight_smile:

David

···

On Wed, 2 Nov 2005, Christophe Grandsire wrote:

--
David A. Black
dblack@wobblini.net

14

then they would not be useful. surely everyone will want to nest a 'util',
'const', or other common name in their classes. if they cannot be nested too
many name classes would occur - something i would expect namespaces to solve.

-a

···

On Wed, 2 Nov 2005, nobuyoshi nakada wrote:

By the way, are namespaces in their own namespace? (pardon the repetition)

I don't think they can be nested.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
anything that contradicts experience and logic should be abandoned.
-- h.h. the 14th dalai lama

===============================================================================

15

but then how to i __stop__ using a namespace?

   using jcode

   ....

   stopusing jcode

??

-a

···

On Wed, 2 Nov 2005, nobuyoshi nakada wrote:

How about block level?

   using jcode do
     p "\244\242\244\244".chop
   end

I had asked Shugo the question in [ruby-dev:27419], and his answer is that
he prefers one-line construct, since he doesn't like to deepen indent level
more.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
anything that contradicts experience and logic should be abandoned.
-- h.h. the 14th dalai lama

===============================================================================

16

Selon nobuyoshi nakada <nobuyoshi.nakada@ge.com>:

I thought only second, :jcode$chop. That is, it is just an name.

It still looks strange to me. I'd really rather have namespaces after rather
than before the method name. Especially if using '@' (pronounced 'at') as I
did. It just feels easier to read (especially since you still keep the object
and its method next to each other, with just a period in between, unlike the
current syntax which puts a possibly arbitrary name between the object and the
method it receives). In other words, I find:

string.chop@namespace(args)

easier to read than:

string.namespace$chop(args)

Strangely enough I don't have that much problems putting the namespace between
the method name and its arguments :slight_smile: .

> By the way, are namespaces in their own namespace? (pardon the repetition)

I don't think they can be nested.

I wasn't clear, sorry (the attraction of the pun was just too much for me to
resist :confused: ). I meant to ask whether namespace names would be clashing with
method names (or variable names?) or if they were completely separate (and thus
would allow me to give to a namespace the same name as an existing method for
instance). Also, can one start a namespace name with a capital letter?

···

--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

17

mental@rydia.net wrote:

Quoting Christophe Grandsire <christophe.grandsire@free.fr>:

Matz rejected this claim because we cannot add this syntax
without any (yacc's) conflict.

First the block default arguments, now this... It's indeed time
to get rid of yacc or patch it... Don't look at me! I can't do
C :(( ...

Seconded. I really don't think letting yacc dictate the shape of
the language (in ways contrary to human expectation) is a good
thing. Once that starts happening, it urgently needs to go...

It'd be different if we were, say, hitting the limits of what could
be expressed as a context-free grammar, but in this case -- as far
as I know -- we're simply getting bitten by the limits of a
particular LALR(1) parser generator.

Unfortunately, the only authoritative specification I've been able
to find for Ruby's syntax is the YACC grammar. Makes replacing
YACC a bit hard.

If somebody wanted to do that, though, I guess the first few steps
(all doable in pure Ruby) would be something like:

1. write a grammar for Ruby in some neutral format like EBNF

2. write a simple parser generator for this format

3. write a mapping from the raw parse tree to Ruby AST

4. test the grammar against real Ruby ASTs obtained via MetaRuby

(to an extent, these steps can be done incrementally and in
parallel)

Once the neutral grammar's been defined, anyone can take it as a
basis for a real parser in C (or really any language... I imagine
JRuby would find it helpful too -- perhaps the JRuby folks have
already done some of this?), and then lobby for Matz's approval.

But, hopefully there would be ongoing work to keep the neutral
grammar in sync with language developments, so it could also form
the basis of a more comprehensive language specification.

Now, I am relying on the rest of you to tell me what is wrong with
this idea.

-mental

Best. Idea. Ever.

Cheers,
Daniel

18

Yes, but there may be cases where one has a number of operations that
one needs to make with a selector namespace. I think that the *option*
for "using jcode do...end" is a good thing.

···

On 11/2/05, nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:

HI,

At Wed, 2 Nov 2005 22:17:45 +0900,
David A. Black wrote in [ruby-talk:163736]:
> How about block level?
>
> using jcode do
> p "\244\242\244\244".chop
> end

I had asked Shugo the question in [ruby-dev:27419], and his
answer is that he prefers one-line construct, since he doesn't
like to deepen indent level more.

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

19

mental@rydia.net writes:

Quoting Christophe Grandsire <christophe.grandsire@free.fr>:

> Matz rejected this claim because we cannot add this syntax
> without any (yacc's) conflict.

First the block default arguments, now this... It's indeed time
to get rid of yacc or patch it... Don't look at me! I can't do
C :(( ...

Seconded. I really don't think letting yacc dictate the shape of
the language (in ways contrary to human expectation) is a good
thing. Once that starts happening, it urgently needs to go...

Full ack.

It'd be different if we were, say, hitting the limits of what could
be expressed as a context-free grammar, but in this case -- as far
as I know -- we're simply getting bitten by the limits of a
particular LALR(1) parser generator.

Unfortunately, the only authoritative specification I've been able
to find for Ruby's syntax is the YACC grammar. Makes replacing
YACC a bit hard.

If somebody wanted to do that, though, I guess the first few steps
(all doable in pure Ruby) would be something like:

1. write a grammar for Ruby in some neutral format like EBNF

2. write a simple parser generator for this format

3. write a mapping from the raw parse tree to Ruby AST

4. test the grammar against real Ruby ASTs obtained via MetaRuby

(to an extent, these steps can be done incrementally and in
parallel)

Once the neutral grammar's been defined, anyone can take it as a
basis for a real parser in C (or really any language... I imagine
JRuby would find it helpful too -- perhaps the JRuby folks have
already done some of this?), and then lobby for Matz's approval.

But, hopefully there would be ongoing work to keep the neutral
grammar in sync with language developments, so it could also form
the basis of a more comprehensive language specification.

Now, I am relying on the rest of you to tell me what is wrong with
this idea.

I don't think the real problem is the real grammar, that part of
parse.y looks like the easier one (and rather readable) to me. The
problem is the lexer-parser communication, think heredocs, %q etc.
There is no way to express that in BNF.

···

-mental

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

20

How about block level?

   using jcode do
     p "\244\242\244\244".chop
   end

I had asked Shugo the question in [ruby-dev:27419], and his
answer is that he prefers one-line construct, since he doesn't
like to deepen indent level more.

p "\244\242\244\244".chop using jcode

+--- Kero ------------------------- kero@chello@nl ---+

all the meaningless and empty words I spoke |
                      Promises -- The Cranberries |

+--- M38c --- http://members.chello.nl/k.vangelder ---+