Ruby-dev summary 27393-27541

ruby-talk
21

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.

David

--
David A. Black
dblack@wobblini.net

22

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

but then how to i __stop__ using a namespace?

   using jcode

   ....

   stopusing jcode

putting_away jcode

:wink:

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.

···

--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

23

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

···

On 11/2/05, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:

Best. Idea. Ever.

24

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

···

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

--
Mauricio Fernandez

25

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

···

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.

--
Mauricio Fernandez

26

Austin Ziegler <halostatue@gmail.com> writes:

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

···

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

Austin Ziegler * halostatue@gmail.com

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

27

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

28

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

···

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.

29

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.

···

On 11/3/05, Christian Neukirchen <chneukirchen@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.

30

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.

31

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

32

Kero <kero@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 ---+

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

33

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.

-a

···

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

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

--

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

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

34

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

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

···

On 11/2/05, Ryan Leavengood <leavengood@gmail.com> wrote:

On 11/2/05, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:

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

35

Hi --

···

On Thu, 3 Nov 2005, Mauricio Fernández wrote:

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 :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. I'm actually not entirely clear on what static would mean in
this context.

David

--
David A. Black
dblack@wobblini.net

36

Too much inheritance from perl :frowning: 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.

···

On 11/3/05, nobu.nokada@softhome.net <nobu.nokada@softhome.net> wrote:

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.

37

MenTaLguY <mental@rydia.net> writes:

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.

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

(E.g. see leah blogs: The Rightyear parsing library )

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

···

On Thu, 2005-11-03 at 22:13 +0900, Christian Neukirchen wrote:

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

-mental

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

38

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

39

>> 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 ------------------------- kero@chello@nl ---+

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

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

40

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