Le 10/06/2011 16:45, Darren New a écrit :
> On 6/10/2011 1:18, Le_Forgeron wrote:
>> For instance, in Java, you can redefine the value of 3 and 6.
> 
> Of all the languages out there, I'm pretty sure Java isn't one of those.
> :-)  How do you redefine 3 to be 14?

three years late slogan (for the USA): Yes We Can...

http://thedailywtf.com/Articles/Disgruntled-Bomb-Java-Edition.aspx

basically:

import java.lang.*;
...
           Field field = Integer.class.getDeclaredField( "value" );
           field.setAccessible( true );
           int i=3;
           field.setInt(i,14);
...


Integer a = 2;
Integer b = 3;

System.out.println( a + b );



-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

On 6/10/2011 8:05, Le_Forgeron wrote:
> Le 10/06/2011 16:45, Darren New a écrit :
>> On 6/10/2011 1:18, Le_Forgeron wrote:
>>> For instance, in Java, you can redefine the value of 3 and 6.
>>
>> Of all the languages out there, I'm pretty sure Java isn't one of thos
e.
>> :-)  How do you redefine 3 to be 14?
>
> three years late slogan (for the USA): Yes We Can...
>
> http://thedailywtf.com/Articles/Disgruntled-Bomb-Java-Edition.aspx
>
> basically:
>
> import java.lang.*;
> ...
>             Field field = Integer.class.getDeclaredField( "value" );
>             field.setAccessible( true );
>             int i=3;
>             field.setInt(i,14);
> ...
>
>
> Integer a = 2;
> Integer b = 3;
>
> System.out.println( a + b );

That's not redefining the value of 3 and 6. That's redefining the value o
f 
Integer(3) and Integer(6).  The expression "2 + 3" will still return 5.

Note that in Fortran and FORTH at least, it's pretty trivial to make the 

literal 3 refer to the value 15.  (By "pretty trivial" I mean "you might 
do 
it by accident.")

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 10/06/2011 04:12 PM, Darren New wrote:

> That's not redefining the value of 3 and 6. That's redefining the value
> of Integer(3) and Integer(6). The expression "2 + 3" will still return 5.
>
> Note that in Fortran and FORTH at least, it's pretty trivial to make the
> literal 3 refer to the value 15. (By "pretty trivial" I mean "you might
> do it by accident.")

I think Smalltalk will also let you accidentally redefine 3 to mean 
something else. (Certainly if you operate on array literals, it 
permanently changes the literal to refer to something other than what it 
says!)

Haskell will definitely let you define, say, 2+2=5. You'd be hard 
pressed to do this "by accident" though...

Post a reply to this message

On 6/10/2011 8:18, Invisible wrote:
> I think Smalltalk will also let you accidentally redefine 3 to mean
> something else.

I think anything the parser sees is hard-coded, but I could be wrong there.

> Haskell will definitely let you define, say, 2+2=5. You'd be hard pressed to
> do this "by accident" though...

And what does this result in?  Is it just that the expression "2+2" matches 
before "<integer> + <integer>" or some such, so 2+2=5 but 2+3=5 also?

"By accident" is pretty easy in fortran. All values, including literals, are 
passed by reference to a subroutine, so if the subroutine assigns to 
something that's a literal, you probably just changed the global value of 
that literal. (I.e., in most fortran implementations, "3" refers to an 
anonymous global variable that holds the value "3".)

In FORTH, you just write
     : 2 3 ;
So, "the subroutine named 2 now returns 3".  The way the parser works is 
that if it can't find the name of a routine, it then tries to parse it as a 
literal. But if it finds the name of a function, it uses it. Not something 
you're likely to do by accident unless you mess up some metaprogramming.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Haskell will definitely let you define, say, 2+2=5. You'd be hard 
> pressed to do this "by accident" though...

  And some people criticize C++ because it supports operator overloading,
which could potentially be used to make operators do something else than
what they seem...

-- 
                                                          - Warp

Post a reply to this message

On 10/06/2011 05:27 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> Haskell will definitely let you define, say, 2+2=5. You'd be hard
>> pressed to do this "by accident" though...
>
>    And some people criticize C++ because it supports operator overloading,
> which could potentially be used to make operators do something else than
> what they seem...

Yeah, I always thought that was a fairly stupid critisism...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 10/06/2011 04:49 PM, Darren New wrote:
> On 6/10/2011 8:18, Invisible wrote:
>> I think Smalltalk will also let you accidentally redefine 3 to mean
>> something else.
>
> I think anything the parser sees is hard-coded, but I could be wrong there.

I did something like define a method that returns #[1 2 3], and then I 
took the result and manipulated it. To my surprise, the method now 
returns the new, manipulated value, instead of what it claims to return. (!)

Apparently you shouldn't do that.

>> Haskell will definitely let you define, say, 2+2=5. You'd be hard
>> pressed to do this "by accident" though...
>
> And what does this result in? Is it just that the expression "2+2"
> matches before "<integer> + <integer>" or some such, so 2+2=5 but 2+3=5
> also?

You can define a new number type, and have it implement arithmetic any 
way you desire. This works because "2" is not an integer. It's a number. 
It's *any* number type.

As insane as that sounds, I have actually /used/ this myself. I 
implemented a type called HalfInteger, which supports numbers rounded to 
the nearest 1/2. So if you say "7", it really stores it as 14. And if 
you say "half", that's really one. And if you do "7 + half", you get 15. 
Ah, but of course, it doesn't /look/ like 15. It looks like 7.5 (via the 
various interfaces that let you inspect it).

The fun part is deciding what the result of half * half should be...

> (I.e., in most fortran implementations, "3" refers to
> an anonymous global variable that holds the value "3".)

Isn't that almost exactly what Smalltalk does with [at least] class names?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 6/10/2011 10:23, Orchid XP v8 wrote:
> On 10/06/2011 04:49 PM, Darren New wrote:
>> On 6/10/2011 8:18, Invisible wrote:
>>> I think Smalltalk will also let you accidentally redefine 3 to mean
>>> something else.
>>
>> I think anything the parser sees is hard-coded, but I could be wrong there.
>
> I did something like define a method that returns #[1 2 3], and then I took
> the result and manipulated it. To my surprise, the method now returns the
> new, manipulated value, instead of what it claims to return. (!)
>
> Apparently you shouldn't do that.

Especially not in a functional language? That's exactly the sort of thing a 
pure functional language is guaranteed not to do. :-)

