[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: ANN: MetaTags 1.0

dblack

9/8/2003 6:09:00 PM

16 Answers

Hal E. Fulton

9/8/2003 6:15:00 PM

0

dblack@superlink.net wrote:

[snip]

> I agree with your points (about both the strength of the libraries and
> the pitfalls of patching) -- and it also reminds me of an idea from
> long ago that I never researched the feasibility of very deeply....
> Namely, the idea of an extensible %_{} syntax, so that one could
> define the behavior of %y{}, %x{}, and so on from within a Ruby
> program or extension.
>
> Perhaps someone steeped in the ways of the parser could comment on
> how hard this would be (up to and including impossible).

I also agree with Chad''s points.

As for your idea, I like it. As to its difficulty, my (uneducated)
opinion is: In the current Ruby implementation, impossible; in a
future one, difficult.

Hal

why the lucky stiff

9/8/2003 6:43:00 PM

0

On Monday 08 September 2003 12:08 pm, dblack@superlink.net wrote:
>
> Namely, the idea of an extensible %_{} syntax, so that one could
> define the behavior of %y{}, %x{}, and so on from within a Ruby
> program or extension.
>
> Perhaps someone steeped in the ways of the parser could comment on
> how hard this would be (up to and including impossible).
>

this wouldn''t be much of a problem. right now there''s a ''default'' case on a
switch in parse.y:

default:
yyerror("unknown type of %string");
return 0;

establish a USERSTR set of tokens and node types. (you can follow XSTR or
DXSTR around to see how.) Then, in rb_eval, add a case for NODE_MISCSTR,
which could check for the character in a global hash, passing the string
contents into a proc associated with that character. return the result of
the proc call from rb_eval.

the %y{...} hack could become:

add_delimited_prefix( ''y'' ) do |str|
YAML::load( str )
end

_why

Hal E. Fulton

9/8/2003 7:01:00 PM

0

why the lucky stiff wrote:
> On Monday 08 September 2003 12:08 pm, dblack@superlink.net wrote:
>
>>Namely, the idea of an extensible %_{} syntax, so that one could
>>define the behavior of %y{}, %x{}, and so on from within a Ruby
>>program or extension.
>>
>>Perhaps someone steeped in the ways of the parser could comment on
>>how hard this would be (up to and including impossible).
>>
>
>
> this wouldn''t be much of a problem. right now there''s a ''default'' case on a
> switch in parse.y:
>
> default:
> yyerror("unknown type of %string");
> return 0;
>
> establish a USERSTR set of tokens and node types. (you can follow XSTR or
> DXSTR around to see how.) Then, in rb_eval, add a case for NODE_MISCSTR,
> which could check for the character in a global hash, passing the string
> contents into a proc associated with that character. return the result of
> the proc call from rb_eval.
>
> the %y{...} hack could become:
>
> add_delimited_prefix( ''y'' ) do |str|
> YAML::load( str )
> end

Much easier than I thought. I''ll bet there are some gotchas,
though.

Matz??

Hal

Its Me

9/8/2003 7:35:00 PM

0


<dblack@superlink.net> wrote
> Namely, the idea of an extensible %_{} syntax, so that one could
> define the behavior of %y{}, %x{}, and so on from within a Ruby
> program or extension.

In a slightly more general context, a worked-out approach to extensible
syntax grammars is described in:

http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-...

nobu.nokada

9/9/2003 1:25:00 AM

0

Hi,

At Tue, 9 Sep 2003 03:42:53 +0900,
why the lucky stiff wrote:
> > Namely, the idea of an extensible %_{} syntax, so that one could
> > define the behavior of %y{}, %x{}, and so on from within a Ruby
> > program or extension.
> >
> > Perhaps someone steeped in the ways of the parser could comment on
> > how hard this would be (up to and including impossible).
> >
>
> this wouldn''t be much of a problem. right now there''s a ''default'' case on a
> switch in parse.y:
>
> default:
> yyerror("unknown type of %string");
> return 0;
>
> establish a USERSTR set of tokens and node types. (you can follow XSTR or
> DXSTR around to see how.) Then, in rb_eval, add a case for NODE_MISCSTR,
> which could check for the character in a global hash, passing the string
> contents into a proc associated with that character. return the result of
> the proc call from rb_eval.

A few questions.

(1) Can the interpolation take place in such literals?

(2) When should the string be processed, while parsing, after
parse, or runtime?

(3) If it will be in runtime, is it only once, or each time?

BTW, your patch fails with #{}. See
<http://nokada.jin.gr.jp/ruby/yaml-litera....

--
Nobu Nakada

why the lucky stiff

9/9/2003 1:46:00 AM

0

On Monday 08 September 2003 07:25 pm, nobu.nokada@softhome.net wrote:
>
> (1) Can the interpolation take place in such literals?
>
> (2) When should the string be processed, while parsing, after
> parse, or runtime?
>
> (3) If it will be in runtime, is it only once, or each time?
>

nobu, couldn''t all of these options be available to the user? possible
defaults:

(1) yes.
(2) runtime. in rb_eval. provides for the user proc and the literal
contained in the same file. this works?
(3) once.

> BTW, your patch fails with #{}. See
> <http://nokada.jin.gr.jp/ruby/yaml-litera....

ah, much better. beautiful.

_why

matz

9/9/2003 3:36:00 AM

0

Hi,

In message "Re: ANN: MetaTags 1.0"
on 03/09/09, Hal Fulton <hal9000@hypermetrics.com> writes:

|Much easier than I thought. I''ll bet there are some gotchas,
|though.
|
|Matz??

Yes? It is hard for me to merge this, because

* it''s no better than e.g. "y %{foo: bar}".
* it''s against my policy of "syntax should be stable".

I agree with usefulness of user-defined literals, and this is much
disciplined than generic reader macros, but still we need to discuss
pros and cons.

matz.

Gavin Sinclair

9/9/2003 4:26:00 AM

0

> Hi,
>
> In message "Re: ANN: MetaTags 1.0"
> on 03/09/09, Hal Fulton <hal9000@hypermetrics.com> writes:
>
> |Much easier than I thought. I''ll bet there are some gotchas,
> |though.
> |
> |Matz??
>
> Yes? It is hard for me to merge this, because
>
> * it''s no better than e.g. "y %{foo: bar}".
> * it''s against my policy of "syntax should be stable".
>
> I agree with usefulness of user-defined literals, and this is much
> disciplined than generic reader macros, but still we need to discuss
> pros and cons.
>
> matz.

A thought occurred to me. If %y{foo: bar} is seen as desirable as a short
and simple way of declaring a YAML literal, what about this instead?

YAML{foo: bar}

Which is implemented as

class << YAML
def {(str)
# whatever ... "YAML.new(str)??
end
end

Notes:

- no syntax clashes as everyone tries to claim %y{...}
(I know, this is FUD, but it addresses the known namespace problem)

- allowing ''{'' as a method is a nice general change, maintaining a
unified syntax

- syntax-wise, Ruby treats YAML{...} as YAML.{%q{...}}

- this proposal is, if anything, clearer than %y{foo: bar} without
being burdensome

- all of the current %_{...} tricks could be implemented in this way
(not suggesting they should be, rather, pointing out consistency)
e.g. Regexp{...}, Split{...}, Execute{...}

I make no attempt at pros and cons here, but it seems like a pretty good
idea to me.

Gavin

nobu.nokada

9/9/2003 4:36:00 AM

0

Hi,

At Tue, 9 Sep 2003 13:25:58 +0900,
Gavin Sinclair wrote:
> A thought occurred to me. If %y{foo: bar} is seen as desirable as a short
> and simple way of declaring a YAML literal, what about this instead?
>
> YAML{foo: bar}

This clashes against iterator.

--
Nobu Nakada

Mauricio Fernández

9/9/2003 7:25:00 AM

0

On Tue, Sep 09, 2003 at 01:25:58PM +0900, Gavin Sinclair wrote:
> > Hi,
> >
> > In message "Re: ANN: MetaTags 1.0"
> > on 03/09/09, Hal Fulton <hal9000@hypermetrics.com> writes:
> >
> > |Much easier than I thought. I''ll bet there are some gotchas,
> > |though.
> > |
> > |Matz??
> >
> > Yes? It is hard for me to merge this, because
> >
> > * it''s no better than e.g. "y %{foo: bar}".
> > * it''s against my policy of "syntax should be stable".
> >
> > I agree with usefulness of user-defined literals, and this is much
> > disciplined than generic reader macros, but still we need to discuss
> > pros and cons.
> >
> > matz.
>
> A thought occurred to me. If %y{foo: bar} is seen as desirable as a short
> and simple way of declaring a YAML literal, what about this instead?
>
> YAML{foo: bar}

def Y(txt)
YAML.load txt
end

Y %{bla: foo}
=> {"bla"=>"foo"}

OTOH this might scare people who think "... combinator" whenever they
see Y.

--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| ''_ \ / _` | __/ __| ''_ ` _ \ / _` | ''_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Never make any mistaeks.
-- Anonymous, in a mail discussion about to a kernel bug report