ruby-dev summary 27393-27541

[Minero Aoki]

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

[Christophe Grandsire]

Selon Minero Aoki <aam...@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.

[Christophe Grandsire]

Selon Christophe Grandsire <christophe...@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 :) ).

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

[David A. Black]

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
dbl...@wobblini.net

[Christophe Grandsire]

Selon "David A. Black" <dbl...@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).

[nobuyoshi nakada]

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

[nobuyoshi nakada]

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

[Ara.T.Howard]

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

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
--
===============================================================================
| 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
===============================================================================

[David A. Black]

Hi --

On Wed, 2 Nov 2005, Christophe Grandsire wrote:

> Selon "David A. Black" <dbl...@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 :-)

[Ara.T.Howard]

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.

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.

[Ara.T.Howard]

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.

but then how to i __stop__ using a namespace?

using jcode

....

stopusing jcode

??

[David A. Black]

Hi --

On Wed, 2 Nov 2005, Ara.T.Howard wrote:

> 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.
>
> but then how to i __stop__ using a namespace?
>
> using jcode
>
> ....
>
> stopusing jcode

See my previous post, with an example from Ruby Behaviors.

[Christophe Grandsire]

Selon nobuyoshi nakada <nobuyosh...@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 :) .

> > 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 :/ ). 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?

[daz]

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

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

Follow rules of quad (::)

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

A::B::C5
#-> 5

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

daz

[Christophe Grandsire]

Selon "Ara.T.Howard" <Ara.T....@noaa.gov>:

>
> but then how to i __stop__ using a namespace?
>
> using jcode
>
> ....
>
> stopusing jcode
>

putting_away jcode

;)

Seriously, it's a good question. One-liner constructs may be nice in some cases,
but there's a reason why a construction like File.open { |file| ... } is so
great: people just *forget* to close things when they don't use them anymore.
And frankly, there's nothing wrong with adding a level of indentation,
especially when one is dealing with *namespaces*, which are just a different
kind of named scope.

[Ara.T.Howard]

On Wed, 2 Nov 2005, David A. Black wrote:

> See my previous post, with an example from Ruby Behaviors.

sure. but afaikt there is no jcode __object__ in the initial post to call
methods on.

surely the bare token 'jcode' cannot be it, otherwise

using jcode

jcode = 42

would have disaterous effects. hopefully it would, in fact, be

String::jcode

so we might also have

Iconv::jcode

and, if this 'jcode' thing is an object why not create it directly with

namespace jcode
...
end

rather than implicitly using

def jcode::method
end

i'm unclear how this whole construct is more useful that using modules as
namespaces, which can be nested and manipulated like all other module/classes.

cheers.

[David A. Black]

Hi --

On Wed, 2 Nov 2005, Ara.T.Howard wrote:

> On Wed, 2 Nov 2005, David A. Black wrote:
>
>> See my previous post, with an example from Ruby Behaviors.
>
> sure. but afaikt there is no jcode __object__ in the initial post to call
> methods on.
>
> surely the bare token 'jcode' cannot be it, otherwise
>
> using jcode
>
> jcode = 42
>
> would have disaterous effects. hopefully it would, in fact, be

I guess part of my problem here is that I think "using" is the wrong
word, unless it's before a block. Otherwise it feels like it's just
dangling:

Using this namespace, ....

as opposed to:

Use this namespace!

or

Select this namespace!

But generally, I think having both a block and a non-block way to do
it, rather than just one or the other, makes the most sense.

[Ara.T.Howard]

On Wed, 2 Nov 2005, David A. Black wrote:

> But generally, I think having both a block and a non-block way to do
> it, rather than just one or the other, makes the most sense.

completely agree.

[men...@rydia.net]

Quoting Christophe Grandsire <christophe...@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

[Daniel Berger]

Minero Aoki wrote:
> Hi all,
>
> This is a summary of ruby-dev #27393-27541.

<snip>

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

[Daniel Schierbeck]

Best. Idea. Ever.

Cheers,
Daniel

[Trans]

