[perl #42919] [BUG] and [PATCH] overriding 'invoke' requires current object to be explicitly passed

[Allison Randal via RT]

Thanks, applied in r18535 with some modifications. Particularly, changed
the name of the flag from PARROT_ARG_OBJECT to PARROT_ARG_INVOCANT,
moved the code for handling object overrides of 'invoke' from
delegate.pmc to parrotobject.pmc, and kept the regression test for RT
#41732 (still relevant, it just has to check for "2 params" in the error
message instead of "1 params"). Also added a test for inherited 'invoke'
overrides.

Allison

Re: Is Perl 6 too late?

[herbert breunung]

> And to attract contributors, you have to have a convincing vision.

right

please make a decision for you to program in a language that has fame
or one that you like most. as moritz said the special variables are now 
better sorted and some changes you write about are too far from perls
basic principles, i thank that would not be perl anymore. but even for
demands like yours it is thought as 2 or 3 lisp-style macros could
turn perl6 into something your seems to want. except that one with
type recognition of course which i cant think of how to make this work
with an macro.

but hey since parrot also will read python you would not run too far
if you try python. i think you could only win if you try it. maybe youll find 
problems with python you didnt thought abd be than better informed 
of or found your  favoured programming lang.

best
herbert


> I'm only a distant observer of the Perl6 design process, so I might not
> be in the position to criticize Perl6.
> On the other hand, a distant view might be insightful.
> This is not intended to be a provocation.
> But I also think that there is a great opportunity to make _big_ changes
> to Perl to be even more competitive.
> But maybe Perl6 is probably too far defined to encounter big changes in
> some critical aspects.
> 
> As Ruby and Python are getting more and more attraction [1][2] I think
> they do something right, that Perl doesn't.
> What I think where both (especially Python) do better is in readable code.
> 
> What makes Perl hard to read is the excessive use of special characters
> (/\W/).
> In my opinion, reducing the use of those characters would make Perl a
> lot easier to read and also easier to write.
> Global variables with cryptic names, that no beginner can make any sense
> of by reading it. And after not working with "$<" for some months I
> can't remember it either, although I've got quite some Perl experience.
> 
> Additionally I'm not a friend of sigils: Typing them is relatively
> painful, for reading there is no advantage if you use an editor with
> decent syntax highlighting and the code looks more cryptic. The answer
> in Perl6 are twigils, great... One step backwards in my optinion.
> Most programming languages
> /C(++|#)?|Java(Script)?|Python|Ruby|Groovy/... don't need them. The only
> obvious advantage of using sigils is variable interpolation in strings.
> But that could easily be done only in strings without the need to put a
> $ in front of each and every variable name in the rest of the code.
> 
> I would also like semicolons to be optional. There are far more cases of
> single line statements than multiline statements. So you would save
> quite some characters, when the semicolon would be optional and you
> could concatenate multiline statements with e.g. a backslash.
> 
> Some say that there are too much operators in Perl(6). I partially
> agree. I don't like the implicit type casting forced by the operators
> (== int / eq string). That's harder to learn and remember. Harder to
> read also.
> I really like the Python way of doing it: Set the variables type on the
> assignment and remember it. The (fewer) operators now work according to
> the type of the operands. No implicit (and error prone) type casting.
> That way seems to be the best compromise of easiness and type safety.
> 
> I could continue on that, but I've already written too much...
> 
> [1] http://radar.oreilly.com/archives/2007/05/state_of_the_co_6.html
> [2] http://www.google.com/trends?q=perl%2C+python+-snake%2C+ruby
> 
> 
> 
> People not only want code that _is_ sexy, but they also want it to
> _look_ sexy.
> 
> -- 
> Thomas Wittek
> http://gedankenkonstrukt.de/
> Jabber: [EMAIL PROTECTED]
> 


__
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt gratis testen! http://produkte.web.de/club/?mc=021130

Parrot trunk: "The submitted smoke has an invalid format"

[Cosimo Streppone]

Hi all,

I'm trying to get my feet wet with Parrot, and I'd like
to contribute also for what I can.

Today I did a:

  # svn co https://svn.perl.org/parrot/trunk parrot
  # cd parrot; perl Makefile.PL
  # make smoke

Results follow (tried also last week or so with parrot 0.4.11,
had the same results).

--8<---

[...]

- t/stm/runtime.t
- t/distro/manifest.t
# this may take a while...
- t/distro/file_metadata.t
Can't exec "svk": No such file or directory at t/distro/file_metadata.t line 
219.
- t/codingstd/c_code_coda.t
- t/codingstd/c_header_guards.t
[...]
- t/codingstd/trailing_space.t
7143 OK from 7217 tests (98.97% ok)

smoke.html has been generated.
/usr/bin/perl tools/util/smokeserv-client.pl smoke.html
* smokeserv-client v0.4 started.
* Gzip compression on
* Reading smoke "smoke.html" to upload... ok.
* Sending data to smokeserver "http://smoke.parrotcode.org/smoke/";... error: 
The submitted smoke has an invalid format!
make: *** [smoke] Error 1
cosimo:/opt/download/parrot> make smoke

---8<

Is smoke procedure broken? Or it's me doing something wrong?
Thanks for any pointers.

--
Cosimo

Re: Is Perl 6 too late?

[Thomas Wittek]

Moritz Lenz schrieb:

What makes Perl hard to read is the excessive use of special characters
(/\W/).


I disagree: The make it look ugly, but not hard to read.


Even if it's "only" ugly: To what advantage? I don't think ugliness is a 
good characteristic of a programming language.



Global variables with cryptic names, that no beginner can make any sense
of by reading it. And after not working with "$<" for some months I
can't remember it either, although I've got quite some Perl experience.


Well, most of them are gone or renamed to more readable ones in p6.


I hope so. I could only find the counterparts for __PACKAGE__ etc. in 
S02. I didn't find the one for e.g. $<.


Additionally I'm not a friend of sigils: 


Then you shouldn't program in perl. Really.


Reason? I still haven't seen a good justification for sigils.
To allow arrays and scalars and subs to have the same name (besides the 
sigil) although they have different content? No good idea I think.
I also can't remember that I ever named a variable like a "reserved 
word" or operator. And even if I could, I'd consider it to be bad style.


I would also like semicolons to be optional. 


Most people don't ;-).


Oh, really? Source? :)
I think they were invented to allow easier parsing and not easier coding.
E.g. in JavaScript, Python, Ruby and Groovy they are optional or even 
don't exist. As I said, there are much more cases where you wouldn't 
need them but have to write them than vice versa.
Optional semicolons save keystrokes, eye pain and stupid syntactic 
errors. And if you still like them, you could just use them, which is 
the definition of "optional".



I really like the Python way of doing it: Set the variables type on the
assignment and remember it. The (fewer) operators now work according to
the type of the operands. No implicit (and error prone) type casting.
That way seems to be the best compromise of easiness and type safety.


Well, if you like the python way, feel free to code in python.


Oh, if I didn't like Perl, why should I care about posting my ideas here?
Perl has stolen the largest part of the language from other languages.
Why not do so again by adopting good ideas.


Don't get me wrong, there's nothing bad in writing some critics, but
yours is impossible to realize in Perl 6


Admittedly I'm much too late and I didn't expect applause for my critics 
-- but at least I hoped to get a discussion based on arguments.


> and therefore are it's hard to call it constructive.

Unfortunately I already thought this. Even if everyone agreed that 
sigils (or forced semicolons, or tons of operators, ...) are more bad 
than good (and this seems like persuading the pope to allow homosexual 
muslims to marry with priests) the design process is probably too far to 
introduce such dramatic changes.

Sadly.

--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: Is Perl 6 too late?

[Andy Armstrong]

On 14 May 2007, at 11:51, Thomas Wittek wrote:
I also can't remember that I ever named a variable like a "reserved  
word" or operator. And even if I could, I'd consider it to be bad  
style.


How did you know which reserved words and operators were going to be  
introduced in the future so you could avoid them all?


--
Andy Armstrong, hexten.net

Re: dlopen(NULL) ?

[Nikolay Ananiev]

It doesn't work on Win32 too.

"chromatic" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On Sunday 13 May 2007 16:30:23 Mike Mattie wrote:
>
>> I am working on src/dynext.c and I ran across this in get_path.
>>
>> if (lib == NULL) {
>> *handle = Parrot_dlopen((char *)NULL);
>
>> It may be a RTFM, but what does a null dlopen mean if it
>> succeeds, and why is it here ?
>
> First answer: get a handle to load symbols from the main program.
>
> Second answer: I'm not sure, but I know it doesn't work on Mac OS X 10.2 
> and
> earlier.
>
> -- c
> 

Re: Is Perl 6 too late?

[Thomas Wittek]

chromatic wrote:

Global variables with cryptic names, that no beginner can make any sense
of by reading it. And after not working with "$<" for some months I
can't remember it either, although I've got quite some Perl experience.


Most of those have gone away.


Oh, some someone must agree that word characters might be the better choice.
As I wrote Moritz, I could only find the replacements for __PACKAGE__ 
and alike. Additionally it would be very nice to group them in packages.



Additionally I'm not a friend of sigils:


I'm not a friend of potential conflicts between built-in operators and my 
identifier names (and especially the conflicts between scalar, aggregate, 
type, and function names).


As I partially wrote Moritz, I
a) don't think that it's the case very often. you have to write the 
sigil a thousand times where it wouldn't be useful for only 1 case where 
you'd have a name conflict.
b) even if there would be a conflict, it might be considered bad style 
to use identical identifiers (besides the sigil) for different things 
(vars/objects/subs/operators/...).



I would also like semicolons to be optional.


When (smart) people talk about Python's whitespace problem, they don't mean 
*horizontal* whitespace.


I'm not much into Python. But as at least Ruby, Python, JavaScript, 
Groovy and Lua (which all are relatively young languages) don't force 
you to write semicolons.
So semicolons don't seem to be the best invention since sliced bread. 
There should be extra-syntax for the rare cases (multiline) and not for 
the common ones.



Some say that there are too much operators in Perl(6). I partially
agree.


That's like saying there are too many function calls in Scheme.  Perl's an 
operator-oriented language!


And it should be. I really like the expressive power of most of the 
operators. Especially the new zip/junction/reduce/smart-match ones.

But I don't like doing implicit type casting with operators.
It's even discouraged in Perl5 as we have a warning for that.
So maybe it'd be a good idea to completely drop it.


People not only want code that _is_ sexy, but they also want it to
_look_ sexy.


At least almost everyone to whom I said, that I do most work in Perl, 
responded with some sentence containing the word "ugly" or "unreadable".
To get away from that image, it's neccessary to do some radical changes 
I think.


--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: Is Perl 6 too late?

[Thomas Wittek]

Andy Armstrong schrieb:

On 14 May 2007, at 11:51, Thomas Wittek wrote:
I also can't remember that I ever named a variable like a "reserved 
word" or operator. And even if I could, I'd consider it to be bad style.


How did you know which reserved words and operators were going to be 
introduced in the future so you could avoid them all?


How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. know?
They didn't.
If there is a new release, you always have to check if your code still runs.

--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: Is Perl 6 too late?

[Andy Armstrong]

On 14 May 2007, at 12:31, Thomas Wittek wrote:
How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic,  
etc. know?

They didn't.
If there is a new release, you always have to check if your code  
still runs.


I think that may be the point I'm making.

--
Andy Armstrong, hexten.net

Re: Is Perl 6 too late?

[Thomas Wittek]

herbert breunung schrieb:

please make a decision for you to program in a language [..]

> [..] try python. [..]

Oh, just because I think that they've some smart design decisions?
Why not steal them?

BTW: Why do so much people say "go away if you don't like it" instead of 
being open for ideas and discussing them from a neutral point of view?


--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: [perl #42918] [PATCH] src/library.c use mem_sys_free instead of free()

[Mike Mattie]

On Thu, 10 May 2007 12:18:00 -0700
"chromatic via RT" <[EMAIL PROTECTED]> wrote:

> On Thursday 10 May 2007 02:37:15 Mike Mattie wrote:
> 
> > quick patch to use the mem_sys_free wrapper instead of using the
> > platform's free() directly.
> 
> I only see an OpenPGP signature attachment; can you respond with the
> patch attached again (or inline, I suppose).  If it's a small change,
> I could make it directly too.
> 
> -- c
> 
> 

please close this rt. The patch doesn't apply anymore , and I will
get the fix in as a part of later patches to library.c


signature.asc
Description: PGP signature

Re: Is Perl 6 too late?

[Mark J. Reed]

I'm so tired of hearing how unreadable Perl is.  It's specious.  "But
if so many people think it..." Uh-uh.  Instinctive reactions can be
both universal and incorrect...and I think that's what this is.  At
least, among those who have even bothered to look into Perl instead of
just repeating FUD.  As for the rest, nothing we do to P6 will
overcome the default "Perl sucks" reaction from such bigots.  Better
to make it a powerful language with a compelling functional reason to
use it; if we succeed, we can maybe start to win back some mindshare
and undo the rep damage caused by the cgi explosion.

On 5/14/07, Thomas Wittek <[EMAIL PROTECTED]> wrote:

herbert breunung schrieb:
> please make a decision for you to program in a language [..]
 > [..] try python. [..]

Oh, just because I think that they've some smart design decisions?
Why not steal them?

BTW: Why do so much people say "go away if you don't like it" instead of
being open for ideas and discussing them from a neutral point of view?

--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]




--
Mark J. Reed <[EMAIL PROTECTED]>

Re: Is Perl 6 too late?

[herbert breunung]

> herbert breunung schrieb:
> > please make a decision for you to program in a language [..]
>  > [..] try python. [..]
> 
> Oh, just because I think that they've some smart design decisions?
> Why not steal them?
> 
> BTW: Why do so much people say "go away if you don't like it" instead of 
> being open for ideas and discussing them from a neutral point of view?

