problem in porting from smalltalk

hi,
  i'm porting some code from smalltalk and i receive a runtime error of this type

argument of or: must be a block or variable


(or: is the method i'm implementing)

I pass to it a variable i suppose ( the number 0.2)

this is the code:

a _ FuzzyMagnitude new degree:0.7.
b _ FuzzyMagnitude new degree:0.20.
a and: b. 
a and:  <- argument of and: must be a block or variable ->0.2.

(FuzzyMagnitude is an object that i have defined)
 advice,
  nelson
thanks for any

In smalltalk there are two forms for conjunction (and) : the lazy and  
"normal" one

and: evaluates only the second argument is the first one is true
so you have to pass a block

(1 > 2) and: [3 error]
(1 <2) and: [3 error]

compare
with
(1>2) & (3 error)

Stef

On 19 févr. 06, at 12:20, nelson - wrote:

> From: [...] nelson
> argument of or: must be a block or variable
> (or: is the method i'm implementing)

You've just been hit by the Compiler trying to compile inline code for
'and:' and 'or:', I suspect.  If you reimplement them as fuzzyAnd: and
fuzzyOr:, the problem will probably go away.

                - Peter

Le Dimanche 19 Février 2006 14:08, Peter Crowther a écrit :
> > From: [...] nelson
> > argument of or: must be a block or variable
> > (or: is the method i'm implementing)
>
> You've just been hit by the Compiler trying to compile inline code for
> 'and:' and 'or:', I suspect.  If you reimplement them as fuzzyAnd: and
> fuzzyOr:, the problem will probably go away.
>
>   - Peter

browse class MessageNode and classVar MacroTransformers to see a list of
messages that are compiled inline and cannot be redefined in Squeak.

(I think they can be in VW).

Nicolas

Dear Peter,
   the problem is that i HAVE to impelement and: .... I have a fuzzyAnd: method, but i want to be able to mix crisp and fuzzy value, so redefining and: definition would be the best choice... can I disable this code inlining?

thanks,
  nelson

nelson - writes:

 > Dear Peter,
 >    the problem is that i HAVE to impelement and: .... I have a fuzzyAnd:
 > method, but i want to be able to mix crisp and fuzzy value, so redefining
 > and: definition would be the best choice... can I disable this code
 > inlining?

You should definately be able to disable the and: inlining. I doubt
that everyone would be happy with such a change in the mainstream
image but it's definately reasonable for your personal images or for a
project that needs and: to behave like a proper method.

Poke around in the Compiler class, and save your image frequently.
Try exploring how the "special" instance variable on MessageNode is
used.

Hmm, yet another argument for full message inlining. But for now,
you'll loose performance, however the loss may not be noticable.

Bryce

Le Mercredi 22 Février 2006 23:36, Bryce Kampjes a écrit :
What about a little change in the #and: form ?

using blocks both sides of the #and: message would enable the compiler to
choose its way of generating bytecodes:

When both receiver and argument are blocks, use bytecode optimization.
 [a < 0] and: [b > a]
When one of the two isn't a block, then use regular message send.
 a and: b

This is in the spirit of whileTrue: optimization in VW.
Of course, most senders of #and: would have to be rewritten with block
receiver to profit by compiler optimization.

What do you think of this proposition ?

Another more radical solution is a kind of <pragma: #dontOptimizedCode>,
or maybe more selective <dontOptimize: #and:>...

Nicolas

> This is in the spirit of whileTrue: optimization in VW.
> Of course, most senders of #and: would have to be rewritten with block
> receiver to profit by compiler optimization.

That doesn't make sense, #and: and #whileTrue: are completely
different constructs. See the difference when writing down the
execution path of a and b as regular expressions:

      a and: [ b ] -> ab?

      [ a ] whileTrue: [ b ] -> a(ba)*

There is no point in putting expressions into a block that are
executed exactly once. This also violates the SmallLint rule "Block
immediately evaluated".

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

> From: nicolas cellier
> Have to revert to a <pragma> thing...

I'm not convinced.  Pragmas are at best a kludge.

I liked the early gcc response to #pragma.  The spec stated that a
compiler could do whatever it wanted when it saw a #pragma, so gcc tried
to run a variety of games and threw a segmentation fault if it failed to
find any of them.

                - Peter

I think that nicolas is talking about
method pragmas as in VW and now in squeak 3.9.

Retrospectively I think that pragmas are really an excellent addition  
to VW
with is bloated with the lot of less desirable features (class import  
level...)

Stef

On 23 févr. 06, at 22:17, Peter Crowther wrote:

> I'm not convinced.  Pragmas are at best a kludge.
>
> I liked the early gcc response to #pragma.  The spec stated that a
> compiler could do whatever it wanted when it saw a #pragma, so gcc tried
> to run a variety of games and threw a segmentation fault if it failed to
> find any of them.

The pragmas in 3.9 are not there to tweak the code generator. After
parsing they are put into the compiled method, so that the system can
query tagged methods. It has absolutely nothing to do with the
#pragma, except that is shared its name.

The Smalltalk pragmas are a key element to write extensible software.
Right now a lot of extension problems can only be solved trough the
use of strange naming conventions, such as that test-methods in SUnit
have to start with #test, or that meta-descriptions in Magritte have
to start with #description, etc. Moreover there is no clean way to
tell the system that a specific method is used as an event-handler, or
that a method explicitly fails an SLint rule, or that it returns a
string of a specific mime-type, etc. Pragmas are a slick solution to a
permanent problem that cannot be easily solved otherwise.

Lukas


--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli wrote:
> The pragmas in 3.9 are not there to tweak the code generator. After
> parsing they are put into the compiled method, so that the system can
> query tagged methods. It has absolutely nothing to do with the
> #pragma, except that is shared its name.

Which is precisely the reason why I originally called them "annotations"
instead of pragmas.

Cheers,
   - Andreas

> I liked the early gcc response to #pragma.  The spec stated that a
> compiler could do whatever it wanted when it saw a #pragma, so gcc tried
> to run a variety of games and threw a segmentation fault if it failed to
> find any of them.
>
>                 - Peter

Yes, early, but then they added their own __attribute__...

> Which is precisely the reason why I originally called them "annotations"
> instead of pragmas.
>
> Cheers,
>    - Andreas

As everybody, I dislike pragmas for they are compiler dependent, not part of
the language definition itself, and lead to portability problems
(already upset by structure alignment in {} and its damn pragmas).

Inside squeak, portability is not a problem, you can change the compiler, and
you can make this change a prereq when loading into another image.

Problems will raise when you want to move outside Squeak.
But in this case, Squeakers will also get problems with the {a. b. c.}
extension, Dolphiners with the ##() extension etc...

So, at inter-dialect level, pragmas, annotations or whatever syntax extension
will lead to portability problem, because they are not standard.
The difference between #annotations and #pragmas might not be so thick from a
pragmatic point of view...

------------------------------------------------------------------------
The facts:
Without byte code optimization, Smalltalk would not be efficient at all.
Byte code optimization makes Smalltalk not as extensible as it should be.
This problem exists in other Smalltalks.

The solutions:
- Nobody likes the pragma. OK.
- Lukas does not like blocks evaluated once and only once. OK.
- Bryce and Peter suggested unoptimizing only #and/#or:, and that is the
simpler solution by now. In a 3.8 image just :

MessageNode>>transformAnd: encoder
    ^false
MessageNode>>transformOr: encoder
    ^false

Maybe the not optimized and: won't break performance noticeably... worth
trying...

A work around to get both optimized and notoptimized code on a class basis is
this one (mostly 3 classes and 4 messages):
- declare  compilerClass ^NotOptimizedAndOrCompiler as class method where you
intend to use your fuzzy logic and: extension...
- NotOptimizedAndOrCompiler will arrange to use NotOptimizedAndOrParser
- NotOptimizedAndOrParser will use NotOptimizedAndOrMessageNode
- NotOptimizedAndOrMessageNode will only redefine above transformAnd:
transformOr: methods
- maybe have to change a few more refs of MessageNode... (turning isMemberOf:
into isKindOf: and other things like that)

> The clean solution is to dynamically inline message sends so the
> simple unoptimised version of and: is as fast as the optimised
> version. A system with dynamicly inlined messages would be much
> faster for other things as well.
>
> Bryce

Waouh. At the VM level ? That one is far above my skills...
Isn't it the kind of optimization in VW VM ?
My understanding of efficiency problem when not open-bytecoding #and: is the
creation of BlockContext.
Inlining send you gain creation of a MethodContext but not of a  BlockContext.
But if you also gain speed elsewhere, that's surely better...

Nicolas

andreas may be VW people got first the wrong name, but using a  
consistent one is better I think.

Stef

On 23 févr. 06, at 22:58, Andreas Raab wrote:

<meta>
Not that I personally care that much about this particular name but you
are touching a sore point here. That point is that in too many
situations I have seen people copying really screwed up stuff from VW[*]
and other systems just because they can't change it there and don't want
to work around the differences. What happens then is that you are
actively making Squeak worse by repeating a bad decision (even worse:
you are repeating it although you have the benefit of hindsight) where
instead you should be fixing the mistake and help make Squeak a better
system.

And yes, I understand that this is inconvenient if you care about
compatibility but slavishly repeating everything VW does will only get
you a VW clone, not a better system.
</meta>

[*] My pet peeve these days: Proliferation of standard protocols for the
"sake" of compatibility with X, Y, or Z. Just look at the evolution of
the Collection protocols over the last 4-5 Squeak versions to see what I
mean. I mean, if people need compatibility, why not make a compatibility
*package*? Like, in this, a subclass of the real thing that's named
Pragma and can be used if you need "compatible" pragmas.

Cheers,
   - Andreas

stéphane ducasse wrote:

On Feb 24, 2006, at 9:10 AM, stéphane ducasse wrote:

> andreas may be VW people got first the wrong name, but using a  
> consistent one is better I think.

Being consistent with the thinking and naming conventions of some  
Java folks, who might want to drop in, wouldn't hurt either.
Especially as they might have a bigger problem to change their  
"bindings" than the VW-folks... ;-)

And to me "annotations" seems to be a much more telling word than  
"pragma" (though "attribute" from C# seems to be the more polymorph...)

See also
http://en.wikipedia.org/wiki/Annotation
"Differences in computer languages have given rise to a variety of  
words for programmer-added metadata, including annotation (Java),  
attribute (C#), pragma (C), and metadata (HTML)."

Cheers,

Markus

<pragmatic and not ranting> I guess that we are not slavishly  
reproducing VW. And lukas and marcus did a really good
to get annotation or pragmas in Squeak.  Just helping Squeak and VW  
to communicate more.
Because when you will be happily be able to use their crypto package  
then we would all have win something.
And easing the port of good abstractions (Pier, Seaside) between the  
dialect is important for everybody.
<\pragmatic and not ranting>

Andreas, did you have a look at the implementation? It is not an 1:1,
it just supports the same protocol.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Hi All,

I am not new to Smalltalk but I am very, very new to Squeak and know
nothing about the compiler and its optimizations, so this suggestion may be
way off base, but here goes, couldn't the optimized code for and: and or:
be enhanced to test to see if the receiver is a boolean and if not pass the
message on the receiver in the non optimized way?  Hopefully this extra
test would not reduced the optimization much.

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

Yup, I sure did. Mostly because I was concerned about the IP aspects.
But keep in mind that my rant was a meta rant and (in this case) pointed
at using the name Pragma where one only has to look at
http://www.google.com/search?q=define:+pragma to see that pragma
describes not what these annotations are being used for and that
therefore the "consistency" argument is really a "compatibility"
argument, e.g., VW uses that bad name so we have to use the same bad
name. And there is really no point in that unless you want to write a VW
clone.

Cheers,
   - Andreas

Lukas Renggli wrote: