Re: RFC 109 (v1) Less line noise - let's get rid of @%
Ariel Scolnicov wrote: > > > So how do I make C into an array in the first place? Well, I say > something like C. But wait -- that's ambiguous! Is > C now a copy of the list (1,2,3) (in which case it's an array), > or is it a reference to (1,2,3) (in which case it's a scalar)? In the > first case, C (where C is an array, assuming I could > ever assign an array to a variable) would perform a copy, while in the > second it would make the two variables refer to the same thing. Actually, if you wanted an array, you'd say C. Very unambiguous. > > -- > Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] > Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz > 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- > Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: RFC 109 (v1) Less line noise - let's get rid of @%
David Corbin wrote: > > Ariel Scolnicov wrote: > > > > > > So how do I make C into an array in the first place? Well, I say > > something like C. But wait -- that's ambiguous! Is > > C now a copy of the list (1,2,3) (in which case it's an array), > > or is it a reference to (1,2,3) (in which case it's a scalar)? In the > > first case, C (where C is an array, assuming I could > > ever assign an array to a variable) would perform a copy, while in the > > second it would make the two variables refer to the same thing. > > Actually, if you wanted an array, you'd say C. Very > unambiguous. ARG! I mean to say if you wanted an array REFERENCE, not an array. Sorry for the confusion. > > > > > -- > > Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] > > Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz > > 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- > > Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels > > -- > David Corbin > Mach Turtle Technologies, Inc. > http://www.machturtle.com > [EMAIL PROTECTED] -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: RFC 133 (v1) Alternate Syntax for variable names
"David L. Nicol" wrote:
>
> >
> > Consider the following syntax:
> >
> > my var; # declaring a scalar
> > my array[]; # declaring an array
> > my hash{};# declaring a hash
>
> For the remainder of the enclosing block, the barewords var,
> array and hash are to be interpreted as references to a scalar, an
> array, and a hash.
I'm confused by this statement. Are you suggesting an alternative to
the original RFC? My point was supposed to be
that array[] makes more consistent sense that @array when refering to an
variable named 'array' of type 'array'. etc.
Using the @on the front to indicate the variable type in one place, and
as a context indicator in others creates confusion for lot of people.
>
> As long as assignment starts doing automatic dereferencing this
> will not be too tricky, it will require adding some work to C
> and adding more barewords to the local bareword board.
>
> --
> David Nicol 816.235.1187 [EMAIL PROTECTED]
>Laziness with responsibility http://www.tipjar.com/kcpm
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
Re: Ideas that need RFCs?
Larry Wall wrote: > > Dan Sugalski writes: > : At 10:35 AM 8/19/00 +1000, Damian Conway wrote: > : >However, for Perl 6 I'd really like to see run-time access to the > : >Real Tokenizer (tm): > : > > : > use tokenizer; > : > > : > my $tree = tokenizer( $sourcecode ); > : > > : >This would be dead handy for building source-code filtering modules, > : >rather than relying on the pseudo-parsing tricks we're currently > : >forced to use. > : > : Well, sure. You couldn't write an optimizer, bytecode compiler, or bytecode > : execution engine in perl if you couldn't do that... :) > > I was wondering this morning whether we ought to write the Perl 6 > parser as a set of recursive regexes. Might make it easier to plug in > new productions on the fly. And designing the parser around regexes > might indicate ways in which Perl's regexes are not yet powerful > enough. > > Larry That would be coolness. -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: Things to remove
Tom Christiansen wrote:
>
> >2) The ability to dump out a variable and all its attached state into
> >something that can be loaded in later somewhere else.
>
> To hope to do this completely and correctly is courageous.
>
> my @funx = ();
> for my $name (qw/violet purple cream/) {
> push @funx, sub {
> print "I'll take a $name one, please, with @_.\n";
> };
> }
>
> --tom
Or consider this pseudo code -
open file
lock file
dump file
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
Re: transaction-enabled variables
dLux wrote: > > Hello! > > I've posted an RFC about transaction-enabled variables (RFC130: > http://dev.perl.org/rfc/130.pod), but I didn't get too much response > about that. Does anyone have comment about that? I want to clarify > the language part of that (new keyword, new pragma), and if it is > clear, I want to take part in the detailed design of the > implementation. > > dLux > -- > "Don't THINK you are - KNOW you are" >(Morpheus, The Matrix) I think it would be a good thing, and would be another things can distinguish Perl from the other languages like pattern matching once did. It strikes me as one of those things that are going to end up adding a whole lot of power that wasn't expected, once people figure them out. -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: RFC 133 (v1) Alternate Syntax for variable names
Michael Maraist wrote:
>
> > my var; # declaring a scalar
> > my array[]; # declaring an array
> > my hash{}; # declaring a hash
>
> Though the declarations seem fine, I assume that you propose this to be
> optional at usage time, since variable interpolations such as
> "xxx${var1}xxx${var2}xxx" really need the prefix. One of the great
> strengths of perl is in fast and simple string manipulations. Currently,
> it's unabiguous as to how here-document simpler strings get interpolated.
> Compare that to Java's:
> "str" + var + "str"
> or python's:
> "xxx%sxxx" % var
>
> -Michael
At interpolation time, I think you're explictly specifying the context
the variable is in, so the answer is "yes",
though you may also be trigger in the 'quote operator' to recognize
variable interpolation should be performed.
I think all of the following might work.
$x = "xx${var}yy";
$x = "xx$var\yy";
$x = "xx".var."yy";
and for the more complex variables,
$x = "xx".@array."yy";
$x = "xx".array[]."yy";
$x = "xx".@array[]."yy"; # not so sure about this one.
# I'm not sure at all about these - I tend to avoid interpolation of
arrays and hashes for "safety"
$x = "xx@{array}yy"
$x = "xx{array[]}yy"
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
Let's have a Standard for Module Configuration
I'm not sure which is the best mailing list to send this to, so forgive me if I'm off. I'll be glad to RFC this if there is interest. There are several modules I've run across that require you to edit them after you've installed them. I consider this to be a very bad thing. What I'm thinking is needed, is a standard way to have a file in the module package that contains the editable parameters. The name of this file should be consistent relative to the module. The module install system should NEVER overwrite it, but should identify when some configurable item is needed by a new revision that isn't in the old one and warn the user. I assume that this is really just another very small .pm file. Thoughts? -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
What makes Perl Perl?
where it was "Remove sockets from core"... Tom Christiansen wrote: > > >I would like to see a set of "requirements" that make Perl what it is. > >I think we all have a vague idea of what makes Perl great, but I'm also > >sure there's a lot of variation. With a SHORT list of requirements, it > >becomes much easier to address some of these issues that are radical > >changes to the language. > > That's a very good idea. Thank you. > > Many if not most of these radical "let's make a new language" > postings mostly just keep making Python and Java look better and > better. If you strip out the Perlishness from Perl, there's really > no reason to bother with the language anymore. > > --tom You're much closer to the language and the history than I could ever hope to be, so what do YOU think makes Perl Perl? In addition to the four I posted, originally, I've added two. Here's my working list. native pattern matching; list manipulation aweswome text processing. It's application glue (thanks Tim) Ability to write powerful 1-line programs. Make easy things easy and hard things possible. (paraphrased, I suspect) -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: RFC 133 (v1) Alternate Syntax for variable names
Bron Gondwana wrote:
>
> In [EMAIL PROTECTED], you wrote:
> > count = array; # scalar context because of assignment to
> > scalar.
> > alt_array[] = array; # list context
>
> and if array is a subroutine?
>
>count = array();
>count = &array; # warning - special meaning in p5.
>
> Either would be just as messy - and I like being able to say:
Either would be just as messy as what?
>
> my $thingy = $object->subobject->value;
>
I must not understand. Your example here strikes me as
unrelated/unaffected.
> > I'm not the linguist that Mr. Wall is, but it strikes me that context should be
> > derrived automatically as much as possible.
> >
> > An slightly different alternative would be that arrays and hashes are always
> > referred to with their trailing indicator ([] or {}). So, from the example
> > above, you'd have
> >
> > count=array[];
> > alt_array[] = array[];
>
> Yuck. Ugly as thingywhatsit, though it does have the advantage of making
> syntax like array[2..5] for splice...
Ugly? What makes it ugly (to you)? Just having to type an additional
character?
Do you have a better suggestion for separating variable type from
context?
>
> Um, don't know about hash{[a-c].*} though (apply regular expression and only
> keep keys that match)
>
> --
> Bron ( but I don't think the ugliness is worth it in the end.. )
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
Re: RFC 162 (v1) Filtering Here Docs
Bart Lateur wrote: > > On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: > > >It only removes whitespace, > >and it measures whitespace with tabs=8. > > My editor is set to tabs=4. Perl's interpretation wouldn't agree with > the visual appearance in my editor. This doesn't sound like a neat > solution. > > Why not disallow merging of tabs and spaces as being equivalent? If you > want to skip a leading tab, but a tab between '<<"' and the EOL marker. > If you want to skip spaces, put spaces in. If you want to skip tabs and > spaces, put that sequence in. > > The only consequence would be that you'd have to be consistent in what > you put in front of the text lines (and in the whitespace prefix > definition). > > -- > Bart. Why not make the details of this controlled by a pragma? -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: Let's have a Standard for Module Configuration
While I think it is reasonable that all such configuration parameters be changeable by an API, there is clearly a place for system defaults. I've run across two such modules that I know. One wanted you to set the time-zone the system was running in, and the other was to set a default SMTP server. Both are reasonable to me for system installations. As for "Foo::Configuration", I could live with that, but that will tend to add another directory/namespace/module layer that can be a bit of a hassle. The only other logical approach I can see is to use FooConfigation; Carl Johan Berglund wrote: > > That could be very nice. I would really prefer changing parameters > through the API, by calling class functions or something, but I don't > see why everyone should agree with me. Keeping source-editable > parameters in a standard place would then be a win, especially > considering your thoughts about the module install system. > > What about Foo::Configuration? > > /Cajo. > > At 13.35 -0400 2000-08-25, David Corbin wrote: > >There are several modules I've run across that require you to edit them > >after you've installed them. I consider this to be a very bad thing. > >What I'm thinking is needed, is a standard way to have a file in the > >module package that contains the editable parameters. The name of this > >file should be consistent relative to the module. The module install > >system should NEVER overwrite it, but should identify when some > >configurable item is needed by a new revision that isn't in the old one > >and warn the user. > --- > Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236 > Adverb Information, http://www.adverb.se, 08-555 788 30 -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: Nice to have'it
raptor wrote:
>
> Hi,
>
> I have couple of ideas which may or may not worth it, so I didn't
> wrote the RFC but will list them here in short.
> Here are the nice to have'it.
>
> 1. There will be good to have some sort of "match and/or assign" operator
> for structures i.e. HASHES. Can't still figure out the syntax but may be
> it must borrow some ideas from "switch/case" and Pascal
> "with" it should be also easy to say :
>
> if ( %a match %b )
> or
> %a assign_diff %b - assign and/or add all key and/or values from %b which
> are
> not in %a OR diff ... :")
mildly nice...
>
> 2. "in" operator i.e.
>
> $a in (5,6,10,33,45)
> $a in @b
>
might be handy, but frequently when I need this type of functionality, I
just use a hash to start with.
>
> 8. The following syntax to be possible :
>
> $hash{/re/} i.e. this is the same like
>
> my @res;
> foreach my $k (keys %hash)
> {
> if ($k =~ /re/) {push $hash{$k},@res}
> };
>
> OR
> keys %hash{/re/}
> values %hash{/re/}
> each %hash{/re/}
>
> This is very usefull for fast searching in DBM for example.
Way cool. I'd love this. But I think you've got your push arguments
backwards.
> PS.
> Perl6 should stay Perl, but must be more than Perl.
> Perl6 should be fast as mentioned in one RFC - but most importantly it must
> be featurefull and must continue its tradition - "writing less, doing much"
> =
> iVAN
> [EMAIL PROTECTED]
> =
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
Re: the C JIT
"David L. Nicol" wrote: > > Dan Sugalski wrote: > > > I do want to have a set of C/XS/whatever sources as part of the test suite > > as well--right now perl's test suite only tests the language, and I think > > we should also test the HLL interface we present, as it's just as > > important in some ways. > > I want to see Perl become a full-blown C/C++ JIT. Since Perl is for > a large part a compatible subset of C I don't see this as unrealistic. > > Delaying any post-token parsing of barewords until after looking at > what local declarations are in effect is part of it, dealing with the > one or two differences in operator precedence that exist is another > > (Old precedence semantics unless new-ism like a declared typed bareword > exists in the current or a surrounding block would be the easiest way to do > it I think) > > Typed barewords as an available good syntax would please those who find > perl overpunctuated. > > XS would become a more proper part of the language, the line would blur > as we could mix Perl and C freely with very little performance loss due > to late binding except in things that are not known at "compile time" > things which by definition cannot be clarified without run-time inputs. > > -- > David Nicol 816.235.1187 [EMAIL PROTECTED] A C JIT is an interesting idea. I think that a project works best when it has a set of goals (I haven't seen one yet really for Perl 6). Unless this is one of the goals, I can easily see how this could become a serious distraction to what I perceive as the likely goals of Perl6. -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