> You can define a new number type, and have it implement arithmetic any way
> you desire. This works because "2" is not an integer. It's a number. It's
> *any* number type.

I see. So it's not really the integer 2, but the lexical symbol 2 that 
you're talking about.

>> (I.e., in most fortran implementations, "3" refers to
>> an anonymous global variable that holds the value "3".)
>
> Isn't that almost exactly what Smalltalk does with [at least] class names?

I'm not sure what you're talking about. Are you talking about interred 
strings? They're not really *quite* the same thing. FORTRAN only does that 
because most machines existing when FORTRAN was created didn't have 
immediate-mode machine instructions.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/10/2011 9:27, Warp wrote:
>    And some people criticize C++ because it supports operator overloading,

I admit, I lolled.

However, I think it's better to go way over the top than (say) to support 
operator overloading without supporting literal overloading. The ability to 
define "*" on complex numbers without the ability to write complex numbers 
inline is understandable but feels kludgey to me.

(Yes, I know for a great many types you can essentially write them inline in 
C++. I'm not necessarily talking about C++.)

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

>> I did something like define a method that returns #[1 2 3], and then I
>> took
>> the result and manipulated it. To my surprise, the method now returns the
>> new, manipulated value, instead of what it claims to return. (!)
>>
>> Apparently you shouldn't do that.
>
> Especially not in a functional language? That's exactly the sort of
> thing a pure functional language is guaranteed not to do. :-)

Yeah, well, Smalltalk is no functional language. ;-)

>> You can define a new number type, and have it implement arithmetic any
>> way
>> you desire. This works because "2" is not an integer. It's a number. It's
>> *any* number type.
>
> I see. So it's not really the integer 2, but the lexical symbol 2 that
> you're talking about.

Basically, yes. I can make it so that when you type an integer or a 
decimal, it resolves to something utterly unexpected.

Of course, monads let you do strange things to what look like simple 
imperative statements. (E.g., time travel, quantum superposition, etc.) 
Strangely, the Haskell list syntax is so hard-wired that you can't touch 
it, however.

>>> (I.e., in most fortran implementations, "3" refers to
>>> an anonymous global variable that holds the value "3".)
>>
>> Isn't that almost exactly what Smalltalk does with [at least] class
>> names?
>
> I'm not sure what you're talking about.

When you define a class named Foo, it defines a global variable named 
Foo which contains a Class object describing the class.

The fun thing is, since True and False are classes, they are also global 
variables, and you can do something like True := 42, which utterly 
confuses everything.

Then again, Smalltalk := Nil is always fun...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message