Ruby-dev summary 27393-27541

ruby-talk
41

Hi --

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.

David

···

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

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

--
David A. Black
dblack@wobblini.net

42

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.

43

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

···

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

44

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

···

On Thu, Nov 03, 2005 at 04:23:50AM +0900, David A. Black wrote:

--
Mauricio Fernandez

45

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

46

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

-mental

···

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.

47

Eric Mahurin 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
  Comp.compilers: Re: Context sensitive scanner ?

    "Transformation scanner" [!]

  (1997-11-24) - Scott Stanchfield
  Comp.compilers: Re: Context sensitive scanner ?

  (1997-11-28) - Chris F Clark
  Comp.compilers: Re: Context sensitive scanner ?

   "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
  Comp.compilers: Re: Context sensitive scanner ?

   "... the screener ..."

  (( Comp.compilers: Re: Context sensitive scanner ? ))

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
  Comp.compilers: Re: Context sensitive scanner ?

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

  (( Comp.compilers: Re: Context sensitive scanner ? ))

I hope someone might be inspired.

daz

···

On 11/3/05, nobu wrote:

48

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

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.

49

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.

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

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

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

50

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

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.

51

completely agree.

-a

···

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.

--

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

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

52

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

From: "Ara.T.Howard" <Ara.T.Howard@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?

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.

53

something like this?

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

-a

···

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?

--

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

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

54

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

55

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.

···

On 11/4/05, daz <dooby@d10.karoo.co.uk> wrote:

(1997-11-28) - Chris F Clark
Comp.compilers: Re: Context sensitive scanner ?

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

56

Trans wrote:

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

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

57

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 :slight_smile: . If matz and others find it good enough to implement jcode$chop, alternatives should be as good enough :slight_smile: .

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 :slight_smile: . 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" :wink: . 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.

···

--
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.

58

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

He he. Seems like no one read my first post to this thread.

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

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

59

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

···

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

On Thu, 3 Nov 2005, Bill Kelly wrote:

60

class String
  scope :japanese do
    def chop
      ...
    end
  end
end

"Tsumego".scope(:japanese).chop

scope :japanese do
  "Tsumego".chop
end