Exegesis2 and the "is" keyword
So, I finally got around to reading the link Nat sent out:
http://www.perl.com/pub/2001/05/08/exegesis2.html
First off, nice job Damian (as always), it looks excellent. I like the
examples of stuff like this:
my int ($pre, $in, $post) is constant = (0..2);
Awesome. Simple, Perlish, easy to read, etc. Also, I see you took the
suggestion of:
Access through... Perl 5 Perl 6
= == ==
Array slice @foo[@ns] @foo[@ns]
Hash slice @foo{@ks} %foo{@ks}
Which is kewl since it makes a good amount of sense IMO.
The only worry/problem/etc that I wonder about is the potential overuse
of the "is" keyword. It is a very nice syntactic tool, but when I see
something like this:
$*ARGS is chomped;
I wonder if that wouldn't be better phrased as:
autochomp $*ARGS;# $ARGS.autochomp
Or, if :: meant CORE, even:
autochomp $::ARGS;
The thing I worry about is this: I don't think actions should be
declared using "is", necessarily. I know, one could argue that actions
are just a type of property, but I don't know if that's the most
sensible. In particular, it puts the action in the passive voice, and it
could also go too far:
$STDERR is flushed;
$var = $ARGS is read;
$STDOUT is printed to "Hello, World!\n";
It seems actions should be active functions, so:
autoflush $STDERR; # $STDERR.autoflush
$var = read $ARGS;
print $STDOUT "Hello, World!\n";
Plus, this part bothers me a little:
: http://www.perl.com/pub/2001/05/08/exegesis2.html
:
:$ARGS prompts("Search? "); # Perl 6
:while (<$ARGS>) {
:
: Technically, that should be:
:
:$ARGS is prompts("Search? ");
:
: but that grates unbearably. Fortunately, the "is" is optional in
: contexts -- such as this one -- where it can be inferred.
I'd think I'd rather see that as:
prompt $ARGS "Search? "; # $ARGS.prompt("Search? ")
Without the extra new ambiguity. Thoughts?
-Nate
Re: Exegesis2 and the "is" keyword
On Tue, May 15, 2001 at 03:02:44PM -0700, Nathan Wiger wrote: > The only worry/problem/etc that I wonder about is the potential overuse > of the "is" keyword. It is a very nice syntactic tool, but when I see > something like this: > >$*ARGS is chomped; > > I wonder if that wouldn't be better phrased as: > >autochomp $*ARGS;# $ARGS.autochomp Is that autochomp as a keyword or autochomp as an indirect method call on $*ARGS? > The thing I worry about is this: I don't think actions should be > declared using "is", necessarily. > >$STDERR is flushed; >$var = $ARGS is read; >$STDOUT is printed to "Hello, World!\n"; This could be argued 'round and 'round as to what's an action and what's a property. 'chomped' and 'flushed' make sense as properties as they are descriptive. You're setting a property which the variable will take into account in its actions. Whereas things like 'read' and 'printed' are immediate actions. I suppose the best distinction is right there in your example. flushed and chomped don't do anything immediately, whereas read and printed do. TMOWTDI I suppose. > Without the extra new ambiguity. Thoughts? Put down the indirect object syntax and step away from the keyboard with your hands up! ;) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!
Re: Exegesis2 and the "is" keyword
At 15.02 -0700 01-05-15, Nathan Wiger wrote: >The only worry/problem/etc that I wonder about is the potential overuse >of the "is" keyword. It is a very nice syntactic tool, but when I see >something like this: > >$*ARGS is chomped; > >I wonder if that wouldn't be better phrased as: > >autochomp $*ARGS;# $ARGS.autochomp I see your point, but I see a clear difference between these properties and actions taken on the variable. When we say $*ARGS is chomped, we don't ask $*ARGS to do anything right away, just remember that when we later ask it to return something, we want that something chomped. Cajo -- Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236 Adverb Information, http://www.adverb.se, 08-555 788 80
Re: Exegesis2 and the "is" keyword
Ok, this is basically a bunch of "me too!"s.
On Tue, 15 May 2001, Nathan Wiger wrote:
> Awesome. Simple, Perlish, easy to read, etc. Also, I see you took the
> suggestion of:
>
>Access through... Perl 5 Perl 6
>= == ==
>Array slice @foo[@ns] @foo[@ns]
>Hash slice @foo{@ks} %foo{@ks}
>
> Which is kewl since it makes a good amount of sense IMO.
Here's the first one.
>$*ARGS is chomped;
> I wonder if that wouldn't be better phrased as:
>autochomp $*ARGS;# $ARGS.autochomp
>
> [...] I don't think actions should be declared using "is",
> necessarily. [...] In particular, it puts the action in the passive
> voice[...]
> It seems actions should be active functions, so:
>
>autoflush $STDERR; # $STDERR.autoflush
>$var = read $ARGS;
>print $STDOUT "Hello, World!\n";
Here's the second one.
> :
> :$ARGS prompts("Search? "); # Perl 6
> :while (<$ARGS>) {
>
> I'd think I'd rather see that as:
>prompt $ARGS "Search? "; # $ARGS.prompt("Search? ")
> Without the extra new ambiguity. Thoughts?
Hmmm...the '$ARGS prompts("Foo?")' version actually works better
for me. I think that, in line with what you said above, 'prompt $ARGS
"Foo?"' should be interpreted as an action...that is, something that
should be done _right_now_. But I don't want the prompt to be printed
right now...I want it to be printed just before I do a read on the
filehandle. In this case, I really am setting a property, not setting a
property.
I'm not sure what the appropriate way to disambiguate the two is,
or if there even needs to be a specific mechanism (can perl be smart
enough to DWIM on this?). Definitely something to think about.
Dave
Re: Exegesis2 and the "is" keyword
* Michael G Schwern <[EMAIL PROTECTED]> [05/15/2001 17:49]:
>
> Is that autochomp as a keyword or autochomp as an indirect method call
> on $*ARGS?
Who cares? ;-)
> > The thing I worry about is this: I don't think actions should be
> > declared using "is", necessarily.
> >
> >$STDERR is flushed;
> >$var = $ARGS is read;
> >$STDOUT is printed to "Hello, World!\n";
>
> This could be argued 'round and 'round as to what's an action and
> what's a property. 'chomped' and 'flushed' make sense as properties
> as they are descriptive. You're setting a property which the variable
> will take into account in its actions. Whereas things like 'read' and
> 'printed' are immediate actions.
I guess my main problem is the "the 'is' keyword is optional where it
can be inferred" part. That's a whole indirect-object-like can of worms,
and I don't think we should be adding more of those. This could easily
be fixed by writing Damian's example:
$*ARGS prompts("Search? ");
As a past-tense verb:
$*ARGS is prompted("Search? ");
It ends up being the same effective tense. I just really don't think
that "is" should be sometimes-optional.
> Put down the indirect object syntax and step away from the keyboard
> with your hands up! ;)
TMTOWTDI, TMTOWTDI!
-Nate
Re: Exegesis2 and the "is" keyword
At 10:51 AM 5/16/01 +0200, Carl Johan Berglund wrote: >At 15.02 -0700 01-05-15, Nathan Wiger wrote: >> $*ARGS is chomped; >> >>I wonder if that wouldn't be better phrased as: >> >>autochomp $*ARGS;# $ARGS.autochomp > >I see your point, but I see a clear difference between these properties >and actions taken on the variable. When we say $*ARGS is chomped, we don't >ask $*ARGS to do anything right away, just remember that when we later ask >it to return something, we want that something chomped. I've been reading "is" as a declarative imperative, something which declares a property of something you are creating. Here it's being used to moify the properties of something that already exists, and it reads funny to me. Many properties that one can set at declaration time are compile time only, yet this usage might suggest to many people that they can be changed at run time. If you see what I mean. I'm sure I could get used to it, I'm just speaking to learnability. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Exegesis2 and the "is" keyword
Peter Scott <[EMAIL PROTECTED]> writes: | I've been reading "is" as a declarative imperative, something which | declares a property of something you are creating. Here it's being | used to modify the properties of something that already exists, and | it reads funny to me. Many properties that one can set at | declaration time are compile time only, yet this usage might suggest | to many people that they can be changed at run time. If you see | what I mean. Clearly we need 'becomes' and 'gets' for mutable properties, in addition to 'is' and 'has' for constant ones. -- http://www.dfan.org
Re: Exegesis2 and the "is" keyword
Let it be. Not a flame, but a suggestion: let $pi be constant; That any better? =Austin --- Dan Schmidt <[EMAIL PROTECTED]> wrote: > Peter Scott <[EMAIL PROTECTED]> writes: > > | I've been reading "is" as a declarative imperative, something which > | declares a property of something you are creating. Here it's being > | used to modify the properties of something that already exists, and > | it reads funny to me. Many properties that one can set at > | declaration time are compile time only, yet this usage might > suggest > | to many people that they can be changed at run time. If you see > | what I mean. > > Clearly we need 'becomes' and 'gets' for mutable properties, in > addition to 'is' and 'has' for constant ones. > > -- > http://www.dfan.org > __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Exegesis2 and the "is" keyword
Austin Hastings <[EMAIL PROTECTED]> writes:
> Let it be.
>
> Not a flame, but a suggestion:
>
> let $pi be constant;
Personally, I'd rather save let for:
(let ($x,$y,$z,...) = (1,2,3,...) in { ... })
which would be equivilant to:
((sub {my ($x,$y,$z,...) = @_; ... })(1,2,3,...))
Many functional languages use let to mean something similar.
On that note... will there be any provision for formal arguments to
anonymous subs?
If I understand the brief mentions of subroutine signatures, we will
be able to use syntax like:
sub foo (@array, $scalar, %hash) { ... } ;
Will we also be able to do:
$foo = sub (@array, $scalar, %hash) { ... } ;
to get a reference to an anonymous sub with the same signature?
If so, then
$foo = (let (...) = (...) in {...});
could be equivalent to:
$foo = ((sub (...) {...})(...));
>
> That any better?
>
> =Austin
>
> --- Dan Schmidt <[EMAIL PROTECTED]> wrote:
> > Peter Scott <[EMAIL PROTECTED]> writes:
> >
> > | I've been reading "is" as a declarative imperative, something which
> > | declares a property of something you are creating. Here it's being
> > | used to modify the properties of something that already exists, and
> > | it reads funny to me. Many properties that one can set at
> > | declaration time are compile time only, yet this usage might
> > suggest
> > | to many people that they can be changed at run time. If you see
> > | what I mean.
> >
> > Clearly we need 'becomes' and 'gets' for mutable properties, in
> > addition to 'is' and 'has' for constant ones.
> >
> > --
> > http://www.dfan.org
> >
>
>
> __
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
Re: Exegesis2 and the "is" keyword
Please forgive the naiveté of this question. 1 - If Perl6 is going to have multiple back-ends, rather like the cross-compilation feature of gcc, "Perl6" won't be a specific virtual machine or back-end. (As Perl5 is now, and, say, Java has as a fundamental part of its design.) 2 - If Perl6 is going to have multiple front-ends, rather like ... nothing I can think of at the moment, then "Perl6" won't be a syntax, something you can show to people. (Abit it may have a "preferred embodiment" in the similar-to-Perl5-syntax that I see people posting here.) Therefore, if it isn't a back-end and it isn't a front-end, what is it?! Perl6 seems to be a "nothing sandwich". Not that this is bad, Zen is this way. Can someone say what it is? Daniel Wilkerson
Re: Exegesis2 and the "is" keyword
On Fri, May 18, 2001 at 06:29:11PM -0700, Daniel S. Wilkerson wrote: > Therefore, if it isn't a back-end and it isn't a front-end, what is it?! Both! > Can someone say what it is? OK. Most languages out there are separate from their implementation. For C, you have an ANSI specification that tells you exactly what C is and how it works, and then people come along and implement compilers for it. Perl 5, on the other had, didn't really have a language specification, but it was tied into the implementation: "Perl is as perl does". What we're trying to do now for Perl 6, as I understand it, is to make a cleaner separation between the language and the interpreter. Perl 6 the language is what gets discussed here; perl6 the interpreter gets discussed over on perl6-internals. It's true that perl6 the interpreter will be able to read various different types of input, rather like GCC. (since GCC can also parse and compile C++, Objective C and, with a little nudging, Fortran) It's also true that as well as executing bytecode, it'll be able to write various different types of output, whether bytecode, JVM bytecode, native executables, or whatever. Again, a bit like GCC, because GCC can be used as a cross-compiler. But in a sense, what it will be *able* to do isn't really relevant; what's important is what we ship and call perl 6, and I envisage that to be the following parts: a parser for Perl 6 the language; an interpreter and runtime library for Perl 6; plus all the sundry utility things - the regular expression engine, the variable handling, the IO subsystem, and so on. I hope that answers the question. :) -- Grr... don't get me started on Wagner. The man couldn't resolve a dominant seventh to a tonic with two musical dictionaries open to the word "resolution", and a copy of anything by Muddy Waters. - Eric the Read, in the monastery.
Re: Exegesis2 and the "is" keyword
At 03:31 AM 5/19/2001 +0100, Simon Cozens wrote: >On Fri, May 18, 2001 at 06:29:11PM -0700, Daniel S. Wilkerson wrote: > > Therefore, if it isn't a back-end and it isn't a front-end, what is it?! > >Both! It's a dessert topping *and* a floor wax! > > Can someone say what it is? > >It's true that perl6 the interpreter will be able to read various different >types of input, rather like GCC. (since GCC can also parse and compile C++, >Objective C and, with a little nudging, Fortran) This is pretty much true of all the compiler suites these days. If a vendor has compilers for multiple languages, odds are they all share a common back end. GCC does as Simon's mentioned, but Digital's (sorry, Compaq's) compiler suites (for the VAX and Alpha) are the same, as is Microsoft's Visual suite of languages. I think Sun's compilers are the same, as are Intel's. This is less surprising than you might think. Once you get past the trivial syntactic differences, almost all the languages you'll see a compiler for these days are close to identical, barring the odd bell or whistle. C, C++, Ada, Fortran, COBOL, PL/I, Modula-x, Pascal, Basic--they're all essentially identical, at least as far as the compiler writer's concerned. (Things get a little odd with RPN languages like PostScript or Forth, or Lisp-ish things, but those are really niche languages) When you get right down to it, regardless of the source language, the hardware is going to stay the same. That's what the back-end of a compiler is concerned with--emitting the most efficient sequence of back-end instructions it can manage. Having a common back end makes it a lot easier to concentrate your efforts into optimizing that one back end. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Exegesis2 and the "is" keyword
Buddha Buck wrote:
> Personally, I'd rather save let for:
I appreciate the sentiment, but I believe it's misplaced
and unnecessary.
> (let ($x,$y,$z,...) = (1,2,3,...) in { FOO })
>
> which would be equivilant to:
>
> ((sub {my ($x,$y,$z,...) = @_; FOO })(1,2,3,...))
But it's also equivalent to
{
my ($x,$y,$z,...) = (1,2,3,...);
FOO
}
which is far clearer than either of the above syntaces.
--
John Porter
Re: Exegesis2 and the "is" keyword
John Porter writes:
: Buddha Buck wrote:
: > Personally, I'd rather save let for:
:
: I appreciate the sentiment, but I believe it's misplaced
: and unnecessary.
:
:
: > (let ($x,$y,$z,...) = (1,2,3,...) in { FOO })
: >
: > which would be equivilant to:
: >
: > ((sub {my ($x,$y,$z,...) = @_; FOO })(1,2,3,...))
:
: But it's also equivalent to
:
: {
: my ($x,$y,$z,...) = (1,2,3,...);
: FOO
: }
:
: which is far clearer than either of the above syntaces.
I agree, with the possible exception that we still might need to use
a different assignment operator to treat the left side as a prototype.
But think I'd rather attach that info to the operator itself:
my ($x,$y,$z,...) := (1,2,3,...);
rather than using another keyword such as "let".
In Apo2, I said that any list assignment in parens might use
prototyping rules, but I'm leaning the other way again. I'm thinking
we really ought to leave Perl 5's = operator alone, or people will
continually wonder why
($a, $b, $c) = @foo;
no longer does what they expect. The = operator can stay value
assignment, while := (or whatever name we decide on) can be called an
object assignment, or an alias assignment, or a definitional
assignment, or a reference assignment, or some such:
(@foo, @bar) := (@bar, @foo); # swap two arrays
Note that this is another clear case where the variable properties
stay with the variable, but the value properties go with the swapped
values.
I'd also point out that if @foo or @bar were tied, this is probably
an illegal operation, since most tied arrays aren't going to let you
set a reference. At best, they might emulate it by copying the values.
To put it another way, the reference assignment:
(@foo, @bar) := (@bar, @foo); # swap two arrays
is equivalent to the ordinary list assignment:
(@foo.ptr, @bar.ptr) = (@bar.ptr, @foo.ptr);
assuming for the sake of argument that there's a scalar lvalue .ptr
method that can manipulate the variable's internal reference directly.
But a tied array might not be able to implement a .ptr method if the
internal representation is not pointer based. You wouldn't generally
want to store a pointer in a DBM file, for instance.
Larry
apology (was Re: Exegesis2 and the "is" keyword)
I recently received the following email from someone whose name I have snipped. > * Dave Storrs <[EMAIL PROTECTED]> [05/16/2001 08:11]: > > > > Ok, this is basically a bunch of "me too!"s. > > Keep the snide comments to yourself. Thanks. This was regarding a reply I had made to one of Nathan Wiger's posts in the "Re: Exegesis2 and the "is" keyword" thread. This is a case of miscommunication; the "bunch of me too"s was referring to what _I_ was writing...that is, I was saying that the majority of my email consisted of agreeing with what Nathan had written, which I thought was very well constructed and well thought out. Obviously, I was not clear enough, for which I apologize. Dave
Re: apology (was Re: Exegesis2 and the "is" keyword)
* Dave Storrs <[EMAIL PROTECTED]> [05/16/2001 11:25]: > > I recently received the following email from someone whose name I > have snipped. > > > * Dave Storrs <[EMAIL PROTECTED]> [05/16/2001 08:11]: > > > > > > Ok, this is basically a bunch of "me too!"s. > > > > Keep the snide comments to yourself. Thanks. > > This was regarding a reply I had made to one of Nathan Wiger's > posts in the "Re: Exegesis2 and the "is" keyword" thread. > > This is a case of miscommunication; the "bunch of me too"s was > referring to what _I_ was writing...that is, I was saying that the > majority of my email consisted of agreeing with what Nathan had written, > which I thought was very well constructed and well thought > out. Obviously, I was not clear enough, for which I apologize. Dave- No reason to publicly apologize, this was as much a result of my misreading your statements as anything else. I thought we had resolved this quite satisfactorily offline, but I sincerely appreciate the public apology. I must admit I've gotten a little on-edge reading this list lately. It seems many would like to turn many issues into flamewars. I hope that people begin to abide by Nat's requests to tone things down a little. I think a lot of people are unsure and afraid of where Perl's going, which is understandable in a way because we're in the middle of doing some big redesign, but it's not a reason to overreact and assume everyone else on the list is out to destroy Perl. I do agree, however, that we need to make sure people can still program in a subset of Perl effectively. -Nate
what is perl6 (was Re: Exegesis2 and the "is" keyword)
Daniel S. Wilkerson writes: > Therefore, if it isn't a back-end and it isn't a front-end, what is it?! > Perl6 seems to be a "nothing sandwich". Not that this is bad, Zen is this > way. Simon's done a good job of explaining this, but I'll try too. You're right, we're designing many things. Larry's working on the language that will be known as perl, with advice and comments from all in perl6-language. There'll be a compilation system. The compiler will be flexible, allowing you to have mini-languages for all or parts of your programs. The compiler will emit bytecode, but you'll be able to have the compiler interpret the bytecode right away to get the interpreted language "execute your source" feel that we have now. The compilation system might be extended to handle completely different languages, e.g. Ruby, Python, Java, C, etc. We'll design the compiler and runtime so that it's possible, but we won't implement those as our first priority. If there are people who want that, they'll do it. The compiler default will be to emit bytecode for the perl runtime system, but we'll design it in such a way that we can emit C source or Java bytecode or whatever form of bytecode virgin sacrifice that .NET requires. The perl runtime system will be an interpreter for our own bytecode, essentially a virtual machine tailored to our needs. If we play our cards right, you'll be able to write modules in Perl and call them from Python, or vice-versa, because language-specific differences will be erased by the time code comes to execute. Both the compilation and runtime systems are being sketched out on perl6-internals by Dan and others. Right now we're talking about everything and calling it "perl6", but I imagine we'll need to come up with code names for a lot of this stuff. The language will stay as "Perl", but the VM might get its own name. Maybe the compiler system will, too. You might talk about perl being compiled by PRATS (Perl Reinforced Active Translation System) and running on CRAP (Complete Runtime Around Perl). Well, maybe we'll have a contest for codenames :-) Nat
Re: what is perl6 (was Re: Exegesis2 and the "is" keyword)
At 08:57 AM 5/19/2001 -0600, Nathan Torkington wrote: >The language will stay as "Perl", but the VM might get its own name. Parrot! ;-P And I see I need to draw some pictures, since Nat's explanation's not quite what I'm thinking of at the moment. (Close though) I'll see about getting something more detailed up RSN. (Pity POD has no way to embed images...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