you ignore what i wrote. im glad if you stay and keep on ask important questions
but please recognise that there are some core decisions that define the language
called perl, and when we change them its no longer perl. so please dont feel 
offended
to me its a matter of logic and practibality. 

and to me it maybe sometime usefull dont write as much ";" but keep out sigils
i definitly dont like because it became much harder readable to me and the whole
subject of twigils and siginiture sigils goes down the toilet whenn we throw 
that
one away.

so i hope you understand me now better
all best
herbert
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=0066

Parrot Bug Summary

[Parrot Bug Summary]

Parrot Bug Summary

http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon May 14 13:01:05 2007 GMT
---

  * Numbers
  * New Issues
  * Overview of Open Issues
  * Ticket Status By Version
  * Requestors with most open tickets

---

Numbers

Ticket Counts: 115 new + 438 open = 553
Created this week: 11
Closed this week: 7

---

New Issues

New issues that have not been responded to yet

1 - 2 weeks old
42861 [BUG] config.pir broken in installed parrot
42853 [CAGE] API Doc Signature Checker
42848 [File of the Week] src/objects.c
2 - 3 weeks old
42790 [BUG] Tailcall with slurpy argument passing causes a memory leak
3 - 4 weeks old
42624 Parrot compiles now but still fails tests.
42617 t/pmc/threads_7.pir hangs indefinitely
42609 [BUG] make html vs. DEVELOPING
4 - 5 weeks old
42536 build error on Linux 2.6.9-023stab041.3-smp
42508 [CAGE] cleanup pmc null tests
42427 [CAGE] cleanup perlcritic errors
42411 [PARTIALPATCH] Building a 32bit parrot on freebsd under amd64 fails.
42393 [TODO] regex - FIXME items in languages/regex/lib/Regex/Grammar.y
5 - 6 weeks old
42384 [TODO] imcc - check that all the .file text is malloced / freed
42383 [TODO] imcc - if frame->s.file was allocated free it
42382 [TODO] imcc - delete quotes and emit pbc
42379 [TODO] adjust register layout in debug_print()
42378 [TODO] explicit exit from debug_break() op is not ok
42377 [TODO] clone interpreter to play into the debugger
42376 [TODO] handle all ready states in add_io_event opcode
42375 [TODO] make pmcinfo op official
42374 [TODO] free results from string_to_cstring() without ugly warnings
42373 [TODO] handle non-integer file descriptors
42372 [TODO] same opcode names should differ (subclass op)
42369 [TODO] optimize pointer loading in saveall()
42356 [TODO] verify $1 didn't change in pic_callr__() op
42355 [TODO] use ARG_MAX in pic_callr__() op
42354 [TODO] preserve type system in pic_inline_sub__() op
42353 [TODO] perform a dynamic lookup if needed in pic_infix__() op
42352 [TODO] fix or remove strange TODO item in hash() op
42350 [TODO] fix kludge in find_type op
42349 [TODO] dotnet - fix various ops for 64 bit architectures
42330 [BUG]: New warning during 'make': "MAX" redefined
42312 src/pmc/os.pmc: bad use of stat(2) and lstat(2)
42287 [PDD] MMD needs to be in a PDD
42286 [CAGE]: Parrot::Pmc2c::PCCMETHOD constants should be autogenerated
6 - 7 weeks old
42267 [CAGE] Work out how to encourage good editor-independent formatting
  habits
42254 [BUG] Broken I/O on missing file
7 - 8 weeks old
42040 tools/dev/mk_manifest_and_skip.pl doesn't pick up files that are marked
  svn deleted but not yet committed
8 - 9 weeks old
41893 [BUG] 0.4.9 leaks various .c files into install image, creates PREFIX/
  config, PREFIX/compiler
41888 Perl 6 FAQ text
41862 [CAGE] Make a reasonable set of rules for lint
41858 [CAGE] Make a reasonable set of rules for splint
41857 [CAGE] Make a "make valgrind" target
41833 [TODO] test conv_i2 opcode
41827 ICU endian issues causing test failures.
41825 morph vtable method not working in PIR
41802 [BUG] GC errors with PGE (may have failing tests!)
9 - 10 weeks old
41783 [BUG?] main isn't in src/parrot.c
41772 [PATCH] languages/pynie: built-in functions
41765 [TODO] examples embedded in pod should all be parseable
41762 [PATCH] Languages/Pynie functions!
10 - 11 weeks old
41675 [TODO] Add 'languages/perl6' to unified languages testing
41666 Test PIR and PASM by generating PBC and running it
41634 [TODO] warn and abort make if pbc compatibility has changed
11 - 12 weeks old
12 - 13 weeks old
41500 [TODO] config - lib directory needs to be set appropriately for 32/64 bit
  archs
41499 [TODO] config - 32/64 bit architecture setting gcc specific
41497 [TODO] config - profiling options are specific to gcc in config/init/
  defaults.pm
41496 [TODO] config - profiling options should have their own step in config/
  init/defaults.pm
13 - 14 weeks old
14 - 15 weeks old
41374 test MMD with non-perl PMCs
41373 Need test for Clone of HLL info
15 - 16 weeks old
16 - 17 weeks old
41310 [CAGE] autogenerated PMC stubs kill compile
41286 [PDD] revisit properties
41280 [PDD] adding methods to subs as objects
17 - 18 weeks old
41265 [TODO] PGE: refactor pod_comment rule into PGE/Util.pbc
41264 [PDD] should properties get serialized?
41263 [PDD] should/can high-level classes be constructed at compile-time?
41257 [tru64] core dump in t/pmc/io_1.pir
41256 [tru64] NaNQ failures in t/pmc/complex
41255 [tru64] core dump from t/pmc/pmc_5.pasm
41254 [tru64] core dump from library/pg
41253 [tru64] core dump from t/dynoplibs/myops_3.pir
41251 [tru64] core dump from t/pmc/resizablebooleanarray_20.pasm
41249 [tru64] core dump in t/pmc/interp_3.pir
41242 Compile on Linux with Intel C

[PATCH] Add a few clarifying comments about res_lea.c

[Andy Dougherty]

This patch adds a few clarifications to comments.  And I'm afraid this is 
how I'll have to leave it for now.

diff -r -u parrot-current/include/parrot/pobj.h 
parrot-andy/include/parrot/pobj.h
--- parrot-current/include/parrot/pobj.h2007-05-13 19:15:14.0 
-0400
+++ parrot-andy/include/parrot/pobj.h   2007-05-14 08:57:38.0 -0400
@@ -75,14 +75,14 @@
 is also suitably aligned for any use.  If, for example, malloc() returns
 objects aligned on 8-byte boundaries, and obj->bufstart is also aligned
 on 8-byte boundaries, then there should be 4 bytes of padding.  It is
-handled differently in the two files resources.c and res_lea.c.  (I have
-not yet figured out how the 'possible padding' is handled in resources.c.
---A.D.  2007-05-11.)
+handled differently in the two files resources.c and res_lea.c.
+In resources.c, the buffer is carved out of a larger memory pool.  In
+res_lea.c, each buffer is individually allocated.
 
  src/gc/resources.c:   src/gc/res_lea.c:
 
 ptr from malloc ->  +--+  +--+
-| possible padding |  | INTVAL ref_count |
+  [other blocks?] | INTVAL ref_count |
 | INTVAL ref_count |  | possible padding |
 obj->bufstart   ->  +--+  +--+
 | data |  |  data|
diff -r -u parrot-current/src/gc/res_lea.c parrot-andy/src/gc/res_lea.c
--- parrot-current/src/gc/res_lea.c 2007-05-12 19:15:12.0 -0400
+++ parrot-andy/src/gc/res_lea.c2007-05-14 09:03:17.0 -0400
@@ -15,6 +15,12 @@
 The "lea" in the file name refers to Doug Lea, who wrote malloc
 implementation found in F.
 
+As of May 14, 2007, it doesn't work (and hasn't worked for some
+time.)  The problem appears to be related to strings, but actually
+could be somewhere else.  This allocator does not support any of
+Parrot's Copy-on-Write schemes.  Nor does the string allocator
+handle "external" strings.
+
 =head2 Functions
 
 =over 4

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: Is Perl 6 too late?

[Thomas Wittek]

Andy Armstrong schrieb:

On 14 May 2007, at 12:31, Thomas Wittek wrote:
How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. 
know?

They didn't.
If there is a new release, you always have to check if your code still 
runs.


I think that may be the point I'm making.


Your point is that you don't have one?
Do you believe, that new keywords are the only cause of breaking 
backwards compatibility? I don't think so.

So you rely on testing your code anyway. Sigils won't save you from that.

--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

