Compiling to Parrot

[K Stol]

Hi there,

A few weeks ago I posted something about a Tcl->parrot compiler, but Will Coleda 
already was working on such a project. It would be a as a final project for my 
bachelor's. But because such already exists, I'm looking for something else. 
I think parrot is a cool target for compiling, and I'd like to do some sort of a 
compiler project. However, I don't know which language to compile. My knowledge is 
basic, so any OO language would take too much time.
Has anybody any suggestions for me? (maybe modula2?)

Regards.

Klaas-Jan Stol

Re: Compiling to Parrot

[Simon Wistow]

On Tue, Jan 21, 2003 at 09:17:56AM +0100, K Stol said:
> A few weeks ago I posted something about a Tcl->parrot compiler, but Will Coleda 
>already was working on such a project. It would be a as a final project for my 
>bachelor's. But because such already exists, I'm looking for something else. 
> I think parrot is a cool target for compiling, and I'd like to do some sort of a 
>compiler project. However, I don't know which language to compile. My knowledge is 
>basic, so any OO language would take too much time.
> Has anybody any suggestions for me? (maybe modula2?)


PHP?
Similar enough to Perl to make it interesting, nice clean design and an
available grammar. People have already done some work IIRC.

Lua?
Similar-ish to TCL and liked by the games industry. It is procedural but
provides meta mechanisms for implementing classes and inheritance.

Speaking of games, it would be interesting to see Parrot be used in that
direction. A lot of games currently are pretty much developed along the
lines of 'custom scripting language interfaced to custom game engine'

# game scripting in Python
http://www.gamasutra.com/features/20020821/dawson_pfv.htm

# Postmortem of Jak and Daxter which was scripted in Lisp
http://www.gamasutra.com/features/20020710/white_01.htm

Parrot seems to be ideal for this, especially since you could easily
have seperate scripting languages for, say, the world logic and the AI
for NPCs, both of which could compile to Parrot and interact with each
other.

Simon


-- 
I'm full of borrowed ideas that I have no intention of returning

Re: Compiling to Parrot

[Leon Brocard]

K Stol sent the following bits through the ether:

> A few weeks ago I posted something about a Tcl->parrot compiler, but
> Will Coleda already was working on such a project. It would be a as a
> final project for my bachelor's. But because such already exists, I'm
> looking for something else.

An interesting project to do would be to do a Java->Parrot compiler.
Basing it on an existing Java compiler such as Jikes is probably the
best way to do this:
http://oss.software.ibm.com/developerworks/opensource/jikes/
You'd also probably use GNU Classpath:
http://www.gnu.org/software/classpath/classpath.html

HTH, Leon
-- 
Leon Brocard.http://www.astray.com/
scribot.http://www.scribot.com/

... Hmm... How *did* they finally kill Frosty?

Re: [perl #20400] [PATCH] ook.pasm eval

[Leopold Toetsch]

Leon Brocard wrote:


Index: config/gen/makefiles/ook.in



Applied,
leo

Re: [perl #18056] [PATCH] Extending the Packfile (Part 1.)

[Leopold Toetsch]

Jürgen Bömmels (via RT) wrote:


# New Ticket Created by  Jürgen Bömmels 
# Please include the string:  [perl #18056]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=18056 >


Applied with some modifications and extension.
Thanks again,
leo

PS orig description again:



This patch is the beginning of an effort to make PackFile format
extendible. At the moment its combatible with the old bytecode
format.

Ok, to the details:
It appends a 4th segment behind the 3 already defined segments (FIXUP,
CONSTANT and BYTECODE) name DIRECTORY. After this directory one ore
more uniquely named segments may follow. 

The directory segments start with the number of segments in the
PackFile, followed by a list of directory items. Each item constists
of a '\0' terminated c-string (padded to opcode_t-alignment), a
flag-word, the size of the corresponding segment and the position of
the segment in the packfile. The 4 first segments are nothing special,
expect that their name and order is fixed.

The implementation uses a glib style inheritance aproach. The
base-"class" of all Segments is struct PackFile_Segment which consists
of data-members for name, packfile, fileoffset, size and flags and
furter the member-functions destroy, packed_size, and pack. The
derived "classes" struct PackFile_Directory, PackFile_ConstTable
PackFile_FixupTable and PackFile_ByteCode (the later two are ATM just
dummy implementations) embed a PackFile_Segment as first elment so the
base-class can be get by a pointer cast.

Next steps might be:
- seperate the packfile.c in diffrent files (maybe move them to a
  directory/subsystem on its own as suggest by PDD07) one for each
  segment-type.
- document the extension in parrotbyte.pod
- lower the restriction on the ordering of the first 4 segments
- write an objdump-like tool for manipulating packfiles. (I tried to
  extend pdump for that, but it segfaults in unmake_COW, a
  NULL-interpreter from PIO_eprintf)
- Teach the assembler to output the new format. (imcc uses AFAIK
  packout.c and should already work)

bye
b.

[CVS ci] packfile

[Leopold Toetsch]

Thanks to Juergen Boemmels patch #18056, we now have multiple code segments.

Changes:
- multiple code segments in memory, created by compile opcode
- changed packfile constants to a union
- create debug (file/line) info for gdb/stabs, including evaled code
- small JIT changes for eval
- changed imcc run options, -r is optional now, -o necessary for
  assembler mode
- fixed many mem leaks in imcc
- fixed some warnings in imcc

- {un,}managed struct classes simplified
- ook Makefile #20400
- align jumps on 4 byte for i386/jit

leo

Re: Compiling to Parrot

[K Stol]

PHP is especially used in web pages. Would there be any advantage to have a
PHP->Parrot compiler?

LUA seems to be a very nice language, but how is this language to be used?
Is it in combination with a C program one would write? Or could it be used
as a stand alone application? In that case, it seems to me it would be
interesting to have a LUA->Parrot (with IMCC in between) compiler.

Regards.
Klaas-Jan Stol

- Original Message -
From: "Simon Wistow" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 21, 2003 9:41 AM
Subject: Re: Compiling to Parrot


> On Tue, Jan 21, 2003 at 09:17:56AM +0100, K Stol said:
> > A few weeks ago I posted something about a Tcl->parrot compiler, but
Will Coleda already was working on such a project. It would be a as a final
project for my bachelor's. But because such already exists, I'm looking for
something else.
> > I think parrot is a cool target for compiling, and I'd like to do some
sort of a compiler project. However, I don't know which language to compile.
My knowledge is basic, so any OO language would take too much time.
> > Has anybody any suggestions for me? (maybe modula2?)
>
>
> PHP?
> Similar enough to Perl to make it interesting, nice clean design and an
> available grammar. People have already done some work IIRC.
>
> Lua?
> Similar-ish to TCL and liked by the games industry. It is procedural but
> provides meta mechanisms for implementing classes and inheritance.
>
> Speaking of games, it would be interesting to see Parrot be used in that
> direction. A lot of games currently are pretty much developed along the
> lines of 'custom scripting language interfaced to custom game engine'
>
> # game scripting in Python
> http://www.gamasutra.com/features/20020821/dawson_pfv.htm
>
> # Postmortem of Jak and Daxter which was scripted in Lisp
> http://www.gamasutra.com/features/20020710/white_01.htm
>
> Parrot seems to be ideal for this, especially since you could easily
> have seperate scripting languages for, say, the world logic and the AI
> for NPCs, both of which could compile to Parrot and interact with each
> other.
>
> Simon
>
>
> --
> I'm full of borrowed ideas that I have no intention of returning
>

Re: L2R/R2L syntax

[Graham Barr]

On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
> > What benefit does C<< <~ >> bring to the language?
> 
> Again, it provides not just a "null operator" between to calls, but
> rather a rewrite of method call syntax.  So:
> 
>   map {...} <~ grep {...} <~ @boing;
> 
> is not:
> 
>   map {...} grep {...} @boing;
> 
> But rather:
> 
>   @boing.map({...}).grep({...});

This is not a for or against, but there is something that has been
bugging me about this.

Currently in Perl5 it is possible to create a sub that has map/grep-like
syntax, take a look at List::Util

If the function form of map/grep were to be removed, which has been suggested,
and the <~ form maps to methods. How would you go about defining a utility
module similar to List::Util that uses the same syntax as map/grep but
without making the subs methods on the global ARRAY package ?

Graham.

Re: A proposal on if and else

[Dave Whipp]

"Joseph F. Ryan" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Rafael Garcia-Suarez wrote:
> >
> >The tokeniser could send two tokens "else" and "if" whenever it
> >recognizes the keyword "elsif" -- so this isn't a problem.
> >
>
> I think the point of having C as a sub rather than as a separate
> syntax is so the parser doesn't have to do anything special for
> special keywords.

The specialness could be generalized, so that its no longer a parser hack:


#define elsif else if


Dave.

Re: The parrot crashes...

[blair christensen]

On Mon, Jan 20, 2003 at 02:09:10PM -0500, Dan Sugalski wrote:
> Rather badly, actually. All the tests that involve parrot currently 
> segfault in the NCI mark routine. At least on OS X, I'm not sure 
> about other platforms.

5.8.0/Sparc64/OpenBSD is also rather unhappy.

I'm getting the following core dumps:
intlist_1.core   intlist_3.core   list_1.core  parrot.core  sprintf_2.core
intlist_2.core   intlist_4.core   list_2.core  sprintf_1.core

parrot.core is the only one that seems to be having problems with 
Parrot_NCI_mark, however.

% gdb -c parrot.core parrot
GNU gdb 4.16.1
This GDB was configured as "sparc64-unknown-openbsd3.1"
Core was generated by `parrot'.
Program terminated with signal 10, Bus error.
#0  0x1a8638 in pobject_lives ()
(gdb) bt
#0  0x1a8638 in pobject_lives ()
#1  0x1bcc78 in Parrot_NCI_mark ()
#2  0x1a8b88 in trace_active_PMCs ()
#3  0x1a9340 in Parrot_do_dod_run ()
#4  0x1a72c0 in more_traceable_objects ()
#5  0x1a73cc in get_free_object ()
#6  0x1a7a1c in get_free_buffer ()
#7  0x1a7f3c in new_bufferlike_header ()
#8  0x164354 in list_new ()
#9  0x1b2190 in Parrot_Array_init ()
#10 0x1663b0 in setup_argv ()
#11 0x166640 in Parrot_runcode ()
#12 0x1cdf98 in main ()
#13 0x11332c in ___start ()

blair.

Re: Compiling to Parrot

[Simon Wistow]

On Tue, Jan 21, 2003 at 12:14:29PM +0100, K Stol said:
> PHP is especially used in web pages. Would there be any advantage to have a
> PHP->Parrot compiler?

Depends what you mean by 'advantage'. 

Currently, as far as I know, PHP runs on a virtual machine, just like
Perl so it's a good candidate for porting. It is also relatively feature
comparable whilst being easier to parse.

Doing a PHP->Parrot compiler would have these advantages :

* demonstrate your understanding of a inplementing the
  compiler for a featureful language
* allow interaction between Perl6 and PHP scripts/modules
* tap into the PHP community's tuits whcih would mean Parrot'd be likely
  to get stuff like the Zend optimiser and a generic mod_* backend so
  that all languages implemented on top of Parrot would have a
  mod_(php/perl) Apache hook automagically.
* really push Parrot with a real-world, non toy language.


> LUA seems to be a very nice language, but how is this language to be used?
> Is it in combination with a C program one would write? Or could it be used
> as a stand alone application? In that case, it seems to me it would be
> interesting to have a LUA->Parrot (with IMCC in between) compiler.

As I said, I only know it from a games context where it's used as the
basis for the scripting engine. AIUI it can be used a a standalone
language as well.

>From what I know it's specifically designed to be a portable, fast,
lightweight platform for extending platforms and providing a framework
for implementing domain specific languages.

So, basically, a perfect fit for Parrot.

In fact, if you take 

http://www.lua.org/about.html 

and s/Lua/Parrot/ it still makes sense :)

Simon

Re: The parrot crashes...

[Leopold Toetsch]

blair christensen wrote:


On Mon, Jan 20, 2003 at 02:09:10PM -0500, Dan Sugalski wrote:


Rather badly, actually. All the tests that involve parrot currently 
segfault in the NCI mark routine. At least on OS X, I'm not sure 
about other platforms.


(gdb) bt
#0  0x1a8638 in pobject_lives ()
#1  0x1bcc78 in Parrot_NCI_mark ()



Is this with my patch (in CVS) already applied?



blair.



leo

Re: Compiling to Parrot

[Dan Sugalski]

At 9:17 AM +0100 1/21/03, K Stol wrote:

Hi there,

A few weeks ago I posted something about a Tcl->parrot compiler, but 
Will Coleda already was working on such a project. It would be a as 
a final project for my bachelor's. But because such already exists, 
I'm looking for something else.

If you're interested in doing a Tcl compiler, by all means, go 
ahead--I wouldn't let the fact that someone else is doing it stop 
you. The point of doing it is for the experience, which you'll get 
regardless of any other implementation. It's also distinctly possible 
that neither you nor Will will finish a full implementation (as it's 
likely a rather large undertaking for one person) but you'll each 
have part of it that can be merged together.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

tinderbox glastig

[Leopold Toetsch]

Seems to be some missing dependency. 'make realclean' should do it.

jit_cpu.c:603: structure has no member named `number'

This file is generated by jit2h.pl which uses OpTrans::C  and there is 
u.number for 'nc'.

leo

Re: Compiling to Parrot

[K Stol]

Well, I'd do it as a project for my Bachelor's, so I won't get permission to
do such a project, if it already exists.
Klaas-Jan

- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, January 21, 2003 4:40 PM
Subject: Re: Compiling to Parrot


> At 9:17 AM +0100 1/21/03, K Stol wrote:
> >Hi there,
> >
> >A few weeks ago I posted something about a Tcl->parrot compiler, but
> >Will Coleda already was working on such a project. It would be a as
> >a final project for my bachelor's. But because such already exists,
> >I'm looking for something else.
>
> If you're interested in doing a Tcl compiler, by all means, go
> ahead--I wouldn't let the fact that someone else is doing it stop
> you. The point of doing it is for the experience, which you'll get
> regardless of any other implementation. It's also distinctly possible
> that neither you nor Will will finish a full implementation (as it's
> likely a rather large undertaking for one person) but you'll each
> have part of it that can be merged together.
> --
>  Dan
>
> --"it's like this"---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk
>

Re: Compiling to Parrot

[Gopal V]

If memory serves me right, Leon Brocard wrote:
> An interesting project to do would be to do a Java->Parrot compiler.

Hmm... I think with the current Parrot setup that might be a bit difficult.
We need object instructions for that , also I need to be able to define
classes,interfaces and all the Java thingys there ...

> Basing it on an existing Java compiler such as Jikes is probably the
> best way to do this:

Yikes ! (in a thick foreign accent)...

My bachelor's project is a Java compiler for DotGNU ... and I had a look
over of Jikes (and Kjc) for retargetting ... Eventhough I was planning on
building a stack bytecode , I found it quite something to hack on...
(in short, my attempts broke it...)

Kjc is a bit more decent though it's quite OO and might take some redesign
to pass back the result register (instead of "assuming" that the value is
in the stack top) ...

I've decided to base it on the Portable.net codegen... (I've got it into 
parsing now...)  ... This is a Java -> IL compiler from Java source ...

But once the C# -> Parrot compiler works , you might even have a Java -> 
Parrot compiler ... (because I'm re-using almost all the C# AST nodes
for my compiler, the PMCodegen should generate correct Parrot as well).

Hopefully all this will work out for me... :)

