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
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 t
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 argum
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 single
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 thing
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.*(
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
>
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
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
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
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 have
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 Alg
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 capt
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 *
Thom Boyer wrote:
Now, I think that
$x.foo
is a method call, even if there's a postfix: declaration in scope.
And that's a problem, because, no matter what precedence postfix:
was given,
1,2,3.foo
is still going to mean
1, 2, (3.foo)
instead of the desired
postfix:(1,2,3
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
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
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
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
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
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 parse
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 t
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 h
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 eq
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 m
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 bein
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 po
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
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 tw
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 get
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 postfix
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]
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 befo
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
: ne
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 f
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 def
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 f
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 Ge
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
* 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 v
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 changi
* 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 fin
* 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,
>> inst
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 }
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
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, thank
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 be
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
: > tha
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 inversi
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:
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 fr
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 strin
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 BA
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 separ
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
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 w
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
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 a
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 poi
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
>
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 work
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(...
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,
> in
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 = HTML::Ti
64 matches
Mail list logo