[perl #42944] [PATCH] new parrot path handling API from static functions in src/library.c

[via RT]

# New Ticket Created by  Mike Mattie 
# Please include the string:  [perl #42944]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=42944 >


Hello,

This is a patch, and two new files:

parrot/include/path.h
src/path.c

These changes move the static path handling utilities out of library.c into 
their own translation unit.
This allows all of the parrot code to use a single implementation of common 
path handling functions.

slight modifications were made to the win32 specific portions that need to be 
re-tested on that
platform.

I modified the config/gen/makefiles/root.in to get it compiling properly , but 
I might have missed
something as this is my first change to the makefile.

I get two harness failures I haven't figured out yet:

t/op/sprintf.ok 1/308parrot:
src/string.c:727: string_str_index: Assertion `s->encoding &&
s->charset && !(((s)->obj.flags) & b_PObj_on_free_list_FLAG)' failed.

This may be because I modified the functions in path.c to use more of the 
string API instead of
bypassing it. Someone else may be able to decode this assertion failure so I 
can pinpoint
where it is coming from. I suspect that it is coming from path.c:217 .

In fact that entire function needs to be reviewed, I don't have the unicode 
experience
to understand it's string manipulation. beyond the change on 217 I haven't 
touched
that code with a cleanup yet.

# Failed test (t/perl/Parrot_IO.t at line 159)
t/perl/Parrot_IO.NOK 51/57# Looks like you 
failed 1 test of 57.

This one I don't get at all. This could be random.

Other than those two failures the test-suite passed on i686-pc-gnu-linux

Failed TestStat Wstat Total Fail  List of Failed
---
t/op/sprintf.t0 6   308  234  192-308
t/perl/Parrot_IO.t1   256571  51
9 tests and 512 subtests skipped.
Failed 2/304 test scripts. 118/7217 subtests failed.
Files=304, Tests=7217, 575 wallclock secs (288.14 cusr + 46.41 csys =
334.55 CPU)
Failed 2/304 test programs. 118/7217 subtests failed.

Cheers,
Mike Mattie

/*
Copyright (C) 2004-2007, The Perl Foundation.

=head1 NAME

src/path.c

=head1 DESCRIPTION

This file contains a C functions for parrot's platform independent
path handling.

=head2 Functions

=over 6

=cut

*/

#include "parrot/parrot.h"
#include "parrot/path.h"
#include "path.str"

static const char parrot_path_separator = '/';

#ifdef WIN32
static const char platform_path_separator = '\\';


/*
 * Converts a path with forward slashes to one with backward slashes.
 */
static void
cnv_to_platform_filesep (STRING *path) {
char* cnv;

assert(path->encoding == Parrot_fixed_8_encoding_ptr ||
path->encoding == Parrot_utf8_encoding_ptr);

cnv = Parrot_string_cstring(path);

while ((cnv = strchr(cnv, parrot_path_separator)) != NULL)
*cnv = platform_path_seperator;
}

#else

static const char platform_path_separator = '/';

#endif


/*

=item C

return true if the given file is an absolute path, false if relative.

=cut

*/

int
parrot_path_is_abs(Interp* interp, STRING *path)
{
const char *file_name;

if ( !string_length(interp, path) )
return 0;

assert(path->encoding == Parrot_fixed_8_encoding_ptr
   || path->encoding == Parrot_utf8_encoding_ptr);

file_name = Parrot_string_cstring(interp,path);

return (file_name[0] == parrot_path_separator

#ifdef WIN32
|| file_name[0] == platform_path_seperator
|| (isalpha(file_name[0])
&& string_length(file) > 2
&& (strncmp(file_name+1, ":\\", 2) == 0
|| strncmp(file_name+1, ":/",  2) == 0))
#endif
  ) ? 1 : 0;
}

/*

=item C

Ensure that the given path has a trailing path separator.
A new string may be returned.

=cut

*/

STRING*
parrot_path_trailing_separator(Interp *interp, STRING *path)
{
STRING *path_separator_string = string_chr(interp, platform_path_separator);

/* make sure the path has a trailing slash before appending the file */
if (string_index(interp, path , string_length(interp,path) - 1)
 != string_index(interp, path_separator_string, 0))
path = string_append(interp, path , path_separator_string);

return path;
}

/*

=item C

Localize a path to the platform by converting the parrot path
seperator to the platform seperator if necessary.  Also a "hidden
zero" is appended to the path making it suitable for use by C API's
such as platform file/IO.

=cut

*/

STRING*
parrot_path_platform_localize(Interp *interp, STRING *path)
{

#ifdef WIN32
  cnv_to_platform_filesep(path);
#endif

/* TODO create a string API that just does that
 *  a lot of ICU lib functions also need 0-terminated strings
 *  the goal is just to have for sure an invisible 0 at end
 */

STRING *nul 

[perl #42918] [PATCH] src/library.c use mem_sys_free instead of free()

[Paul Cochrane via RT]

On Mon May 14 05:08:56 2007, codermattie wrote:
> On Thu, 10 May 2007 12:18:00 -0700
> "chromatic via RT"  at parrotcode.org> 
wrote:
> 
> > On Thursday 10 May 2007 02:37:15 Mike Mattie wrote:
> > 
> > > quick patch to use the mem_sys_free wrapper instead of using the
> > > platform's free() directly.
> > 
> > I only see an OpenPGP signature attachment; can you respond with the
> > patch attached again (or inline, I suppose).  If it's a small 
change,
> > I could make it directly too.
> > 
> > -- c
> > 
> > 
> 
> please close this rt. The patch doesn't apply anymore , and I will
> get the fix in as a part of later patches to library.c

Ok, ticket closed.

Re: Parrot trunk: "The submitted smoke has an invalid format"

[Gaal Yahas]

On 5/14/07, Cosimo Streppone <[EMAIL PROTECTED]> wrote:

   # svn co https://svn.perl.org/parrot/trunk parrot
   # cd parrot; perl Makefile.PL
   # make smoke

smoke.html has been generated.
/usr/bin/perl tools/util/smokeserv-client.pl smoke.html
* smokeserv-client v0.4 started.
* Gzip compression on
* Reading smoke "smoke.html" to upload... ok.
* Sending data to smokeserver "http://smoke.parrotcode.org/smoke/";... error: 
The submitted smoke has an invalid format!

Is smoke procedure broken? Or it's me doing something wrong?
Thanks for any pointers.


Try the same command again (smokeserv-client.pl smoke.html), just to
see if this isn't a transient network failure.

If the error stays the same, parrot's smoke server may have gone out
of sync with the client.

Also, make sure you aren't running YAML::Syck 0.84, which contained a
bug. If this is the case, remove your smoke and try again (simply
"make smoke" again should do the trick).

--
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/

Re: Is Perl 6 too late?

[John Macdonald]

On Mon, May 14, 2007 at 02:36:10PM +0200, Thomas Wittek wrote:
> Andy Armstrong schrieb:
> >On 14 May 2007, at 12:31, Thomas Wittek wrote:
> >>How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. 
> >>know?
> >>They didn't.
> >>If there is a new release, you always have to check if your code still 
> >>runs.
> >
> >I think that may be the point I'm making.
> 
> Your point is that you don't have one?
> Do you believe, that new keywords are the only cause of breaking 
> backwards compatibility? I don't think so.
> So you rely on testing your code anyway. Sigils won't save you from that.

Back in the 90's I was with a company that had a 20K line
perl program.  We would provide a copy of perl as part of the
program suite, so that we could control which version was
being used for our software and when it was upgraded while
still allowing the customer to have their own version of perl
that they could upgrade on their own schedule.  Before any perl
upgrade was built into our suite, we would of course test it
extensivily to ensure that all of the code was still compatible.
Until the perl4->perl5 change, there was never any problem -
Larry is a wizard at adding totally new concepts and features
in a way that just "happens" to include all of the old usage
bits as a special case that falls magically out of the new,
enhanced, more coherent whole.  But there is no way that this
would have been possible without the distinction between named
operators and variables provided by sigils.  Removing the sigil
on a function call (it used to always be written &sub(args...))
did, I think, lead to the difficulty in perl5 where it became
difficult to add new keyword operators to the language - because
they could conflict with subroutine names in existing code.

Needless to say, that level of dependable upgradability without
requiring code rewrites was considered to e a huge benefit of
using perl for our company.

(For the record, we delayed converting from perl4 to perl5 for
many years, woried about the possibility of subtle problems
arising from the massive changes that had been made to the
language.  When I finally tried it out, there were only a few
changes that really affected us.  I had the code converted in
about two weeks, although we then ran it in parallel with the
old code for about two months before accepting that nothing
tricky had snuck in.)

-- 

Re: Is Perl 6 too late?

[chromatic]

On Monday 14 May 2007 04:28:15 Thomas Wittek wrote:

> > I'm not a friend of potential conflicts between built-in operators and my
> > identifier names (and especially the conflicts between scalar, aggregate,
> > type, and function names).

> As I partially wrote Moritz, I
> a) don't think that it's the case very often. you have to write the
> sigil a thousand times where it wouldn't be useful for only 1 case where
> you'd have a name conflict.
> b) even if there would be a conflict, it might be considered bad style
> to use identical identifiers (besides the sigil) for different things
> (vars/objects/subs/operators/...).

theproblemlinguisticallyspeakingisthatsometimespunctuationishighlyimportant\ 
fromareadabilitystandpointyoumaynotliketheuseofspacescommasdashesupper\
casinghyphensandperiodsbutitmakesatremendousdifferencetoreadabilitywhether\
youlikeitornotasitmaybebadstyleifyoudontputspacesbetweentwowordsandtheresult\
lookslikeawordthatsomeonemaydefineinthefuture

There *are* a few linguists involved in Perl.

> So semicolons don't seem to be the best invention since sliced bread.
> There should be extra-syntax for the rare cases (multiline) and not for
> the common ones.

Somehow English seems to get by with periods at the ends of statements, though 
almost no one pronounces them.

> But I don't like doing implicit type casting with operators.
> It's even discouraged in Perl5 as we have a warning for that.
> So maybe it'd be a good idea to completely drop it.

I can't really see that changing DWIM to DWTWM is anything but a step 
backwards in Perlishness.

> >> People not only want code that _is_ sexy, but they also want it to
> >> _look_ sexy.

> At least almost everyone to whom I said, that I do most work in Perl,
> responded with some sentence containing the word "ugly" or "unreadable".
> To get away from that image, it's neccessary to do some radical changes
> I think.

I agree.  You need less ignorant colleagues.  I'm not sure Perl 6 can fix 
that.

By the way, I'm still waiting to meet your cadre of Dylan hackers.

-- c

Re: Is Perl 6 too late?

[chromatic]

On Monday 14 May 2007 04:35:19 Thomas Wittek wrote:

> BTW: Why do so much people say "go away if you don't like it" instead of
> being open for ideas and discussing them from a neutral point of view?

Perhaps you're not a native English speaker, but running into the room and 
saying "Perl 6 doesn't have a compelling vision", "Everyone thinks Perl is 
ugly", and "Python and Ruby are doing things better than Perl 6" is *not* the 
way to start a friendly and neutral discussion, as if a sane, calm, neutral 
discussion of programming language designs and tradeoffs were possible.

-- c

Re: Is Perl 6 too late?

[Moritz Lenz]

Thomas Wittek wrote:
> Moritz Lenz schrieb:
>>> What makes Perl hard to read is the excessive use of special characters
>>> (/\W/).
>>
>> I disagree: The make it look ugly, but not hard to read.
> 
> Even if it's "only" ugly: To what advantage? I don't think ugliness is a
> good characteristic of a programming language.

In fact it makes the code easier to read. At least to me.
The other day I had a lot of work to do with matlab code, and it just
sucked. No variables where declared, and therefore I had no type
information. I didn't knew if arguments passed to functions were
arrays/matrices or scalars, and sigils would have helped very much.

And don't say "but a good IDE.." - I didn't have one. No language should
depend on its IDE's syntax hilighting.

>>> I would also like semicolons to be optional. 
>>
>> Most people don't ;-).
> 
> Oh, really? Source? :)

I paraphrased Larry Wall. Iirc it was "everybody wants the semicolon" or
something - correct me if I'm wrong.

> I think they were invented to allow easier parsing and not easier coding.

I think the p6 grammar is so complex that you couldn't do it without a
statement terminator, be it a semicolon or a newline. And we know that
you prefer the newline, I (and it seems, many other) do prefer semicolons.

> E.g. in JavaScript, Python, Ruby and Groovy they are optional or even
> don't exist.

most languages don't allow you to call a function without parentheses.
if you have

foo bar

without a statement termination, you can't know if thats
foo(bar()),
or
foo()
bar()
whereas if you force the parentheses, it is unambigous anyway.

Which explains why languages with simpler syntax can well live without
the semicolon.


>>> I really like the Python way of doing it: Set the variables type on the
>>> assignment and remember it. The (fewer) operators now work according to
>>> the type of the operands. No implicit (and error prone) type casting.
>>> That way seems to be the best compromise of easiness and type safety.
>>
>> Well, if you like the python way, feel free to code in python.
> 
> Oh, if I didn't like Perl, why should I care about posting my ideas here?
> Perl has stolen the largest part of the language from other languages.
> Why not do so again by adopting good ideas.

because, as was pointed out earlier, huge changes
a) delay implementation significantly and
b) change the character of the language too heavily. We want Perl 6 to
be Perl still.


>> Don't get me wrong, there's nothing bad in writing some critics, but
>> yours is impossible to realize in Perl 6
> 
> Admittedly I'm much too late and I didn't expect applause for my critics
> -- but at least I hoped to get a discussion based on arguments.

Most of these issues have been discussed in one way or another, either
on p6l or on use.perl.org. If you really want the arguments, you'll find
most of them.

>> and therefore are it's hard to call it constructive.
> 
> Unfortunately I already thought this. Even if everyone agreed that
> sigils (or forced semicolons, or tons of operators, ...) are more bad
> than good (and this seems like persuading the pope to allow homosexual
> muslims to marry with priests) the design process is probably too far to
> introduce such dramatic changes.

Right.

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/



signature.asc
Description: OpenPGP digital signature

Re: Is Perl 6 too late?

[Moritz Lenz]

Thomas Wittek wrote:
> BTW: Why do so much people say "go away if you don't like it" instead of
> being open for ideas and discussing them from a neutral point of view?

because the design process of perl 6 started long time ago, and if we
incooperate major changes to it, no implementation will ever finish.

I don't think most of are not open to new point of views, but regard p6
they just don't help atm.

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/



signature.asc
Description: OpenPGP digital signature

[svn:perl6-synopsis] r14390 - doc/trunk/design/syn

[larry]

Author: larry
Date: Mon May 14 10:13:16 2007
New Revision: 14390

Modified:
   doc/trunk/design/syn/S02.pod
   doc/trunk/design/syn/S06.pod
   doc/trunk/design/syn/S12.pod

Log:
coercion type renamed from "returns" to "as" to avoid confusion with "of" type.
ambiguity in block-end parsing noted by rhr++


Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podMon May 14 10:13:16 2007
@@ -822,19 +822,19 @@
 
 In either case this sets the C property of the container to C.
 
-Subroutines have a variant of the C property, C, that sets
-the C property instead.  The C property specifies a
+Subroutines have a variant of the C property, C, that sets
+the C property instead.  The C property specifies a
 constraint (or perhaps coercion) to be enforced on the return value (either
 by explicit call to C or by implicit fall-off-the-end return).
 This constraint, unlike the C property, is not advertised as the
 type of the routine.  You can think of it as the implicit type signature of
 the (possibly implicit) return statement.  It's therefore available for
-type inferencing within the routine but not outside it.  If no inner type
+type inferencing within the routine but not outside it.  If no C type
 is declared, it is assumed to be the same as the C type, if declared.
 
 sub get_pet() of Animal {...}   # of type, obviously
 our Animal sub get_pet() {...}  # of type
-sub get_pet() returns Animal {...}  # inner type
+sub get_pet() as Animal {...}   # as type
 
 A value type on an array or hash specifies the type stored by each element:
 
@@ -892,18 +892,19 @@
 my Hash of Array of Recipe %book;   # HoHoAoRecipe
 my %book of Hash of Array of Recipe;# same thing
 
-The C form may be used in subroutines:
+The C form may be used in subroutines:
 
-my sub get_book ($key) returns Hash of Array of Recipe {...}
+my sub get_book ($key) as Hash of Array of Recipe {...}
 
 Alternately, the return type may be specified within the signature:
 
 my sub get_book ($key --> Hash of Array of Recipe) {...}
 
 There is a slight difference, insofar as the type inferencer will
-ignore a C but pay attention to C<< --> >> or prefix type
+ignore a C but pay attention to C<< --> >> or prefix type
 declarations, also known as the C type.  Only the inside of the
-subroutine pays attention to C.
+subroutine pays attention to C, and essentially coerces the return
+value to the indicated type, just as if you'd coerced each return expression.
 
 You may also specify the C type as the C trait:
 
@@ -963,18 +964,18 @@
 
 On a scoped subroutine, a return type can be specified before or after
 the name.  We call all return types "return types", but distinguish
-two kinds of return types, the C type and the C type,
+two kinds of return types, the C type and the C type,
 because the C type is normally an "official" named type and
-declares the official interface to the routine, while the C
+declares the official interface to the routine, while the C
 type is merely a constraint on what may be returned by the routine
 from the routine's point of view.
 
-our sub lay returns Egg {...}   # inner type
+our sub lay as Egg {...}# as type
 our Egg sub lay {...}   # of type
 our sub lay of Egg {...}# of type
 our sub lay (--> Egg) {...} # of type
 
-my sub hat returns Rabbit {...} # inner type
+my sub hat as Rabbit {...}  # as type
 my Rabbit sub hat {...} # of type
 my sub hat of Rabbit {...}  # of type
 my sub hat (--> Rabbit) {...}   # of type
@@ -983,14 +984,14 @@
 namespace (module, class, grammar, or package), as if it's scoped with
 the C scope modifier. Any return type must go after the name:
 
-sub lay returns Egg {...}   # inner type
+sub lay as Egg {...}# as type
 sub lay of Egg {...}# of type
 sub lay (--> Egg) {...} # of type
 
 On an anonymous subroutine, any return type can only go after the C
 keyword:
 
-$lay = sub returns Egg {...};   # inner type
+$lay = sub as Egg {...};# as type
 $lay = sub of Egg {...};# of type
 $lay = sub (--> Egg) {...}; # of type
 
@@ -1003,14 +1004,14 @@
 without affecting the meaning.
 
 The return type may also be specified after a C<< --> >> token within
-the signature.  This doesn't mean exactly the same thing as C.
+the signature.  This doesn't mean exactly the same thing as C.
 The C type is the "official" return type, and may therefore be
-used to do type inferencing outside the sub.  The C type only
+used to do type inferencing outside the sub.  The C type only
 makes the return type available to the internals of the sub so that
 the C statement can know its cont

Re: Is Perl 6 too late?

[Moritz Lenz]

Moritz Lenz wrote:
> Thomas Wittek wrote:
>> Moritz Lenz schrieb:
 I would also like semicolons to be optional. 
>>> Most people don't ;-).
>> Oh, really? Source? :)
> 
> I paraphrased Larry Wall. Iirc it was "everybody wants the semicolon" or
> something - correct me if I'm wrong.

sorry, masak++ pointed out that it was wrong indeed.

Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/



signature.asc
Description: OpenPGP digital signature

Re: Parrot trunk: "The submitted smoke has an invalid format"

[Cosimo Streppone]

Gaal Yahas wrote:


On 5/14/07, Cosimo Streppone <[EMAIL PROTECTED]> wrote:

   # svn co https://svn.perl.org/parrot/trunk parrot
   # cd parrot; perl Makefile.PL
   # make smoke
[...]
* Sending data to smokeserver "http://smoke.parrotcode.org/smoke/";... 
error: The submitted smoke has an invalid format!


Try the same command again (smokeserv-client.pl smoke.html), just to
see if this isn't a transient network failure.


No way.


Also, make sure you aren't running YAML::Syck 0.84, which contained a
bug. If this is the case, remove your smoke and try again (simply
"make smoke" again should do the trick).


This wasn't the case. I didn't even have it installed.
Tried installing, but failed again.

> If the error stays the same, parrot's smoke server may have gone out
> of sync with the client.

I installed the server part on my workstation.
I think the problem is with 'revision: 0' in my smoke.html file.

The smokeserv-server.pl script lines that say:

if ( grep { not $smoke{$_} } qw ) {
print "The submitted smoke has an invalid format!";
exit;
}

make the smoke upload process fail, because revision is zero.
Even change it to 'grep { not exists $smoke{$_} }' or change
revision value to something else than zero.

Changing 'revision: 0' to 'revision: 1' solved the problem,
but it's not so correct, I think.

--
Cosimo

Re: Is Perl 6 too late?

[Gabor Szabo]

On 5/14/07, John Macdonald <[EMAIL PROTECTED]> wrote:

 Removing the sigil
on a function call (it used to always be written &sub(args...))
did, I think, lead to the difficulty in perl5 where it became
difficult to add new keyword operators to the language - because
they could conflict with subroutine names in existing code.


Actually I think I never understood  this issue.
We claim that having the sigils saves us from stepping on our future
feet by making sure keywords of the language are always different
from any variable we might create.

The fact that function don't need a sigil any more and it is even
AFAIK discouraged to be used makes *this* argument mute.

Thought this thread might not be the best place to ask this
I'd be glad to read some explanation about this.

regards
  Gabor

Re: Is Perl 6 too late?

[Frank Wiles]

On Mon, 14 May 2007 12:51:53 +0200
Thomas Wittek <[EMAIL PROTECTED]> wrote:

> Reason? I still haven't seen a good justification for sigils.

   This may not qualify as a "good justification", but it is one I've 
   discussed with others and rings true for many.  Take a look at 
   actual code written in other languages and you'll find many variable
   names that end in things like _ary, _array, _dict, _list, etc.  to
   denote the type of container it is. Why?  Because 'foo' doesn't
   tell you what it is, so programmers compensate with 'foo_dict' or
   'foo_array' so they don't have to constantly go looking for the 
   definition.  

   With Perl you get that plainly visible with one single character at
   the beginning of the variable name.  You can differentiate what it
   is easily, in a consistent way, with only one character. 

   Personally, I love sigils for this reason alone.

> To allow arrays and scalars and subs to have the same name (besides
> the sigil) although they have different content? No good idea I think.
> I also can't remember that I ever named a variable like a "reserved 
> word" or operator. And even if I could, I'd consider it to be bad
> style.

   Much like your argument about naming variables after reserved
   words, I see naming an array, scalar, and a sub the same to be
   bad style.

 -
   Frank Wiles <[EMAIL PROTECTED]>
   http://www.wiles.org
 -

Re: [perl #42919] [BUG] and [PATCH] overriding 'invoke' requires current object to be explicitly passed

[Mehmet Yavuz Selim Soyturk]

On 5/10/07, via RT Alek Storm <[EMAIL PROTECTED]> wrote:

# New Ticket Created by  "Alek Storm"
# Please include the string:  [perl #42919]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42919 >


Because PIR can't tell the difference between invoking an object PMC and
invoking a sub PMC, it doesn't generate a correct set_args when an object is
invoked.  Since the 'invoke' override is a method, it expects the current
object to be the first parameter.  There are currently two workarounds: pass
the current object explicitly as the first parameter, or don't declare
'invoke' as a :method.  The first is inconvenient and unintuitive, and the
second means 'invoke' doesn't get access to its own object.

Example code for bug:
.sub _ :main
  $P0 = newclass "Foo"
  $P1 = new "Foo"
  $P1("bar")
.end

.namespace ["Foo"]
.sub 'invoke' :method :vtable
  .param string bar
  say bar
  self.'baz'()
.end

.sub 'baz' :method
  say "baz"
.end

Output:
too few arguments passed (1) - 2 params expected
current instr.: 'parrot;Foo;invoke' pc 16 (/home/alek/test2.pir:8)
called from Sub '_' pc 11 (/home/alek/test2.pir:4)

I've attached a patch that fixes this by grabbing the args signature inside
delegate.invoke() and unshifting an arg of type PARROT_ARG_PMC |
PARROT_ARG_OBJECT.  It also modifies src/inter_call.c to handle this by
setting the arg equal to interp->current_object, and enums.h to add the new
argument flag.  The tests in t/pmc/parrotobject.t have been changed to
include :method on the 'invoke' overrides, and to remove the test for
#41732, which is no longer applicable.

--
Alek Storm


Should we not be able to use an object that implements 'invoke' as a
method of another object? There is some strange behaviour when I try
to.


.sub main :main
   $P0 = newclass 'Func'
   $P1 = newclass 'Obj'
   $P2 = new 'Obj'
   $P2.'some_method'()
.end

.namespace ['Func']

.sub invoke :vtable :method
   .param pmc an_arg

   print 'vtable invoke with self = "'
   print self
   print '", arg = "'
   print an_arg
   say '"'
.end

.sub get_string :vtable
   .return ('an instance of Func')
.end

.namespace ['Obj']

.sub find_method :vtable :method
   .param string meth_name

   print 'find_method "'
   print meth_name
   print '" from "'
   print self
   say '" (***)'


   .local pmc func
   func = new 'Func'
   .return (func)
.end

.sub get_string :vtable
   .return ('an instance of Obj')
.end

=

I expect as output:

find_method "some_method" from "an instance of Obj" (***)
vtable invoke with self = "an instance of Func", arg = "an instance of Obj"

I don't know about the internals of parameter passing, it could be
that it's not possible.


The current output is:

find_method "some_method" from "an instance of Obj" (***)
vtable invoke with self = "an instance of Func", arg = "" (***)"

Some strange things are happening with registers.

--
Mehmet

Re: Is Perl 6 too late?

[Ryan Richter]

On Mon, May 14, 2007 at 20:41:35 +0300, Gabor Szabo wrote:
> On 5/14/07, John Macdonald <[EMAIL PROTECTED]> wrote:
> >  Removing the sigil
> > on a function call (it used to always be written &sub(args...))
> > did, I think, lead to the difficulty in perl5 where it became
> > difficult to add new keyword operators to the language - because
> > they could conflict with subroutine names in existing code.
> 
> Actually I think I never understood  this issue.
> We claim that having the sigils saves us from stepping on our future
> feet by making sure keywords of the language are always different
> from any variable we might create.
> 
> The fact that function don't need a sigil any more and it is even
> AFAIK discouraged to be used makes *this* argument mute.
> 
> Thought this thread might not be the best place to ask this
> I'd be glad to read some explanation about this.

In Perl 6, the & sigil is used to distinguish between

foo bar

which calls bar and passes the return value to foo, and

foo &bar

which passes bar as a Code object to foo.

-ryan

(sorry, I deleted your message by mistake, I'm attempting to fake up a reply)

Re: Is Perl 6 too late?

[Juerd Waalboer]

Thomas Wittek skribis 2007-05-14  0:42 (+0200):
> excessive use of special characters (/\W/).

This seems to be "I don't like regexes". Ignoring for now that Perl 6
regexes will be more verbose and thus easier to read for someone without
much prior exposure to them, what would you suggest as an alternative to
regex matching?

One of the common alternatives is to iterate over a list of characters,
possibly using an index. Would you say that a screen page full of such
code is easier to read and maintain than a single regex on a single
line?

Many languages have regexes, even the cleanest among them. And they're
all as messy as Perl's. They're often more verbose on the outside, which
can result in something like foo.match(/foo/) instead of foo =~ /foo/,
but the /foo/ part is most important here. If you don't recognise what
that is, it doesn't matter if ".match" or "=~" was used.

Many languages have regexes, but Perl was probably the first to apply
them heavily in "normal" programming. And nowadays, they're so
ubiquitous that it's hard to find a language without Perl-ish or "Perl
compatible" regexes. Why do you think this is?

I think it's kind of funny that indeed exactly the most cryptic part of
Perl's syntax is copied to so just about every modern programming
language, while at the same time Perl is constantly criticized for using
"special characters" so much.

No, special characters aren't a problem. They are the fundament of a
very powerful and expressive syntax. Just don't try to understand a
screen full of them all at once -- realise that in another language, the
first three lines would sometimes already fill the same screen, and
adjust your reading speed.

On the other hand, the overall structure of a program is often more
obvious, exactly because so much more fits in one screenful.

In Perl it is often not needed to refactor something to many tiny
subroutines with verbose identifiers, just for legibility.

One thing stays true, though: Perl is very hard to read for someone who
doesn't know Perl well enough. But that's practically true for almost
language, be it Python or Japanese.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: Is Perl 6 too late?

[Larry Wall]

On Mon, May 14, 2007 at 02:21:47PM -0400, Ryan Richter wrote:
: In Perl 6, the & sigil is used to distinguish between
: 
: foo bar
: 
: which calls bar and passes the return value to foo, and
: 
: foo &bar
: 
: which passes bar as a Code object to foo.

In other words, the sigil is consistently a noun marker in Perl 6,
even when a sigil is used on a verb.  In Perl 6, where sigils
distinguish nouns not only from verbs, but also from adjectives (if
you count types as adjectival).  With a glance you can tell which
are the nouns and which are the types here:

multi CatDog sub make_catdog (Cat $cat, Dog $dog) {...}
multi CatDog sub make_catdog (Cat Dog $catdog) {...}

While Gabor is correct that in Perl 5 removing the sigils from verbs
made some verbal collisions happen that otherwise wouldn't have, in
Perl 6 we've mostly fixed that by essentially getting rid of most
reserved words, and making even the builtin functions participate
as normal multis and methods.  For that reason, and because verbs
linguistically tend to be disambiguated by the nouns fed to them as
argements, verbs don't need to be conjugated nearly as badly as nouns
need to be declined.  A lot of nouns typically don't have arguments
to disambiguate them with, at least until you start subscripting them,
and we don't do multiple dispatch on subscripts.

As for the original complaint, we long ago decided to ignore people who
are prejudiced against languages that mark nouns.  Greek wouldn't be
Greek if you couldn't decline your nouns.  (In my estimation, it's
the conjugated verbs that make Greek so difficult to learn, really.
On the other hand, once you learn them they're very expressive in
tense and aspect.  It's all tradeoffs.)

Larry

Re: Is Perl 6 too late?

[Tibor Foeldes]

OK! Be concrete  !   :-) ( Hart wie Beton !)

As Ruby and Python are getting more and more attraction [1][2] I think
they do something right, that Perl doesn't.
What I think where both (especially Python) do better is in readable 
code.


What makes Perl hard to read is the excessive use of special characters
(/\W/).
  

(/\W/)
It is  in Ruby the same.  In Python  re.search('\W',foo).Is  it  
really nicer ?



In my opinion, reducing the use of those characters would make Perl a
lot easier to read and also easier to write.
Global variables with cryptic names, that no beginner can make any sense
of by reading it. And after not working with "$<" for some months I
can't remember it either, although I've got quite some Perl experience.

  

In Perl6:  $*UID   (see S02.pod)

Additionally I'm not a friend of sigils: Typing them is relatively
painful, for reading there is no advantage if you use an editor with
decent syntax highlighting and the code looks more cryptic. The answer
in Perl6 are twigils, great... One step backwards in my optinion.
Most programming languages
/C(++|#)?|Java(Script)?|Python|Ruby|Groovy/... don't need them. The only
obvious advantage of using sigils is variable interpolation in strings.
But that could easily be done only in strings without the need to put a
$ in front of each and every variable name in the rest of the code.

  
Perl is a language with sigils. We must see it more penetrating ! The 
advantages of sigils in Perl are overall, by item access in structures, 
by the flexibility of subroutine calls, interpolation , global 
variables,  
Perl wants separate variables from other language structures . Perl 
without sigils is not Perl more.  Perl6 in this regards is really to 
late for you :-)

I would also like semicolons to be optional. There are far more cases of
single line statements than multiline statements. So you would save
quite some characters, when the semicolon would be optional and you
could concatenate multiline statements with e.g. a backslash.

Some say that there are too much operators in Perl(6). I partially
agree. I don't like the implicit type casting forced by the operators
(== int / eq string). That's harder to learn and remember. Harder to
read also.

Operators are only another format ( nice ) of functions.

I really like the Python way of doing it: Set the variables type on the
  assignment and remember it. The (fewer) operators now work according to
the type of the operands. No implicit (and error prone) type casting.
That way seems to be the best compromise of easiness and type safety.
I could continue on that, but I've already written too much...
  

"use warnings" is helping you !

And you can always make explicit type conversion. That does mean 
explicit :-) . But you must type something more.
The only builtin implicit type casting in Perl is this numeric / string 
conversion and it is fairly obvious and absolutely not error-prone.



[1] http://radar.oreilly.com/archives/2007/05/state_of_the_co_6.html
[2] http://www.google.com/trends?q=perl%2C+python+-snake%2C+ruby

  
These reports are fairly special. These are not about popularity of a 
programming language , but
how many books O'Reilly sold, and how many were googled. What about is 
not clear. Maybe waiting for Perl6 ?

In place of contributing? Searching for redemption ?

People not only want code that _is_ sexy, but they also want it to
_look_ sexy.
  
Sex is oftentimes perversion ;-) Well, natural selection. Survives the 
fittest idea , not necessarily the sexiest look.


Tibor

Re: explicit line termination with ";": why?

[Andrew Shitov]

> I don't want to argue about the design of perl6[1], I just wonder: why
> the semicolon is still needed in the end of lines in perl6?

JavaScript allows to omit semicolumn. In lecture at Yahoo's YUI
Theatre one of JS's gurus talked about how it is organized in
JavaScript parser.

If the line of code is not ended with ';' the parser tries first
to assume that the next line continues current one. If then syntax error
occurs, the parser _goes_back_ and make another asumption that previous
line was ended with semicolumn.

Probably there are much more than one way to implement ';'-less but it
either slows down the compiler or makes grammar more complex.

And in fact Perl 6 already allows not to type ';' at the end of
{block} ;-)

The following simple snippets work correctly with Pugs and perl5:

 perl 6
sub debug ($value)
{
say $value
}
debug 'me'


# perl 5
sub debug
{
   print shift
}
debug 'me'


And finally, Perl is not an Assembler with one only instrucion per
line.


--
Andrew Shitov
__
[EMAIL PROTECTED] | http://www.shitov.ru

explicit line termination with ";": why?

[gabriele renzi]

Hi everyone,

I don't want to argue about the design of perl6[1], I just wonder: why 
the semicolon is still needed in the end of lines in perl6?


I can think of different reasons (history, readability, easier parsing 
of multiline statements, force people to write one-line functions to 
avoid typing them :) but I'm curious to know the real one.


Sorry if this is already been explained but my google-fu was not good 
enough to find an answer.




[1] of course I actually do, but I know that I will be able to write my 
own Grammar, to scratch my Wannabe Language Designer itches ;)

Re[2]: explicit line termination with ";": why?

[Andrew Shitov]

> JavaScript allows to omit semicolumn.

Sorry, s/lumn/lon/.

By the way, Perl also ignors semicolumn :-)



--
Andrew Shitov
__
[EMAIL PROTECTED] | http://www.shitov.ru

Re: explicit line termination with ";": why?

[Larry Wall]

On Mon, May 14, 2007 at 07:05:01PM +0200, gabriele renzi wrote:
: Hi everyone,
: 
: I don't want to argue about the design of perl6[1], I just wonder: why 
: the semicolon is still needed in the end of lines in perl6?
: 
: I can think of different reasons (history, readability, easier parsing 
: of multiline statements, force people to write one-line functions to 
: avoid typing them :) but I'm curious to know the real one.

The "real" one, eh?

These sorts of things are almost never for a single reason.  Some of
it is my prejudice against dangling syntax, and perhaps prejudice
against anything resembling Fortran.  Some of it is not wanting to
distinguish different kinds of whitespace any more than we already do.
Some of it is simplicity of parsing, both for the human reader as
well as for the computer.  I think if I had to pick one reason,
though, it's that it allows the parser to understand the intent of
the writer much better and hence give more useful diagnostics when
something seems to be going wrong.  Much more than other languages,
Perl depends on the prohibition against two terms in a row as a kind
of "self-clocking" mechanism to disambiguate programmer intent, and
not requiring a semicolon between the final term of one statement
and the first term of the next statement would tend to weaken that,
especially when the term starts with a prefix operator that could be
mistaken for an infix.

: Sorry if this is already been explained but my google-fu was not good 
: enough to find an answer.

Honest questions deserve honest answers, even if they aren't simple answers.

Larry

Re: Is Perl 6 too late?

[Thomas Wittek]

Frank Wiles schrieb:
> Take a look at
> actual code written in other languages and you'll find many variable
> names that end in things like _ary, _array, _dict, _list, etc.

Actually I've not seen that often. Where I've seen it frequently is in
Visual Basic and Delphi/Pascal.
I hated it too.

But I think that the name of an identifier (noun/verb, single/plural,
the meaning of the word) already gives enough context to understand what
type it is.
And every use of it (assigning and reading) additionally makes it clear.
So _for me_ there is no need for an additional hint for the type.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: Is Perl 6 too late?

[Thomas Wittek]

chromatic wrote:
> theproblemlinguisticallyspeakingisthatsometimes [snipped]

I can't remember that I said that you shouldn't separate your
expressions (by punctation/whitspaces),
$.but! (*adding$ %*characters _+that^# &$might) @#not_ !#be()
!&necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier
to read and to type (in addition it was a torture to type that).

>> So semicolons don't seem to be the best invention since sliced bread.
>> There should be extra-syntax for the rare cases (multiline) and not for
>> the common ones.
> 
> Somehow English seems to get by with periods at the ends of statements, 
> though 
> almost no one pronounces them.

Oh, I thought Perl was a programming language. My fault.
Apples and oranges.
Most modern scripting languages don't need the semicolons. I think
there's no plausible reason for them.

> I agree.  You need less ignorant colleagues.  I'm not sure Perl 6 can fix 
> that.

I don't think that it's a point of ignorance.
Especially as they (and enough other people on the web) only seem to be
ignorant regarding Perl. Strange, huh?

> By the way, I'm still waiting to meet your cadre of Dylan hackers.

I never claimed to have some.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: explicit line termination with ";": why?

[Aankhen]

On 5/14/07, Andrew Shitov <[EMAIL PROTECTED]> wrote:

JavaScript allows to omit semicolumn.


Speaking of JavaScript, any experienced JavaScript programmer will
tell you that while semi-colons are in fact optional, you should
always treat them as mandatory, to avoid subtle errors creeping into
your code.

--
Aankhen
(We have no branches.)

Re: Is Perl 6 too late?

[Doug McNutt]

At 11:43 -0700 5/14/07, Larry Wall wrote:
>In other words, the sigil is consistently a noun marker in Perl 6, even when a 
>sigil is used on a verb.

It would seem to me that a preprocessor, written in perl of course, could 
easily respond to "DIMENSION noun AS double" statements or whatever you like by 
adding the appropriate sigl every the noun appears without it.

As for "too late" I do have a problem. I started with perl 4 or so as MacPerl 
with Apple's MPW as a shell. Now, at age 72, I do worry that perl 6 may be too 
late for me. It's been two years since I got to the point of using the * sigl 
in perl 5 and I still have a lot to learn about that.

FORTRAN forever.
-- 

Applescript syntax is like English spelling:
Roughly, though not thoroughly, thought through.

Sigils by example (was: Re: Is Perl 6 too late?)

[Juerd Waalboer]

Thomas Wittek skribis 2007-05-14 22:20 (+0200):
> But I think that the name of an identifier (noun/verb, single/plural,
> the meaning of the word) already gives enough context to understand what
> type it is.

So is "user_id" a variable or a type? How about "substring" or
"document"?

Is "new" a function, or a variable? How about "old"?

Is "is_valid" a function that determines whether something is valid, or
a variable holding the result of this test?

When you have "update(delete_random)", where both update and
delete_random are functions, does this pass the function "delete_random"
to "update", or does it first delete something, and then pass the
resulting value to update? Don't forget that one of the important
decisions in Perl was that we don't always like to use parentheses,
because that clutters code (and you don't want that!!).

Given "HTML Element", is HTML the type and Element the variable of that
type, or is Element the type, and HTML the variable (for example, to
hold the  element object)?

Is "pid" a variable you used yourself, for example as the return value
from "fork", or does "pid" give you the pid of your current process? And
if the latter, is that by calling the pid function, or because pid is a
variable?

Doesn't "count input" look wrong to you? It should, because "count" is a
hash! By the way, what would "input" be?

And how on earth would you write "object.foo()", where foo is a variable
holding a reference to a method, not the name of the method, if you had
no sigils?


...


...


...


...


...

| So is "user_id" a variable or a type? How about "substring" or
| "document"?

The Perl Way:

$user_id is a variable, $substring is a variable, $document is a
variable.

user_id is not a variable, substring is not a variable, document is not
a variable.

| Is "new" a function, or a variable? How about "old"?

The Perl Way:

$new is a variable, $old is a variable.

new is not a variable, old is not a variable.

| Is "is_valid" a function that determines whether something is valid, or
| a variable holding the result of this test?

The Perl Way:

$is_valid is a variable.

is_valid is not a variable.

| When you have "update(delete_random)", where both update and
| delete_random are functions, does this pass the function "delete_random"
| to "update", or does it first delete something, and then pass the
| resulting value to update? 

The Perl 6 Way:

update(&delete_random) passes the function &delete_random to &update.

update(delete_random) calls the function &delete_random, and passes
whatever it returned to &update.

| Given "HTML Element", is HTML the type and Element the variable of that
| type, or is Element the type, and HTML the variable (for example, to
| hold the  element object)?

The Perl 6 Way:

HTML $Element is a variable of the type HTML.

$HTML Element is a syntax error caught early by the compiler. (And
that's really great if your native language makes you think the other
way around than the programming language wants you to.)

| Is "pid" a variable you used yourself, for example as the return value
| from "fork", or does "pid" give you the pid of your current process? 
| And if the latter, is that by calling the pid function, or because
| pid is a variable?

The Perl Way:

$pid is a variable that you set yourself.

pid is not a variable.

$*PID is a variable, that represents the pid of your current process.

| Doesn't "count input" look wrong to you? It should, because "count" is a
| hash! By the way, what would "input" be?

The Perl Way:

%count $input (or %count input) looks wrong, error caught even before
compile time, programmer time and energy conserved.

| And how on earth would you write "object.foo()", where foo is a variable
| holding a reference to a method, not the name of the method, if you had
| no sigils?

The Perl Way:

$object.foo() calls the method called "foo".

$object.$foo() calls the method that is in the variable $foo.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: Is Perl 6 too late?

[Juerd Waalboer]

Thomas Wittek skribis 2007-05-14 22:31 (+0200):
> $.but! (*adding$ %*characters _+that^# &$might) @#not_ !#be()
> !&necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier

Those characters are meaningless. The many symbols in Perl 6 have very
distinct meanings, which makes them very powerful tools!

> Oh, I thought Perl was a programming language. My fault.
> Apples and oranges.

There is a reason that C programmers don't throw away their source code
after compiling it.

While in some companies, writing software is indeed a unidirectional
process, most companies that wish to survive have to maintain what they
wrote, and then you also have to read it.

Programming languages and spoken languages are both read by human
beings, so they should still be easily parsed by these creatures.

> Most modern scripting languages don't need the semicolons. I think
> there's no plausible reason for them.

They typically have a line continuation character instead of a
semicolon, though. However, like the previous sentence, and this one
too, actually, sometimes there is a line break in between.

Again, written language can be a nice example, because if we had line \
continuation characters in here, it would suddenly look a lot \
different. Did you, while reading this, pause, just before "different"?
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re[2]: explicit line termination with ";": why?

[Andrew Shitov]

> Aankhen wrote:

> Speaking of JavaScript, any experienced JavaScript programmer will
> tell you that while semi-colons are in fact optional, you should
> always treat them as mandatory, to avoid subtle errors creeping into
> your code.

We should also note that the idea of omitting ';' is not as simple as
<"\n" always means ";\n">. In mentioned JavaScript language one can
do this:


var
x
=
123
alert
(
x
)


and that will work!

";\n" can almost always be converted into "\n" but not vice versa.


--
Andrew Shitov
__
[EMAIL PROTECTED] | http://www.shitov.ru

Re: explicit line termination with ";": why?

[Jonathan Lang]

gabriele renzi wrote:

Hi everyone,

I don't want to argue about the design of perl6, I just wonder: why
the semicolon is still needed in the end of lines in perl6?


It isn't - sometimes.  S03 identifies a number of ways that an
expression can be terminated: the semicolon (';'), a block-final
('}'), a control block (' { ... }'), a statement modifier
('if'|'unless'|'while'|'until'|'for'|'given'|'when')^, or a feed
operator ('<<==', '<==', '==>', '==>>').

^ FWIW, S03 needs updating, since it doesn't list 'given' or 'when'
among the statement modifiers in the block termination section.

A couple of thoughts:

1. There's a subtlety here: termination of an expression is not always
the same as termination of a statement.  In particular, ';' is pretty
much equivalent to the '<==' feed operator when used in a bracketing
construct [1]^, and feed operators in general don't appear to force
statement termination the way that control blocks, statement
modifiers, and block-finals do.  Of course, this distinction may be me
misunderstanding how expression termination works.

2. This brings up the possibility of custom-designed termination
operators.  Question: which kinds of operators can have this
precedence?  That is, prefix, postfix, infix, circumfix, or
postcircumfix?  It appears to me that our current list of termination
operators includes analogs of most of these: postfix:<;>,
infix:{'<=='}, circumfix:<{ }>, and postcircumfix:«\s{ }» [2]^.

  Meanwhile, how much clarity does the parser have between postfix
and infix?  That is, if I defined both postfix: and infix:,
would the parser be able to reliably distinguish between them?  This
matters to the current topic because ';' could be thought of as
'postfix-like' when used to terminate a statement, and 'infix-like'
when being used to construct feeds; if clarity between postfix and
infix exists, you might be able to do away with the "bracketed
context" clause - though it might not be wise to do so, even if you
could.)

  I'm thinking about this in terms of the possibility of adding more
punctuation to the syntax: consider something akin to a postfix:
operator that behaves exactly like postfix:<;>, except that it
automatically topicalizes the expression's value.  Or a postfix:<.>
that always behaves the way that postfix:<;> does at statement level
[3]^.  Borrowing from Spanish, circumfix:<¿ ?> might be to
circumfix:<{ }> as postfix: would be to postfix:<;>.  And so on.

  As long as we maintain clarity between the grammatical categories,
such "punctuation operators" shouldn't present any difficulty; e.g.,
postfix: will not clobber prefix: or vice versa, even if the
former has terminator precedence and the latter has symbolic unary
precedence.

  Or is this the sort of thing that you'd rather consign to explicit
hacks of the parser?

^[1]: see S09.
^[2]: Admittedly, this last one cheats a bit by putting whitespace
into the delimiter.  But the principle is the same.
^[3]: If this were included in the core, you might even reverse things
so that ';' is defined in terms of postfix:<.> or infix:{'<=='},
depending on the context; in this case, postfix: would be defined
in terms of postfix:<.>, rather than postfix:<;>.  In fact, the only
thing keeping postfix:<.> from completely replacing postfix:<;> as a
statement terminator and insisting that the latter always be used as a
shortcut for feeds is the long tradition that the latter has in
programming languages - much like perl 6's infix:<.> replaces perl 5's
'->' because that's what everyone else uses.

--
Jonathan "Dataweaver" Lang

Re: Sigils by example (was: Re: Is Perl 6 too late?)

[Jonathan Lang]

Good examples.  Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and '&'?  I ask
because I've seen a lot of object-based code that has said stuff like
'$container{$key}'; it seems that there's an assumption that $foo can
be used as a list, a hash, or even a routine if the object that it's
tied to has list-, hash-, or routine-like behavior: i.e., it no longer
seems to be "a scalar variable", but rather "a variable".  Whereas
'@', '%', and '&' still seem to promise list, hash, and routine
functionality, respectively.  In short, there no longer appears to be
a sigil that says "I give my solemn promise that the contents herein
will be scalar."

--
Jonathan "Dataweaver" Lang

Re: explicit line termination with ";": why?

[Jonathan Lang]

Jonathan Lang wrote:

^[3]: If this were included in the core, you might even reverse things
so that ';' is defined in terms of postfix:<.> or infix:{'<=='},
depending on the context; in this case, postfix: would be defined
in terms of postfix:<.>, rather than postfix:<;>.  In fact, the only
thing keeping postfix:<.> from completely replacing postfix:<;> as a
statement terminator and insisting that the latter always be used as a
shortcut for feeds is the long tradition that the latter has in
programming languages - much like perl 6's infix:<.> replaces perl 5's
'->' because that's what everyone else uses.


Umm, never mind.  I just realized that introducing a postfix:<.>
operator would complicate matters in unexpected ways by forcing
infix:<.> to require disambiguating whitespace, as per S02.  This
would be Very Bad in several ways, e.g., an infixed dot is given as
the appropriate way to separate a postfix operator from the term in
front of it when whitespace is forbidden.  Or the fact that 'foo.bar'
would no longer parse as expected.  :sigh:

--
Jonathan "Dataweaver" Lang

Re: Sigils by example (was: Re: Is Perl 6 too late?)

[Mark J. Reed]

On 5/14/07, Jonathan Lang <[EMAIL PROTECTED]> wrote:

Good examples.  Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and '&'?  I ask
because I've seen a lot of object-based code that has said stuff like
'$container{$key}';


Well, $container{$key} is how you access elements of %container in
Perl5; in Perl6 that's %container{$key}.  But in object-based P5 code,
you'd be much more likely to see $container->{$key}, where $container
contains a reference to a hash.  I believe in P6 you could write that
either as $container.{$key}, $container{$key} (where the . is implied
since $container{$key} can't refer to %container anymore),  or
%$container{$key}.

If I understand your point, however, it is that the availability of
references, which are scalars, has essentially removed the
scalar/array/hash/sub distinction, since you can store references to
any of those things in a $var.   Further, in order to dereference such
references, you need something beyond the sigil anyway, which takes
its place as a type disambiguator.

You aren't the only person who feels this way; there was a proposal
back in the RFC process to remove sigils in favor of "everything is a
scalar, dereference as needed".  I was in that camp myself.  But Larry
rejected that proposal, defending the utility of sigils, and I have
been swayed by the arguments, which I'm not going to repeat because I
can't say it as well, but I do advise you to go read - it was either
Apoc1 or Apoc2, I think.

Anyway, one of the things I like about the Perl6 design is that it
essentially restores sigils to their pre-Perl5 importance via
automatic referencing and dereferencing according to context.   This
effectively removes the "everything's a scalar anyway" argument since
you can toss references around without making everything a $var.  (I
dunno how many times I have tried to declare and initialize a hash
with my %hash = { ... }, which initializes the hash to have a single
element whose key is the hash reference provided and whose value is
undef... but in P6 that does the right thing.)


--
Mark J. Reed <[EMAIL PROTECTED]>

Re: Sigils by example

[Thomas Wittek]

Juerd Waalboer wrote:
> Thomas Wittek skribis 2007-05-14 22:20 (+0200):
>> But I think that the name of an identifier (noun/verb, single/plural,
>> the meaning of the word) already gives enough context to understand what
>> type it is.
>
> [examples]

You are right, I should have weakened this sentence by "in most cases".
Tricky from you to cut out my next sentence, which was about additional
context that's needed in this cases and that your examples are missing
of course:

> Thomas Wittek also wrote:
>> And every use of it (assigning and reading) additionally makes it
>> clear.
>> So _for me_ there is no need for an additional hint for the type.

Juerd Waalboer wrote:
> And how on earth would you write "object.foo()", where foo is a variable
> holding a reference to a method, not the name of the method, if you had
> no sigils?

That would not happen in my code.
I consider having the same name for different things bad.
I even wouldn't do that _with_ sigils.

> The Perl Way:
> $object.foo() calls the method called "foo".
> $object.$foo() calls the method that is in the variable $foo.

My way:
someref = &somemethod
object.someref()

Of course you could argue that you don't know in advance, if "object"
has a method with that name, so you cannot manually avoid the conflict.
But it should be no problem to put out a warning/error at runtime (or
maybe even at compile time) when a variable name clashes with a method name.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: Is Perl 6 too late?

[Austin Hastings]

Thomas Wittek wrote:

chromatic wrote:
  

theproblemlinguisticallyspeakingisthatsometimes [snipped]



I can't remember that I said that you shouldn't separate your
expressions (by punctation/whitspaces),
$.but! (*adding$ %*characters _+that^# &$might) @#not_ !#be()
!&necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier
to read and to type (in addition it was a torture to type that).
  


Forgive chromatic. Part of joining @Larry is undergoing a painful 
initiation process, which tends to inspire zealotry.


The point, though, is that there are three ways of handling the whole 
"part of speech" issue. One is with a dictionary (reserved words): in 
this method, every word is assigned a part of speech, usually with a 
"default." Any use of the word "FOR" must be a loop, any use of "INT" 
must be a typedef, etc.


Another is with context (and predeclaration). In this method, the 
surrounding context can be used to infer the part of speech of a word, 
with some sort of confirmation for 'new' words (user-defined variables, 
functions, etc.). Most present-day compiled languages use this one, 
although they frequently rely on the "reserved words" approach, too, for 
some words.


Finally, the approach Larry has chosen is to explicitly mark the part of 
speech. Perl up to version 5 used an approach that attempted to 
correlate the marker with the part of speech associated with the 
surrounding context: foo(@array) vs. foo($array[0])


This approach was criticized for providing relatively little value over 
the context+lookup approach. If the sigil has to correspond to the 
context, then only in rare cases (ambiguous context) is the sigil adding 
much value.


The new approach (@array[0]) ties the sigil to the declaration, serving 
to distinguish name collisions and of course to autovivify variables 
correctly.


Ultimately, it comes down to value added, and culture/custom. "Perl has 
always used sigils, so perl should continue to use sigils." That's a 
legitimate stand, in the absence of compelling arguments to the 
contrary. It "let's perl be perl."


As far as value goes, let's call the C/C++ approach the "nul" approach, 
since by default there is no sigil in front of words. (And I'm 
considering * and & to be sigils, rather than operators.)


The nul approach reduces typing. It relies on context to identify the 
part of speech, occasionally forces some look-ahead (a name followed by 
'(' is an invocation instead of a reference) and can't handle multiply 
typed (@foo vs. &foo vs. $foo vs. %foo) names.


The perl approach increases typing, by something less than 1 character 
per identifier. (This is a real cost, that Larry continues to elect to 
bear.) The p5 version imposed some disambiguation burden on the parser, 
since $foo[0] involved @foo, not $foo. Perl *can* handle *some* multiply 
typed names. There is a difference between $foo and @foo, but not 
between "my Cat $foo" and "my Dog $foo".


In addition, however, there is the whole *foo thing. Adding the sigil 
has encouraged people to think in weird ways, 'tied' variables and 
typeglobs not least among them. I don't know if a 'perl' that used the 
nul approach would ever have had those features. (Sapir-Whorf lives!)


The perl approach, then, opts to pay a significant penalty (0.9+ 
characters per variable) to allow access to the cool extra features that 
few other languages use, and none so compactly.


A similar trade-off exists with the statement terminating semicolon. In 
this case, it involves the number of statements per line:


A language that terminates statements can ignore whitespace, allowing 
multiple statements per line and statements that span multiple lines.


A language that associates line termination with statement termination 
must pay a separate cost (continuation marker) for a statement to span 
multiple lines. It will not, in general, support multiple statements per 
line. (Though it could make the terminator "optional" and then inject 
terminators between colinear statements.)


The vast majority of languages have opted to terminate statements. Perl 
is among them. Probably the best argument is that encountering a 
semicolon (or full stop, in COBOL) is a positive indicator rather than a 
negative one. "I see a semicolon. I know the statement is over." as 
opposed to "I don't see a continuation marker, so it's likely that the 
statement is over, although it could be tabbed way off to the right or 
something."


Also, there's the increasing size of words to consider. While $a = $b + 
$c is a great example of why line termination is not needed, the trend 
is for variable and function names, not to mention object and method 
dereferences, to grow longer.


From 
http://www.oreillynet.com/pub/a/javascript/2003/03/18/movabletype.html I 
get:


|MT::Template::Context->add_tag(HelloWorld => sub { return 'Hello World.'; } );|


The MT::...add_tag method name alone is 30 characters. Jam a few long 
identifiers together and you're wr

Re: Is Perl 6 too late?

[Thomas Wittek]

Juerd Waalboer schrieb:
> Thomas Wittek skribis 2007-05-14  0:42 (+0200):
>> excessive use of special characters (/\W/).
> 
> This seems to be "I don't like regexes". Ignoring for now that Perl 6
> regexes will be more verbose and thus easier to read for someone without
> much prior exposure to them, what would you suggest as an alternative to
> regex matching?

Not ignoring that will nullify your argument.
Regexps/rules are great, and I never said anything differing. If the
syntax gets more readable without any cost (in which I belive) its even
better.
Now do s/Regexps\/rules are/Perl is/ on the last sentence.

> On the other hand, the overall structure of a program is often more
> obvious, exactly because so much more fits in one screenful.

My suggestions won't have an impact on the expressiveness of Perl.
So in many cases you might have even less characters on your screen.
Of course some special character sequences would be replaced by word
character sequences, but that won't fill your screen by a magnitude.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: explicit line termination with ";": why?

[Daniel Hulme]

On Mon, May 14, 2007 at 02:29:11PM -0700, Jonathan Lang wrote:
> 2. This brings up the possibility of custom-designed termination
> operators.

cf. Semi::Semicolons. I think that being flexible enough that people can
write packages like that is one of Perl < 6's greatest strengths.

Long may it continue. Of course, if Perl 6 is actually parsed using a
descendant of Larry's 'Perl 6 grammar as a Perl 6 grammar', the compiler
could easily (*cough*) provide hooks to edit the grammar at parse-time,
meaning you can write your own (lexically scoped) Semi::Semicolons, or
Semi::Line::Continuation::Markers, or even
Semi::I::Don't::Really::Want::Prefix::Operators::Available::As::Methods.
Then there need be no arguments about what it looks like, and everyone
will be happy, and all programmers will hold hands and stop having
holy wars. Maybe.

-- 
"Sometimes it's a Boat,  and sometimes it's more of an Accident.  It all
"Depends on what?" depends."
"On whether I'm on the top of it or underneath it."
   -- A. A. Milne, 'Winnie-the-Pooh'   http://surreal.istic.org/


signature.asc
Description: Digital signature

Feeling Slushy

[chromatic]

Hi everyone,

I'm handling the release tomorrow, so please hold off on changes to the core 
code until after the release.  Documentation and typo fixes are fine.  
Language changes are fine too.  Not-too-invasive bug fixes are good.

In the meantime, I'd like to collect platform status results, smoke test 
results, and any information you think should be in the new features list.

-- c

Re: Sigils by example

[Juerd Waalboer]

Thomas Wittek skribis 2007-05-15  0:48 (+0200):
> > The Perl Way:
> > $object.foo() calls the method called "foo".
> > $object.$foo() calls the method that is in the variable $foo.
> My way:
> someref = &somemethod
> object.someref()
> Of course you could argue that you don't know in advance, if "object"
> has a method with that name, so you cannot manually avoid the conflict.

Indeed. Now you have to know your object very well, and avoid all of its
method names for variable names. For example, an HTTP::Request object
has a .headers method. If Your Way were in effect, I could no longer
safely use the name "headers" for my own variables, and then still call
the "headers" method on the object.

Perl allows both avoiding clashes and not-avoiding clashes. Your way
only strictly requires the former programming style. And since my
preferred style is different, I'm glad you're not designing Perl 6.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: explicit line termination with ";": why?

[Thomas Wittek]

Andrew Shitov:
> If the line of code is not ended with ';' the parser tries first
> to assume [..]

Wouldn't that be unambigous?

 foo = 23
 bar = \
   42

?

I think there would be no ambiguities and you only had to add additional
syntax for the rare cases instead of the common cases.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: Sigils by example (was: Re: Is Perl 6 too late?)

[Juerd Waalboer]

Jonathan Lang skribis 2007-05-14 14:52 (-0700):
> Good examples.  Now could you provide some to explain to me why it's
> important to distinguish between '$', '@', '%', and '&'?

It's useful code self documentation, but not very important, in my
opinion.

If you have sigils, it makes sense to have different sigils for
different things, because that allows very nice shorthands (remember how
this thread was originally more or less about avoiding clutter?) like:

sub foo (@bar, $baz) { ... }

And of course, different behaviour in list context:

my @quux = (@foo, @bar);  # These arrays "foo" and "bar" flatten
my @quux = ($foo, $bar);  # These arrays "foo" and "bar" do not

That's a subtle yet very useful distinction.

But this is "just" very handy, not important.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: Sigils by example

[chromatic]

On Monday 14 May 2007 15:48:24 Thomas Wittek wrote:

> But it should be no problem to put out a warning/error at runtime (or
> maybe even at compile time) when a variable name clashes with a method
> name.

Do you always know all of the method names in your entire memory space at 
compile time?

-- c

Re: Is Perl 6 too late?

[Thomas Wittek]

Austin Hastings:
> A similar trade-off exists with the statement terminating semicolon. In
> this case, it involves the number of statements per line:
> 
> A language that terminates statements can ignore whitespace, allowing
> multiple statements per line and statements that span multiple lines.

Still possible with optional semicolons (as you say later):

 a = 1
 b = \
 2
 c = 3; d = 4

> The vast majority of languages have opted to terminate statements.

Most of the younger scripting languages didn't.

> Probably the best argument is that encountering a
> semicolon (or full stop, in COBOL) is a positive indicator rather than a
> negative one. "I see a semicolon. I know the statement is over." as
> opposed to "I don't see a continuation marker, so it's likely that the
> statement is over, although it could be tabbed way off to the right or
> something."

Your semicolon could also be tabbed way off, so you can't be sure there
either.
"I see no semicolon, so it's likely that the statement continues on the
next line".

> So line termination doesn't gain a punctuation character

No problem I think.

> and causes the ends of lines to be uncertain.

It's exactly as certain as with semicolon termination. See above.

> It does reduce typing, for the small crowd of people that wouldn't
> just use them anyway because they use them in every other language.

> I think the lack of value here outweights the "savings" of one character
> per line.

But even if the advantage of line termination is low (some characters
saved, some people might say it looks cleaner), I cannot see any
advantage of semicolon termination.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: explicit line termination with ";": why?

[John Macdonald]

On Tue, May 15, 2007 at 01:22:48AM +0200, Thomas Wittek wrote:
> Andrew Shitov:
> > If the line of code is not ended with ';' the parser tries first
> > to assume [..]
> 
> Wouldn't that be unambigous?
> 
>  foo = 23
>  bar = \
>42
> 
> ?
> 
> I think there would be no ambiguities and you only had to add additional
> syntax for the rare cases instead of the common cases.

Without explicit \ to join unterminated lines you get:

  foo = 23
  if x == 7
  { y = 5; z = 6 }

Is that:

  foo = 23
  if x == 7;
  { y = 5; z = 6 }

or:

  foo = 23;
  if x == 7
  { y = 5; z = 6 }

?

With explicit \ to join unterminated lines you just get more
ugliness than having semicolons.  It's also, in many cases,
harder to edit - that's why a trailing comma in a list that
is surrounded by parens, or a trailing semicolon in a block
surrounded by braces, is easier to manage.  The syntax of
the last element is the same as the rest so you can shuffle
the order around easily without having to add a separator to
the end of what used to be the final element and remove the
separator on what is now the final element.

Having punctuation where there is a stop is more natural than
having an explicit marker for "don't stop here, keep going".

-- 

Re: Is Perl 6 too late?

[Juerd Waalboer]

Thomas Wittek skribis 2007-05-15  1:03 (+0200):
> > On the other hand, the overall structure of a program is often more
> > obvious, exactly because so much more fits in one screenful.
> My suggestions won't have an impact on the expressiveness of Perl.

Not so.

Consider /@foo/, which is an alternation of all the elements of @foo.
That's not "just" interpolation, it's something very smart, and even
without seeing the context that this regex is in, I know how to read
this. I don't have to scroll back up to find out that "foo" was once
assigned an array.

> So in many cases you might have even less characters on your screen.

Less characters isn't always better. Often it's worse, sometimes it's
better. It appears to me a hell of a job to find out when it's what, and
I think Larry figured it out quite well.

> Of course some special character sequences would be replaced by word
> character sequences, but that won't fill your screen by a magnitude.

Of course. Every symbol can be substituted for a word comma but that
doesn apostrophe t automatically make code easier to read period I think
a language needs a good balance between symbols and letters comma and
for a programming language comma I think alternating between the two is
close to a perfect balance comma whereas in human languages once, every
$few (words) is.probably; "period"
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: Sigils by example

[Thomas Wittek]

Juerd Waalboer schrieb:
> Thomas Wittek skribis 2007-05-15  0:48 (+0200):
>>> The Perl Way:
>>> $object.foo() calls the method called "foo".
>>> $object.$foo() calls the method that is in the variable $foo.
>> My way:
>> someref = &somemethod
>> object.someref()
>> Of course you could argue that you don't know in advance, if "object"
>> has a method with that name, so you cannot manually avoid the conflict.
> 
> Indeed. Now you have to know your object very well, and avoid all of its
> method names for variable names. For example, an HTTP::Request object
> has a .headers method. If Your Way were in effect, I could no longer
> safely use the name "headers" for my own variables, and then still call
> the "headers" method on the object.

You are right, it would not be practical to prohibit variable names to
be the same like any other object method names.

But still I can't imagine a useful example where I want so call a method
of object A on object B, which doesn't have this method.
Would it be a good idea to call methods on objects, that never thought
of this methods?
If it wasn't allowed to do so (because it may be not a good idea at all
-- i don't know), we wouldn't have that problem:

Storing a reference to a method of object A, that will only be called on
object A could be done like this:

  my ref = A.method
  ref()


> Perl allows both avoiding clashes and not-avoiding clashes. Your way
> only strictly requires the former programming style. And since my
> preferred style is different, I'm glad you're not designing Perl 6.

I'm also glad not to do that as I don't think that I'd have the
knowledge to do that.
I just offer my thoughts.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: Sigils by example

[Thomas Wittek]

chromatic schrieb:
> On Monday 14 May 2007 15:48:24 Thomas Wittek wrote:
> 
>> But it should be no problem to put out a warning/error at runtime (or
>> maybe even at compile time) when a variable name clashes with a method
>> name.
> 
> Do you always know all of the method names in your entire memory space at 
> compile time?

No, and as I wrote to Juerd, I now think that it's also not a good idea
at runtime.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: Sigils by example (was: Re: Is Perl 6 too late?)

[Jonathan Lang]

Mark J. Reed wrote:

Jonathan Lang wrote:
> Good examples.  Now could you provide some to explain to me why it's
> important to distinguish between '$', '@', '%', and '&'?  I ask
> because I've seen a lot of object-based code that has said stuff like
> '$container{$key}';

Well, $container{$key} is how you access elements of %container in
Perl5; in Perl6 that's %container{$key}.  But in object-based P5 code,
you'd be much more likely to see $container->{$key}, where $container
contains a reference to a hash.


True; but not at all what I was referring to.


I believe in P6 you could write that
either as $container.{$key}, $container{$key} (where the . is implied
since $container{$key} can't refer to %container anymore),  or
%$container{$key}.


_This_ is closer to what I'm referring to.  As I understand it, Hash
is a role that provides (among other things) postcircumfix:<{ }>.  So
any object that does Hash should be able to call the above method.
And unless I've missed something, there's nothing in perl 6 that
insists that an object that does Hash must be assigned to a variable
that uses the '%' sigil; the '$' sigil seems to work equally well.
i.e., I've seen code to the effect of:

 class Foo does Hash { ... }
 my $obj is Foo;
 $obj = 5;
 say $obj;

In short, it appears that there's nothing keeping you from assigning
hash-like or list-like objects to scalar variables.

And this is without bringing references into the picture.


You aren't the only person who feels this way; there was a proposal
back in the RFC process to remove sigils in favor of "everything is a
scalar, dereference as needed".  I was in that camp myself.  But Larry
rejected that proposal, defending the utility of sigils, and I have
been swayed by the arguments, which I'm not going to repeat because I
can't say it as well, but I do advise you to go read - it was either
Apoc1 or Apoc2, I think.


I have never been in that camp.  In fact, I tend to see the points I
raise above as a bug, not a feature.

Perhaps the relationship between sigils and roles will be addressed in
the as-yet unwritten S14 (or whichever spec is supposed to address
tied variables)?

--
Jonathan "Dataweaver" Lang

Re: Sigils by example

[Juerd Waalboer]

Thomas Wittek skribis 2007-05-15  1:52 (+0200):
> Would it be a good idea to call methods on objects, that never thought
> of this methods?

Absolutely! Roles can be used for that too.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

variable type specific sigils (was Re: Sigils by example)

[Darren Duncan]

Speaking just for my own preferences, I very much like having sigils 
to differentiate variables from routines, that is, a $ prefix versus 
either & or no prefix.  However, I generally do *not* like the @ and 
% prefixes.  They seem somewhat contrived so to cover very specific 
variable types while other very similar types don't have them, eg 
built-in arrays versus some array-like other container type.


And so in my own coding style I use $ for all arrays and hashes too, 
so all my variables are $.  This is done consistently in both Perl 5 
and Perl 6.  The only place a @ or % appears is when I have to say 
@{} or %{}, and even then it is mainly just Perl 5 that requires 
this, such as in foreach or map.  Perl 6 is an improvement over Perl 
5 in that it is easier to use $ for arrays and hashes too without 
making code more verbose as a result.


I would be happy if Perl 6 dropped the @ and % for arrays and hashes, 
using just $ instead; however, I won't necessarily request this as 
the semantics of @ and % can be useful (assignment copy by value 
rather than by reference), and I can choose to not use them if I 
don't want to (TIMTOADY and all that).


On the other hand, unless this steps on something, I could suggest 
dropping the @ and % anyway, so we have $array and $hash, and then we 
could instead use the @ and % sigils as a prefix to indicate in that 
case that we want them to copy by value.  For example:


  my $foo = [23, 434, 6];
  my $bar;
  $bar = $foo; # copy by reference
  @$bar = @$foo; # copy by value

Actually, I think that would be a vast improvement, as we could then 
use the @ prefix with any collection type as short-hand to say that = 
is copy by value.


I also don't think the language would feel any less Perlish with this change.

-- Darren Duncan

Re: explicit line termination with ";": why?

[Thomas Wittek]

John Macdonald schrieb:
> It's also, in many cases,
> harder to edit - that's why a trailing comma in a list that
> is surrounded by parens, or a trailing semicolon in a block
> surrounded by braces, is easier to manage.

Now that the list is surrounded by parens makes clear that it ends with
the closing paren and not with a line break. So you could still use
commas (without backslashes) to separate the items over multiple lines.
See e.g. http://docs.python.org/ref/implicit-joining.html

> Having punctuation where there is a stop is more natural than
> having an explicit marker for "don't stop here, keep going".

That's the pro-semicolon reason that makes most sense in all comments
that I've read so far in this discussion.
But maybe that's just something where you have to get used to.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: explicit line termination with ";": why?

[Jonathan Lang]

On 5/14/07, Daniel Hulme <[EMAIL PROTECTED]> wrote:

On Mon, May 14, 2007 at 02:29:11PM -0700, Jonathan Lang wrote:
> 2. This brings up the possibility of custom-designed termination
> operators.

cf. Semi::Semicolons.


Close.  I'm thinking "added functionality for semicolon alternatives"
rather than the "replace the semicolon" stunt that Semi::Semicolons
pulls.  In particular, as long as there's no ambiguity between
prefix: and postfix:, I think that it would be quite useful for
postfix: to act as a semicolon that additionally sets $_ equal to
the expression's value, allowing for a pseudo-Prolog style of syntax
(i.e., the code could include questions as well as declarations and
instructions).

--
Jonathan "Dataweaver" Lang

[perl #42947] [PATCH] revise Parrot_get_runtime_prefix API for safety and usablility

[via RT]

# New Ticket Created by  Mike Mattie 
# Please include the string:  [perl #42947]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=42947 >


Hello,

This patch changes the Parrot_get_runtime_prefix API from

char* Parrot_get_runtime_prefix(Interp *interp, STRING **prefix_str)

to

STRING* Parrot_get_runtime_prefix (Interp *interp ) {

This is done to make the routine safer, it no longer can leak memory. Also the 
useless "." paths
are removed from src/library.c. some minor changes to 
Parrot_locate_runtime_file_str are present
to sync and correct that function.

other callers in src/inter_misc.c , and compilers/imcc/main.c are fixed as well.

also a case of a bare free() being used instead of the proper mem_sys_free is 
fixed.

This relies on #42944 to apply.

Cheers,
Mike Mattie - [EMAIL PROTECTED]

Re: Is Perl 6 too late?

[Jonathan Scott Duff]

On 5/14/07, Thomas Wittek <[EMAIL PROTECTED]> wrote:


Moritz Lenz schrieb:
>> What makes Perl hard to read is the excessive use of special characters
>> (/\W/).
>
> I disagree: The make it look ugly, but not hard to read.

Even if it's "only" ugly: To what advantage? I don't think ugliness is a
good characteristic of a programming language.



Some people consider mathematics ugly too, but expressivity for
mathematicians is valued more over general readability.  So too in perl.
(This is related to "learn once, use often")


Additionally I'm not a friend of sigils:

>
> Then you shouldn't program in perl. Really.

Reason? I still haven't seen a good justification for sigils.



Whether you like it or not, sigils are a part of Perl's personality that
aren't going away any time soon.  If you don't like them, then you shouldn't
use perl.  All those people claiming that Perl 6 isn't Perl would be on the
money if Perl 6 didn't have sigils.

To allow arrays and scalars and subs to have the same name (besides the

sigil) although they have different content? No good idea I think.
I also can't remember that I ever named a variable like a "reserved
word" or operator. And even if I could, I'd consider it to be bad style.




I think of it more like hungarian notation.  The sigils enable a default set
of expectations. "Oh, I see an @, so this thing must be an array".  Perl 6
has changed the meaning behind the notation ever so slightly, but the
utility is still there.

-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: variable type specific sigils (was Re: Sigils by example)

[Darren Duncan]

At 5:00 PM -0700 5/14/07, Darren Duncan wrote:
On the other hand, unless this steps on something, I could suggest 
dropping the @ and % anyway, so we have $array and $hash, and then 
we could instead use the @ and % sigils as a prefix to indicate in 
that case that we want them to copy by value.  For example:


  my $foo = [23, 434, 6];
  my $bar;
  $bar = $foo; # copy by reference
  @$bar = @$foo; # copy by value

Actually, I think that would be a vast improvement, as we could then 
use the @ prefix with any collection type as short-hand to say that 
= is copy by value.


As a follow-up or clarification of what I just said, here is a proposal ...

Variables of all types have $ sigils.

The semantics of $foo = $bar are unchanged; usually $foo and $bar 
point to the same container after the assignment, afaik.


Prefixing a @ or % before a variable name indicates a syntactic 
short-hand for something concerning the variable.


On declaration, saying @$foo means the same as "Array $foo", and 
saying %$foo means the same as "Hash $foo", or some such.  This works 
for my|our|has etc as well as parameter declarations.  This is 
instead of declaring @foo or %foo.


On use in an expression, @$foo = @$bar indicates we want a copy by 
value or clone or shallow copy or whatever, and $foo and $bar point 
to different containers after the assignment; the semantics are like 
the current @foo = @bar.


Similarly, use eg @@$foo rather than @@foo as appropriate.

With these changes, I see it making Perl more consistent in 
appropriate ways, and easier to use, and huffmanizing isn't worse.


Also, it means we can free up the @ and % rare ASCII symbols for 
other purposes in some situations.


I could also argue that the conception of @ meaning plural vs $ 
singular isn't really an absolute, since any value can be treated as 
either being a collection or being atomic under different 
circumstances.


-- Darren Duncan

Re: Is Perl 6 too late?

[Tibor Foeldes]

OK! Be concrete  !  :-) ( Hart wie Beton !)

As Ruby and Python are getting more and more attraction [1][2] I think
they do something right, that Perl doesn't.
What I think where both (especially Python) do better is in readable 
code.


What makes Perl hard to read is the excessive use of special characters
(/\W/).
  

(/\W/)
It is  in Ruby the same.  In Python  re.search('\W',foo).Is  it  
really nicer ?



In my opinion, reducing the use of those characters would make Perl a
lot easier to read and also easier to write.
Global variables with cryptic names, that no beginner can make any sense
of by reading it. And after not working with "$<" for some months I
can't remember it either, although I've got quite some Perl experience.

  

In Perl6:  $*UID   (see S02.pod)

Additionally I'm not a friend of sigils: Typing them is relatively
painful, for reading there is no advantage if you use an editor with
decent syntax highlighting and the code looks more cryptic. The answer
in Perl6 are twigils, great... One step backwards in my optinion.
Most programming languages
/C(++|#)?|Java(Script)?|Python|Ruby|Groovy/... don't need them. The only
obvious advantage of using sigils is variable interpolation in strings.
But that could easily be done only in strings without the need to put a
$ in front of each and every variable name in the rest of the code.

  
Perl is a language with sigils. We must see it more penetrating ! The 
advantages of sigils in Perl are overall, by item access in structures, 
by the flexibility of subroutine calls, interpolation , global 
variables,  
Perl wants separate variables from other language structures . Perl 
without sigils is not Perl more.  Perl6 in this regards is really to 
late for you :-)

I would also like semicolons to be optional. There are far more cases of
single line statements than multiline statements. So you would save
quite some characters, when the semicolon would be optional and you
could concatenate multiline statements with e.g. a backslash.

Some say that there are too much operators in Perl(6). I partially
agree. I don't like the implicit type casting forced by the operators
(== int / eq string). That's harder to learn and remember. Harder to
read also.

Operators are only another format ( nice ) of functions.

I really like the Python way of doing it: Set the variables type on the
  assignment and remember it. The (fewer) operators now work according to
the type of the operands. No implicit (and error prone) type casting.
That way seems to be the best compromise of easiness and type safety.
I could continue on that, but I've already written too much...
  

"use warnings" is helping you !

And you can always make explicit type conversion. That does mean 
explicit :-) . But you must type something more.
The only builtin implicit type casting in Perl is this numeric / string 
conversion and it is fairly obvious and absolutely not error-prone.



[1] http://radar.oreilly.com/archives/2007/05/state_of_the_co_6.html
[2] http://www.google.com/trends?q=perl%2C+python+-snake%2C+ruby

  
These reports are fairly special. These are not about popularity of a 
programming language , but
how many books O'Reilly sold, and how many were googled. What about is 
not clear. Maybe waiting for Perl6 ?

In place of contributing? Searching for redemption ?

People not only want code that _is_ sexy, but they also want it to
_look_ sexy.
  
Sex is oftentimes perversion ;-) Well, natural selection. Survives the 
fittest idea , not necessarily the sexiest look.


Tibor

[perl #42950] [PATCH] mswin32 (msvc) builds don't need -lodbc32

[via RT]

# New Ticket Created by  Mark Glines 
# Please include the string:  [perl #42950]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=42950 >


Someone in #parrot tried to build parrot today after stripping irrelevant
stuff from his MS Platform SDK installation, only to discover Parrot is
relying on the odbc32 library, which he hadn't installed.

It doesn't look like its actually *used* anywhere, its just included in
the list of libraries, apparently for no reason.

#parrot highlights:

[08:14] < kjs> ah shoot; odbc32.lib missing
[08:14] < kjs> do I need that??
[08:14] < kjs> at least,t hat's what test.ldo is saying
[08:15]  * Infinoid looks for that on his system
[08:16] <@particle> probably in platform sdk
[08:16] < kjs> i probably deselected that one

[08:16] < kjs> figured i didn't need it, and to speed up download...
[08:16] <@Infinoid> oh, in the platform sdk setup?
[08:17] < kjs> yes, i deselected some stuff

[08:18] <@particle> i don't know that we need it
[08:18] <@particle> it might just be cargo-cult

[08:20] <@codermattie> I just grepped the whole tree, that config stuff is the 
only place where odbc was found

I removed it from the linker line, did a configure, build, and smoke.
I detected no ill effects.  (other than an intermittant "three alarms"
thing in t/dynoplibs/myops.t that was there before the change.)  So,
how about removing it?

Mark
=== config/init/hints/mswin32.pm
==
--- config/init/hints/mswin32.pm	(revision 20357)
+++ config/init/hints/mswin32.pm	(local)
@@ -185,7 +185,7 @@
 ld  => 'g++',
 ldflags => '',
 libs =>
-'-lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 ',
+'-lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion ',
 link  => 'gcc',
 linkflags => '',
 o => '.o',

Re: explicit line termination with ";": why?

[John Macdonald]

On Tue, May 15, 2007 at 02:02:06AM +0200, Thomas Wittek wrote:
> John Macdonald schrieb:
> > It's also, in many cases,
> > harder to edit - that's why a trailing comma in a list that
> > is surrounded by parens, or a trailing semicolon in a block
> > surrounded by braces, is easier to manage.
> 
> Now that the list is surrounded by parens makes clear that it ends with
> the closing paren and not with a line break. So you could still use
> commas (without backslashes) to separate the items over multiple lines.
> See e.g. http://docs.python.org/ref/implicit-joining.html

I was actually talking about existing perl5 here.  I write:

my %h = (
x => 100,
y => 75,
z => 99,
);

explicitly writing the "unrequired" comma on the last element
(z=>99).  That way, if I add another element to the hash there's
no danger that I will forget to go back and add the comma to
the line above.  Alternately, if I reorder the hash elements
(maybe sorting on the value instead of the key) I don't have
to check whether there is now a commaless line in the middle
of the reordered bunch.

-- 

Re: Sigils by example

[Larry Wall]

Language design is hard.  Let's go shopping!  :-)

Larry

[perl #42919] [BUG] and [PATCH] overriding 'invoke' requires current object to be explicitly passed

[Allison Randal via RT]

And reverted in r18541. The patch is fragile. Broken on Windows, and
fixing it for Windows breaks it for OSX and Linux.

Allison

Re: Is Perl 6 too late?

[Garrett Cooper]

Thomas Wittek wrote:

Moritz Lenz schrieb:

What makes Perl hard to read is the excessive use of special characters
(/\W/).


I disagree: The make it look ugly, but not hard to read.


Even if it's "only" ugly: To what advantage? I don't think ugliness is a 
good characteristic of a programming language.



Global variables with cryptic names, that no beginner can make any sense
of by reading it. And after not working with "$<" for some months I
can't remember it either, although I've got quite some Perl experience.


Well, most of them are gone or renamed to more readable ones in p6.


I hope so. I could only find the counterparts for __PACKAGE__ etc. in 
S02. I didn't find the one for e.g. $<.


Additionally I'm not a friend of sigils: 


Then you shouldn't program in perl. Really.


Reason? I still haven't seen a good justification for sigils.
To allow arrays and scalars and subs to have the same name (besides the 
sigil) although they have different content? No good idea I think.
I also can't remember that I ever named a variable like a "reserved 
word" or operator. And even if I could, I'd consider it to be bad style.


No one mentioned that if it wasn't for sigils, many strings would be 
increased, length-wise, to do operator concatentation. If it wasn't for 
that then simple string insertions couldn't be used.


Plus sigils are a defacto form of representing variables in other 
languages, like Unix scripting and PHP. I'd rather read a data item 
[scalar, { associative, 1-D } array, list, class object ] and have a 
good idea of what the target data type is. References is the only data 
type ones that introduces some sort of mystery to this mix, IMO.


I would also like semicolons to be optional. 


Most people don't ;-).


Oh, really? Source? :)
I think they were invented to allow easier parsing and not easier coding.
E.g. in JavaScript, Python, Ruby and Groovy they are optional or even 
don't exist. As I said, there are much more cases where you wouldn't 
need them but have to write them than vice versa.
Optional semicolons save keystrokes, eye pain and stupid syntactic 
errors. And if you still like them, you could just use them, which is 
the definition of "optional".


Almost all mainstream languages do it though, and it serves as nice 
visual breaks in source. I honestly hate lack of semi-colons, with the 
exception of shell scripts, all of which I produce that are less than 
150 lines long.


Then again I don't do more than 2 sets of statements in a given line for 
shell scripts either, and I don't so the same with Perl.




The only thing I hate about Perl with required formatting is the silly 
braces. If it's one line and separated by visible whitespace, why is the 
only option available to me the


statement_1 if(statement_2);

or

statement_1 unless(statement_2);

syntax? Seems less readable than:

if(statement_2)
statement_1

or

unless(statement_2)
statement_1

The only legitimacy for the first set of formats would be if in fact you 
were reading off the logic statement in a left-to-right language. But 
then again many languages don't follow that convention (Japanese, 
Korean, etc etc for instance).


The same opinion goes for all loops, except the

do { statement } ( { while, until } );

variety.




I really like the Python way of doing it: Set the variables type on the
assignment and remember it. The (fewer) operators now work according to
the type of the operands. No implicit (and error prone) type casting.
That way seems to be the best compromise of easiness and type safety.


Well, if you like the python way, feel free to code in python.


Oh, if I didn't like Perl, why should I care about posting my ideas here?
Perl has stolen the largest part of the language from other languages.
Why not do so again by adopting good ideas.


Don't get me wrong, there's nothing bad in writing some critics, but
yours is impossible to realize in Perl 6


Admittedly I'm much too late and I didn't expect applause for my critics 
-- but at least I hoped to get a discussion based on arguments.


 > and therefore are it's hard to call it constructive.

Unfortunately I already thought this. Even if everyone agreed that 
sigils (or forced semicolons, or tons of operators, ...) are more bad 
than good (and this seems like persuading the pope to allow homosexual 
muslims to marry with priests) the design process is probably too far to 
introduce such dramatic changes.

Sadly.


Yes, probably about as likely as Neo-Nazi's getting married to Haccidic 
Jewish people with Satanic priests presiding.


-Garrett