Fw: [Yaml-core] Summary of the IRC session
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
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
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
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
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
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
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
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
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
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
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