- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
ignorable positions
Tue, 2010-05-18, 16:39
that arises is what to do with errors which emerge from the scaffolding
scala has to swaddle around scripts to make them into compilation units.
("You can't swaddle with scaffolding," you're thinking. Yes, metaphor
abstraction boundaries are also violated.) Which is not to say that the
scaffolding has errors per se, but an error in one place (especially
something like a missing brace) can cause scala to point inside there,
causing confused wailing. I'm directing this at miles because he is as
far as I know the main "positions guy" other than martin. Background
complete.
In my first patch to fix script positions, my approach to suppressing
those was to give Reporter an optional suppression function Position =>
Boolean, and it would be quiet if that returned true. That worked of
course, but now having had the thrill of writing the patch two
completely different ways, the second time through it seems like it
should be a property of the Position. Something akin to this
special-purpose variation.
case class FakePos(msg: String) extends Position {
override def toString = msg
}
If Position had some Boolean indicating isSynthetic or isRealSource or
correspondsToSource or some word juggling I haven't hit on yet, then
with "class IgnorablePos" and the corresponding change to Reporter we'd
have a nice granular close-to-the-scaffolding way of warding off
spurious errors.
What do you think, I ask.
Wed, 2010-05-19, 16:07
#2
Re: ignorable positions
On Wed, May 19, 2010 at 07:45:22AM +0100, Miles Sabin wrote:
> Why is it necessary to suppress anything? What makes it so difficult
> to map the swaddled positions back to their unswaddled form?
The positions have no unswaddled form. They don't correspond to any
source code a user wrote. And now they don't correspond to any source
code at all since I'm buiding the AST wrapper directly.
If a user's script is something like
val z "a"
Right now in trunk we see these errors:
(fragment of a.scala):1: error: '=' expected but string literal found.
val z "line 8"
^
(virtual file):2: error: illegal start of simple expression
object Main {
^
two errors found
I don't want to map the second error to a good position. I want it to
not exist in the output.
Wed, 2010-05-19, 17:17
#3
Re: ignorable positions
On Wed, May 19, 2010 at 4:01 PM, Paul Phillips wrote:
> If a user's script is something like
>
> val z "a"
>
> Right now in trunk we see these errors:
>
> (fragment of a.scala):1: error: '=' expected but string literal found.
> val z "line 8"
> ^
> (virtual file):2: error: illegal start of simple expression
> object Main {
> ^
> two errors found
>
> I don't want to map the second error to a good position. I want it to
> not exist in the output.
This doesn't seem to be so much an issue with positions as an issue
with the "file" of origin.
Isn't is possible to filter out messages in the reporter based on the
type of the source of the position? Of course it is, and presumably
that's exactly what you did. I suppose I'm not really understand why
that isn't exactly the right thing to do.
I'm also not fully understanding your proposed alternative. Is it that
you would dynamically switch the positions factory methods to create
IgnorablePositions while processing the wrapper, and to create
non-ignorable positions the rest of the time?
Cheers,
Miles
Wed, 2010-05-19, 17:37
#4
Re: ignorable positions
On Wed, May 19, 2010 at 05:07:56PM +0100, Miles Sabin wrote:
> Isn't is possible to filter out messages in the reporter based on the
> type of the source of the position? Of course it is, and presumably
> that's exactly what you did. I suppose I'm not really understand why
> that isn't exactly the right thing to do.
It's just a question of where the logic goes. In both cases the
reporter has to be selective based on some test. In my first patch this
was done at reporter creation time by specifying a Position => Boolean
function. This time around I was suggesting associating the knowledge
with the position. But I don't care much, I'm ready to move on.
Although at this point I guess this isn't going into 2.8 anyway.
Wed, 2010-05-19, 18:27
#5
Re: ignorable positions
On Wed, May 19, 2010 at 5:30 PM, Paul Phillips wrote:
> It's just a question of where the logic goes. In both cases the
> reporter has to be selective based on some test. In my first patch this
> was done at reporter creation time by specifying a Position => Boolean
> function. This time around I was suggesting associating the knowledge
> with the position.
OK, but isn't that just something like (in Position),
def isWrapperPos : Boolean = source.isWrapper
where the default implementation of isWrapper is false and
CompoundSourceFile redefines it as true?
You seemed to be suggesting something much more invasive wrt Positions
(which made me correspondingly more anxious).
Cheers,
Miles
Wed, 2010-05-19, 18:37
#6
Re: ignorable positions
On Wed, May 19, 2010 at 06:20:34PM +0100, Miles Sabin wrote:
> OK, but isn't that just something like (in Position),
>
> def isWrapperPos : Boolean = source.isWrapper
>
> where the default implementation of isWrapper is false and
> CompoundSourceFile redefines it as true?
Yes, this is exactly what I was suggesting.
Wed, 2010-05-19, 18:47
#7
Re: ignorable positions
On Wed, May 19, 2010 at 6:35 PM, Paul Phillips wrote:
> On Wed, May 19, 2010 at 06:20:34PM +0100, Miles Sabin wrote:
>> OK, but isn't that just something like (in Position),
>>
>> def isWrapperPos : Boolean = source.isWrapper
>>
>> where the default implementation of isWrapper is false and
>> CompoundSourceFile redefines it as true?
>
> Yes, this is exactly what I was suggesting.
OK, I'm happy with that.
On Tue, May 18, 2010 at 4:39 PM, Paul Phillips wrote:
> In my first patch to fix script positions, my approach to suppressing
> those
I need a bit more context to understand this bit ...
Why is it necessary to suppress anything? What makes it so difficult
to map the swaddled positions back to their unswaddled form?
Cheers,
Miles