Re: reduce metaoperator on an empty list
On Friday 20 May 2005 08:11, "TSa (Thomas Sandlaß)" wrote:
> John Macdonald wrote:
> > ... (and there may be additional
> > operator attributes that make sense there too, although none
> > come immediately to mind).
>
> Well, I wonder why people neglect the fact that the
> neutral/identity element is not a property of the operator
> alone?! Besides the associativity and commutativity of the
> operator the inverse element---or the left and right
> one---with respect to the underlying representation come at
> least to my mind :)
Yes, a number of operators have an inverse on Boolean 0 and 1
only.
> This would give an "axiomatic" type system:
>
> class Num does Group[Num,+,0] {...}
> class Num does Field[Num,+,0,*,1] {...}
> class Str does Monoid[Str,~,''] {...}
>
> class Complex does Field[Array[2] of Num,+,[0,0],*,[1,0]]
> {...}
>
> class 3DVector does VectorSpace[Array[3] of Num,+,[0,0,0]]
> {...}
>
> And it provides valuable information to the optimizer.
--
Edward Cherlin
Generalist & activist--Linux, languages, literacy and more
"A knot! Oh, do let me help to undo it!"
--Alice in Wonderland
http://cherlin.blogspot.com
Re: reduce metaoperator on an empty list
On Friday 20 May 2005 07:18, John Macdonald wrote: > Is there a built-in operator that doesn't have a meaningful > identity value? Certainly. > I first thought of exponentiation, but it has > an identity value of 1 - you just have to realize that since > it is a right associative operator, the identity has to be > applied from the right. > > I suspect that if people ever get into writing code that works > on operators instead of data, there would be additional uses > found for the identity attribute (and there may be additional > operator attributes that make sense there too, although none > come immediately to mind). APL and J programmers have lots of examples. -- Edward Cherlin Generalist & activist--Linux, languages, literacy and more "A knot! Oh, do let me help to undo it!" --Alice in Wonderland http://cherlin.blogspot.com
Re: reduce metaoperator on an empty list
On Thursday 19 May 2005 20:42, Andrew Rodland wrote: > On Thursday 19 May 2005 10:51 pm, Sam Vilain wrote: > > Edward Cherlin wrote: > > > Here is the last answer from Ken Iverson, who invented > > > reduce in the 1950s, and died recently. > > > file:///usr/share/j504/system/extras/help/dictionary/intro > > >28.htm > > > >[snip] > > > > Thanks for bringing in a little history to the discussion. > > Those links are all local to your system; do you have > > internet reachable versions of them? > > These seem to be the original sources: > > http://www.jsoftware.com/books/help/dictionary/intro28.htm > http://www.jsoftware.com/books/help/dictionary/d420.htm > > and so on. Front page is at > http://www.jsoftware.com/books/help/dictionary/title.htm . I > still haven't figured out what "J" is though. It's an enhanced APL without the funny characters. -- Edward Cherlin Generalist & activist--Linux, languages, literacy and more "A knot! Oh, do let me help to undo it!" --Alice in Wonderland http://cherlin.blogspot.com
RE: Declaration of my() variables using symbolic referentiation
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Ingo Blechschmidt
> Sent: Saturday, May 21, 2005 7:22 AM
> To: perl6-language@perl.org
> Subject: Declaration of my() variables using symbolic referentiation
>
> Hi,
>
> am I correct in the assumption that the following is an error?
> # Not in a BEGIN block
> my $::(calc_varname()) = 42;
>
> I think so, as my() is a compile-time operation, but in this
> example, the variable name is not known until runtime, so I
> think this should be forbidden. Correct?
>
> But:
> BEGIN {
> my $::(calc_varname()) = 42;
> }
> I think this one is ok, as the compiler can invoke
> &calc_varname at compile-time, and therefore know the variable
> name at compile-time. Correct?
>
> FWIW, I wouldn't mind BEGIN { my $::(...) } being disallowed, too
> (consistency).
>
Even if it's legal it's fairly useless because $::(calc_varname()) goes
out of scope at the end of the BEGIN block. You could probably write a
macro to accomplish what you want:
macro declare_var(String $varName) {"\$$varName"}
Then you wouldn't even need the BEGIN block.
my declare_var(calc_varname()) = 42;
The compiler wouldn't know the variable name until runtime, but I think this
just means that this just transforms compile-time errors to runtime errors.
Joe Gottman
Declaration of my() variables using symbolic referentiation
Hi,
am I correct in the assumption that the following is an error?
# Not in a BEGIN block
my $::(calc_varname()) = 42;
I think so, as my() is a compile-time operation, but in this
example, the variable name is not known until runtime, so I
think this should be forbidden. Correct?
But:
BEGIN {
my $::(calc_varname()) = 42;
}
I think this one is ok, as the compiler can invoke
&calc_varname at compile-time, and therefore know the variable
name at compile-time. Correct?
FWIW, I wouldn't mind BEGIN { my $::(...) } being disallowed, too
(consistency).
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
