Fw: [Yaml-core] Summary of the IRC session

2002-09-06 Thread Brian Ingerson

This is an interesting tidbit from a longer posting by Oren Ben-Kiki, the
YAML specification author. Thought I'd pass it on.

- Forwarded message from Oren Ben-Kiki [EMAIL PROTECTED] -

From: Oren Ben-Kiki [EMAIL PROTECTED]
Date: Thu, 5 Sep 2002 11:28:12 +0300
To: [EMAIL PROTECTED]
Subject: [Yaml-core] Summary of the IRC session
X-Mailer: Internet Mail Service (5.5.2653.19)



- I'm impressed by the fact that this is almost identical to Perl's type
system - and we arrived at it independently. Either Larry Wall was extremely
lucky, he had a working crystal ball that told him this type system would be
good for Yaml, or this approach is right in some deep way (for scripting
languages) and he merely arrived at it as an inevitable result. Of
course this made our life easier because we had it in front of us, while he
more-or-less invented it from scratch (AFAIK).

I don't want to start a language war here or anything, and Parrot is
supposed to run Python and Ruby programs as well anyway... I'm just rather
surprised by this result. If you would have asked me a year back my bet
would have been that we'd end up being more traditional and Perl would be
the odd man out. In fact when I first encountered bless I thought it was
a horrible hack; now I want to bless Larry for getting it right.

Either way, YAML makes a *perfect* fit for Parrot now. Way to go!





Re: regex args and interpolation

2002-09-06 Thread Nicholas Clark

On Wed, Sep 04, 2002 at 10:46:24PM -0400, Ken Fox wrote:
 What is really needed is something that converts the date syntax
 to normal Perl code:
 