Gopal
-- 
The difference between insanity and genius is measured by success

Re: Compiling to Parrot

[Dan Sugalski]

At 4:46 PM +0100 1/21/03, K Stol wrote:

Well, I'd do it as a project for my Bachelor's, so I won't get permission to
do such a project, if it already exists.


Ah, that could be a problem. Will it be a problem if you start a 
project that someone else later also starts?

From: "Dan Sugalski" <[EMAIL PROTECTED]>
 > At 9:17 AM +0100 1/21/03, K Stol wrote:

 >Hi there,
 >
 >A few weeks ago I posted something about a Tcl->parrot compiler, but
 >Will Coleda already was working on such a project. It would be a as
 >a final project for my bachelor's. But because such already exists,
 >I'm looking for something else.

 If you're interested in doing a Tcl compiler, by all means, go
 ahead--I wouldn't let the fact that someone else is doing it stop
 you. The point of doing it is for the experience, which you'll get
 regardless of any other implementation. It's also distinctly possible
 that neither you nor Will will finish a full implementation (as it's
 likely a rather large undertaking for one person) but you'll each

 > have part of it that can be merged together.


--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Compiling to Parrot

[K Stol]

well, I think not, then I can't help it. What do you think about compiling
Lua to parrot (IMCC)?
Klaas-Jan

- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, January 21, 2003 4:58 PM
Subject: Re: Compiling to Parrot


> At 4:46 PM +0100 1/21/03, K Stol wrote:
> >Well, I'd do it as a project for my Bachelor's, so I won't get permission
to
> >do such a project, if it already exists.
>
> Ah, that could be a problem. Will it be a problem if you start a
> project that someone else later also starts?
>
> >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> >  > At 9:17 AM +0100 1/21/03, K Stol wrote:
> >>  >Hi there,
> >>  >
> >>  >A few weeks ago I posted something about a Tcl->parrot compiler, but
> >>  >Will Coleda already was working on such a project. It would be a as
> >>  >a final project for my bachelor's. But because such already exists,
> >>  >I'm looking for something else.
> >>
> >>  If you're interested in doing a Tcl compiler, by all means, go
> >>  ahead--I wouldn't let the fact that someone else is doing it stop
> >>  you. The point of doing it is for the experience, which you'll get
> >>  regardless of any other implementation. It's also distinctly possible
> >>  that neither you nor Will will finish a full implementation (as it's
> >>  likely a rather large undertaking for one person) but you'll each
> >  > have part of it that can be merged together.
>
> --
>  Dan
>
> --"it's like this"---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk
>

Re: tinderbox glastig

[Dan Sugalski]

At 4:40 PM +0100 1/21/03, Leopold Toetsch wrote:

Seems to be some missing dependency. 'make realclean' should do it.

