REBOL3 tracker
  0.9.12 beta
Ticket #0000743 User: anonymous

Project:



rss
TypeBug Statustested Date1-May-2009 23:00
Versionalpha 49 Categoryn/a Submitted bymeijeru
PlatformAll Severityminor Prioritynormal

Summary numerical refinement allowed in function spec -- should be error
Description a refinement of the form /1 in the function spec is not caught as error, but a function call with that refinement is!

ticket 733 relates: there is no reason to consider /1 as a valid refinement -- the fact that it may validly occur in a path expression is neither here nor there, because there are many more constructs that are allowed in a path expression, and are not a valid refinement (e.g. get-word, paren)
Example code
>> f: func[a /1 b][a]
== make function! [[a /1 b][a]]
>> f/1 0 0
** Script error: incompatible refinement: 1

Assigned ton/a Fixed inalpha 58 Last Update22-Jun-2009 15:59


Comments
(0000610)
BrianH
2-May-2009 00:19

It turns out that the 1 in a/1 is the integer! 1, not the refinement! /1 or the word! to-word "1". That is why you get the incompatible refinement error. The problem is not that the function can't be called, it's that the call can't be directly specified in REBOL syntax.

>> a: func [/1] [get /1]
== make function! [[/1][get /1]]
>> a
== none
>> a/1
** Script error: incompatible refinement: 1
>> type? second first [a/1]
== integer!
>> type? second first [a/b]
== word!
>> do reduce [to-path reduce ['a to-word /1]]
== true
>> apply :a [true]
== true
(0000612)
meijeru
2-May-2009 10:21

All the more reason to forbid /1 as a (free-standing) literal of type refinement! why not narrow refinement! down to slash+word? It seems clear to me that the lexical analysis of free-standing slash+word and that of path expressions are done separately, since /-1 is not allowed but a/-1 is. The language would become cleaner that way.
(0000614)
BrianH
2-May-2009 20:06

Here's where that argument breaks down:
- Paths and refinements are not the same thing, and don't have the same syntax.
- Refinements are not just used in function specs - they are used in other dialects where they are not translated from word elements in paths
- Numeric elements in paths are not words, they are numbers. They are not converted to refinements on path decoding.
- There are tricks you can do with refinements that make it worth supporting refinements that don't have the same syntax as words, even in function specs.

I am leaning towards recommending that this be dismissed.
(0000617)
meijeru
3-May-2009 12:21

"There are tricks you can do with refinements that make it worth supporting refinements that don't have the same syntax as words, even in function specs."
Would you care to elaborate? If you prefer, we can continue this dialogue by e-mail.
(0000622)
BrianH
5-May-2009 00:58

R3 chat is best for such discussions.

Date User Field Action Change
19-Feb-2012 19:48 BrianH Comment : 0000610 Modified -
22-Jun-2009 15:59 BrianH Status Modified built => tested
21-Jun-2009 00:07 carl Status Modified reviewed => built
21-Jun-2009 00:07 carl Fixedin Modified => alpha 58
5-May-2009 00:58 BrianH Comment : 0000622 Added -
3-May-2009 12:21 meijeru Comment : 0000617 Added -
2-May-2009 20:06 BrianH Comment : 0000614 Added -
2-May-2009 19:57 BrianH Comment : 0000610 Modified -
2-May-2009 15:10 meijeru Description Modified -
2-May-2009 10:21 meijeru Comment : 0000612 Added -
2-May-2009 00:26 BrianH Comment : 0000610 Modified -
2-May-2009 00:25 BrianH Code Modified -
2-May-2009 00:19 BrianH Comment : 0000610 Added -
2-May-2009 00:15 BrianH Code Modified -
1-May-2009 23:36 BrianH Status Modified submitted => reviewed
1-May-2009 23:36 BrianH Code Modified -
1-May-2009 23:36 BrianH Description Modified -
1-May-2009 23:00 meijeru Ticket Added -