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: 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
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
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 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
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 toos 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 toos 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
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 purl 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!