jit_cpu.c:603: structure has no member named `number'


That's mine--I'll go get it cleaned up. I'm not sure it'll help that 
much, as I'm seeing multiply-defined symbol issues at the moment. OS 
X is very picky about that when it links.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Compiling to Parrot

[Dan Sugalski]

At 5:01 PM +0100 1/21/03, K Stol wrote:

well, I think not, then I can't help it. What do you think about compiling
Lua to parrot (IMCC)?


I like the idea, and I don't think you'll see anyone else tackle it 
for a while. (And if that falls through, there's always LISP... :)

From: "Dan Sugalski" <[EMAIL PROTECTED]>
 > At 4:46 PM +0100 1/21/03, K Stol wrote:

 >Well, I'd do it as a project for my Bachelor's, so I won't get permission

to

 >do such a project, if it already exists.

 Ah, that could be a problem. Will it be a problem if you start a
 project that someone else later also starts?

 >From: "Dan Sugalski" <[EMAIL PROTECTED]>
 >  > At 9:17 AM +0100 1/21/03, K Stol wrote:
 >>  >Hi there,
 >>  >
 >>  >A few weeks ago I posted something about a Tcl->parrot compiler, but
 >>  >Will Coleda already was working on such a project. It would be a as
 >>  >a final project for my bachelor's. But because such already exists,
 >>  >I'm looking for something else.
 >>
 >>  If you're interested in doing a Tcl compiler, by all means, go
 >>  ahead--I wouldn't let the fact that someone else is doing it stop
 >>  you. The point of doing it is for the experience, which you'll get
 >>  regardless of any other implementation. It's also distinctly possible
 >>  that neither you nor Will will finish a full implementation (as it's
 >>  likely a rather large undertaking for one person) but you'll each

 > >  > have part of it that can be merged together.


--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Compiling to Parrot

[K Stol]

Only thing I need to know before I can start is: what would the purpose be
of a Lua to Parrot compiler? Lua is originally an embedded language for
easy-scripting, as far as I understand. How could it be used when targeted
to parrot? Would it be possible to call functions written in Lua (and which
are then compiled to parrot) from (for example) a python script? (So: python
script calls function writtenin Lua and compiled to parrot).

Klaas-Jan

- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, January 21, 2003 5:05 PM
Subject: Re: Compiling to Parrot


> At 5:01 PM +0100 1/21/03, K Stol wrote:
> >well, I think not, then I can't help it. What do you think about
compiling
> >Lua to parrot (IMCC)?
>
> I like the idea, and I don't think you'll see anyone else tackle it
> for a while. (And if that falls through, there's always LISP... :)
>
> >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> >  > At 4:46 PM +0100 1/21/03, K Stol wrote:
> >>  >Well, I'd do it as a project for my Bachelor's, so I won't get
permission
> >to
> >>  >do such a project, if it already exists.
> >>
> >>  Ah, that could be a problem. Will it be a problem if you start a
> >>  project that someone else later also starts?
> >>
> >>  >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> >>  >  > At 9:17 AM +0100 1/21/03, K Stol wrote:
> >>  >>  >Hi there,
> >>  >>  >
> >>  >>  >A few weeks ago I posted something about a Tcl->parrot compiler,
but
> >>  >>  >Will Coleda already was working on such a project. It would be a
as
> >>  >>  >a final project for my bachelor's. But because such already
exists,
> >>  >>  >I'm looking for something else.
> >>  >>
> >>  >>  If you're interested in doing a Tcl compiler, by all means, go
> >>  >>  ahead--I wouldn't let the fact that someone else is doing it stop
> >>  >>  you. The point of doing it is for the experience, which you'll get
> >>  >>  regardless of any other implementation. It's also distinctly
possible
> >>  >>  that neither you nor Will will finish a full implementation (as
it's
> >>  >>  likely a rather large undertaking for one person) but you'll each
> >  > >  > have part of it that can be merged together.
>
> --
>  Dan
>
> --"it's like this"---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk
>

Re: Compiling to Parrot

[Dan Sugalski]

At 5:13 PM +0100 1/21/03, K Stol wrote:

Only thing I need to know before I can start is: what would the purpose be
of a Lua to Parrot compiler? Lua is originally an embedded language for
easy-scripting, as far as I understand. How could it be used when targeted
to parrot? Would it be possible to call functions written in Lua (and which
are then compiled to parrot) from (for example) a python script? (So: python
script calls function writtenin Lua and compiled to parrot).


If you follow the calling conventions, then yes you'll be able to 
call python/ruby/perl/befunge routines from Lua code, and vice versa.

From: "Dan Sugalski" <[EMAIL PROTECTED]>
 > At 5:01 PM +0100 1/21/03, K Stol wrote:

 >well, I think not, then I can't help it. What do you think about

compiling

 >Lua to parrot (IMCC)?

 I like the idea, and I don't think you'll see anyone else tackle it
 for a while. (And if that falls through, there's always LISP... :)

 >From: "Dan Sugalski" <[EMAIL PROTECTED]>
 >  > At 4:46 PM +0100 1/21/03, K Stol wrote:
 >>  >Well, I'd do it as a project for my Bachelor's, so I won't get

permission

 >to
 >>  >do such a project, if it already exists.
 >>
 >>  Ah, that could be a problem. Will it be a problem if you start a
 >>  project that someone else later also starts?
 >>
 >>  >From: "Dan Sugalski" <[EMAIL PROTECTED]>
 >>  >  > At 9:17 AM +0100 1/21/03, K Stol wrote:
 >>  >>  >Hi there,
 >>  >>  >
 >>  >>  >A few weeks ago I posted something about a Tcl->parrot compiler,

but

 >>  >>  >Will Coleda already was working on such a project. It would be a

as

 >>  >>  >a final project for my bachelor's. But because such already

exists,

 >>  >>  >I'm looking for something else.
 >>  >>
 >>  >>  If you're interested in doing a Tcl compiler, by all means, go
 >>  >>  ahead--I wouldn't let the fact that someone else is doing it stop
 >>  >>  you. The point of doing it is for the experience, which you'll get
 >>  >>  regardless of any other implementation. It's also distinctly

possible

 >>  >>  that neither you nor Will will finish a full implementation (as

it's

 >>  >>  likely a rather large undertaking for one person) but you'll each
 >  > >  > have part of it that can be merged together.

 --
  Dan

 --"it's like this"---
 Dan Sugalski  even samurai
 [EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk




--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Flex & IMCC

[Dan Sugalski]

Okay, I can be a bit slow, but I finally figured out what's going on 
with IMCC and OS X. imclexer.c is autogenerated (duh!) and flex, or 
whatever's being used to do it, spits out bad code. Could the IMCC 
folks upgrade to the latest version of flex to see if that fixes 
things and, if not, I'll hack up a post-processing program to make 
the output buildable.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Flex & IMCC

[Dan Sugalski]

At 11:29 AM -0500 1/21/03, Dan Sugalski wrote:

Okay, I can be a bit slow, but I finally figured out what's going on 
with IMCC and OS X. imclexer.c is autogenerated (duh!) and flex, or 
whatever's being used to do it, spits out bad code. Could the IMCC 
folks upgrade to the latest version of flex to see if that fixes 
things and, if not, I'll hack up a post-processing program to make 
the output buildable.

FWIW, the version of flex I have on my OS X box generates linkable 
code, but I'm not sure if the fink folks smacked flex around some.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Compiling to Parrot

[K Stol]

Is it possible for parrot-code to call functions in other parrot files?
(which implies there is some program which consists of multiple files)

Klaas-Jan

- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, January 21, 2003 5:20 PM
Subject: Re: Compiling to Parrot


> At 5:13 PM +0100 1/21/03, K Stol wrote:
> >Only thing I need to know before I can start is: what would the purpose
be
> >of a Lua to Parrot compiler? Lua is originally an embedded language for
> >easy-scripting, as far as I understand. How could it be used when
targeted
> >to parrot? Would it be possible to call functions written in Lua (and
which
> >are then compiled to parrot) from (for example) a python script? (So:
python
> >script calls function writtenin Lua and compiled to parrot).
>
> If you follow the calling conventions, then yes you'll be able to
> call python/ruby/perl/befunge routines from Lua code, and vice versa.
>
> >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> >  > At 5:01 PM +0100 1/21/03, K Stol wrote:
> >>  >well, I think not, then I can't help it. What do you think about
> >compiling
> >>  >Lua to parrot (IMCC)?
> >>
> >>  I like the idea, and I don't think you'll see anyone else tackle it
> >>  for a while. (And if that falls through, there's always LISP... :)
> >>
> >>  >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> >>  >  > At 4:46 PM +0100 1/21/03, K Stol wrote:
> >>  >>  >Well, I'd do it as a project for my Bachelor's, so I won't get
> >permission
> >>  >to
> >>  >>  >do such a project, if it already exists.
> >>  >>
> >>  >>  Ah, that could be a problem. Will it be a problem if you start a
> >>  >>  project that someone else later also starts?
> >>  >>
> >>  >>  >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> >>  >>  >  > At 9:17 AM +0100 1/21/03, K Stol wrote:
> >>  >>  >>  >Hi there,
> >>  >>  >>  >
> >>  >>  >>  >A few weeks ago I posted something about a Tcl->parrot
compiler,
> >but
> >>  >>  >>  >Will Coleda already was working on such a project. It would
be a
> >as
> >>  >>  >>  >a final project for my bachelor's. But because such already
> >exists,
> >>  >>  >>  >I'm looking for something else.
> >>  >>  >>
> >>  >>  >>  If you're interested in doing a Tcl compiler, by all means, go
> >>  >>  >>  ahead--I wouldn't let the fact that someone else is doing it
stop
> >>  >>  >>  you. The point of doing it is for the experience, which you'll
get
> >>  >>  >>  regardless of any other implementation. It's also distinctly
> >possible
> >>  >>  >>  that neither you nor Will will finish a full implementation
(as
> >it's
> >>  >>  >>  likely a rather large undertaking for one person) but you'll
each
> >>  >  > >  > have part of it that can be merged together.
> >>
> >>  --
> >>   Dan
> >>
> >>  --"it's like
this"---
> >>  Dan Sugalski  even samurai
> >>  [EMAIL PROTECTED] have teddy bears and even
> >> teddy bears get drunk
> >>
>
>
> --
>  Dan
>
> --"it's like this"---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk
>

Re: Flex & IMCC

[Leopold Toetsch]

Dan Sugalski wrote:


Okay, I can be a bit slow, but I finally figured out what's going on 
with IMCC and OS X. imclexer.c is autogenerated (duh!) and flex, or 
whatever's being used to do it, spits out bad code. Could the IMCC folks 
upgrade to the latest version of flex to see if that fixes things and, 
if not, I'll hack up a post-processing program to make the output 
buildable.

Could you be more precise in your error descriptions?
Error message, file line # ... ;-)

If you are talking about the yyin, yyout thingy, this sould be fixed. 
Ths was a double define.

leo

Re: [perl #20315] [PATCH] eval - inter code segment branches

[Jason Gloudon]

On Tue, Jan 21, 2003 at 12:08:29AM +0100, Leopold Toetsch wrote:

> Here is a proposal for inter code segment jumps:
> 
> The assembler (imcc) can recognize when a branch ins goes to a different
> code segment.
> 
> For such a branch, imcc generates this opcode seqence:
> 
>inter_cs
>if i, ic # or whatever

Why do we need branches to go to different code segments ?  I think the
expectation has been that control transfers between segments would have their
own op, because separate code segments would generally coincide with subs,
closures or at least blocks, that have specific entry points.

Maybe Dan could give us a hint about the closure/block/byte code segment
relationship.

-- 
Jason

Re: Compiling to Parrot

[Jerome Quelin]

Dan Sugalski wrote:
> If you follow the calling conventions, then yes you'll be able to
> call python/ruby/perl/befunge routines from Lua code, and vice versa.

No, you won't be able to call befunge routines from Lua, because:
 - befunge does not know how to define subroutines (at least befunge-93 
and befunge-98... maybe befunge-103?). Well, to be honest, maybe I'll 
introduce the hack I'm using in Inline::Befunge in order to have named 
subroutines.
 - befunge, because of its nature, _can't_ be compiled and is only 
interpreted. So, in order to call befunge subs, you'll have to embed a 
Befunge interpreter in your code.

Jerome
-- 
[EMAIL PROTECTED]

Re: L2R/R2L syntax

[Luke Palmer]

> Date: Tue, 21 Jan 2003 10:04:58 +
> From: Graham Barr <[EMAIL PROTECTED]>
> 
> If the function form of map/grep were to be removed, which has been
> suggested, and the <~ form maps to methods. How would you go about
> defining a utility module similar to List::Util that uses the same
> syntax as map/grep but without making the subs methods on the global
> ARRAY package ?

I don't know whether you can use multimethods to do it, but if you
can, it would probably go something like this:

sub wonk (@list: &code) is multi {
grep {!code()} <~ @list
}

So C would be called like a method, but still not have access to
C's private attributes as it's not a part of the class.

I don't know whether I like this or not.

Luke

Re: L2R/R2L syntax

[arcadi shehter]

Damian Conway writes:
 > Buddha Buck wrote:
 > > 
 > > Perl 5 allows you to do:
 > > 
 > >   $object->meth1->meth2->meth3;  # Perl5 chained method, L2R
 > > 
 > > Perl 6 will also allow you to do:
 > > 
 > >   $data  ~> sub1  ~>  sub2 ~> sub3;# Perl6 chained subs, L2R
 > > 
 > > Perl 5 allows you to to:
 > > 
 > >   sub3   sub2   sub1  $data;   # Perl5 chained subs, R2L
 > > 
 > > Perl 6 will also allow you to do:
 > > 
 > >   meth3 <~ meth2 <~ meth1 <~ $Xbject  # Perl 6 chained methods, R2L
 > > 
 > > All four syntaxes will be available in Perl 6, modulo the fact that '->' 
 > > is now spelled '.'
 > > 
 > > The additional functionality that when the last sub or method in the ~> 
 > > and <~ is a variable an assigment is done is a convenience issue.
 > 

will something like that work ? and how ~> distinguish between  = and
:= ? 

 @source ~> part [
 /foo/, 
 /bar/, 
 /zap/ ]  
 ~> (@foo,@bar,@zap) 


the issue is : what happens if function returns more than one
variables . 

It seems that it is not very bad idea to have some special (lexical )
variable similar to $0 for regexes that is set after
grep/part/sort/or_may_be_something_userdefined have done its work and
then ( here $0 is a placeholder for that variable ) : 


 @source ~> part [
 /foo/ => @foo, 
 /bar/ => @bar 
 /zap/ => @zap ] ; 
$0{'@foo'} ~> map { ... } ~> @foo; 
$0{'@bar'} ~> map { ... } ~> @bar; 
$0{'@zap'} ~> map { ... } ~> @zap; 

but maybe that may be stilll shortened .  the idea ( maybe bad ) is to
have "named" or "numbered" (pseudo)pipes similar to having named or
numbered arguments.

 @source |> part [
 /foo/ => "foo", 
 /bar/ => "bar" 
 /zap/ => "zap" ]  
|foo> map { ... } |> @foo, 
|bar> map { ... } |> @bar, 
|zap> map { ... } |> @zap ; 

So |foo> is "undone" by perl arranging temporal variable after the
action of part and then feeding this temporal variable to the rest of
pipeline. that also means that |foo> "remembers" the return values
_only_ from the thing on its _closest_ left . 

then something like that can be made to work :

 @source |> grep { ... } 
|ok>  map { ... } |> @foo, 
|nok> map { ... } |> @bar  ; 






I am not sure this is a good solution 
but I think that "purge" and L2R-R2L threads of this maillist have to
be more close somehow. 

arcadi 


  

Re: L2R/R2L syntax

[Michael Lazzaro]

On Tuesday, January 21, 2003, at 02:04  AM, Graham Barr wrote:

If the function form of map/grep were to be removed, which has been 
suggested,
and the <~ form maps to methods. How would you go about defining a 
utility
module similar to List::Util that uses the same syntax as map/grep but
without making the subs methods on the global ARRAY package ?

If you want the method to be available everywhere, you probably 
_should_ make it a method of the global Array class.  More typically, 
perhaps, you'd only be using your new method to operate on certain 
arrays that you use, in which case you would make a new class for those 
particular arrays, so your new method would work only on the specific 
arrays you intended it to:

   class MyArray is Array {
   method foo_grep (Code $test) returns MyArray {
   ...
   }
   }

   my @a is MyArray = (1..10);
   my @b = @a.foo_grep {...};
   my @c = foo_grep {...} <~ @a;   # identical

I don't see any problem (other than maybe a philosophical objection) 
with making them methods of Array, though, if they're valuable enough.  
That certainly would seem the common Perl thing to do.

MikeL

Re: Why C needs work (was Re: L2R/R2L syntax)

[Michael Lazzaro]

On Monday, January 20, 2003, at 04:33  PM, Michael Lazzaro wrote:

But both the OO and pipeline syntaxes do more to point out the noun, 
verb, and adjective of the operation.
  

Adverb.  The {...} part is an adverb, not an adjective.  Sorry there.

MikeL

Re: L2R/R2L syntax

[Graham Barr]

On Tue, Jan 21, 2003 at 09:20:04AM -0800, Michael Lazzaro wrote:
> 
> On Tuesday, January 21, 2003, at 02:04  AM, Graham Barr wrote:
> > If the function form of map/grep were to be removed, which has been 
> > suggested,
> > and the <~ form maps to methods. How would you go about defining a 
> > utility
> > module similar to List::Util that uses the same syntax as map/grep but
> > without making the subs methods on the global ARRAY package ?
> 
> If you want the method to be available everywhere,

But I don't

> you probably 
> _should_ make it a method of the global Array class.

Thats like trying to wite a whole perl5 application in main
without any packages

>  More typically, 
> perhaps, you'd only be using your new method to operate on certain 
> arrays that you use, in which case you would make a new class for those 
> particular arrays, so your new method would work only on the specific 
> arrays you intended it to:

Thats not always possible. Those Arrays may be passed to me from
somewhere else, so I have no control over thier class.

> I don't see any problem (other than maybe a philosophical objection) 
> with making them methods of Array, though, if they're valuable enough.  
> That certainly would seem the common Perl thing to do.

No, namespaces were invented for a reason.

Graham.

Perltalk

[Thom Boyer]

Smylers [mailto:[EMAIL PROTECTED]] wrote:

> And an alternative
> spelling for the assignment operator[*0] doesn't strike me as something
> Perl is really missing:
> 
>   $msg <~ 'Hello there';
>   $msg = 'Hello there';


I still remember the first time I saw a computer program, before I had
learned anything about programming myself. A friend showed me his first
Fortran program, and it included the following line:

  N = N + 1

I stared at that in puzzlement for a long minute, and then said "That sure
isn't true for any value of N that *I* know of!" Then he told me that "="
doesn't mean "equals" in Fortran (no, *that's* spelled "EQ" :-). 

I've always been bothered by this misuse of mathematical notation, which is
used in an incredibly bewildering array of computer programming languages.
On the other hand, I've never been a fan of the ":=" spelling of assignment,
either. I always thought that "<-" was much better, except for the pitfall
that humans are likely to misread "a<-5" as a comparison. 

One of the most... er, *interesting*, dodges I've seen in this area is the
one used by Squeak (a Smalltalk variant). Squeak spells assignment with an
underscore ("_"), but the Squeak system *draws* it as a left-pointing arrow.
Hey, I know: let's not bother with Unicode...let's just reassign a few ASCII
control characters for Perl's use!   :-)

I, for one, could live with "<~" as the only assignment operator. But I only
suggest it tongue in cheek.



Speaking of Squeak, I notice that Buddha Buck just posted a
Smalltalk-translated-to-Perl implementation of the if-operator:
> class True is Bool is singleton {
>...
> our True true is builtin;
>etc.

which even includes the notion that the implementation of True and False is
immutable, so that the code generator has a ghost of a chance of knowing
what to do!

That was followed by Austin Hastings' post:

> log $user onto $system.
> log $message to $stderr.
> l2x = log 2 * log $x;   # Don't check my math, please. :-)
> ...
> sub log($n) { ... }
> sub log _ onto($user; &_ ; $machine) { ... }
> sub log _ to($message; &_ ; $stream) { ... }

which is a recycling of Smalltalk's "inject:into:"-style operators. I have
to admit that I *like* the idea of being able to define those kinds[1] of
operators; they can really add to the clarity of the code. I just don't want
to have to write the parser!
[1] What *do* you call this style of operator -- intermingled-fix?

Looks like we've got some Smalltalk fans here. What say we start a new
mailing list for designing Perltalk?  :-)

=thom
Riker: "They were just sucked into space."
Data:  "Blown, sir." 
Riker: "Sorry, Data."
Data:  "Common mistake, sir."
(The Naked Now) 

RE: A proposal on if and else

[Thom Boyer]

Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED]] wrote:
> The tokeniser could send two tokens "else" and "if" whenever it
> recognizes the keyword "elsif" -- so this isn't a problem.

The primary advantage, to my mind, in using C, is that it eliminates
the dangling-else ambiguity -- so splitting it in half removes almost ALL
the value of even having an C keyword.

=thom
"More people worry themselves to death than bleed to death." --
_Tunnel_in_the_Sky_, Robert Heinlein

Re: Perltalk

[Mark J. Reed]

On 2003-01-21 at 11:09:21, Thom Boyer wrote:
> One of the most... er, *interesting*, dodges I've seen in this area is the
> one used by Squeak (a Smalltalk variant). Squeak spells assignment with an
> underscore ("_"), but the Squeak system *draws* it as a left-pointing arrow.
There's a history behind that particular choice; before the ISO-8859
standardization, people got the characters they needed by making
"mostly-ASCII" character sets that differed in small ways from the
original US standard.  Having a left-pointing arrow in place of the
underscore was a common variant (used in, for instance, PET ASCII
on Commodore computers, which also had other substitutions, such
as the letter pi in place of tilde, and the British pound symbol
in place of backslash).  

Assignment has been written as a left arrow in pseudocode for
decades, but because the character was left out of ASCII (although
it's in EBCDIC), its use within actual languages has been pretty
much limited to those which already specify their own character set
and/or glyph display anyway (such as APL).   I do know of at
least one Pascal derivative that uses '<-' as a synonym for ':=',
requiring whitespace if your intent is the relational operator followed
by unary minus.

Squeak does, incidentally, also let you use := for assignment, which is
the standard for ASCII Smalltalk.

-- 
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G  | [EMAIL PROTECTED]
Atlanta, GA 30348  USA   | +1 404 827 4754

Re: Compiling to Parrot

[Christopher Armstrong]

On Tue, Jan 21, 2003 at 08:41:47AM +, Simon Wistow wrote:
> Speaking of games, it would be interesting to see Parrot be used in that
> direction. A lot of games currently are pretty much developed along the
> lines of 'custom scripting language interfaced to custom game engine'

One of the reasons I'm interested in Parrot -- I'm hoping that it's
going to have some secure execution facilities built-in from the
ground up (to facilitate user-code on virtual world servers) :-)

-- 
 Twisted | Christopher Armstrong: International Man of Twistery
  Radix  |  Release Manager,  Twisted Project
-+ http://twistedmatrix.com/users/radix.twistd/

Re: [perl #20315] [PATCH] eval - inter code segment branches

[Leopold Toetsch]

Jason Gloudon wrote:


On Tue, Jan 21, 2003 at 12:08:29AM +0100, Leopold Toetsch wrote:



Here is a proposal for inter code segment jumps:

The assembler (imcc) can recognize when a branch ins goes to a different
code segment.

For such a branch, imcc generates this opcode seqence:

  inter_cs
  if i, ic # or whatever



Why do we need branches to go to different code segments ?  


Because of this nasty piece of little code:
t/syn/eval_3.imc:

# #!/usr/bin/perl -w
# my $i= 5;
# LAB:
#$i++;
#eval("goto LAB if ($i==6)");
#print "$i\n";
#
# 7
#

.sub _test
I1 = 5
$S0 = ".sub _e\nif I1 == 6 goto LAB\nend\n.end\n"
compreg P2, "PIR"
compile P0, P2, $S0
LAB:
inc I1
invoke
print I1
print "\n"
end
.end




... I think the
expectation has been that control transfers between segments would have their
own op, because separate code segments would generally coincide with subs,
closures or at least blocks, that have specific entry points.



The problem is, that the "invoke" calls a different code segment, which 
eventually  branches back.
Parsing the eval code into the same code segment in not possible, we 
can't expand code segments, or let's say not easily, except (if even 
possible) with invalidating prederef and JIT code, and restarting. This 
is IMHO too expensive to go that road.

The proposed "inter_cs" op is such a special op, but suitable for all 
branches. E.g. "inter_cs ; bsr _somewhere"


Maybe Dan could give us a hint about the closure/block/byte code segment
relationship.


I just can tell you from imcc's POV. Everything compiled in one sequence 
(e.g. all subs of all files) could be one code segment. As soon as you 
start running the code, and you want to compile again, produced bytecode 
has to go into a different code segment. Of course, it could be more 
fine grained, but not less.

leo

Re: The parrot crashes...

[blair christensen]

On Tue, Jan 21, 2003 at 01:53:26PM +0100, Leopold Toetsch wrote:
> blair christensen wrote:
> 
> >On Mon, Jan 20, 2003 at 02:09:10PM -0500, Dan Sugalski wrote:
> >
> >>Rather badly, actually. All the tests that involve parrot currently 
> >>segfault in the NCI mark routine. At least on OS X, I'm not sure 
> >>about other platforms.
> 
> >(gdb) bt
> >#0  0x1a8638 in pobject_lives ()
> >#1  0x1bcc78 in Parrot_NCI_mark ()
> 
> 
> Is this with my patch (in CVS) already applied?

Yes.

I just did a realclean, cvs up, configure, make, and make test.

Lots of core files and as the last tinderbox report for this box
shows [0], a lot of failed tests.  Parrot has never been completely
happy on this box but it seems to have taken a turn for the worse.

blair.

[0] 

Re: The parrot crashes...

[Simon Glover]

 Here's another data-point, for Linux/x86: with a fresh check-out, parrot
 is passing all of its tests, but most of the imcc tests are failing.
 Specifically, I get:

 Failed Test   Stat Wstat Total Fail  Failed  List of Failed
 --
 t/syn/clash.t5  1280 55 100.00%  1-5
 t/syn/const.t3   768 33 100.00%  1-3
 t/syn/eval.t 2   512 32  66.67%  1-2
 t/syn/labels.t   3   768 33 100.00%  1-3
 t/syn/namespace.t3   768 33 100.00%  1-3
 t/syn/scope.t3   768 33 100.00%  1-3
 1 subtest skipped.
 Failed 6/9 test scripts, 33.33% okay. 19/24 subtests failed, 20.83% okay.

 Closer examination suggests that all of these tests are failing because
 imcc is sgefaulting; a representative backtrace is:

 Program received signal SIGSEGV, Segmentation fault.
 0x080dfb0a in pobject_lives ()
 (gdb) bt
 #0  0x080dfb0a in pobject_lives ()
 #1  0x080ec252 in Parrot_NCI_mark ()
 #2  0x080dfe94 in trace_active_PMCs ()
 #3  0x080e03ac in Parrot_do_dod_run ()
 #4  0x080e4cdd in more_traceable_objects ()
 #5  0x080e4d7c in get_free_object ()
 #6  0x080df260 in get_free_buffer ()
 #7  0x080df61a in new_bufferlike_header ()
 #8  0x080b60e3 in list_new ()
 #9  0x080e51ff in Parrot_Array_init ()
 #10 0x080b76ae in setup_argv ()
 #11 0x080b7834 in Parrot_runcode ()
 #12 0x0805693a in main ()

 ...which looks to be related to the problem people are encountering on
 the other platforms.

 Hope this is useful,
 Simon

Re: Objects, finally (try 1)

[Piers Cawley]

Dan Sugalski <[EMAIL PROTECTED]> writes:

> At 3:06 PM -0500 1/15/03, Christopher Armstrong wrote:
>>On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
>>>  At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
>>>  >But who knows, maybe it could be made modular enough (i.e., more
>>>  >interface-oriented?) to allow the best of both worlds -- I'm far too
>>>  >novice wrt Parrot to figure out what it'd look like, unfortunately.
>>>
>>>  It'll actually look like what we have now. If you can come up with
>>>  something more abstract than:
>>>
>>>callmethod P1, "foo"
>>>
>>>  that delegates the calling of the foo method to the method dispatch
>>>  vtable entry for the object in P1, well... gimme, I want it. :)
>>
>>>  I'll add "define method dispatch more" to the list o' stuff for the
>>>  next edit of the proposal.
>>
>>I'll help you along by offering this explanation of how instance
>>methods work in Python. (sorry if you're already familiar with this
>>stuff, but it's in my best interest to make sure you are ;-))
>>
>>When you say something like `o.foo()', it translates into these steps:
>>
>>  1) LOAD_NAME 'o'
>>  2) LOAD_ATTR 'bar'
>>  3) CALL_FUNCTION
>>
>>#2 has extra magic. What I mean is, when you LOAD_ATTR a function from
>>a *class*, you just get back a plain old `unbound method'. When you
>>LOAD_ATTR from an *instance*, and (after failing to find an instance
>>attribute) the attribute is found on its class, you get a `bound
>>method', which basically means that Python has "curried" that method
>>so the first argument is automatically passed -- that first argument
>>is the instance which you LOAD_ATTRd from. This is why you see all
>>those python methods with the first argument being `self', and rarely
>>see code which explicitly passes that first argument.
>>
>>Now, like I said, this magic is done in LOAD_ATTR, not CALL_FUNCTION,
>>so you can take that bound method object and do whatever you want with
>>it before calling it.
>>
>>Here's an interesting code snippet which also demonstrates the fact
>>that methods are just attributes.
>
> Hrm, interesting. Single symbol table for methods and attributes,
> though that's not too surprising all things considered. That may make
> interoperability interesting, but I was already expecting that to some
> extent.

Isn't that, essentially what Perl 6 will have too? It's just that the
sigil will be taken to be part of the symbol. Thus a method's symbol
will be &method (method?). Presumably one would first check with the
object for a matching symbol and then search up the class tree until
something comes up (which could then be cached back on the object, though
that would require some smarts on the object's binding to the method
so that Parrot could distinguish between cached methods and 'custom'
methods (hopefully the binding would also contain information about
where a cached method was found so that SUPER:: type dispatch could be
done dynamically instead of using the current hack based on the
package in which the C<< $self->SUPER::method() >> call was compiled
(what me? On a hobby horse? Never!)))

Hmm... was that a paragraph or an S-expression?

-- 
Piers

Re: Perltalk

[Smylers]

Thom Boyer wrote:

> Smylers [mailto:[EMAIL PROTECTED]] wrote:
> 
> > And an alternative spelling for the assignment operator[*0] doesn't
> > strike me as something Perl is really missing:
> > 
> >   $msg <~ 'Hello there';
> >   $msg = 'Hello there';
> 
> I still remember the first time I saw a computer program ...:
> 
>   N = N + 1
> 
> ... "That sure isn't true for any value of N that *I* know of!" ...
> I've always been bothered by this misuse of mathematical notation, ..

In this respect I was fortunate that the first language I saw was
a Basic[*0] dialect which used C:

  LET n = n + 1

which avoids much of the confusion, at the annoyance of having to type a
keyword for such a common operation.  I at least slightly share your
botheredness -- I found it distinctly odd when I first saw the C
being dropped -- but try not to think about it most of the time, having
just got accustomed to the "misuse".

  [*0]  Please note I'm specifically _not_ commenting on how fortunate
  or otherwise that was in _other_ respects.

> I always thought that "<-" was much better ...  I, for one, could live
> with "<~" as the only assignment operator. But I only suggest it
> tongue in cheek.

My first version of the message you quoted above had a footnote with
exactly that tongue-in-cheek suggestion, saying that, as an alternative,
if right-left streams are to be kept then could we drop C<=>.

This has several plausible-sounding advantages, including the one you
highlight, making assignment completely reversible (allowing statements
which emphasize the value rather than the variable having equal status
to the usual way round), and avoiding the common beginner confusion of
trying to use C<=> to test for equality.

But then I remembered assignent short-cut operators.  

  $msg ~<~ "Your current balance is $total.\n";

Regardless of where your font puts the squiggles, I just don't see that
looking like a concatenation operator ...

Smylers

TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])

[David Storrs]

On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote:
> Paul Johnson wrote:
> 
> > Well, I'll be pretty interested to discover what cause is deemed more
> > deserving than Larry, Perl 6 or Parrot.  The P still stands for Perl,
> > right?
> 
> True. But I suspect that TPF's position is that, to many people, Perl 6 is
> far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, or 
> Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or any of 
> a hundred other projects on which their job depends on a daily basis.
> 
> Supporting those efforts is important too, and TPF has only limited resources.

Correct me if I'm wrong, but isn't the one thing that all those
projects have in common...well...Perl?  And isn't Larry the guy to
whom we owe the existence of Perl?  I'm not fortunate enough to be
using Perl in my job, but I'm still more than happy to pony up for a
donation, purely from gratitude. 

This is something along the lines of the applied research vs basic
research question.  What Larry is doing pretty much amounts to basic
research that will help all of these other projects in the long run.


--Dks

Re: L2R/R2L syntax

[Piers Cawley]

Graham Barr <[EMAIL PROTECTED]> writes:

> On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
>> > What benefit does C<< <~ >> bring to the language?
>> 
>> Again, it provides not just a "null operator" between to calls, but
>> rather a rewrite of method call syntax.  So:
>> 
>>   map {...} <~ grep {...} <~ @boing;
>> 
>> is not:
>> 
>>   map {...} grep {...} @boing;
>> 
>> But rather:
>> 
>>   @boing.map({...}).grep({...});
>
> This is not a for or against, but there is something that has been
> bugging me about this.
>
> Currently in Perl5 it is possible to create a sub that has map/grep-like
> syntax, take a look at List::Util
>
> If the function form of map/grep were to be removed, which has been
> suggested, and the <~ form maps to methods. How would you go about
> defining a utility module similar to List::Util that uses the same
> syntax as map/grep but without making the subs methods on the global
> ARRAY package ?

Well, I very much hope that the function form won't be going away;
functional style is bloody useful dammit and I don't want to be forced
to add line noise just to make those who have a woody for
orthogonality happy. Anyhoo, if it *does* go away, then it should be
possible to set up an appropriate set of multiply dispatched generic
functions.

  sub reduce ( &block, $init, *@array ) is multi {
@array.reduce(&block, $init);
  }

  sub reduce ( &block, $init, Collection $collection ) is multi {
$collection.reduce(&block, $init);
  }

  sub reduce ( $expr is qr//,
   $init, *@array ) is immediate, is multi {
@array.reduce( $expr, $init);
  }

  sub reduce ( $expr is qr/Perl::term/,
   $init, Collection $collection ) is immediate, is multi
  {
$collection.reduce($expr, $init);
  }

Though I'm sure Damian will be long eventually to correct my
syntax. I'm getting this weird feeling of deja vu though...

-- 
Piers

Re: TPF donations

[Piers Cawley]

David Storrs <[EMAIL PROTECTED]> writes:

> On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote:
>> Paul Johnson wrote:
>> 
>> > Well, I'll be pretty interested to discover what cause is deemed more
>> > deserving than Larry, Perl 6 or Parrot.  The P still stands for Perl,
>> > right?
>> 
>> True. But I suspect that TPF's position is that, to many people,
>> Perl 6 is far less important than mod_Perl, or DBI, or HTML::Mason,
>> or POE, or PDL, or Inline, or SpamAssassin, or XML::Parser, or
>> YAML, or the Slashcode, or any of a hundred other projects on which
>> their job depends on a daily basis.
>> 
>> Supporting those efforts is important too, and TPF has only limited
>> resources.
>
> Correct me if I'm wrong, but isn't the one thing that all those
> projects have in common...well...Perl?  And isn't Larry the guy to
> whom we owe the existence of Perl?  I'm not fortunate enough to be
> using Perl in my job, but I'm still more than happy to pony up for a
> donation, purely from gratitude.
>
> This is something along the lines of the applied research vs basic
> research question.  What Larry is doing pretty much amounts to basic
> research that will help all of these other projects in the long run.

I shall certainly be thinking long and hard about passing the perl.com
payments to TPF if Larry's not being funded this year (if I should
become a member of the copious free time club there'll be no thought
necessary I'm afraid, income is income). Which reminds me, I need to
check (as I have naively assumed) that the money is automagically
being paid to TPF without my having to muck about with invoices and
the like. Hmm...

Seriously, I think that not putting some funding Larry's way is a big
mistake. I'm not saying he should be the only recipient of funds, but
he *is* a special case.

Re: Compiling to Parrot

[Andrew Rodland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday 21 January 2003 07:16 am, Simon Wistow wrote:
> On Tue, Jan 21, 2003 at 12:14:29PM +0100, K Stol said:
> > LUA seems to be a very nice language, but how is this language to be
> > used? Is it in combination with a C program one would write? Or could it
> > be used as a stand alone application? In that case, it seems to me it
> > would be interesting to have a LUA->Parrot (with IMCC in between)
> > compiler.
>
> As I said, I only know it from a games context where it's used as the
> basis for the scripting engine. AIUI it can be used a a standalone
> language as well.
>
> From what I know it's specifically designed to be a portable, fast,
> lightweight platform for extending platforms and providing a framework
> for implementing domain specific languages.

IIRC, it's also being used in some browsers (elinks, at least) as a 
lightweight stand-in for javascript. Not that anyone actually uses it, of 
course.

- --hobbs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+La/16xdpaulLLFURAhCQAJ9Brp3HKF97j2Ocgs3PbXQVf9tLBgCfX9pE
c0n2Kb/mjg6ND7t5/gvX9FQ=
=j0px
-END PGP SIGNATURE-

Re: L2R/R2L syntax

[Michael Lazzaro]

On Tuesday, January 21, 2003, at 12:26  PM, Piers Cawley wrote:

Though I'm sure Damian will be long eventually to correct my
syntax. I'm getting this weird feeling of deja vu though...


When I come home from work each day, I can see my dog eagerly waiting 
at the window, just black snout and frenetically wagging tail visible 
over the sill.

I often think Larry and Damian must feel that way about this group.  
Poor, comical beasts, but so eager and well-meaning.  We greet them so 
enthusiastically when they've arrived, it's hard for them to get too 
mad at us.  Even when they discover we've peed on the carpet while 
they've been gone, and they have an awful mess to clean up.

MikeL

"Arc: An Unfinished Dialect of Lisp"

[Rich Morin]

I just finished skimming this write-up, located at

  http://paulgraham.com/arcll1.html

I'm not a Lisp enthusiast, by and large, but I think he makes some
interesting observations on language design.  Take a look if you're
feeling adventurous...

-r
--
email: [EMAIL PROTECTED]; phone: +1 650-873-7841
http://www.cfcl.com/rdm- my home page, resume, etc.
http://www.cfcl.com/Meta   - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series
http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection

Re: L2R/R2L syntax

[Piers Cawley]

Michael Lazzaro <[EMAIL PROTECTED]> writes:

> On Tuesday, January 21, 2003, at 12:26  PM, Piers Cawley wrote:
>> Though I'm sure Damian will be long eventually to correct my
>> syntax. I'm getting this weird feeling of deja vu though...
>
> When I come home from work each day, I can see my dog eagerly waiting
> at the window, just black snout and frenetically wagging tail visible
> over the sill.
>
> I often think Larry and Damian must feel that way about this group.
> Poor, comical beasts, but so eager and well-meaning.  We greet them so
> enthusiastically when they've arrived, it's hard for them to get too
> mad at us.  Even when they discover we've peed on the carpet while
> they've been gone, and they have an awful mess to clean up.

Heh. I wouldn't mind, but I'm getting the very strong feeling that
this is about the third time we've returned to this particular pile of
vomit and spread it around differently.

Everyone, please don't take that perjoratively, I just saw the
opportunity to extend Mike's metaphor further than it should be
expected to go, and I took it.

Right, back to the summary.

-- 
Piers

Re: Why C needs work (was Re: L2R/R2L syntax)

[Smylers]

Michael Lazzaro wrote:

>  On Monday, January 20, 2003, at 12:30  PM, Smylers wrote:
> 
> > It was only on reading that (and discovering that you hadn't
> > previously known about the 'optional comma with closure argument'
> > rule) that I understood why you had previously been so in favour of
> > proposed new syntaxes: through a desire to banish the Perl 5 syntax.
>  
> Yes.  Again, it's not that I never knew about the perl5 rule,

Sorry, I wasn't meaning to suggest that you didn't know Perl 5; I was
specifically referring to your saying that you'd presumed that
conditions and loops were special cases in the grammar, but that
actually they'll be dealt with by the general Perl _6_ rule about commas
and closure arguments.

> it's that I _dislike_ the perl5 rule, ...

Oh.  That's "dislike" rather than "disliked"?  My question was
predicated on your declaration "I emphatically withdraw my objection",
which I took to mean that your knowledge of the infrared comma rule --
or whatever it's called -- meant you no longer disliked the Perl 5
syntax?

> as I dislike most special-case grammar rules.

So do I!  I was particularly impressed by the ultraviolet comma rule,
and how it avoids special cases, when Damian paraded it at a talk last
summer.

I also don't reckon it's _that_ special.  So long as the rule is that
such commas are optional, as distinct from their absence being
mandatory, then the rule is a very general one: commas may be omitted
where they aren't needed to delimit list items.  Obviously with string
and numeric values commas are always required:

  $a -1

They are the only way of determining op/term for the minus sign: a
single argument of one less than the value in C<$a>, or two arguments
with the second being minus one?

But closures can be unambiguously determined without commas.  Since
whitespace is no longer allowed in hash look-ups, space followed by an
open brace must be the start of a closure, and hence another argument.
Similarly once the closing brace has been reached the closure is ...
ahem, closed, so anything following must be a separate argument.

> If we dropped C, etc., we could drop the inferred-comma rule as
> well (unless we're really successful in making C a simple
> function, in which case we need the rule anyway, so who cares?)

I guess that's the crucial issue.  Since it was Damian saying that it is
possible to have C and friends as functions -- and since this was
something that'd already been dealt with before I joined this list, and
so presumably would've had any impossibility pointed out -- I believed
it to be true.

There's another sub-thread casting doubt on -- and trying to resolve --
the issue.  I completely agree that whether the infrared comma rule is
needed over there makes a big difference to its use here.

But I think I disagree about the "who cares" part ...

> But the inferred-comma rule is tangential to my dislike of the current
> C syntax.  I'd dislike C, and like pipelines, even if the
> inferred-comma rule wasn't there.

As you've not doubt noticed, I'm the opposite: I like C and don't
(yet?) see the point of right-left pipelines.  (That means not that I
claim you're in some way 'wrong' to have those preferences, merely that
we think differently to each other.)  There's one Perl slogan that'd
suggest having both ways in the language, so both of us get to code in
the way we like.

Countering that is the risk of adding too many ways of doing things and
just causing confusion for everybody with all the different ways of
invoking functions/methods on data.  Hence my quibble with "who cares":
I could probably be persuaded that it's 'better' for the language not to
have the Perl 5 syntax, my preference, than to have so many alternative
syntaxes.  (I'm not sure.)

> > Mike ... do you still find right-left pipelines as compelling as
> > you've previously argued?
> 
> Yes, very much so.  ... I've seen quite a few newbies struggle with
> the C syntax;

Me too.  The most-strugglable bit for many has been the right-left data
flow, that you start by typing where you want the data to end up, then
the process it goes through last, then the process it goes through
first, and lastly the data that's being processed.  Left-right pipelines
should be great at fixing this.

> the most frequent mistake is to reverse the order of the arguments,
> saying
> 
> map @a, {...}

That happens if you conceptualize C as taking two arguments.  In my
mind C operates on items in a list (and it just so happens that
in Perl an array provides a list):

  map { ... } $a, $b, $c;

So C takes _many_ arguments, and one of these arguments is not like
the others.  And it makes sense to put the 'special' argument first.
(That's also how I remember which way round things like C are.)

Thinking of it as operating on a list of things also helps to emphasize
that C processes just a single item at a time, that it isn't an
agregate operation on the items as a group.

> (Another common one is to not understa

Re: A proposal on if and else

[Smylers]

Thom Boyer wrote:

> The primary advantage, to my mind, in using C, is that it
> eliminates the dangling-else ambiguity -- so splitting it in half
> removes almost ALL the value of even having an C keyword.

Surely it's the compulsory braces, even with a single statement, which
eliminates that problem?

These look ambiguous to me, with no C required:

  if test1
if test2
  statement_A;
else
  statement_B;

  if test1
if test2
  statement_A;
  else
statement_B;

Where as putting the braces in there always disambiguates which C
and C goes with:

  if test1 {
if test2 {
  statement_A;
}
else {
  statement_B;
}
  }

  if test1 {
if test2 {
  statement_A;
}
  }
  else
  {
statement_B;
  }

Smylers

Re: Re: TPF donations

[John Adams]

This is a valuable discussion, and I hope people will take this up on 
[EMAIL PROTECTED] as well.

Thanks,

  John A
  see me fulminate at http://www.jzip.org/

Re: Perltalk

[Austin Hastings]

--- Thom Boyer <[EMAIL PROTECTED]> wrote:
> Smylers [mailto:[EMAIL PROTECTED]] wrote:
> 
> > And an alternative
> > spelling for the assignment operator[*0] doesn't strike me as
> something
> > Perl is really missing:
> > 
> >   $msg <~ 'Hello there';
> >   $msg = 'Hello there';
> 
> 
> I still remember the first time I saw a computer program, before I
> had
> learned anything about programming myself. A friend showed me his
> first
> Fortran program, and it included the following line:
> 
>   N = N + 1
> 
> I stared at that in puzzlement for a long minute, and then said "That
> sure
> isn't true for any value of N that *I* know of!" Then he told me that
> "="
> doesn't mean "equals" in Fortran (no, *that's* spelled "EQ" :-). 
> 
> I've always been bothered by this misuse of mathematical notation,
> which is
> used in an incredibly bewildering array of computer programming
> languages.
> On the other hand, I've never been a fan of the ":=" spelling of
> assignment,
> either. I always thought that "<-" was much better, except for the
> pitfall
> that humans are likely to misread "a<-5" as a comparison. 
> 
> One of the most... er, *interesting*, dodges I've seen in this area
> is the
> one used by Squeak (a Smalltalk variant). Squeak spells assignment
> with an
> underscore ("_"), but the Squeak system *draws* it as a left-pointing
> arrow.
> Hey, I know: let's not bother with Unicode...let's just reassign a
> few ASCII
> control characters for Perl's use!   :-)
> 
> I, for one, could live with "<~" as the only assignment operator. But
> I only
> suggest it tongue in cheek.
> 

Hey! Don't make me come over there...

> 
> 
> Speaking of Squeak, I notice that Buddha Buck just posted a
> Smalltalk-translated-to-Perl implementation of the if-operator:
> > class True is Bool is singleton {
> >...
> > our True true is builtin;
> >etc.
> 
> which even includes the notion that the implementation of True and
> False is
> immutable, so that the code generator has a ghost of a chance of
> knowing
> what to do!
> 
> That was followed by Austin Hastings' post:
> 
> > log $user onto $system.
> > log $message to $stderr.
> > l2x = log 2 * log $x;   # Don't check my math, please. :-)
> > ...
> > sub log($n) { ... }
> > sub log _ onto($user; &_ ; $machine) { ... }
> > sub log _ to($message; &_ ; $stream) { ... }
> 
> which is a recycling of Smalltalk's "inject:into:"-style operators. I
> have
> to admit that I *like* the idea of being able to define those
> kinds[1] of
> operators; they can really add to the clarity of the code. I just
> don't want
> to have to write the parser!
> [1] What *do* you call this style of operator -- intermingled-fix?
> 
> Looks like we've got some Smalltalk fans here. What say we start a
> new
> mailing list for designing Perltalk?  :-)

I can't even smell Spalltalk.

=Austin

Re: TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])

[Austin Hastings]

--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote:
> > Paul Johnson wrote:
> > 
> > > Well, I'll be pretty interested to discover what cause is deemed
> more
> > > deserving than Larry, Perl 6 or Parrot.  The P still stands for
> Perl,
> > > right?
> > 
> > True. But I suspect that TPF's position is that, to many people,
> Perl 6 is
> > far less important than mod_Perl, or DBI, or HTML::Mason, or POE,
> or PDL, or 
> > Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode,
> or any of 
> > a hundred other projects on which their job depends on a daily
> basis.
> > 
> > Supporting those efforts is important too, and TPF has only limited
> resources.
> 
> Correct me if I'm wrong, but isn't the one thing that all those
> projects have in common...well...Perl?  And isn't Larry the guy to
> whom we owe the existence of Perl?  I'm not fortunate enough to be
> using Perl in my job, but I'm still more than happy to pony up for a
> donation, purely from gratitude. 
> 
> This is something along the lines of the applied research vs basic
> research question.  What Larry is doing pretty much amounts to basic
> research that will help all of these other projects in the long run.

Sure. But managing the funding budget isn't a business, where basic
research will enable more income. It's the allocation of scarce
resources. And from that viewpoint, Larry and P6 is an iceberg, just
cruising along hoping to gash a massive hole in the support/maintenance
schedule, because once P6 rolls all the other stuff has to be sorted,
ported, and supported.

If I was in charge of the TPF funding budget, I'd be yearning to pick
up the phone whenever I saw an episode of "The Sopranos"(*)...


=Austin

Re: Why C needs work (was Re: L2R/R2L syntax)

[Michael Lazzaro]

On Tuesday, January 21, 2003, at 01:31  PM, Smylers wrote:

Michael Lazzaro wrote:

it's that I _dislike_ the perl5 rule, ...


Oh.  That's "dislike" rather than "disliked"?  My question was
predicated on your declaration "I emphatically withdraw my objection",
which I took to mean that your knowledge of the infrared comma rule --
or whatever it's called -- meant you no longer disliked the Perl 5
syntax?


I still dislike it, but if a variation upon it means we can make things 
like C, C, etc. semi-normal functions, instead of cases within 
the grammar, then I think everyone agrees that would be a Good Thing.  
Keeping one grammar special case in return for not having a dozen 
others -- yeah, I'll sign up for that.

I don't loath the old C syntax to the point where I'd just die if 
it were there.  And I don't expect we'd really get rid of it, it's too 
intrinsic to Perl5.  At very minimum, we'd have to keep the global 
functions around as a module you could load for Perl5-friendliness.

I do think OO & pipelines are the better, more generic way to do the 
same thing.  So I'd really like to see pipelines, even if they're just 
in addition to the old C style.  After that, it's just a question 
of whether the old style is worth the redundant declarations, which is 
purely a matter-of-taste thing.


the most frequent mistake is to reverse the order of the arguments,
saying
map @a, {...}

That happens if you conceptualize C as taking two arguments.


I think you're right about that.  And we have both:

   for (@a) {...}
and
   map {...} @a;

Which stings some newbies repeatedly, poor lads.



Was that an understandable explanation?  :-)


Yes.  Thanks, again.  Please don't take personally my disagreeing with
so much you've written!


On the contrary.  I'm just so happy someone understood what I was 
trying to say, I think I'm going to burst into tears...  Wait, no... 
OK, I'm better now.

MikeL

Re: Why C needs work (was Re: L2R/R2L syntax)

[Buddha Buck]

Smylers wrote:

Michael Lazzaro wrote:





And it provides a very visual way to define any pipe-like algorithm, in 
either direction:

   $in -> lex -> parse -> codify -> optimize -> $out;   # L2R

   $out <- optimize <- codify <- parse <- lex <- $in;   # R2L

It's clear, from looking at either of those, that they represent data
pipes.


Yes; that is nice.  I'm just not convinced that it's sufficiently nice
to require adding yet another way of passing data around to the
language.  I'm happy enough with the asymmetry that occurs just having
the arrows to indicate 'reverse flow' data.


The problem with this example is that the two lines deal with two 
different calling conventions, going by Damian's proposal...

Perl 5 has two different code calling conventions:  object oriented 
method calls, and procedural subroutine calls.

OO method calls are L2R already:

  $object.method1().method2().method3().method4();

Procedural subroutine calls are R2L already:

  sub4 sub3 sub2 sub1 $variable;

But there is no way to do OO method calls R2L, and there is no way to do 
procedural subroutine calls L2R.

Damian's ~> and <~ proposal fills in this gap:

  method4 <~ method3 <~ method2 <~ method1 <~ $Xbject;
  $variable ~> sub1 ~> sub2 ~> sub3 ~> sub4;

To the best of my knowledge, the following two WILL NOT WORK:

  sub4 <~ sub3 <~ sub2 <~ sub1 <~ $variable;
  $Xbject ~> method1 ~> method2 ~> method3 ~> method4

The first one tries to invoke the sub1 method of $variable, while the 
second tries to call the method1 function with $object as an argument. 
If either of these works, it's either coincidence or careful planning.

So the apparant symmetry between <~ and ~> isn't really there.

I like <~ and ~>, but I think that it will be a common mistake to think 
that $a ~> b~>c~>d can be reversed to give d<~c~, at least as currently 
formulated.

Re: Why C needs work (was Re: L2R/R2L syntax)

[Michael Lazzaro]

On Tuesday, January 21, 2003, at 02:38  PM, Buddha Buck wrote:

Michael Lazzaro wrote:

And it provides a very visual way to define any pipe-like algorithm, 
in either direction:
   $in -> lex -> parse -> codify -> optimize -> $out;   # L2R

   $out <- optimize <- codify <- parse <- lex <- $in;   # R2L

It's clear, from looking at either of those, that they represent data
pipes.
The problem with this example is that the two lines deal with two 
different calling conventions, going by Damian's proposal...


So the apparant symmetry between <~ and ~> isn't really there.

I like <~ and ~>, but I think that it will be a common mistake to 
think that $a ~> b~>c~>d can be reversed to give d<~c~, at least as 
currently formulated.

Agreed, it could be quite misleading.  Personally, I'd be happier if <~ 
and ~> worked _only_ on objects and methods, instead of arbitrary 
subs... but I understand the utility of the other way.

Of course, _I'd_ even prefer using <- and -> as the 'piping' operators, 
and having ~> or |> for pointy sub, because then $a->foo and $a.foo 
really _could_ be the same thing, 'cept for precedence.  But that's not 
gonna happen, and _I'm_ not gonna press it.  :-)

MikeL

Re: The parrot crashes...

[Leopold Toetsch]

blair christensen wrote:

and Simon Glover reported:


#0  0x1a8638 in pobject_lives ()
#1  0x1bcc78 in Parrot_NCI_mark ()


I dunno yet, why mark is called with an uninitialized struct_val. The 
mark function should only be called, if the corresponding flag is set.

For a first check, what's going on, I added init() again, which clears 
struct_val.

I still don't understand, why NCI's mark is called. These objects are 
only present in nci and (derived in) eval tests (and one pmc test or 
so). Wrong object numbering or such, which "make realclean" (the 
dependencies in the first place but, ...) should cope with.

Thanks for keekping on reporting this,
leo

Re: Perltalk

[Uri Guttman]

> "MJR" == Mark J Reed <[EMAIL PROTECTED]> writes:

  MJR> On 2003-01-21 at 11:09:21, Thom Boyer wrote:

  >> One of the most... er, *interesting*, dodges I've seen in this area
  >> is the one used by Squeak (a Smalltalk variant). Squeak spells
  >> assignment with an underscore ("_"), but the Squeak system *draws*
  >> it as a left-pointing arrow.

  MJR> There's a history behind that particular choice; before the ISO-8859
  MJR> standardization, people got the characters they needed by making
  MJR> "mostly-ASCII" character sets that differed in small ways from the
  MJR> original US standard.  Having a left-pointing arrow in place of the
  MJR> underscore was a common variant (used in, for instance, PET ASCII
  MJR> on Commodore computers, which also had other substitutions, such
  MJR> as the letter pi in place of tilde, and the British pound symbol
  MJR> in place of backslash).  

<- instead of underscore goes way back. the teletype (ASR33 and friends)
had <- on the keyboard and the print head. 

  MJR> Assignment has been written as a left arrow in pseudocode for
  MJR> decades, but because the character was left out of ASCII (although
  MJR> it's in EBCDIC), its use within actual languages has been pretty

it wasn't left out but the graphic morphed to underscore sometime in the
70's. the vt52, decterminals and such came out then and had underscore
instead of <-. the ascii code stayed the same.

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding 
Search or Offer Perl Jobs    http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class

Re: TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])

[Nicholas Clark]

On Tue, Jan 21, 2003 at 02:21:58PM -0800, Austin Hastings wrote:
> 
> --- David Storrs <[EMAIL PROTECTED]> wrote:

> > This is something along the lines of the applied research vs basic
> > research question.  What Larry is doing pretty much amounts to basic
> > research that will help all of these other projects in the long run.
> 
> Sure. But managing the funding budget isn't a business, where basic
> research will enable more income. It's the allocation of scarce

I'm not convinced that that is correct. Basic research may enable more
income. If it works. But at least 90% of basic research won't. Hence you
have to do a lot of it, but the odd time you get it right, it can be very
lucrative

> resources. And from that viewpoint, Larry and P6 is an iceberg, just
> cruising along hoping to gash a massive hole in the support/maintenance
> schedule, because once P6 rolls all the other stuff has to be sorted,
> ported, and supported.

I'm not quite following you - this looks like an argument against P6, because
its appearance will create a lot more work?

> If I was in charge of the TPF funding budget, I'd be yearning to pick
> up the phone whenever I saw an episode of "The Sopranos"(*)...

And this I don't follow at all, having never seen The Sopranos. So I'm
probably completely failing to address the points you are making


The problem I see with not funding Larry, is that if as a consequence
Larry has to get a job that prevents him from working on Perl 6, Perl 6
won't happen until he retires. Anyone can implement Perl 6 (although I
reckon we'd have a setback of many months on parrot if Dan stopped and
left, and more if other people dropped out as a result. But it can be
picked up by anyone capable). Not just anyone can design Perl 6.

The obvious counter argument is that if Perl 6 stops, Perl 5 as is won't go
away; Perl 5 is what we have; Perl 5 is what we are using, and Perl 5 is
good enough. However eventually everyone volunteering to work on it will
drift away. At which point it is stagnant, and no bugs get fixed. For some
reason, Perl 6 actually brought a lot of new blood and new momentum to Perl
5. I suspect Perl 5.8 would not have happened, or at least not have happened
yet, had Perl 6 not been around. Perl 6 may seem crazy, far fetched and long
term.  Yet it is bringing morale to Perl 5, suggesting that Perl does have a
future, and that maybe Perl 5 is worth working on. If Perl 5 doesn't feel
worth working on, then most will go away. I've been involved in development
communities before where the future has been pulled out from under our feet.
The community dissipates - there is more fun to be had elsewhere.

You may think that volunteers on Perl 5 are not important. You may not be
using Perl 5.8, and you may see no need to. Ever.

But if you're using 5.004, 5.005_03 or 5.6.1, and you have hit a bug in it,
how are you going to get it fixed? Currently bugs discovered in 5.8 are
actively being fixed (or at least ought to be - nag p5p if they aren't).
But a release of 5.6.2 looks unlikely, and 5.005_04 equally improbable.
How would you feel if there was never going to be a 5.8.1 either?
Would it affect your technology choice? Would it affect your
clients'/employers'?

Hence I would argue that if Perl 6 halts, Perl 5 stops looking credible
long term. Which I don't want to happen.

Currently this argument is shaky, because to an external observer, Larry
with funding unable to produce apocolypses due to other reasons is
indistinguishable from Larry unable to produce apocolypses due to lack of
funding. Except that there is visibly less money for anything else worthy.

Nicholas Clark

Re: [perl #20315] [PATCH] eval - inter code segment branches

[Jason Gloudon]

On Tue, Jan 21, 2003 at 08:21:42PM +0100, Leopold Toetsch wrote:

> >>For such a branch, imcc generates this opcode seqence:
> >>
> >>  inter_cs
> >>  if i, ic # or whatever
> 
> >Why do we need branches to go to different code segments ?  
> 
> 
> Because of this nasty piece of little code:
> t/syn/eval_3.imc:
> 
> # #!/usr/bin/perl -w
> # my $i= 5;
> # LAB:
> #$i++;
> #eval("goto LAB if ($i==6)");

Ok. Having inter_cs call DO_OP just seems more involved than it has to be.
How about a single self-contained inter-segment jump instruction.

Since the compiler knows when a branch is non-local it can always break a
non-local conditional branch into a conditional local branch to a non-local
branch instruction.

For example

if i, nonlocal

... not taken

can be expressed as

if i, TAKEN

... not taken
...

TAKEN: inter_jump nonlocal

-- 
Jason

Re: The parrot crashes...

[Leopold Toetsch]

blair christensen wrote:


(gdb) bt
#0  0x1a8638 in pobject_lives ()
#1  0x1bcc78 in Parrot_NCI_mark ()


Just one thought:

before my eval patch PerlHash's enum was 12, what now NCI has.
From PMC.pm (now):

   	NCI => 12,
PerlArray => 13,
PerlHash => 14,
PerlInt => 15,

leo

RE: Compiling to Parrot

[Paul Du Bois]

The advantage of Lua (at least for my project, which is a game) is that it
is quite easy to embed, and quite easy to customize.  The C API is small and
easily understandable (at the expense of being a little bit of a pain to
use), and the internals are simple and quite malleable.  The language itself
is pretty ugly IMHO.

So... I can't think of a good purpose of Lua/Parrot myself.  I'm not trying
to discourage you by any means!  If I were to embed a Parrot interpreter for
our next game (!) I'd happily leave Lua behind.

p

> Only thing I need to know before I can start is: what would the purpose be
> of a Lua to Parrot compiler? Lua is originally an embedded language for
> easy-scripting, as far as I understand. How could it be used when targeted
> to parrot? Would it be possible to call functions written in Lua
> (and which
> are then compiled to parrot) from (for example) a python script?
> (So: python
> script calls function writtenin Lua and compiled to parrot).
>
> Klaas-Jan