HaloO,
Larry Wall wrote:
As it stands the .() forms are a great way to stack ops after
a term. Together with knowing about the ops on the symbolic unary
level you can easily read expressions from the terms outwards.
I'm not actually parsing expressions. Or as you point out below
with respect
At 09:46 -0400 3/27/08, Mark J. Reed wrote:
Is it just me, or is all this talk about precedence and functions vs operators
vs methods creating a niggling sensation in anyone else's head? It feels like
we're in the vicinity of another one of them Big Simplifying Idea things.
Unfortunately, I
Thom Boyer wrote:
Now, I think that
$x.foo
is a method call, even if there's a postfix:foo declaration in scope.
And that's a problem, because, no matter what precedence postfix:foo
was given,
1,2,3.foo
is still going to mean
1, 2, (3.foo)
instead of the desired
Thom Boyer wrote:
And does dot always do that? If it does, then something odd happens.
Consider infix:* and postfix:!, where infix:* binds tighter than
postfix:+, and both bind more loosely than dot. Then
I meant ... tighter than postfix:!, ...
1 * 2! # means (1 * 2)!
1 * 2.!
HaloO,
Larry Wall wrote:
I deem that to be an unlikely failure mode, however. So maybe .++
is just gone now, and you have to write \++ instead. Any objections?
Please keep .++ as outlined below. Does the degenerate unspace not
collide with prefix:\? That is does foo\bar() not mean to
HaloO,
TSa wrote:
Another good use of the dot forms is to get a single character
form to tighten precedence: $x**3! != $x**3.! == $x**(3!).
BTW, is the dot form only available for postfix or for infix
as well? I.e. 3 * 2 == 3.*(2)?
Regards, TSa.
--
The Angel of Geometry and the Devil of
HaloO,
Jon Lang wrote:
TSa wrote:
Note that I see ** more as a parametric postscript then a real binary.
That is $x**$y sort of means $x(**$y).
That's where we differ, then. I'm having trouble seeing the benefit
of that perspective, and I can clearly see a drawback to it - namely,
you
Jon Lang wrote:
Thom Boyer wrote:
That seems better to me than saying that there's no tab character in
say blah $x\t blah
Whoever said that?
Oops. I thought Larry did. But he didn't; I misread it. Whew.
Somehow I managed to read Larry's words and get exactly the *opposite*
meaning
Is it just me, or is all this talk about precedence and functions vs
operators vs methods creating a niggling sensation in anyone else's
head? It feels like we're in the vicinity of another one of them Big
Simplifying Idea things. Unfortunately, I don't have the actual Big
Idea, so it could just
On Wed, Mar 26, 2008 at 07:32:23PM -0600, Thom Boyer wrote:
Question: given
($x)++ # no whitespace, so postfix?
is ++ postfix, or infix?
That is postfix. Any infix that could be confused with a postfix
requires intervening whitespace.
Now, I think that
$x.foo
is a method
On Thu, Mar 27, 2008 at 01:01:27PM +0100, TSa wrote:
HaloO,
Larry Wall wrote:
I deem that to be an unlikely failure mode, however. So maybe .++
is just gone now, and you have to write \++ instead. Any objections?
Please keep .++ as outlined below. Does the degenerate unspace not
collide
On Thu, Mar 27, 2008 at 01:08:43PM +0100, TSa wrote:
HaloO,
TSa wrote:
Another good use of the dot forms is to get a single character
form to tighten precedence: $x**3! != $x**3.! == $x**(3!).
BTW, is the dot form only available for postfix or for infix
as well? I.e. 3 * 2 == 3.*(2)?
Only
On Thu, Mar 27, 2008 at 09:46:29AM -0400, Mark J. Reed wrote:
: Is it just me, or is all this talk about precedence and functions vs
: operators vs methods creating a niggling sensation in anyone else's
: head? It feels like we're in the vicinity of another one of them Big
: Simplifying Idea
Larry Wall wrote:
The .++ form is still not a method (single) dispatch, just an alternate
form of the postfix, which is a multi dispatch.
But the postfix is a unary operator, right? So that'd be multi dispatch
on one argument.
How does single dispatch differ from multi dispatch on a
On Thu, Mar 27, 2008 at 09:02:37AM -0600, Thom Boyer wrote:
Larry Wall wrote:
The .++ form is still not a method (single) dispatch, just an alternate
form of the postfix, which is a multi dispatch.
But the postfix is a unary operator, right? So that'd be multi dispatch on
one argument.
At 21:40 +0100 3/25/08, TSa wrote:
Doug McNutt wrote:
Don't allow it ( = - f($x); )to become
= f(-$x); ## wrong!
Unless of course f does Linear, then you can factor out or in the
multiplication with -1 at will. So linearity of operators and
functions is a very interesting property for
HaloO,
Doug McNutt wrote:
Well. . . I was going to let it pass but I had trouble sleeping this
morning because of it.
Sorry.
f($x) = constant + $x
would certainly be considered a linear function
No, I was talking about the other linear ;)
with constant
derivative but for that
On Wed, Mar 26, 2008 at 11:24 AM, TSa [EMAIL PROTECTED] wrote:
I agree. But let me explain how I arrive at that. To me there is no
binary minus!
I must agree with that one. In chalkboard mathematics, - is a unary
negation operator, and its use as a binary op in x - y is just
shorthand for x
On Wed, Mar 26, 2008 at 12:04:43PM -0400, Mark J. Reed wrote:
: On Wed, Mar 26, 2008 at 11:24 AM, TSa [EMAIL PROTECTED] wrote:
: I agree. But let me explain how I arrive at that. To me there is no
: binary minus!
:
: I must agree with that one. In chalkboard mathematics, - is a unary
:
HaloO,
Larry Wall wrote:
That interpretation doesn't help me solve my generic parsing problems,
which is about the relationship of op1 to op2 and op3 in
op1 a() op2 b() op3 c()
and presumably the same thing for postfixes in the other order.
My idea is to have a term re-writing stage
On Wed, Mar 26, 2008 at 1:06 PM, TSa [EMAIL PROTECTED] wrote:
1 + a(x)²!
Seems like a mathematician would be inclined to write that one as this instead:
1 + a²(x)!
But I'm not suggesting that you try to make (a**2)(x) work for
(a(x))**2 in Perl. :)
--
Mark J. Reed [EMAIL PROTECTED]
On Wed, Mar 26, 2008 at 06:06:29PM +0100, TSa wrote:
HaloO,
Larry Wall wrote:
That interpretation doesn't help me solve my generic parsing problems,
which is about the relationship of op1 to op2 and op3 in
op1 a() op2 b() op3 c()
and presumably the same thing for postfixes in the
Larry Wall wrote:
So here's another question in the same vein. How would mathematicians
read these (assuming Perl has a factorial postfix operator):
1 + a(x)**2!
1 + a(x)²!
The 1 + ... portion is not in dispute: in both cases, everything to
the right of the addition sign gets
On Wed, Mar 26, 2008 at 11:00:09AM -0700, Jon Lang wrote:
: OTOH, you didn't ask how mathematicians would write this; you asked
: how they'd read it. As an amateur mathematician (my formal education
: includes linear algebra and basic differential equations), I read the
: former as a(x) to the
HaloO,
Jon Lang wrote:
all unary operators, be
they prefix or postfix, should be evaluated before any binary operator
is.
Note that I see ** more as a parametric postscript then a real binary.
That is $x**$y sort of means $x(**$y). Note also that for certain
operations only integer values for
Larry Wall wrote:
Now, I think I know how to make the parser use precedence on either
a prefix or a postfix to get the desired effect (but perhaps not going
both directions simulatenously). But that leads me to a slightly
different parsing question, which comes from the asymmetry of
HaloO,
Mark J. Reed wrote:
On Wed, Mar 26, 2008 at 1:06 PM, TSa [EMAIL PROTECTED] wrote:
1 + a(x)²!
Seems like a mathematician would be inclined to write that one as this instead:
1 + a²(x)!
That one is ambiguous because it could mean a(a(x)) or a(x)*a(x)
with the latter case being
HaloO,
Larry Wall wrote:
That's what I thought. Now note that ! can't easily be rewritten
as a simple binary operator (unless you do something recursive, and
then it's not simple).
Would $x! == [*]1..$x constitute simple parserwise? Admittedly
it's not a single but two ops and one of them a
On Wed, Mar 26, 2008 at 11:00:09AM -0700, Jon Lang wrote:
: all unary operators, be they prefix or postfix, should be evaluated
: before any binary operator is.
And leaving the pool of voting mathematicians out of it for the moment,
how would you parse these:
sleep $then - $now
not $a
TSa wrote:
Jon Lang wrote:
all unary operators, be
they prefix or postfix, should be evaluated before any binary operator
is.
Note that I see ** more as a parametric postscript then a real binary.
That is $x**$y sort of means $x(**$y).
That's where we differ, then. I'm having
HaloO,
Larry Wall wrote:
likewise, should these be parsed the same?
$a**2i
$a**2.i
and if so, how to we rationalize a class of postfix operators that
*look* like ordinary method calls but don't parse the same.
This is a conceptual problem that .blahh is visually nailed down on
the
On Wed, Mar 26, 2008 at 07:43:16PM +0100, TSa wrote:
HaloO,
Larry Wall wrote:
That's what I thought. Now note that ! can't easily be rewritten
as a simple binary operator (unless you do something recursive, and
then it's not simple).
Would $x! == [*]1..$x constitute simple parserwise?
On Wed, Mar 26, 2008 at 12:03 PM, Larry Wall [EMAIL PROTECTED] wrote:
On Wed, Mar 26, 2008 at 11:00:09AM -0700, Jon Lang wrote:
: all unary operators, be they prefix or postfix, should be evaluated
: before any binary operator is.
And leaving the pool of voting mathematicians out of it for
On Wed, Mar 26, 2008 at 3:18 PM, Jon Lang [EMAIL PROTECTED] wrote:
Those don't strike me as being unary operators; they strike me as
being function calls that have left out the parentheses.
At least through Perl5, 'tain't no difference between those two in Perl land.
As for binary !, you
Mark J. Reed wrote:
Jon Lang wrote:
Those don't strike me as being unary operators; they strike me as
being function calls that have left out the parentheses.
At least through Perl5, 'tain't no difference between those two in Perl land.
True enough - though the question at hand
Larry Wall wrote:
On Wed, Mar 26, 2008 at 12:56:08PM -0600, Thom Boyer wrote:
Larry Wall wrote:
... In the
limit, suppose some defines a postfix say looser than comma:
(1,2,3)say
1,2,3say
1,2,3.say
I must be missing something. Wouldn't it be easier to write
1,2,3 say
since
Thom Boyer wrote:
But the main point I was trying to make is just that I didn't see the
necessity of positing
1,2,3\say
when (if I understand correctly) you could write that as simply as
1,2,3 say
Nope. This is the same situation as the aforementioned '++' example,
in that
HaloO,
Larry Wall wrote:
Another minor psychological factor is comes into play is that, besides
being too hard to type, ÷ is visually a symmetrical operator,
while division is inherently an asymmetric operation. You'll notice
that other asymmetric operators invented by mathematicians tend to
HaloO,
Doug McNutt wrote:
Don't allow it to become
= f(-$x); ## wrong!
Unless of course f does Linear, then you can factor out or in the
multiplication with -1 at will. So linearity of operators and
functions is a very interesting property for optimizers.
Regards, TSa.
--
The Angel of
* TSa [EMAIL PROTECTED] [2008-03-19 16:00]:
Aristotle Pagaltzis wrote:
Something like
path { $app_base_dir / $conf_dir / $foo_cfg . $cfg_ext }
where the operators in that scope are overloaded irrespective of
the types of the variables (be they plain scalar strings,
instances of a
* Mark J. Reed [EMAIL PROTECTED] [2008-03-19 20:45]:
Maybe it's just 'cause I cut my teeth on BASIC, but + for
string concatenation has always felt pretty natural. Obviously
it won't work in Perl where you are using the operator to
determine how to treat the operands. At first blush I find it
On Fri, Mar 21, 2008 at 4:25 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
It makes the meaning of the statement dependent on
the types of any variables, which is information that a reader
won't necessarily find in close vicinity of the statement.
[...]
if you're completely changing
* Mark J. Reed [EMAIL PROTECTED] [2008-03-21 21:35]:
On Fri, Mar 21, 2008 at 4:25 PM, Aristotle Pagaltzis [EMAIL PROTECTED]
wrote:
It makes the meaning of the statement dependent on the types
of any variables, which is information that a reader won't
necessarily find in close vicinity of
On 2008-Mar-19, at 1:40 pm, Mark J. Reed wrote:
On Wed, Mar 19, 2008 at 1:01 PM, Larry Wall [EMAIL PROTECTED] wrote:
The use of + in Python or in C++ is, I think, primarily the
violation of a *linguistic* principle, not a mathematical principle.
Maybe it's just 'cause I cut my teeth on
On Thu, Mar 20, 2008 at 2:24 AM, David Green [EMAIL PROTECTED] wrote:
Interestingly, BASIC has gone the other direction --
at least, Visual BASIC uses + for addition and for concatenation;
I'm guessing this happened when VB got variant types that could hold
either numbers or strings.
HaloO,
Mark J. Reed wrote:
For the record, I am opposed to any restriction on operator
overloading that requires mathematical properties to hold. ANYTHING
is fair if you predeclare.
Hmm, my idea is more about defining interfaces that allow to detach
implementation of (numerical) algorithms
On Thu, Mar 20, 2008 at 10:01 AM, TSa [EMAIL PROTECTED] wrote:
Hmm, my idea is more about defining interfaces that allow to detach
implementation of (numerical) algorithms from datatypes. E.g. the
Euclidean algorithm to find the gcd requires division and a remainder
that decreases in
HaloO,
Mark J. Reed wrote:
Sure. But that's different from saying Ok, you can only define an /
operator for numberish things.
Well, if you adhere to the ring, field or whatever interface the
overloaded / sort of ends up being numberish anyway.
BTW, do we have a unary multiplikative
On Thu, Mar 20, 2008 at 11:03:11AM -0400, Mark J. Reed wrote:
:Besides, there is nothing that inherently
:associates the / symbol with division - it's only an ASCII
:approximation of fraction notation.
:
: We all know that ASCII is a rather limited char set but one
: that has the
On Thu, Mar 20, 2008 at 05:06:00PM +0100, TSa wrote:
BTW, do we have a unary multiplikative inversion operator?
That is 1/ as prefix or **-1 as postfix?
Well, 1/ looks like a pretty good prefix. :)
Except it's not really first class. This ain't Haskell...
As for **-1, I'd suspect that of
At 17:06 +0100 3/20/08, TSa wrote:
BTW, do we have a unary multiplikative inversion operator?
That is 1/ as prefix or **-1 as postfix? Perhaps .inv as method?
Do we have .neg for additive inversion?
There certainly is the unary minus even though it is badly interpreted in some
languages,
On Thu, Mar 20, 2008 at 1:09 PM, Doug McNutt [EMAIL PROTECTED] wrote:
Don't even think about parsing = -$x**2; so that it returns a positive
result.
Okay, going way off on a tangent here, but I don't think the Perl
interpretation is quite as obviously correct as you think it is;
there's a
Hi Jonathan,
* Jonathan Lang [EMAIL PROTECTED] [2008-02-24 22:30]:
So if I'm understanding you correctly, the following would be
an example of what you're talking about:
{ use text; if $a 49 { say $a } }
...with the result being the same as Perl5's 'if $a gt 49 {
say $a }' (so if $a
HaloO,
Aristotle Pagaltzis wrote:
Something like
path { $app_base_dir / $conf_dir / $foo_cfg . $cfg_ext }
where the operators in that scope are overloaded irrespective of
the types of the variables (be they plain scalar strings,
instances of a certain class, or whatever).
Assuming there
For the record, I am opposed to any restriction on operator
overloading that requires mathematical properties to hold. ANYTHING
is fair if you predeclare. Besides, there is nothing that inherently
associates the / symbol with division - it's only an ASCII
approximation of fraction notation. I
On Wed, Mar 19, 2008 at 12:38:48PM -0400, Mark J. Reed wrote:
: For the record, I am opposed to any restriction on operator
: overloading that requires mathematical properties to hold. ANYTHING
: is fair if you predeclare. Besides, there is nothing that inherently
: associates the / symbol with
On Wed, Mar 19, 2008 at 1:01 PM, Larry Wall [EMAIL PROTECTED] wrote:
While I agree with the sentiment of not arbitrarily restricting
people from doing ugly things unless they ask for such restrictions,
Agreed... though I disagree that the sort of overloading under
discussion (/ for separating
HaloO,
Doug McNutt wrote:
I really want to use complex numbers, vectors, matrices, and
sometimes quarternions. I really want to be able to define or use
previously defined operators in a way that I learned in the 50's. I
want my compiler to understand when I use vectors in which the
components
[Cc to perl6-language as I think this is of interest]
[Oh, and please read the entire thing before responding to any
one particular point. There are a number of arguments flowing
from one another here. (I am guilty of being too quick with the
Reply button myself, hence this friendly reminder.)]
On 24 Feb 2008, at 15:00, Aristotle Pagaltzis wrote:
Something like
path { $app_base_dir / $conf_dir / $foo_cfg . $cfg_ext }
I've wanted this often. I've also wanted a clean way to lexically
supply a default target object. For example with HTML::Tiny you often
write
my $h =
On Sun, Feb 24, 2008 at 3:00 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
Something like
path { $app_base_dir / $conf_dir / $foo_cfg . $cfg_ext }
where the operators in that scope are overloaded irrespective of
the types of the variables (be they plain scalar strings,
instances
On Sun, Feb 24, 2008 at 04:23:54PM +, Andy Armstrong wrote:
I've wanted this often. I've also wanted a clean way to lexically supply a
default target object. For example with HTML::Tiny you often write
my $h = HTML::Tiny-new();
$h-body($h-head($h-title('FooPage')), $h-body(...));
I'd
At 17:30 + 2/24/08, Luke Palmer wrote:
On Sun, Feb 24, 2008 at 3:00 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
And I read both very carefully and failed to understand most of it.
I use perl for physics and engineering mostly because I forgot most of my
FORTRAN long ago and perl works
Aristotle Pagaltzis wrote:
And this contradiction – that being able to declare sugar is
good, but the way that languages have permitted that so far leads
to insanity – is what sent me thinking along the lines that there
has to be some way to make overloading sane. And we all know that
On 2008-Feb-24, at 2:28 pm, Jonathan Lang wrote:
{ use text; if $a 49 { say $a } }
...with the result being the same as Perl5's 'if $a gt 49 { say
$a }' (so if $a equals '5', it says '5'). Am I following you? If
so, I'm not seeing what's so exciting about the concept;
The whole point
65 matches
Mail list logo
