Dear All,
I have two suggestion for changes, one following the standard without breaking too much old code (if at all), the other one differing from it (for the standard see below). At the moment I don't have a fixed opinion if one or both should be applied (though I like them!): this is mainly because of compatibility reasons. 1. Changes following the standard --------------------------------- a) Change parsing to parse (0@-1) as (0) @- (1) . b) Define Number>>@- to generate a Point with negated second arg (sent #negated). c) Define Number>>@+ to generate a Point with second arg sent #performUnaryOperatorPlus or similar (defined returning self in case of numbers) before. - a) together with b) avoids breaking code containing (0@-1) -like things. - b) gives some symmetry (related to next point). - Points b) and c) together give unique handling of vars and literals, e.g. (1 @- 1) would be treated the same as (firstVar @- secondVar), leading to a message send #@- to the first number/var, the same for #@+ . - It is always possible to avoid the message sends by just using whitespace accordingly. - As an optimization b) and c) *could* be inlined for numbers at compile time (if not overridden (to ensure this forever could be a problem)), if there *should* be a performance problem. - a), b), c) all are standard conform. 2. Changes differing from the standard -------------------------------------- a) Allow #+ as prefix before a number leading to the corresponing unary #performUnaryOperatorPlus message send. b) Add #+ to the special right binding treatment of #- (see below). c) Also allow prefix and right binding behaviour of #+ and #- for literals. - a) allows to write (+1) as well as (-1) . - a), b) gives the possibility to write (+ 1 @ + 1) as well as ( - 1 @ - 1) . - a), b), c) allow to write (+ 1 @ - 1) as well as (+ firstVar @ - secondVar) or (+ aVar @ - 1) . The motivation here is unification. To be portable this would lead to the need of porting filters changing the source code for the target platform (following the standard or not). But these should already be necessary in the current situation (all differing differently from the standard)... A question related to this: how often there are ports of things using Points? The GUI stuff mostly cannot be ported, I think, and there I'm expecting most of the (0@-1) -like things... So for Points I don't see 2. very problematically - at the moment -, but for numerical (or other code) it is. What do you think? Corrections (there may be mistakes) are appreciated, too. Best regards, Stephan =============================== >From the standards draft NCITS J20 DRAFT December, 1997 33 of ANSI Smalltalk Standard revision 1.9 , in short: - 'White space is allowed between the '-' and the <number>' for a numeric literal; and - 'If a negative <number literalfollows a binary selector there must intervening white space.' Snippets from the standard draft: std> 3.4.6.1 Numeric Literals std> std> Numbers are objects that represent numerical values. Numeric literals are used to create numeric std> objects which have specific values and numeric representations. std> std> std> <number literal> ::= ['-'] <number> std> <number> ::= integer | float | scaledDecimal std> std> If the preceding '-' is not present the value of the numeric object is a positive number. If the '-' is std> present the value of the numeric object is the negative number that is the negation of the positive std> number defined by the <number> clause. White space is allowed between the '-' and the std> <number>. std>... std> std> 3.5.5 Operators std> std> Three types of operator tokens are defined in Smalltalk: binary selectors, the return operator, and std> the assignment operator. std> std> . std> binaryCharacter ::= std> '!' | '%' | '&'' | '*' | '+' | ','' | '/' | '<' | '=' | '>' | '?' | '@' | '\' | '~' | '|' | '-' std> binarySelector ::= binaryCharacter+ std> std> returnOperator ::= '^' std> std> assignmentOperator ::= ':=' std> std> Binary selectors are method selectors that appear similar to mathematical operators. A binary std> selector may be any length greater than or equal to one. If a negative <number literal> follows a std> binary selector there must intervening white space. std> std> An implementation may define additional binaryCharacters but their use may result in a non- std> portable program. -- Stephan Rudlof ([hidden email]) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3 |
Free forum by Nabble | Edit this page |