I agree with Ara. What's being presented here looks like it may be s
simple name "hack", i.e.

define_method( "jcode$chop" ) { ... }

'using' just auto prefixes all method calls. This isn't true namespace
selectors, is it?

What we need is as Ara suggests and my expiremention confirms, are
module/module-like constructs.

class String

namespace JCode ; end

def JCode.chop
...
end

end

In fact modules themselves can be used here with the concept of
self-shimmying, which has been disccussed a good deal on suby mailing
list. (I'll resue $ here for demonstration purposes):

class X

module M
def x
self
end
end

def show_em_how_you_shimmy
M$x
end

end

X.new.show_em_how_you_shimmy #=> #<X ...>

Which is the simplified essence of namespace selector.

T.

[David A. Black]

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? :-)

[Austin Ziegler]

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.
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca

[Ryan Leavengood]

On 11/2/05, Daniel Schierbeck <daniel.s...@gmail.com> wrote:
>
> Best. Idea. Ever.

I tend to agree, but this begs the question: since this idea is fairly
obvious, and YACC has probably presented problems for quite some time,
why hasn't this been done earlier?

In other words, have other people before hit brick walls when doing
this, and stopped, or is this just a matter of no one making a real
effort in the past?

For what it's worth, the thought of writing a EBNF grammer for Ruby
gives me shivers, but I've never been a big BNF or parser person.

Ryan

[Bill Kelly]

From: "Ara.T.Howard" <Ara.T....@noaa.gov>

>
> i'm unclear how this whole construct is more useful that using modules as
> namespaces, which can be nested and manipulated like all other module/classes.

There's only one reason I've been eagerly awaiting selector namespaces,
and it was that I thought it meant we would be able to, in our own
modules (or namespaces) be able to redefine core methods, and have
these changes be in effect only within our own namespace.

I was imagining something like:

namespace foo
require 'mathn' # without changing mathn source
p 5/9 # => 5/9
end

p 5/9 # => 0

I.e. by defining and working in a namespace, you'd be insulating
the rest of Ruby from changes made within that namespace,
particularly overriding core class' methods.

I guess with the proposed scheme, it would be,

require 'mathn' # presuming mathn changed to use namespaces

using mathn

p 5/9 # => 5/9

stopusing mathn

p 5/9 # => 0

???

Is it true that with the proposed approach, the source code of
mathn would have to be changed to make it define its methods
explicitly within a namespace? Is there no way to 'require'
a module into a namespace without having to change the module's
source code?

Regards,

Bill

[Mauricio Fernández]

On Wed, Nov 02, 2005 at 10:52:57PM +0900, David A. Black wrote:
> 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 :-)

Wasn't Ruby Behaviors dynamically scoped though?
It seems Ruby's selector namespaces are more likely to be static.

--
Mauricio Fernandez

[Tanner Burson]

I think your last comment sums up most people. There are very few people
willing to do the mass amount of work that translating the Ruby grammer
would take. And to make it worse of those willing thare are probably far
fewer with the time and/or skill. While I sincerely hope someone takes it
upon themself to do this, I don't hold out a lot of hope for anything to be
done soon simply because of the scale of what's required.

Ryan
>
>

--
===Tanner Burson===
tanner...@gmail.com
http://tannerburson.com <---Might even work one day...

[Mauricio Fernández]

On Thu, Nov 03, 2005 at 01:32:47AM +0900, Austin Ziegler 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.
>
> 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.

IIRC from the original thread (around [ruby-dev:27421]), a
using jcode
expression would activate the namespace until the end of some "syntactical
feature" (such as the end of the current method/class).

--
Mauricio Fernandez

[Dale Martenson]

---- Original message from Bill Kelly on 11/2/2005 11:23 AM:

I thought there would be specific uses:

1. Global namespace change to allow for transistion from one namespace
to another.

Example: (please note my alternative syntax)

require 'mathn'
namespace mathn, :begin

p 5/9 # => 5/9

namespace mathn, :end

p 5/9 # => 0

or

require 'mathn'
namespace mathn do