rule iso_date { (Perl.term) -
(Perl.term) -
(Perl.term)
{ use grammar Perl::AbstractSyntax;
  $0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }

I'm confused. Why has that last line got a lisp expression for the spliced
in code?

Nicholas Clark



Re: regex args and interpolation

2002-09-06 Thread Piers Cawley

Nicholas Clark [EMAIL PROTECTED] writes:

 On Wed, Sep 04, 2002 at 10:46:24PM -0400, Ken Fox wrote:
 What is really needed is something that converts the date syntax
 to normal Perl code:
 
rule iso_date { (Perl.term) -
(Perl.term) -
(Perl.term)
{ use grammar Perl::AbstractSyntax;
  $0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }

 I'm confused. Why has that last line got a lisp expression for the spliced
 in code?

'cos S expressions are a relatively simple way of writing a syntax tree?

-- 
Piers

   It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
 -- Jane Austen?



Re: regex args and interpolation

2002-09-06 Thread Nicholas Clark

On Fri, Sep 06, 2002 at 02:20:10PM +0100, Piers Cawley wrote:
 Nicholas Clark [EMAIL PROTECTED] writes:
 
  On Wed, Sep 04, 2002 at 10:46:24PM -0400, Ken Fox wrote:
  What is really needed is something that converts the date syntax
  to normal Perl code:
  
 rule iso_date { (Perl.term) -
 (Perl.term) -
 (Perl.term)
 { use grammar Perl::AbstractSyntax;
   $0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }
 
  I'm confused. Why has that last line got a lisp expression for the spliced
  in code?
 
 'cos S expressions are a relatively simple way of writing a syntax tree?

But it's in the middle of stream of perl.

Except, if I understand things correctly, the way the perl parsing rules
work, it would be quite legal for any perl grammar to say that the next
argument is to be written as an S expression *directly and raw in the source
code*, and the parser will happily then read one S expression to its
terminator, before continuing in perl (well, more conventional perl) syntax.

ie Ken's code, above, could well be completely legal perl6 code.

This idea of just switching language syntax in a context-sensitive way is
trying to make my head explode.

Nicholas Clark



Re: regex args and interpolation

2002-09-06 Thread Piers Cawley

Nicholas Clark [EMAIL PROTECTED] writes:

 On Fri, Sep 06, 2002 at 02:20:10PM +0100, Piers Cawley wrote:
 Nicholas Clark [EMAIL PROTECTED] writes:
 
  On Wed, Sep 04, 2002 at 10:46:24PM -0400, Ken Fox wrote:
  What is really needed is something that converts the date syntax
  to normal Perl code:
  
 rule iso_date { (Perl.term) -
 (Perl.term) -
 (Perl.term)
 { use grammar Perl::AbstractSyntax;
   $0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }
 
  I'm confused. Why has that last line got a lisp expression for the spliced
  in code?
 
 'cos S expressions are a relatively simple way of writing a syntax tree?

 But it's in the middle of stream of perl.

 Except, if I understand things correctly, the way the perl parsing rules
 work, it would be quite legal for any perl grammar to say that the next
 argument is to be written as an S expression *directly and raw in the source
 code*, and the parser will happily then read one S expression to its
 terminator, before continuing in perl (well, more conventional perl) syntax.

 ie Ken's code, above, could well be completely legal perl6 code.

 This idea of just switching language syntax in a context-sensitive way is
 trying to make my head explode.

But you mean that in a good way right? Anyway, he did introduce the
'use grammar Perl::AbstractSyntax;' in the lexical scope, so obviously
there's *something* afoot...


-- 
Piers

   It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
 -- Jane Austen?



Re: regex args and interpolation

2002-09-06 Thread Mark J. Reed

On Fri, Sep 06, 2002 at 02:34:52PM +0100, Nicholas Clark wrote:
 On Wed, Sep 04, 2002 at 10:46:24PM -0400, Ken Fox wrote:
  What is really needed is something that converts the date syntax
  to normal Perl code:
  
 rule iso_date { (Perl.term) -
 (Perl.term) -
 (Perl.term)
 { use grammar Perl::AbstractSyntax;
   $0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }
  
 This idea of just switching language syntax in a context-sensitive way is
 trying to make my head explode.
[Two programmers walk around the corner in an office, heads down in hardcopy,
and run right into each other, papers flying everywhere.]

FIRST PROGRAMMER:  Hey!  You got your LISP in my Perl!
SECOND PROGRAMMER: Hey!  You wrapped your Perl around my LISP!

[Both do a take] 
BOTH PROGRAMMERS: That's pretty cool!

[Cue music: 
o/~ N great tastes that taste great together . . . 
Larry's Pick-Your-Syntax Code! o/~ ]

Sorry, couldn't resist.  

Well, okay, I didn't try that hard.

-- 
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G  | [EMAIL PROTECTED]
Atlanta, GA 30348  USA   | +1 404 827 4754 
--
Surely you can't be serious.
I am serious.  And stop calling me Shirley.
-- Airplane



Re: Second try: Builtins

2002-09-06 Thread Aaron Sherman

On Fri, 2002-09-06 at 09:29, Nicholas Clark wrote:
 On Fri, Sep 06, 2002 at 01:34:56AM -0400, Aaron Sherman wrote:
 
  # INTERNAL q, qq, qw
  # XXX - how do I do quote-like operators? I know I saw someone say...
  # Need to do: qr (NEVER(qr)) and qx
 
 presumably the way the perl5 tokeniser does them - by parsing the string
 into a series of concatenated constants and variables, with some optionally
 fed through uc/ucfirst/lc/lcfirst/quotemeta
 (And scalar and list interpolators breaking back out to the real parser)

Ok, so I guess that all has to go in the parser, not the builtins. Perl
5 already provides builtin functions that are the back-ends for things
like C  , Cqx, etc so those will be in the builtins, and the
parser can just call them. It may already do so, I've not had time to
look.

  sub chomp($string is rw){
  my $irs = ${/}; # XXX What is $/ now?
 
 per file handle. So does that mean each string needs a property to hold what
 the record separator for the file handle it was read from at the time of
 reading?

That's not terribly useful, since filehandles will auto-chomp in Perl 6
anyway. I propose the alternate:

sub chomp($string is rw, $sep //= rx/\n/) { ... }
sub chomp(strings is rw, $sep //= rx/\n/) { ... }

This will mean that you can:

chomp(lines=)

but not:

chomp($line1, $line2, $line3);

Is that going to be a problem?


 (Well, as record separators could be regexps^Wpatterns actually I think a
 an offset to the start of the record separator will do)

I forgot they could be patterns. Need to go fix that!

  sub index($string, $substr, int $pos //= 0) {
  # XXX - slow dumb way... need to break out Knuth
[...]
 I think that string in string searches are common functionality that ought
 to be implemented in the parrot core. Rather than every language and
 extension that needs them having to re-implement the wheel.

Good point. I will look at what parrot does now, and consider moving
index over to the Internal section.

 Why is socketpair never? It's a real Unix system call that provides

Because I was tired :)

I'm going to cut that section down to just a list of the functions that
need to be moved over to the IO modules as one long comment. It's just
there for a reminder right now.

Thanks for the comments and answers to some of my questions. The
feedback as been quite helpful!





Re: regex args and interpolation

2002-09-06 Thread Nicholas Clark

On Fri, Sep 06, 2002 at 02:49:13PM +0100, Piers Cawley wrote:
 Nicholas Clark [EMAIL PROTECTED] writes:

  This idea of just switching language syntax in a context-sensitive way is
  trying to make my head explode.
 
 But you mean that in a good way right? Anyway, he did introduce the

Yes. Now all we need is an animation of a Monty Python gumby character
with his head exploding. Preferably in the style of Terry Gilliam, and
U rated. [1]

 'use grammar Perl::AbstractSyntax;' in the lexical scope, so obviously
 there's *something* afoot...

Yes, but somewhat like concepts dawning on people during Damian's perl6 talk,
it's the fact that I can define syntax/grammar/whatever so that

somefunc ({some=hash, in=normal, perl=syntax},
  ('this 'argument 'is 'an 'S-expr 'and is 'parsed 'as 'such)
  Bang!
 );


is valid, where somefunc has a prototype that says first argument is a
hashref, second is an S-expr, third is a string.

(and the lack of comma after the closing brace of S-expr was intentional.
I presume I need one to mark the end of the first argument)

Nicholas Clark

1: U rating explanation if needed:
  
http://www.bbfc.co.uk/website/Customers.nsf/Guidelines/GuidelinesTheCategoriesU?OpenDocument



Re: Request for default rule modifiers in a grammar

2002-09-06 Thread Damian Conway

Ken Fox wrote:

  Excellent. Will there be an abstract syntax for tree
  rewriting or is it Perl 6 all the way down?

I'd expect it to be Perl all the way down. Though a
tree rewriting module might make it seem abstract. ;-)


  This is really amazing stuff. I was expecting some
  support for building mini languages on top of Perl 6,
  but it really looks like Perl 6 is going to become
  the de facto language prototyping tool. (Bye bye
  yacc!)

I certainly hope so!

Damian






More A5/E5 questions

2002-09-06 Thread Jonathan Scott Duff


Question #1:

If \n matches any one of the platform-specific newline character
sequences, does that mean that if I have a string like this[*]:

foo bar baz\rfoo bar baz\nfoo bar bar\r\n

that \n will match in 3 places?  How do you tell perl that you only
want \n to match a specific newline sequence?  And if \n does match in
3 places in that string, does that mean that ^^ and $$ will also match
in 3 places?

[*] In my string \r and \n are substituting for carriage return
and line feed respectively.

Question #2:

Why are we storing the hypothetical's sigil in the match object?

Question #3:

Related to question #2, if I didn't use hypotheticals, how would I
access the Nth match of a repitition?  For instance, in E5, there's an
example that looks like this:

rule file { ^  @adonises := hunk*  $ }

If I didn't have the hypothetical @adonises, how would I retrieve the
3rd hunk matched? Would I need to write it like so:

rule file { ^  hunks  $ }
rule hunks :e { (hunk) }

and then access it with $0{file}{hunks}[2] ?

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]



Re: More A5/E5 questions

2002-09-06 Thread Luke Palmer


Answering to the best of my knowledge.

On Sat, 7 Sep 2002, Jonathan Scott Duff wrote:

 Question #2:
 
 Why are we storing the hypothetical's sigil in the match object?

I think it's to differentiate the different namespaces (scalar, array, 
hash) within the match object's hash.  Personally, I don't like it, and 
think that people should just not do:

/ $var := foo , var := bar* /

Because it's dumb.

 Question #3:
 
 Related to question #2, if I didn't use hypotheticals, how would I
 access the Nth match of a repitition?  For instance, in E5, there's an
 example that looks like this:
 
   rule file { ^  adonises := hunk*  $ }

 If I didn't have the hypothetical adonises, how would I retrieve the
 3rd hunk matched? Would I need to write it like so:
 
   rule file { ^  hunks  $ }
   rule hunks :e { (hunk) }

No. I think you can do this:

/ hunk* / # maybe / (hunk)* /
$0{hunk}[3]

Luke