p 5/9 # => 5/9
end
p 5/9 # => 0

2. A notational convenience for class/module definition.

class Bubba
using home_security
def nickel_plated_45
end
end

Pardon my syntax. Just try out some different flavors.

[David A. Black]

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

[Mauricio Fernández]

On Thu, Nov 03, 2005 at 04:23:50AM +0900, David A. Black wrote:
> >>Of course, Ruby Behaviors had some issues, especially thread safety --
> >>which is what got the discussion going about selector namespaces at
> >>RubyConf 2001 :-)
> >
> >Wasn't Ruby Behaviors dynamically scoped though?
> >It seems Ruby's selector namespaces are more likely to be static.
>

> That was one of the things on the list of unresolved questions in the
> summary.

Yes, that's why I only said it seemed more likely, based on the original
discussion and matz's reference to JavaScript's namespaces, see
http://www.mozilla.org/js/language/js20/core/namespaces.html

> I'm actually not entirely clear on what static would mean in this context.

Lexically scoped.

--
Mauricio Fernandez

[Ara.T.Howard]

On Thu, 3 Nov 2005, Bill Kelly wrote:

> Is there no way to 'require' a module into a namespace without having to
> change the module's source code?

something like this?

http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/f071a389410e3aa4/b39d5538b0f5218f?q=howard+trans+module&rnum=5#b39d5538b0f5218f

[Bill Kelly]

From: "Ara.T.Howard" <Ara.T....@noaa.gov>

>
> On Thu, 3 Nov 2005, Bill Kelly wrote:
>
>> Is there no way to 'require' a module into a namespace without having to
>> change the module's source code?
>
> something like this?
>
> http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/f071a389410e3aa4/b39d5538b0f5218f?q=howard+trans+module

Neat; but what I'm looking for may be just unreasonable. When I
require 'mathn', it does:

class Fixnum
alias / quo
end

class Bignum
alias / quo
end

I wanted to wrap that require in a namespace, so that its changes
to core classes would be isolated to that namespace.

. . But I don't mean to belabor the point - as it seems that
namespaces aren't going to "wrap" definitions automatically...

Regards,

Bill

[Trans]

> I wanted to wrap that require in a namespace, so that its changes
> to core classes would be isolated to that namespace.

The should be able to do this.

T.

[Kev Jackson]

>
> I guess part of my problem here is that I think "using" is the wrong
> word, unless it's before a block. Otherwise it feels like it's just
> dangling:
>
> Using this namespace, ....
>

Isn't using the keyword from C# for declaring namespaces? Similar to
package com.myco.module.whatever that Java uses.

> as opposed to:
>
> Use this namespace!
>
> or
>
> Select this namespace!
>
> But generally, I think having both a block and a non-block way to do
> it, rather than just one or the other, makes the most sense.

Looking at the options so far, I really like

using jcode
str.chop
end

To me it looks much more ruby than

using jcode

..
..

..

str.chop

Kev

[Kev Jackson]

>
>I think your last comment sums up most people. There are very few people
>willing to do the mass amount of work that translating the Ruby grammer
>would take. And to make it worse of those willing thare are probably far
>fewer with the time and/or skill. While I sincerely hope someone takes it
>upon themself to do this, I don't hold out a lot of hope for anything to be
>done soon simply because of the scale of what's required.
>
>Ryan
>
>

RubyQuiz idea, translate the grammar for a portion of Ruby (I don't
know, somthing like class methods etc avoid eval and blocks forr now)
and write a simple parser that will take a ruby class and output EBNF for it

Thoughts

Kev

[Christian Neukirchen]

Austin Ziegler <halos...@gmail.com> writes:

> On 11/2/05, nobuyoshi nakada <nobuyosh...@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.
>
> 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.

Unrelated, but that option would be really nice for "private" and
"protected" too...

> Austin Ziegler * halos...@gmail.com
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org

[Christian Neukirchen]

men...@rydia.net writes:

> Quoting Christophe Grandsire <christophe...@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

[nobu....@softhome.net]

Hi,

At Thu, 3 Nov 2005 22:13:46 +0900,
Christian Neukirchen wrote in [ruby-talk:163903]:

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

Exactly. It's a headache.

--
Nobu Nakada

[Eric Mahurin]

Too much inheritance from perl :( heredocs are the worst of all.

Since I'm writing a ruby lexer and parser in my Grammar package I've really
been diving into the details. I'm trying to match the
lex_state/space_seen/etc way of doing things (from parse.y), but if I were
to start from a scratch, I possibly would make a lexer-free parser (no
tokens - parser deals directly with characters). Of course there would be a
performance hit (parser has to lookahead more), but you wouldn't have to
deal with the parser-driven lexer state stuff.

I would love to see the ruby syntax refactored and simplified - especially
with regards to the lexer state. The first thing would be to get rid of
heredocs or only allow whitespace/comments on the line after the initial <<
keyword. Secondly, I think it might be possible to reduce the lexer state to
one bit - whether the next operator is unary or binary. For example - %:
string vs. modulus, <<: heredoc vs. leftshift, `: execution quote vs. method
name. I may look at some of this simplification later.

[MenTaLguY]

On Thu, 2005-11-03 at 22:13 +0900, Christian Neukirchen wrote:
> 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.

Well, you could, it would just be prohibitively verbose (well,
infinitely long, if you don't place a limit on the number of characters
in heredoc tags -- the special quote syntax by itself isn't so bad).

However, I think we're still in the world of context-free grammars here
-- heredoc/quote processing can still be handled by a pushdown
automaton. So it should be describable by a simple EBNF extension.

Notionally, there would be a stack of "quote terminator" tokens, magic
tokens like e.g. magic QUOTE_START and HEREDOC_START tokens which, if
successfully matched, push the associated closing token onto the stack,
and a QUOTE_END token which matches the closing token on the top of the
stack and pops it if matched.

Any other icky features of the grammar this wouldn't cover?

-mental

[MenTaLguY]

On Fri, 2005-11-04 at 00:07 +0900, Eric Mahurin wrote:
> Secondly, I think it might be possible to reduce the lexer state to
> one bit - whether the next operator is unary or binary. For example - %:
> string vs. modulus, <<: heredoc vs. leftshift, `: execution quote vs. method
> name. I may look at some of this simplification later.

If you can reduce it that far, you don't need lexer state, just
sufficient lookahead.

-mental

[Christian Neukirchen]

MenTaLguY <men...@rydia.net> writes:

In this case, it may make sense not to use EBNF but some kind of
parser combinator?

(E.g. see http://chneukirchen.org/blog/archive/2005/10/the-rightyear-parsing-library.html )

This just would be needed to make language-independent enough to be
useful to all parties.

> Any other icky features of the grammar this wouldn't cover?
>
> -mental

[Caleb Clausen]

On 11/3/05, Christian Neukirchen <chneuk...@gmail.com> wrote:
> 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.

This is true, but it shouldn't be an obstacle to doing a parser. There
is a ruby lexer which handles these issues and all other lexer-parser
communication issues internally, and returns you a nice clean stream
of tokens without any particular help from a parser: it's my own
project, RubyLexer.

It looks to me like it ought to be pretty easy to write a racc-based
ruby parser using RubyLexer's output. If someone wants to do the racc
parts of this, it would be great; but I can't do it myself as I'm
allergic to yacc and related tools... It should be a straightforward
port from the current yacc grammar.

[daz]

Eric Mahurin wrote:

> On 11/3/05, nobu wrote:
> > Christian Neukirchen wrote in [ruby-talk:163903]:
> >
> > > 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.
> >
> > Exactly. It's a headache.
> >
>
>

> I would love to see the ruby syntax refactored and simplified -
> especially with regards to the lexer state.

A-m-e-n.

Selection from thread:
[Context sensitive scanner ?] - comp.compilers (1997)

(1997-11-23) - Mikael Pettersson
http://compilers.iecc.com/comparch/article/97-11-127

"Transformation scanner" [!]

(1997-11-24) - Scott Stanchfield
http://compilers.iecc.com/comparch/article/97-11-141

(1997-11-28) - Chris F Clark
http://compilers.iecc.com/comparch/article/97-11-150

"Unfortunately, most parsing systems don't encourage
thinking about parsing as sequences of transformations.
Instead they promote the view of one lexer and one parser."

(1997-11-28) - Henry Spencer
http://compilers.iecc.com/comparch/article/97-11-151

"... the screener ..."

(( http://compilers.iecc.com/comparch/article/97-11-167 ))

Note: In the next post, Chris mentions "Scannerless Parsing".
I read a lot of papers on this subject and there was always
a feeling that this wouldn't be suitable for a transitional
solution for Ruby. [IMHO]

(1997-12-05) - Chris Clark USG
http://compilers.iecc.com/comparch/article/97-12-016

"The point has been clearly made that feedback from the
parser to the lexer (using lexer states controlled from
the parser) is not a good idea when avoidable."

"However, at the same time using (manually controlled)
state in a lexer to control which tokens are returned
should also be avoided when possible."

(( http://compilers.iecc.com/comparch/article/97-12-043 ))

I hope someone might be inspired.

daz

[Eric Mahurin]

On 11/4/05, daz <do...@d10.karoo.co.uk> wrote:
>
> (1997-11-28) - Chris F Clark
> http://compilers.iecc.com/comparch/article/97-11-150
>
> "Unfortunately, most parsing systems don't encourage
> thinking about parsing as sequences of transformations.
> Instead they promote the view of one lexer and one parser."

BTW, in my grammar project, I do think of parsing as sequences of
transformations. A lexer simply transforms a sequence of characters to a
token sequence. A parser transforms a sequence of tokens to an AST (or
whatever) sequence. With my system, you could easily make a lexer-free
parser (parse directly from characters) or go the other way and add more
transformation stages (i.e. a preprocessor). For example, I made a TCL
interpreter that required no lexer (the simplicity and no keywords helps a
lot). Or on the other extreme, you could envision a C compiler built with a
series of transformations: preprocess -> tokenize -> parse -> optimize ->
assembly -> machine code. My Grammar classes don't care what type of input
and output they make - an extreme unification of lexing, parsing, AST
parsing, etc.

[Kero]

>> 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 ---+

[Christophe Grandsire]

Selon Kero :

>>>How about block level?
>>>
>>> using jcode do
>>> p "\244\242\244\244".chop
>>> end
>>
>

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

Nice one. But then I'd rather have my proposal of putting the namespace
after the method name adopted and just write:

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

I know: "boohoo! syntax!" But it's a syntax that's rather natural
considering the omnipresence of e-mail addresses nowadays, and it's not
as if Ruby doesn't use @ already, nor ever uses one symbol for two
different (but unambiguous) roles.
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.

[daz]

Kero 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.
>
> p "\244\242\244\244".chop using jcode
>

But then how to express (as proposed):

p "\244\242\244\244".jcode$chop.kcode$change

Gets silly ?

p "\244\242\244\244".(chop using jcode).(change using kcode)
p "\244\242\244\244".chop.change using jcode, kcode # ??

Same problems with block level - identifies only one namespace
and no specific connection to any/all referenced methods within
that block.

I guess ruby-dev will have been through this process.

Check responses against this contrivance :-/

p "\244\242\244\244".jcode$chop.kcode$chop

Sometimes, a new language feature can be helped by new syntax.
When all single chr syntax has been used, two chrs are suggested.
One 2-chr combo is often as silly as the next.
'using' is a 5-chr combo ...
'each_with_index' is a ... hang on ... anyway, they're readable
and have no 'sharp & pointy' arrows.

I'm so sorry, I seem to have 'gone off on one'.

daz

[Dave Burt]

Christophe Grandsire wrote:
> p "\244\242\244\244".chop@jcode
>
> I know: "boohoo! syntax!" But it's a syntax that's rather natural
> considering the omnipresence of e-mail addresses nowadays, and it's not as
> if Ruby doesn't use @ already, nor ever uses one symbol for two different
> (but unambiguous) roles.

It's too close to:
p "\244\242\244\244".chop @jcode

That's an ArgumentError, but it would be a valid call to chomp, for
instance.

FWIW, I think I like the block-style idea, but rescue-ish is good, too.

def foo # or any block-starting thing
# global namespace
using my_namespace
# specific namespace
end
# global namespace again

and you could also allow a trailing using to apply the namespace to the
whole expression:

"foo".reverse.capitalize using my_wacky_string_namespace

Cheers,
Dave

[Trans]

In the past I always thought of ':' (boy that comes up a lot ;-)

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

But I'm wondering if two colons could work,

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

because a namespace is much like a module. Also maybe

p "\244\242\244\244".(jcode)chop

By the way Facets can already do some stuff like this via:

module JCode
def chop
...
end
end

class String
include JCode
end

"\244\242\244\244".as(JCode).chop

Yep. If you guessed Functor, you are right.

T.

[Eero Saynatkari]

Trans wrote:
> In the past I always thought of ':' (boy that comes up a lot ;-)
>
> p "\244\242\244\244".jcode:chop

Yes, this is usually the syntax I prefer to illustrate selector namespaces.
They would also (visually) benefit from being constants (i.e. uppercase
rather than lowercase).

However, it seems that the name 'selector namespace' is a bit inaccurate
for the current implementation as it concentrates much more on the 'namespace'
than the 'selector' which is unfortunate. I would much rather see this:

module NS
def foo
puts 'NS' + @foo
end
end

class Foo
def initialize
@foo = 'foo'
end

def foo
puts 'Foo' + @foo
end
end

f = Foo.new
puts f.foo # Foofoo
puts f.NS:foo # NSfoo

Here there is no concrete namespace but rather a namespace is dynamically
created to facilitate selecting the implementation. Again, this is perhaps more
AOP-like than some would prefer and perhaps this is missing some benefits of
the other approach.

E.face[:cheek] = :tongue

p "\244\242\244\244".JCode-chop

p "\244\242\244\244".chop~JCode

p "\244\242\244\244".jcode->chop

p "\244\242\244\244".JCode#chop

> But I'm wondering if two colons could work,
>
> p "\244\242\244\244".jcode::chop
>
> because a namespace is much like a module. Also maybe
>
> p "\244\242\244\244".(jcode)chop
>
> By the way Facets can already do some stuff like this via:
>
> module JCode
> def chop
> ...
> end
> end
>
> class String
> include JCode
> end
>
> "\244\242\244\244".as(JCode).chop
>
> Yep. If you guessed Functor, you are right.
>
> T.

E

[Kero]

>> >> 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
>
> But then how to express (as proposed):
>
> p "\244\242\244\244".jcode$chop.kcode$change
>
> Gets silly ?

A bit silly, yes

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

Works as long as there is no conflict. The problem of conflicting
namespaces was mentioned in this thread; I ask, do we care?

class X
include A
include B
end

may conflict as well, but we accept that methods from B override methods
from A (in the same way jcode would override kcode in my example above).

If there is such a conflict, you would/should/could do

chopped = "\244\242\244\244".chop using jcode
p chopped.change using kcode

.

obj.xtract.manipulate.serialize using FunnyNamespace

if you need three namespaces here, did you do a proper design job?
(the answer can be Yes, but I suppose it's mostly No; if it is Yes, I
certainly hope the namespaces have different purposes)

The same story (both overriding and the amount of namespaces needed)
holds for

begin
using OneNamespace
using LogElsewhere
using AnotherNamespace {
...code...
}
end

whether using is in block style or not.

Bye,
Kero.

[Kero]

> It's too close to:
> p "\244\242\244\244".chop @jcode
>
> That's an ArgumentError, but it would be a valid call to chomp, for
> instance.

holds as well for

jcode $chop
jcode :chop
chop :jcode

and probably some other ideas in this thread.

I recall someone asking whther namespaces would be 'different' from
methods, i.e. if there is also a *method* jcode in the example above,
the space is really wreaking havoc.

Bye,
Kero.

[Christian Neukirchen]

Kero <ke...@chello.single-dot.nl> writes:

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

Now, what is the advantage over doing

p "\244\242\244\244".jchop

? I thought the purpose of namespaces was to allow for the methods to
be redefined transparently, without mentioning the namespace all
over...

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

[Christophe Grandsire]

Selon Kero :

>>It's too close to:
>>p "\244\242\244\244".chop @jcode
>>
>>That's an ArgumentError, but it would be a valid call to chomp, for
>>instance.
>
>
> holds as well for
>
> jcode $chop
> jcode :chop
> chop :jcode
>
> and probably some other ideas in this thread.
>

Exactly. I wanted to reply that but you beat me to it :) . If matz and
others find it good enough to implement jcode$chop, alternatives should
be as good enough :) .

> I recall someone asking whther namespaces would be 'different' from
> methods, i.e. if there is also a *method* jcode in the example above,
> the space is really wreaking havoc.
>

That was me again :) . I had also already thought of that problem, which
is why I said that there shouldn't be any space allowed between the
method and the namespace using such a syntax. Namespaces, when used
directly with a method, should indeed be considered *part* of the name
of that method. And since we don't have methods which allow a space in
their name (short maybe of using exotic method definitions with
define_method, and even then I don't know if it's possible), I don't
think we should allow it if we add namespaces to them.

I agree on the other hand that the "using" suffix idea solves the
problem neatly, except that it breaks havoc with method chaining.

Anyway, it's not as if Ruby's philosophy is "there's only one way to do
it" ;) . I don't see why we couldn't have a $, :, @ or whatever syntax
*and* a "using" suffix (or prefix?), although with the "using", to
prevent unsolvable issues about how two "using"s might work with each
other in case of method chaining, we would restrict to 1 "using". If you
need to chain methods from different namespaces, use the $, @, : or
whatever syntax.

On the subject of "using", what should happen if we call a method in the
scope of a "using" (whether it is "using namespace", "using namespace
{...}, or "obj.method using namespace") that is *not* redefined in that
namespace. Should we get an error, a warning, or should the original
method from that object simply be called without any warning. I'm
personally leaning toward a warning, and let the original method of the
object be used. Maybe the warning should be there only in verbose
output... I'm curious what others think about that.

[Michel Martens]

class String
scope :japanese do

def chop
...
end
end

end

"Tsumego".scope(:japanese).chop

scope :japanese do
"Tsumego".chop
end

[gabriele renzi]

Christian Neukirchen ha scritto:

>>p "\244\242\244\244".chop using jcode
>
>
> Now, what is the advantage over doing
>
> p "\244\242\244\244".jchop
>
> ? I thought the purpose of namespaces was to allow for the methods to
> be redefined transparently, without mentioning the namespace all
> over...
>

this is exactly the same thing that I was thinking.
I think we need some more use cases before we keep on talking about this
bicycle shed :)

[Trans]

> this is exactly the same thing that I was thinking.
> I think we need some more use cases before we keep on talking about this
> bicycle shed :)

He he. Seems like no one read my first post to this thread. I don;t
think they are doing anything different from this except providing a
way to wrap then into a "using case". Hence this is nothing more then

define_method( 'jcode$chop' ) do
...
end

And then #using prefixes subsequent method calls.

While it is nice in it simplicity, I do not beleive it constitues a
complete namespace selector solution.

T.

[gabriele renzi]

Trans ha scritto:

>>this is exactly the same thing that I was thinking.
>>I think we need some more use cases before we keep on talking about this
>>bicycle shed :)
>
>
> He he. Seems like no one read my first post to this thread.

Actually, I did not, it did not appear in my newsreader :/

> I don;t
> think they are doing anything different from this except providing a
> way to wrap then into a "using case". Hence this is nothing more then
>
> define_method( 'jcode$chop' ) do
> ...
> end
>
> And then #using prefixes subsequent method calls.
>
> While it is nice in it simplicity, I do not beleive it constitues a
> complete namespace selector solution.
>

I think I agree