Nabble - Scala - User

.asViewOf[T], .isViewOf[T] for <% relationship

2009-11-24T00:54:18Z

It seems very strange to me that there are no methods on the Any class corresponding to the <% type relationship, ie. def asViewOf[T]:T and def isViewOf[T]:Boolean, in the same manner as the .isInstanceOf[T] and .asInstanceOf[T] methods.

I've run into a few situations where it would have been handy -- does anyone else agree? It seems a glaring omission.

Re: Continuation on Tasks

2009-11-23T23:55:19Z

Dear Kai,

i forgot to include a trace of the unit test.

Best wishes,

--greg

Welcome to Scala version 2.8.0.r18915-b20091004170819 (Java HotSpot(TM) Client VM, Java 1.5.0_20).

Type in expressions to have them evaluated.

Type :help for more information.

scala> import com.biosimilarity.validation._

import com.biosimilarity.validation._

scala> TheModChoice.select( List( 1, 2, 3 ) )

TheModChoice.select( List( 1, 2, 3 ) )

a new beginning...

scala> a new beginning...

found a result: 2

the winner is: ModWorker(2,TheModChoice)

a new beginning...

working...

stopping!

TheModChoice.showWorkerStatus

ModWorker(1,TheModChoice) has status Some(Aborted())

ModWorker(2,TheModChoice) has status Some(Complete())

ModWorker(3,TheModChoice) has status Some(Aborted())

scala> :q

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESSFUL

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 1 minute 3 seconds

[INFO] Finished at: Mon Nov 23 23:42:25 PST 2009

[INFO] Final Memory: 32M/63M

[INFO] ------------------------------------------------------------------------

bash-3.2$

On Mon, Nov 23, 2009 at 11:47 PM, Meredith Gregory <lgreg.meredith@...> wrote:

Dear Kai,

You can grab a continuation and pass it to each worker, when anyone of them fires the continuation arrange that it continues at the point of ending tasks still underway. You can see a running implementation here.

However, before looking at fancy solutions i note that you need to know the status of tasks during the dispatching phase. Hence, you might consider a status report (say case class Status( task, complete, success ) ) as the event that causes the next dispatch of task. A status report of completion & success would cause the end of task dispatching and -- if required -- send out ending of work on the already dispatched tasks.

// inside the defn of act of a dispatcher we find
// the dispatcher maintains state:

// stillWaiting : Boolean
// tasks : Stream[Task]

// ignoring end-of-stream conditions...
react {

   //
   case Init( taskStream ) => {
   stillWaiting = true;
   tasks = taskStream;

   val worker = new Worker();
   workers += worker

   worker ! beginWork( taskStream.next, this )
   }

   case Status( task, false, _ ) => {
   if (stillWaiting) {

     val worker = new Worker();
   workers += worker
   worker ! beginWork( taskStream.next, this )
   }

   }
   case Status( task, true, false ) => {

   if (stillWaiting) {
     val worker = new Worker();
   workers += worker
   worker ! beginWork( taskStream.next, this )

   }
   }
   case Status( task, true, true ) => {

   stillWaiting = false;
   workers.foreach( w => w ! Stop() )

   }
}

Best wishes,

--greg

On Fri, Nov 20, 2009 at 9:46 AM, Kai Meder <stuff@...> wrote:

Hello,

I want to process tasks successively in a continuation.
The first successful Task (an Actor-Message), determined by a predicate,
shall
terminate/short-circuit the processing of the following tasks and return
its result.

Is there any predefined Library for that purpose?
Do I have to use something like a Maybe/Option-Monad?

Thanks alot,
Kai

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

Re: Continuation on Tasks

2009-11-23T23:47:21Z

Dear Kai,

You can grab a continuation and pass it to each worker, when anyone of them fires the continuation arrange that it continues at the point of ending tasks still underway. You can see a running implementation here.

However, before looking at fancy solutions i note that you need to know the status of tasks during the dispatching phase. Hence, you might consider a status report (say case class Status( task, complete, success ) ) as the event that causes the next dispatch of task. A status report of completion & success would cause the end of task dispatching and -- if required -- send out ending of work on the already dispatched tasks.

// inside the defn of act of a dispatcher we find

// the dispatcher maintains state:

// stillWaiting : Boolean

// tasks : Stream[Task]

// ignoring end-of-stream conditions...

react {

case Init( taskStream ) => {

stillWaiting = true;

tasks = taskStream;

val worker = new Worker();

workers += worker

worker ! beginWork( taskStream.next, this )

}

case Status( task, false, _ ) => {

if (stillWaiting) {

val worker = new Worker();

workers += worker

worker ! beginWork( taskStream.next, this )

}

case Status( task, true, false ) => {

if (stillWaiting) {

val worker = new Worker();

workers += worker

worker ! beginWork( taskStream.next, this )

}

case Status( task, true, true ) => {

stillWaiting = false;

workers.foreach( w => w ! Stop() )

}

Best wishes,

--greg

On Fri, Nov 20, 2009 at 9:46 AM, Kai Meder <stuff@...> wrote:

Hello,

I want to process tasks successively in a continuation.
The first successful Task (an Actor-Message), determined by a predicate,
shall
terminate/short-circuit the processing of the following tasks and return
its result.

Is there any predefined Library for that purpose?
Do I have to use something like a Maybe/Option-Monad?

Thanks alot,
Kai

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

Re: Current directory

2009-11-23T22:52:00Z

It's very unfortunate about the naming on that one though, far too close to user.home for my comfort...

On Tue, Nov 24, 2009 at 12:45 AM, Tony Morris <tonymorris@...> wrote:

Same way you do in Java

scala> val whereami = System.getProperty("user.dir")
whereami: java.lang.String = /tmp

http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperties()

Charles F. Munat wrote:
> How does one determine the current directory in Scala? Dumb question,
> I know, but this is the sort of thing you can search for for hours. I
> presume it's Java, not Scala. Anyone know this off the top of his/her
> head?
>
> Thanks.
>
> Chas.
>

--
Tony Morris
http://tmorris.net/

parameter type not matched to return type

2009-11-23T22:40:47Z

I've upgraded Alex Azarov's excellent mongo-scala-driver (http://wiki.github.com/alaz/mongo-scala-driver/howto-getting-started) to Scala 2.8 and it compiled fine (http://github.com/alexy/mongo-scala-driver). Now I've done it again with the latest nightly and it gave me two type errors. Here they are as explained types, maven output:

[ERROR] /s/w/scala/mongo/alexyk/src/main/scala/com/osinka/mongodb/shape/Implicits.scala:12: error: type mismatch;
[INFO] found : coll.Self
[INFO] required: Coll
[INFO] def in[Coll <: QueriedCollection[T, Coll]](coll: QueriedCollection[T, Coll]): Coll = coll.applied(q.query)

[ERROR] /s/w/scala/mongo/alexyk/src/main/scala/com/osinka/mongodb/Preamble.scala:21: error: type mismatch;
[INFO] found : coll.Self
[INFO] required: Self
[INFO] def in(coll: QueriedCollection[T, Self]): Self = coll.applied(q)
[INFO] ^
[ERROR] /s/w/scala/mongo/alexyk/src/main/scala/com/osinka/mongodb/Preamble.scala:21: error: type mismatch;coll.Self <: Self?

The trait in question is defined thus:

trait QueriedCollection[T, Self <: QueriedCollection[T, Self]] extends MongoCollection[T] {
def query: Query

def applied(q: Query): Self

// -- MongoCollection[T]
override def find = find(query)
override def firstOption = findOne(query)
override def sizeEstimate = getCount(query)
}
Apparently, that Self returned via def applied is treated as coll.Self in the errors above, and not as the same Self supposedly given as a parameter. Why is that, and why could have it changed recently, if it did?

Cheers,
Alexy

Linearization

2009-11-23T20:41:34Z

Hi,

How to print the linearization of a class from one of its instance?

Re: Current directory

2009-11-23T16:45:21Z

Same way you do in Java

scala> val whereami = System.getProperty("user.dir")
whereami: java.lang.String = /tmp

http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperties()

Charles F. Munat wrote:
> How does one determine the current directory in Scala? Dumb question,
> I know, but this is the sort of thing you can search for for hours. I
> presume it's Java, not Scala. Anyone know this off the top of his/her
> head?
>
> Thanks.
>
> Chas.
>

--
Tony Morris
http://tmorris.net/

Re: Current directory

2009-11-23T16:45:19Z

scala> new java.io.File(".").getAbsolutePath

res1: java.lang.String = C:\Users\Naftoli\.

scala> new java.io.File(".").getCanonicalPath

res2: java.lang.String = C:\Users\Naftoli

On Mon, Nov 23, 2009 at 7:41 PM, Stepan Koltsov <stepancheg@...> wrote:

new File(".").getAbsolutePath()

S.

On Tue, Nov 24, 2009 at 03:33, Charles F. Munat <chas@...> wrote:
> How does one determine the current directory in Scala? Dumb question, I
> know, but this is the sort of thing you can search for for hours. I presume
> it's Java, not Scala. Anyone know this off the top of his/her head?

Re: Current directory

2009-11-23T16:41:53Z

new File(".").getAbsolutePath()

S.

On Tue, Nov 24, 2009 at 03:33, Charles F. Munat <chas@...> wrote:
> How does one determine the current directory in Scala? Dumb question, I
> know, but this is the sort of thing you can search for for hours. I presume
> it's Java, not Scala. Anyone know this off the top of his/her head?

Re: Current directory

2009-11-23T16:37:28Z

Don't know if it's the best way, but try new File(".").getCanonicalPath().

On Mon, Nov 23, 2009 at 7:33 PM, Charles F. Munat <chas@...> wrote:

How does one determine the current directory in Scala? Dumb question, I know, but this is the sort of thing you can search for for hours. I presume it's Java, not Scala. Anyone know this off the top of his/her head?

Thanks.

Chas.

Current directory

2009-11-23T16:33:10Z

How does one determine the current directory in Scala? Dumb question, I
know, but this is the sort of thing you can search for for hours. I
presume it's Java, not Scala. Anyone know this off the top of his/her head?

Thanks.

Chas.

Re: Re: swing.TextField generates EditDone event when losing focus

2009-11-23T15:22:38Z

You need to listenTo(textField.keys). This is one of the unfortunate points of the publisher/reactor design. In order to make things more efficient, components do not publish all events themselves. See Component.mouse, Component.keys and ListView.selection for examples. Also look into the test package which is part of the scala.swing distribution, do a grep, and you may find what you need. For your specific case, there is the painting demo (not in 2.7.x I believe but in 2.8/trunk) which also reacts to key events.

Ingo

On Mon, Nov 23, 2009 at 12:33 PM, nikolaj lindberg <nikolaj.lindberg@...> wrote:

On Mon, Nov 23, 2009 at 7:40 PM, Ingo Maier <ingoem@...> wrote:

Ken was referring to the KeyTyped event, not the ValueChanged event. The latter won't trigger since typing enter does not change the text field's contents.

Hope this helps,

Ingo

Ingo,

thanks.

Hmm... I still don't see any KeyTyped events generated by the TextField.
I must be doing something really stupid, but I just get those ValueChanged events.

When I run the code below (Scala 2.8), and input characters into the TextField, all that's printed are ValueChanged events.

What am I doing wrong, and how do I catch those KeyTyped events? (I'm beginning to fear that I'm missing some fundamental clue here...)

/nikolaj

//------------------------------------------------------------------

import swing._
import event._

object tst extends MainFrame {

val textField = new TextField(20)
contents = textField
listenTo(textField)
reactions += {case e =>
println(e)
println()

}

pack
visible = true

def main(args: Array[String]) {}
}

On Sun, Nov 22, 2009 at 9:16 AM, nikolaj lindberg <nikolaj.lindberg@...> wrote:

On Sun, Nov 22, 2009 at 6:00 PM, Ken Bloom <kbloom@...> wrote:

On Wed, 18 Nov 2009 18:52:52 +0100, nikolaj lindberg wrote:

[...]

> How do I know what EditDone events are generated by typing <enter> and
> not by the TextField component losing focus? Any hints are welcome!

You probably want a KeyTyped event to look specifically for the Enter key.

Hi Ken,

yes, I would love one of those, but the Enter key seems to only generate the EditDone event (and not a ValueChanged event, like when entering an "ordinary" character).

/nikolaj

--

Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

Re: Re: Nesting alternative parser combinators

2009-11-23T15:09:51Z

Hi Pavol,

I'm glad you found my mail useful.

- the \z took me a moment to figure out, it turns out to be the Java

regex syntax for end of file

- I agree that the error reporting behaviour of phrase is unclear,

at least it should be described in the ScalaDoc. The choice of

reporting the last no success is somewhat arbitrary but arguably

more useful than just saying 'end of input expected'. Perhaps a

better situation would be to do both.

cheers,

Tony

On 23/11/2009, at 5:49 PM, Pavol Vaskovic wrote:

Thank you very much for explanation. Now I understand.

I have encountered the same problem before, but did not realize, it is the same problem. By same problem, I mean the parser itself succeeds, but the parseAll fails due to remaining unparsed input. The error message was then "`\z' expected but ..." which pointed me to look up in the combination tree, because I had no `\z' in my part of the grammar.

Now it did not occur to me, that 'Y' was succeeding, I was expecting the `\z' message for that case. I guess this is another instance of [scala-user] Confusing parsing combinator errors.

The way how parseAll chooses the error to report does not make sense to me. I see no correlation between the reported failure of an unsuccessful parser that
consumed most of the input before failing and the real error in this case - expected end of input (`\z'), but `-' found. In effect, it is choosing arbitrary previous error message, that hides the true nature of the problem - the topmost user-defined parser _succeeded_, but there was input still left.

Regards
Pavol Vaskovic

On Mon, Nov 23, 2009 at 5:16 AM, Tony Sloane <inkytonik@...> wrote:

Hi Pavol,

BNF semantics is not quite right for this kind of parser. Significant
differences are that alternative order and backtracking behaviour
matter for the alternation combinator but are not really defined for
BNF.

It appears to me that your pY parser works because phrase(X) cannot
succeed (since it doesn't consume all of the input). Hence the second

alternative of pY is chosen and succeeds.

For the Y variant, X actually succeeds since a prefix of the input is
"K", which is a KD, which is an X. Hence Y succeeds. But the next

level up (parseAll (Y, ...)) doesn't succeed, since some of the input
has not been consumed.  It is too late to backtrack into the second
alternative of Y at that point though, since Y has already succeeded.

I think the error you are seeing:

[1.3] failure: `D' expected but `O' found

K-O#1
^

is reported because the phrase combinator (used by parseAll) reports
the last unsuccessful parse (see lastNoSuccess var in Parsers class),
where "last" refers to latest in the input. This makes sense because

that error is the likely cause of the parser not consuming the entire
input. In your case, the most recent unsuccessful parse is the
failure in the K ~ ("-" ~> D) alternative of KD on the D, hence the

error. (There is also a failure in the KD ~ ("#" ~> num) alternative
of X that happens later in time but at an earlier position in the
input (on the "-", expecting a "#"), so it is not preferred.)

Whew! This stuff can be tricky to reason about, but I hope this helps
clarify what is going on.

cheers,
Tony

On 23/11/2009, at 11:54 AM, Pavol Vaskovic wrote:

I've removed the partial function applications from the test case, because they were not affecting the results. This is even simpler demonstration of behavior I can not explain:

object Test extends util.parsing.combinator.RegexParsers {
override val whiteSpace = "".r

def letter = "[A-Z]".r
def lettersAndDash = "[-A-Z]+".r
def num = "[1-9]".r

def pY = phrase(X) | lettersAndDash ~ ("#" ~> num)
def Y = X | lettersAndDash ~ ("#" ~> num)

def X = KD ~ ("#" ~> num) | KD

def KD = K ~ ("-" ~> D) | K

def K = "K"
def D = "D"

def main(args: Array[String]) {
    println(parseAll(Y, "K-O#1"))
    println(parseAll(pY, "K-O#1"))
}
}

Why am I getting the following?
[1.3] failure: `D' expected but `O' found

K-O#1
^
[1.6] parsed: (K-O~1)

Nesting alternatives third time, triggers the failure.
(Commenting out "| KD" in def X or "| K" in def KD causes the Y to parse with " | lettersAndDash ~ ("#" ~> num)".) Why exactly does wrapping the X in phrase make this case work?

This seems like a dangerous pitfall, when using parser combinators naively (assuming EBNF semantics), as I do.
Why does it behave like this? Why doesn't "b ~ c | b" behave same as "b ~ opt(c)"?
Thanks in advance for bringing some light on this issue.

Regards
Pavol Vaskovic

On Thu, Nov 19, 2009 at 2:05 PM, Pavol Vaskovic <pali@...> wrote:

I'm parsing addresses in semi-structured format. I've created a grammar that behaves strange, and I am unable to explain what is going on.

I have been avoiding the use of opt method for wrapping optional parts of grammar, because it complicated the return signatures too much. Instead I was using alternative composition with longer variant first.

Instead of:
def a = b ~ opt(c)

I'm using:
def a = b ~ c | b

When I nest such rules, they start to behave surprisingly - seems like the alternatives are never tried.

Re: Re: swing.TextField generates EditDone event when losing focus

2009-11-23T12:33:42Z

On Mon, Nov 23, 2009 at 7:40 PM, Ingo Maier <ingoem@...> wrote:

Ken was referring to the KeyTyped event, not the ValueChanged event. The latter won't trigger since typing enter does not change the text field's contents.

Hope this helps,

Ingo

Ingo,

thanks.

Hmm... I still don't see any KeyTyped events generated by the TextField.
I must be doing something really stupid, but I just get those ValueChanged events.

When I run the code below (Scala 2.8), and input characters into the TextField, all that's printed are ValueChanged events.

What am I doing wrong, and how do I catch those KeyTyped events? (I'm beginning to fear that I'm missing some fundamental clue here...)

/nikolaj

//------------------------------------------------------------------
import swing._
import event._

object tst extends MainFrame {

val textField = new TextField(20)
contents = textField
listenTo(textField)
reactions += {case e =>
println(e)
println()
}

pack
visible = true

def main(args: Array[String]) {}
}

On Sun, Nov 22, 2009 at 9:16 AM, nikolaj lindberg <nikolaj.lindberg@...> wrote:

On Sun, Nov 22, 2009 at 6:00 PM, Ken Bloom <kbloom@...> wrote:

On Wed, 18 Nov 2009 18:52:52 +0100, nikolaj lindberg wrote:

[...]

> How do I know what EditDone events are generated by typing <enter> and
> not by the TextField component losing focus? Any hints are welcome!

You probably want a KeyTyped event to look specifically for the Enter key.

Hi Ken,

yes, I would love one of those, but the Enter key seems to only generate the EditDone event (and not a ValueChanged event, like when entering an "ordinary" character).

/nikolaj

--

Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

Re: Re: Java Parser in Scala avalable ?

2009-11-23T12:06:09Z

Thanks everyone for all the feedback.

I will certainly have a look at the eclipse links that you have provided. Meanwhile, I also found this interesting thread that calls visitors to the AST : http://dev.eclipse.org/mhonarc/newsLists/news.eclipse.tools.jdt/msg24263.html

Cheers,
Manohar

On Mon, Nov 23, 2009 at 3:16 AM, Peter C. Chapin <pcc482719@...> wrote:

Manohar Jonnalagedda
<manojo10386@...> wrote in
news%3Ad17eedc90911221707n4be9c9d0q4e63245c67eb2b92@...:

> I am working in a project where I would be needing to analyse Java
> code, and have therefore started to work on a parser for Java. The
> size of the grammar being immense however, before going deeper, I was
> wondering if anyone had attempted a similar (futile ?) feat, and if
> there was some code available in the public domain I could find ?

Since Scala can easily call Java code, you might also find what you need in
Java somewhere. I'm working on a project where I needed a parser for the
nesC programming language. I used ANTLR to create the parser in Java and
then used the result from my Scala program.

Peter

Re: _|_ vs null (Was Re: Cost of Option / Some vs null)

2009-11-23T10:59:31Z

Babylonians didn't fully develop division (i.e. they didn't fully work out the idea of multiplicative inverse and come up with methods for representing such things to arbitrary precision). So for them (1/7) was a problem. They did create tables of exact multiplicative inverses, though, along with approximations for the ones that didn't have exact inverses (and they recognized that those were just approximations).

These days, to split a meter into thirds, it's (1/3) meters--just leave it as a rational number! Convert (1/3) or whatever you end up with into decimal to the desired number of significant figures as the last step. Not so hard!

Of course, it would be easier still to divide by 3 if we used base 6 or 12 for counting. (60 is too much of a hassle, since your addition table has ~900 entries in it, which is hard to memorize.)

--Rex

On Mon, Nov 23, 2009 at 1:40 PM, Kevin Wright <kev.lee.wright@...> wrote:

Yeah, base 60 is fun, divisible by so many other useful integers. Same
logic applies to base 12; try and easily split a meter into thirds,
then do the same with a foot.

On Monday, November 23, 2009, Ishaaq Chandy <ishaaq@...> wrote:

> In fact, in all this, the people that really shine out were the Babylonians - the mathematical discoveries they made 4000 years ago were unmatched for their time! The stuff they discovered still affects us today - ever wondered why there are 60 seconds to the minute? 360 degrees to form a circle?
>

Re: _|_ vs null (Was Re: Cost of Option / Some vs null)

2009-11-23T10:40:42Z

Yeah, base 60 is fun, divisible by so many other useful integers. Same
logic applies to base 12; try and easily split a meter into thirds,
then do the same with a foot.

On Monday, November 23, 2009, Ishaaq Chandy <ishaaq@...> wrote:

> Amen brother! No argument there. That is what I implied when I previously pointed out that the Arabs have a myriad achievements to their credit. And yes, as you point out, so do the Greeks, the Chinese, the Europeans etc. I was merely pointing out a factual error that was made about the history of zero, nothing more, nothing less.
>
> In fact, in all this, the people that really shine out were the Babylonians - the mathematical discoveries they made 4000 years ago were unmatched for their time! The stuff they discovered still affects us today - ever wondered why there are 60 seconds to the minute? 360 degrees to form a circle?
>
> Cheers,
> Ishaaq
>
> 2009/11/23 Kevin Wright <kev.lee.wright@... <javascript:_e({}, 'cvml', 'kev.lee.wright@...');>>
>
>
> But at the other end of the spectrum; I think that Europeans+Russians fairly got infinity, the proper formalised aleph-zero stuff, not just ∞ (Cantor was German, but born in Russia)
>
> Or if you just want to get very-very-very close to zero then we have Newton and Leibniz to thank for infinitesimals and differential calculus
>
> Recent research has shown that traditional African villages have been built around a fractal structure for, well, a very long time.
>
>
> There's a lot to be said for the famous "standing on the shoulders of giants" quote. Mathematics is truly global and is built from the work of a great many people scattered across the globe.
>
>
>
>
>
> On Mon, Nov 23, 2009 at 11:02 AM, Ishaaq Chandy <ishaaq@...> wrote:
>
>
>
> Ok, at the risk of irritating every one else on this mailing list - I'll take the bait and continue this off-topic conversation with one last post.
>
> Please back your claims with references. You statements may be true, but they need to be backed with documentation to be believable.
>
> Zero has had a long and convoluted history pre-dating the Indians, but the first *documented* instance of using the decimal system (which is based on the concept of using zeroes to denote place-holders to denote magnitude) as well as treating zero as a number in its own right is of Indian origin: http://en.wikipedia.org/wiki/Zero#History
>
> According to that wiki page the Chinese had a non-formalised concept of zero in the first century (not first by a long shot, the Babylonians win there again - 2nd millennium BCE! - followed by a number of other civilizations before the Chinese got to it), and that their first formalised documented instance of using zero as we do now was in 1247 CE. I concede that not everyone may consider wikipedia as a legitimate source, however it is not alone in making this claim, and it is the easiest one I could search and link to in an email like this. If you have documented evidence contradicting this please do share.
>
> Ishaaq
>
> 2009/11/23 De Gao <gaode.ml@...>
>
>
>
>
>
>
>
>
>
>
>
>
> add some fun: about 3500 yrs ago
> chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU
> did was just invent how to write numbers in a simple way
>
>
>
>
>
> De
> Gao
> 2009-11-23
>
>
>
> 发件人： Philip
> Köster
> 发送时间：
> 2009-11-21 23:22:08
> 收件人： Ishaaq
> Chandy
> 抄送： Moez A. Abdel-Gawad;
> Scala User List
> 主题： Re: _|_ vs null (Was
> Re: [scala-user] Cost of Option / Some vs null)
>
>
> To possibly take some strength out of this discussion---none of us lived
> 4000 yrs ago, so we really don't know---, I'm always surprised to see
> that even the Chinese and Japanese and Hindu folks adopted ``our"
> numbers. They must have been a good invention. :)
>
> Ishaaq Chandy schrieb:
>> We'll just have to agree to disagree - even though the vast majority of
>> literature on the topic (including the Encyclopaedia Britannica - which
>> you were so quick to quote) agree with what I said: i.e. the decimal
>> number system, with zero as a place-holder denoting magnitude was an
>> Indian inve
>

Re: Re: swing.TextField generates EditDone event when losing focus

2009-11-23T10:40:13Z

Ken was referring to the KeyTyped event, not the ValueChanged event. The latter won't trigger since typing enter does not change the text field's contents.

Hope this helps,

Ingo

On Sun, Nov 22, 2009 at 9:16 AM, nikolaj lindberg <nikolaj.lindberg@...> wrote:

On Sun, Nov 22, 2009 at 6:00 PM, Ken Bloom <kbloom@...> wrote:

On Wed, 18 Nov 2009 18:52:52 +0100, nikolaj lindberg wrote:

[...]

> How do I know what EditDone events are generated by typing <enter> and
> not by the TextField component losing focus? Any hints are welcome!

You probably want a KeyTyped event to look specifically for the Enter key.

Hi Ken,

yes, I would love one of those, but the Enter key seems to only generate the EditDone event (and not a ValueChanged event, like when entering an "ordinary" character).

/nikolaj

--

Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

Re: ObservableMap

2009-11-23T09:20:30Z

You need to create a class that mixes in ObservableMap and some kind of concrete Map, such as HashMap.

Donna

On Mon, Nov 23, 2009 at 5:53 PM, Daniel Sobral <dcsobral@...> wrote:

How does one go about instantiating an ObservableMap? I have to confess I wasn't able to get the type inferencer to work for me, nor was I able to figure out the right type incantations.

--
Daniel C. Sobral

Veni, vidi, veterni.

status of Manifest

2009-11-23T09:00:24Z

When I had issues with Manifest a while ago I learned the
implementation was not complete at the time.

Will it be complete for 2.8.0? or what is the ETA?

Is there another way to do the following:

def manifestOf[T](implicit m : Manifest[T]) = m

def typeCheck[T](implicit m : Manifest[T]) = (
if (m <:< manifestOf[AnyVal]) "Value"
else if (m <:< manifestOf[AnyRef]) "Reference"
else "???")

Yesterdays nighly still gives:

scala> typeCheck[Int]
res8: java.lang.String = ???

scala> typeCheck[java.lang.Integer]
res5: java.lang.String = Value

scala> typeCheck[java.util.List[java.lang.Integer]]
res6: java.lang.String = ???

Or am I doing something wrong?

thanks
Daniel

ObservableMap

2009-11-23T08:53:19Z

How does one go about instantiating an ObservableMap? I have to confess I wasn't able to get the type inferencer to work for me, nor was I able to figure out the right type incantations.

--
Daniel C. Sobral

Veni, vidi, veterni.

RE: about actor

2009-11-23T06:58:21Z

A single actor processes the items on its mailbox one-at-a-time in the order the items were added to the mailbox *by the relevant partial-function* being used for a given call to receive or react

From: Caesar.Jr@...
To: scala-user@...
Subject: [scala-user] about actor
Date: Mon, 23 Nov 2009 21:15:15 +0800

does the actor process the next message exactly after the first message,

or they can be processed at the same time?

New! Receive and respond to mail from other email accounts from within Hotmail Find out how.

about actor

2009-11-23T06:22:32Z

does the actor process the next message exactly after the first message,

or they can be processed at the same time?

Re: Cost of Option / Some vs null

2009-11-23T05:34:27Z

Erik Engbrecht schrieb:
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw NoSuchElementException
> because foo may be None

And some would argue that you should really write something like
this to avoid all the case matches and if/else constructs:

scala> def addFive(foo: Option[Int]) = foo map (_ + 5)
addFive: (Option[Int])Option[Int]

scala> addFive(None)
res0: Option[Int] = None

scala> addFive(Some(4))
res1: Option[Int] = Some(9)

This works equally well for Tony's Optionn:

scala> def addFiveN(foo: Optionn[Int]) = foo map (_ + 5)
addFiveN: (Optionn[Int])java.lang.Object with Optionn[Int]

scala> object NoneN extends Optionn[Nothing] {
| def cata[X](ding: Nothing => X, dong: => X) = dong
| }
defined module NoneN

scala> class SomeN[T](x: T) extends Optionn[T] {
| def cata[X](ding: T => X, dong: => X) = ding(x)
| }
defined class SomeN

scala> addFiveN(NoneN) cata (x => "SomeN(" + x.toString + ")", "NoneN")
res16: java.lang.String = NoneN

scala> addFiveN(new SomeN(4)) cata (x => "SomeN(" + x.toString + ")", "NoneN")
res17: java.lang.String = SomeN(9)

- Florian

about actor

2009-11-23T05:15:15Z

does the actor process the next message exactly after the first message,

or they can be processed at the same time?

Re: Re: Nesting alternative parser combinators

2009-11-23T05:13:05Z

Let me thank you too, Tony. In particular, I never really understood "phrase" until now.

On Mon, Nov 23, 2009 at 4:49 AM, Pavol Vaskovic <pali@...> wrote:

Hi Tony,

Thank you very much for explanation. Now I understand.

I have encountered the same problem before, but did not realize, it is the same problem. By same problem, I mean the parser itself succeeds, but the parseAll fails due to remaining unparsed input. The error message was then "`\z' expected but ..." which pointed me to look up in the combination tree, because I had no `\z' in my part of the grammar.

Now it did not occur to me, that 'Y' was succeeding, I was expecting the `\z' message for that case. I guess this is another instance of [scala-user] Confusing parsing combinator errors.

The way how parseAll chooses the error to report does not make sense to me. I see no correlation between the reported failure of an unsuccessful parser that
consumed most of the input before failing and the real error in this case - expected end of input (`\z'), but `-' found. In effect, it is choosing arbitrary previous error message, that hides the true nature of the problem - the topmost user-defined parser _succeeded_, but there was input still left.

Regards
Pavol Vaskovic

On Mon, Nov 23, 2009 at 5:16 AM, Tony Sloane <inkytonik@...> wrote:

Hi Pavol,

BNF semantics is not quite right for this kind of parser. Significant

differences are that alternative order and backtracking behaviour

matter for the alternation combinator but are not really defined for

BNF.

It appears to me that your pY parser works because phrase(X) cannot

succeed (since it doesn't consume all of the input). Hence the second

alternative of pY is chosen and succeeds.

For the Y variant, X actually succeeds since a prefix of the input is

"K", which is a KD, which is an X. Hence Y succeeds. But the next

level up (parseAll (Y, ...)) doesn't succeed, since some of the input

has not been consumed.  It is too late to backtrack into the second

alternative of Y at that point though, since Y has already succeeded.

I think the error you are seeing:

[1.3] failure: `D' expected but `O' found

K-O#1
^

is reported because the phrase combinator (used by parseAll) reports

the last unsuccessful parse (see lastNoSuccess var in Parsers class),

where "last" refers to latest in the input. This makes sense because

that error is the likely cause of the parser not consuming the entire

input. In your case, the most recent unsuccessful parse is the

failure in the K ~ ("-" ~> D) alternative of KD on the D, hence the

error. (There is also a failure in the KD ~ ("#" ~> num) alternative

of X that happens later in time but at an earlier position in the

input (on the "-", expecting a "#"), so it is not preferred.)

Whew! This stuff can be tricky to reason about, but I hope this helps

clarify what is going on.

cheers,

Tony

On 23/11/2009, at 11:54 AM, Pavol Vaskovic wrote:

I've removed the partial function applications from the test case, because they were not affecting the results. This is even simpler demonstration of behavior I can not explain:

object Test extends util.parsing.combinator.RegexParsers {
override val whiteSpace = "".r

def letter = "[A-Z]".r
def lettersAndDash = "[-A-Z]+".r
def num = "[1-9]".r

def pY = phrase(X) | lettersAndDash ~ ("#" ~> num)
def Y = X | lettersAndDash ~ ("#" ~> num)

def X = KD ~ ("#" ~> num) | KD

def KD = K ~ ("-" ~> D) | K

def K = "K"
def D = "D"

def main(args: Array[String]) {
    println(parseAll(Y, "K-O#1"))
    println(parseAll(pY, "K-O#1"))
}
}

Why am I getting the following?
[1.3] failure: `D' expected but `O' found

K-O#1
^
[1.6] parsed: (K-O~1)

Nesting alternatives third time, triggers the failure.
(Commenting out "| KD" in def X or "| K" in def KD causes the Y to parse with " | lettersAndDash ~ ("#" ~> num)".) Why exactly does wrapping the X in phrase make this case work?

This seems like a dangerous pitfall, when using parser combinators naively (assuming EBNF semantics), as I do.
Why does it behave like this? Why doesn't "b ~ c | b" behave same as "b ~ opt(c)"?
Thanks in advance for bringing some light on this issue.

Regards
Pavol Vaskovic

On Thu, Nov 19, 2009 at 2:05 PM, Pavol Vaskovic <pali@...> wrote:

I'm parsing addresses in semi-structured format. I've created a grammar that behaves strange, and I am unable to explain what is going on.

I have been avoiding the use of opt method for wrapping optional parts of grammar, because it complicated the return signatures too much. Instead I was using alternative composition with longer variant first.

Instead of:
def a = b ~ opt(c)

I'm using:
def a = b ~ c | b

When I nest such rules, they start to behave surprisingly - seems like the alternatives are never tried.

--
Daniel C. Sobral

Veni, vidi, veterni.

Re: Re: _|_ vs null (Was Re: Cost of Option / Some vs null)

2009-11-23T05:07:07Z

Amen brother! No argument there. That is what I implied when I previously pointed out that the Arabs have a myriad achievements to their credit. And yes, as you point out, so do the Greeks, the Chinese, the Europeans etc. I was merely pointing out a factual error that was made about the history of zero, nothing more, nothing less.

In fact, in all this, the people that really shine out were the Babylonians - the mathematical discoveries they made 4000 years ago were unmatched for their time! The stuff they discovered still affects us today - ever wondered why there are 60 seconds to the minute? 360 degrees to form a circle?

Cheers,
Ishaaq

2009/11/23 Kevin Wright <kev.lee.wright@...>

But at the other end of the spectrum; I think that Europeans+Russians fairly got infinity, the proper formalised aleph-zero stuff, not just ∞ (Cantor was German, but born in Russia)

Or if you just want to get very-very-very close to zero then we have Newton and Leibniz to thank for infinitesimals and differential calculus

Recent research has shown that traditional African villages have been built around a fractal structure for, well, a very long time.

There's a lot to be said for the famous "standing on the shoulders of giants" quote. Mathematics is truly global and is built from the work of a great many people scattered across the globe.

On Mon, Nov 23, 2009 at 11:02 AM, Ishaaq Chandy <ishaaq@...> wrote:
Ok, at the risk of irritating every one else on this mailing list - I'll take the bait and continue this off-topic conversation with one last post.

Please back your claims with references. You statements may be true, but they need to be backed with documentation to be believable.

Zero has had a long and convoluted history pre-dating the Indians, but the first *documented* instance of using the decimal system (which is based on the concept of using zeroes to denote place-holders to denote magnitude) as well as treating zero as a number in its own right is of Indian origin: http://en.wikipedia.org/wiki/Zero#History

According to that wiki page the Chinese had a non-formalised concept of zero in the first century (not first by a long shot, the Babylonians win there again - 2nd millennium BCE! - followed by a number of other civilizations before the Chinese got to it), and that their first formalised documented instance of using zero as we do now was in 1247 CE. I concede that not everyone may consider wikipedia as a legitimate source, however it is not alone in making this claim, and it is the easiest one I could search and link to in an email like this. If you have documented evidence contradicting this please do share.

Ishaaq

2009/11/23 De Gao <gaode.ml@gmail.com>

add some fun: about 3500 yrs ago chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU did was just invent how to write numbers in a simple way

De Gao

2009-11-23

发件人： Philip Köster

发送时间： 2009-11-21 23:22:08

收件人： Ishaaq Chandy

抄送： Moez A. Abdel-Gawad; Scala User List

主题： Re: _|_ vs null (Was Re: [scala-user] Cost of Option / Some vs null)

To possibly take some strength out of this discussion---none of us lived

4000 yrs ago, so we really don't know---, I'm always surprised to see

that even the Chinese and Japanese and Hindu folks adopted ``our"

numbers. They must have been a good invention. :)

Ishaaq Chandy schrieb:

> We'll just have to agree to disagree - even though the vast majority of

> literature on the topic (including the Encyclopaedia Britannica - which

> you were so quick to quote) agree with what I said: i.e. the decimal

> number system, with zero as a place-holder denoting magnitude was an

> Indian invention.

>

> ... and yes I already knew the word "Algebra" is rooted from an Arab

> word - that does not mean they invented the discipline - that honour

> belongs to the ancient Babylonians (almost 4000 years ago!) - refined by

> the Greeks and the Indians before the Arabs got hold of it.

> (http://en.wikipedia.org/wiki/Timeline_of_algebra)

>

> I'm not belittling the myriad achievements of the Arabs - far from it,

> they were essential to the history of Mathematics, but please don't

> miss-attribute stuff.

>

> Ishaaq

>

> PS - and no, modern Indians do not call their numerals "Arab numerals",

> I know, because I am one of them :)  - "Arab numerals" is western

> nomenclature.

>

> 2009/11/22 Moez A. Abdel-Gawad <moez@... <mailto:moez@...>>

>

>     Ishaaq,

>

>

>     You wrote:

>      > Slightly off topic, but the Arabs got the concept of zero from the

>      > Indians - the Arabs then introduced it to the western world.

>      >

>

>     That is a myth that is trying - by some well-intentioned people? -

>     to be created/spread.

>

>     Arabs may have borrowed other digits (ie, their shapes) from India

>     (not a 100% sure fact either) but they have NOT borrowed 0.  They

>     invented it, because they were the center of scientific research

>     then, and they simply needed it. Without it, math - as they had

>     (possibly) borrowed it from the Indians - would make much less

>     sense.  That's to the best of my knowledge/research on this

>     off-topic historical point.

>

>     Also, note that even *Indians* of today do call numerals we use

>     'Arabic numerals', because they - digits we/Arabs - use/used *look

>     different* from ones they have/had (check TUG India and their TeX

>     Tutorial, for example).

>

>     Finally, you may also like to check the 'Islamic Mathematics'

>     article, on Encyclopedia Britannica (despite some of its

>     misinformation about Islam), for getting more info about the

>     numerous contributions made by Arabs and Muslims to the fundamentals

>     of Mathematics (should I mention where the word 'Algebra' came from?).

>

>     Now...

>

>     Tony,

>

>     Are your responses an attempt to let ignorance - or misinformation -

>     reign, among Scala users??  I hope not.

>

>     I've *studied* Peirce's TAPL (as it is commonly abbreviated), years

>     ago! It is not The Qur'an, or a Bible, that has to believed in its

>     totality, and without questioning.  TAPL has some fundamental

>     criticisms against it.

>

>     Relevant to our discussion is the fact/criticism that TAPL is too

>     syntactic, and rarely discusses (mathematical) semantics. Saying

>     this, I also recognize it is VERY HARD for people who are not

>     familiar much with PL semantics (particularly Domain Theory, and

>     denotational semantics) to realize TAPL's "syntactic-ness".

>

>     I thus suggest YOU first read more, in PL semantics, particularly

>     Dana Scott seminal work (for which he was awarded the Turing Award

>     [the "Nobel Prize" of CS], and Gordon Plotkin and Cardelli's

>     important work on PL semantics, before talking about _|_ (and

>     wrongly associating it with 'null').

>

>     And please remember: I was once - at the time of that discussion I

>     had with Corky - in your shoes.  Corky then helped me, a lot, to

>     realize the distinction you are now still unable to make.

>

>     So, finally, please be careful before you talk, specially on a

>     mailing list with so many members.  It is only because I am sure of

>     my main premises, backed by Corky's opinion, that I sent to this

>     mailing list (I usually do not follow it/send to it much).  I - and

>     you? - should not want to MISGUIDE the nice people on this list who

>     are looking for sure and true information, right?

>

>     -Moez

>

>     PS: For the one who asked how can the (simple) program that squares

>     its input non-terminate, I think you missed my point (I also

>     suggest, if possible, studying semantics). My point is a GENERAL

>     one, about all possible computations, not a (your) specific one. My

>     point is that if you want ANY programming language to be *useful* it

>     HAS to allow the possibility of non-termination.  That is a

>     consequence of the halting-problem & the Church-Turing thesis, if I

>     recall correctly and properly understand them.  Non-termination

>     ("giving an answer, but at time infinity!") ALWAYS has to be in our

>     (programmers') minds if we want to write any useful general software

>     (as defined by Church's lambda calculus and Turing's Turing

>     machines).  My point is, thus, sort of a "meta"-statement, about all

>     useful programs we can write, not a statement/point about a specific

>     program.

>

>     PS2: Even though I find it exciting, I apologize if I may not

>     continue this discussion further. I have too much other stuff on my

>     plate that needs my immediate attention and time.

>

>

>     Tony Morris wrote:

>      > I strongly recommend Types and Programming Languages by Benjamin

>     Pierce.

>      >

>      > Tony Morris wrote:

>      >> Moez A. Abdel-Gawad wrote:

>      >>

>      >>> Tony Morris wrote:

>      >>>

>      >>>> 0 exists. null represents "that which does not exist." In

>     computational

>      >>>> theory, what null represents is more commonly called bottom, _|_,

>      >>>> undefined, non-terminating computation, logical absurdity. In

>      >>>>

>      >>> philosophy

>      >>>

>      >>>> it is sometimes called "not even false."

>      >>>>

>      >>>>

>      >>> That's not true.

>      >>>

>      >>> Me and Corky (Prof. Robert Cartwright, my PhD advisor)

>     discussed this

>      >>> once while discussing Domain Theory (the "Math of Computing", upon

>      >>> which my PhD thesis is based).  We reached the conclusion that

>      >>> non-termination is just, well, non-termination. It can NOT be

>      >>> eliminated from computation.  Null, on the other hand *exists*,

>     as a

>      >>> genuine real but unusual/ exceptional/ unexpected value.  It

>     should,

>      >>> formally speaking, be added to each type that needs one such value

>      >>> (some don't), or forced on them by belonging to a

>      >>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a

>      >>> subclass) of all types (classes). 'null' - just like all regular

>      >>> values - can be got ridden of (is not absolutely essential).  _|_

>      >>> (bottom)/non-termination is absolutely essential to the nature of

>      >>> computation, and cannot be got ridden of.

>      >>>

>      >> It's true. You may not realise it but you contradicted yourself.

>      >> Non-termination must exist in Scala, therefore, it must be

>     represented.

>      >> You said this yourself.

>      >>

>      >> Pattern matching will never be exhaustive, the error function is

>     of type

>      >> forall A. A (which is a LIE!), and (wait for it) null exists. Null

>      >> represents that which does not exist and that is the extent of its

>      >> existence. In a language with different syntax, you might consider

>      >> calling it _|_. The null value is a value has the type forall A.

>     A. This

>      >> is not a theorem. It represents bottom, non-termination,

>     undefinedness,

>      >> logical absurdity. That is what null is. I recommend you try

>     again with

>      >> Corky. You buggered up.

>      >>

>      >>

>      >>>> Philip Köster wrote:

>      >>>>

>      >>>>> Discovering the `0' was what separated the Arabians from the

>     Romans.

>      >>>>>

>      >>>>>

>      >>> 'Arabs', you mean.

>      >>>

>      >>> One day we used to teach the world.  We hope one day soon we would

>      >>> again!  :)

>      >>>

>      >>> -Moez

>      >>>

>      >>>

>      >>

>      >

>

>

Re: Re: _|_ vs null (Was Re: Cost of Option / Some vs null)

2009-11-23T03:21:13Z

But at the other end of the spectrum; I think that Europeans+Russians fairly got infinity, the proper formalised aleph-zero stuff, not just ∞ (Cantor was German, but born in Russia)

Or if you just want to get very-very-very close to zero then we have Newton and Leibniz to thank for infinitesimals and differential calculus

Recent research has shown that traditional African villages have been built around a fractal structure for, well, a very long time.

There's a lot to be said for the famous "standing on the shoulders of giants" quote. Mathematics is truly global and is built from the work of a great many people scattered across the globe.

On Mon, Nov 23, 2009 at 11:02 AM, Ishaaq Chandy <ishaaq@...> wrote:

Ok, at the risk of irritating every one else on this mailing list - I'll take the bait and continue this off-topic conversation with one last post.

Please back your claims with references. You statements may be true, but they need to be backed with documentation to be believable.

Zero has had a long and convoluted history pre-dating the Indians, but the first *documented* instance of using the decimal system (which is based on the concept of using zeroes to denote place-holders to denote magnitude) as well as treating zero as a number in its own right is of Indian origin: http://en.wikipedia.org/wiki/Zero#History

According to that wiki page the Chinese had a non-formalised concept of zero in the first century (not first by a long shot, the Babylonians win there again - 2nd millennium BCE! - followed by a number of other civilizations before the Chinese got to it), and that their first formalised documented instance of using zero as we do now was in 1247 CE. I concede that not everyone may consider wikipedia as a legitimate source, however it is not alone in making this claim, and it is the easiest one I could search and link to in an email like this. If you have documented evidence contradicting this please do share.

Ishaaq

2009/11/23 De Gao <gaode.ml@gmail.com>

add some fun: about 3500 yrs ago chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU did was just invent how to write numbers in a simple way

De Gao

2009-11-23

发件人： Philip Köster

发送时间： 2009-11-21 23:22:08

收件人： Ishaaq Chandy

抄送： Moez A. Abdel-Gawad; Scala User List

主题： Re: _|_ vs null (Was Re: [scala-user] Cost of Option / Some vs null)

To possibly take some strength out of this discussion---none of us lived

4000 yrs ago, so we really don't know---, I'm always surprised to see

that even the Chinese and Japanese and Hindu folks adopted ``our"

numbers. They must have been a good invention. :)

Ishaaq Chandy schrieb:

> We'll just have to agree to disagree - even though the vast majority of

> literature on the topic (including the Encyclopaedia Britannica - which

> you were so quick to quote) agree with what I said: i.e. the decimal

> number system, with zero as a place-holder denoting magnitude was an

> Indian invention.

>

> ... and yes I already knew the word "Algebra" is rooted from an Arab

> word - that does not mean they invented the discipline - that honour

> belongs to the ancient Babylonians (almost 4000 years ago!) - refined by

> the Greeks and the Indians before the Arabs got hold of it.

> (http://en.wikipedia.org/wiki/Timeline_of_algebra)

>

> I'm not belittling the myriad achievements of the Arabs - far from it,

> they were essential to the history of Mathematics, but please don't

> miss-attribute stuff.

>

> Ishaaq

>

> PS - and no, modern Indians do not call their numerals "Arab numerals",

> I know, because I am one of them :)  - "Arab numerals" is western

> nomenclature.

>

> 2009/11/22 Moez A. Abdel-Gawad <moez@... <mailto:moez@...>>

>

>     Ishaaq,

>

>

>     You wrote:

>      > Slightly off topic, but the Arabs got the concept of zero from the

>      > Indians - the Arabs then introduced it to the western world.

>      >

>

>     That is a myth that is trying - by some well-intentioned people? -

>     to be created/spread.

>

>     Arabs may have borrowed other digits (ie, their shapes) from India

>     (not a 100% sure fact either) but they have NOT borrowed 0.  They

>     invented it, because they were the center of scientific research

>     then, and they simply needed it. Without it, math - as they had

>     (possibly) borrowed it from the Indians - would make much less

>     sense.  That's to the best of my knowledge/research on this

>     off-topic historical point.

>

>     Also, note that even *Indians* of today do call numerals we use

>     'Arabic numerals', because they - digits we/Arabs - use/used *look

>     different* from ones they have/had (check TUG India and their TeX

>     Tutorial, for example).

>

>     Finally, you may also like to check the 'Islamic Mathematics'

>     article, on Encyclopedia Britannica (despite some of its

>     misinformation about Islam), for getting more info about the

>     numerous contributions made by Arabs and Muslims to the fundamentals

>     of Mathematics (should I mention where the word 'Algebra' came from?).

>

>     Now...

>

>     Tony,

>

>     Are your responses an attempt to let ignorance - or misinformation -

>     reign, among Scala users??  I hope not.

>

>     I've *studied* Peirce's TAPL (as it is commonly abbreviated), years

>     ago! It is not The Qur'an, or a Bible, that has to believed in its

>     totality, and without questioning.  TAPL has some fundamental

>     criticisms against it.

>

>     Relevant to our discussion is the fact/criticism that TAPL is too

>     syntactic, and rarely discusses (mathematical) semantics. Saying

>     this, I also recognize it is VERY HARD for people who are not

>     familiar much with PL semantics (particularly Domain Theory, and

>     denotational semantics) to realize TAPL's "syntactic-ness".

>

>     I thus suggest YOU first read more, in PL semantics, particularly

>     Dana Scott seminal work (for which he was awarded the Turing Award

>     [the "Nobel Prize" of CS], and Gordon Plotkin and Cardelli's

>     important work on PL semantics, before talking about _|_ (and

>     wrongly associating it with 'null').

>

>     And please remember: I was once - at the time of that discussion I

>     had with Corky - in your shoes.  Corky then helped me, a lot, to

>     realize the distinction you are now still unable to make.

>

>     So, finally, please be careful before you talk, specially on a

>     mailing list with so many members.  It is only because I am sure of

>     my main premises, backed by Corky's opinion, that I sent to this

>     mailing list (I usually do not follow it/send to it much).  I - and

>     you? - should not want to MISGUIDE the nice people on this list who

>     are looking for sure and true information, right?

>

>     -Moez

>

>     PS: For the one who asked how can the (simple) program that squares

>     its input non-terminate, I think you missed my point (I also

>     suggest, if possible, studying semantics). My point is a GENERAL

>     one, about all possible computations, not a (your) specific one. My

>     point is that if you want ANY programming language to be *useful* it

>     HAS to allow the possibility of non-termination.  That is a

>     consequence of the halting-problem & the Church-Turing thesis, if I

>     recall correctly and properly understand them.  Non-termination

>     ("giving an answer, but at time infinity!") ALWAYS has to be in our

>     (programmers') minds if we want to write any useful general software

>     (as defined by Church's lambda calculus and Turing's Turing

>     machines).  My point is, thus, sort of a "meta"-statement, about all

>     useful programs we can write, not a statement/point about a specific

>     program.

>

>     PS2: Even though I find it exciting, I apologize if I may not

>     continue this discussion further. I have too much other stuff on my

>     plate that needs my immediate attention and time.

>

>

>     Tony Morris wrote:

>      > I strongly recommend Types and Programming Languages by Benjamin

>     Pierce.

>      >

>      > Tony Morris wrote:

>      >> Moez A. Abdel-Gawad wrote:

>      >>

>      >>> Tony Morris wrote:

>      >>>

>      >>>> 0 exists. null represents "that which does not exist." In

>     computational

>      >>>> theory, what null represents is more commonly called bottom, _|_,

>      >>>> undefined, non-terminating computation, logical absurdity. In

>      >>>>

>      >>> philosophy

>      >>>

>      >>>> it is sometimes called "not even false."

>      >>>>

>      >>>>

>      >>> That's not true.

>      >>>

>      >>> Me and Corky (Prof. Robert Cartwright, my PhD advisor)

>     discussed this

>      >>> once while discussing Domain Theory (the "Math of Computing", upon

>      >>> which my PhD thesis is based).  We reached the conclusion that

>      >>> non-termination is just, well, non-termination. It can NOT be

>      >>> eliminated from computation.  Null, on the other hand *exists*,

>     as a

>      >>> genuine real but unusual/ exceptional/ unexpected value.  It

>     should,

>      >>> formally speaking, be added to each type that needs one such value

>      >>> (some don't), or forced on them by belonging to a

>      >>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a

>      >>> subclass) of all types (classes). 'null' - just like all regular

>      >>> values - can be got ridden of (is not absolutely essential).  _|_

>      >>> (bottom)/non-termination is absolutely essential to the nature of

>      >>> computation, and cannot be got ridden of.

>      >>>

>      >> It's true. You may not realise it but you contradicted yourself.

>      >> Non-termination must exist in Scala, therefore, it must be

>     represented.

>      >> You said this yourself.

>      >>

>      >> Pattern matching will never be exhaustive, the error function is

>     of type

>      >> forall A. A (which is a LIE!), and (wait for it) null exists. Null

>      >> represents that which does not exist and that is the extent of its

>      >> existence. In a language with different syntax, you might consider

>      >> calling it _|_. The null value is a value has the type forall A.

>     A. This

>      >> is not a theorem. It represents bottom, non-termination,

>     undefinedness,

>      >> logical absurdity. That is what null is. I recommend you try

>     again with

>      >> Corky. You buggered up.

>      >>

>      >>

>      >>>> Philip Köster wrote:

>      >>>>

>      >>>>> Discovering the `0' was what separated the Arabians from the

>     Romans.

>      >>>>>

>      >>>>>

>      >>> 'Arabs', you mean.

>      >>>

>      >>> One day we used to teach the world.  We hope one day soon we would

>      >>> again!  :)

>      >>>

>      >>> -Moez

>      >>>

>      >>>

>      >>

>      >

>

>

Re: Java Parser in Scala avalable ?

2009-11-23T03:16:25Z

Manohar Jonnalagedda
<manojo10386@...> wrote in
news:d17eedc90911221707n4be9c9d0q4e63245c67eb2b92@...:

> I am working in a project where I would be needing to analyse Java
> code, and have therefore started to work on a parser for Java. The
> size of the grammar being immense however, before going deeper, I was
> wondering if anyone had attempted a similar (futile ?) feat, and if
> there was some code available in the public domain I could find ?

Since Scala can easily call Java code, you might also find what you need in
Java somewhere. I'm working on a project where I needed a parser for the
nesC programming language. I used ANTLR to create the parser in Java and
then used the result from my Scala program.

Peter

Re: Java Parser in Scala avalable ?

2009-11-23T03:12:14Z

I used the Eclipse compiler to do some analysis once;

http://bitbucket.org/mbana/moodmetricsplug-in/src/tip/src/metricsplugin/

The calc file is where the analysis is done.

—Mohamed

On Mon, Nov 23, 2009 at 3:21 AM, Manohar Jonnalagedda <manojo10386@...> wrote:

The idea is to compare abstract syntax trees of different java code snippets. A complete parser and syntactic tree might therefore not be necessary, but I thought I could refine the parser once I had the whole thing.

Thanks for the suggesting the Eclipse compiler, I will have a look at it.

Manohar

On Sun, Nov 22, 2009 at 5:33 PM, Mohamed Bana <mohamed@...> wrote:

What exactly are you trying to analyse? Have you looked at the Eclipse compiler?

—Mohamed

On Mon, Nov 23, 2009 at 1:07 AM, Manohar Jonnalagedda <manojo10386@...> wrote:
Hello all,

I am working in a project where I would be needing to analyse Java code, and have therefore started to work on a parser for Java. The size of the grammar being immense however, before going deeper, I was wondering if anyone had attempted a similar (futile ?) feat, and if there was some code available in the public domain I could find ?

Thanks,
Manohar

Re: Re: _|_ vs null (Was Re: Cost of Option / Some vs null)

2009-11-23T03:02:13Z

Ok, at the risk of irritating every one else on this mailing list - I'll take the bait and continue this off-topic conversation with one last post.

Please back your claims with references. You statements may be true, but they need to be backed with documentation to be believable.

Zero has had a long and convoluted history pre-dating the Indians, but the first *documented* instance of using the decimal system (which is based on the concept of using zeroes to denote place-holders to denote magnitude) as well as treating zero as a number in its own right is of Indian origin: http://en.wikipedia.org/wiki/Zero#History

According to that wiki page the Chinese had a non-formalised concept of zero in the first century (not first by a long shot, the Babylonians win there again - 2nd millennium BCE! - followed by a number of other civilizations before the Chinese got to it), and that their first formalised documented instance of using zero as we do now was in 1247 CE. I concede that not everyone may consider wikipedia as a legitimate source, however it is not alone in making this claim, and it is the easiest one I could search and link to in an email like this. If you have documented evidence contradicting this please do share.

Ishaaq

2009/11/23 De Gao <gaode.ml@gmail.com>

add some fun: about 3500 yrs ago chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU did was just invent how to write numbers in a simple way

De Gao

2009-11-23

发件人： Philip Köster

发送时间： 2009-11-21 23:22:08

收件人： Ishaaq Chandy

抄送： Moez A. Abdel-Gawad; Scala User List

主题： Re: _|_ vs null (Was Re: [scala-user] Cost of Option / Some vs null)

To possibly take some strength out of this discussion---none of us lived

4000 yrs ago, so we really don't know---, I'm always surprised to see

that even the Chinese and Japanese and Hindu folks adopted ``our"

numbers. They must have been a good invention. :)

Ishaaq Chandy schrieb:

> We'll just have to agree to disagree - even though the vast majority of

> literature on the topic (including the Encyclopaedia Britannica - which

> you were so quick to quote) agree with what I said: i.e. the decimal

> number system, with zero as a place-holder denoting magnitude was an

> Indian invention.

>

> ... and yes I already knew the word "Algebra" is rooted from an Arab

> word - that does not mean they invented the discipline - that honour

> belongs to the ancient Babylonians (almost 4000 years ago!) - refined by

> the Greeks and the Indians before the Arabs got hold of it.

> (http://en.wikipedia.org/wiki/Timeline_of_algebra)

>

> I'm not belittling the myriad achievements of the Arabs - far from it,

> they were essential to the history of Mathematics, but please don't

> miss-attribute stuff.

>

> Ishaaq

>

> PS - and no, modern Indians do not call their numerals "Arab numerals",

> I know, because I am one of them :)  - "Arab numerals" is western

> nomenclature.

>

> 2009/11/22 Moez A. Abdel-Gawad <moez@... <mailto:moez@...>>

>

>     Ishaaq,

>

>

>     You wrote:

>      > Slightly off topic, but the Arabs got the concept of zero from the

>      > Indians - the Arabs then introduced it to the western world.

>      >

>

>     That is a myth that is trying - by some well-intentioned people? -

>     to be created/spread.

>

>     Arabs may have borrowed other digits (ie, their shapes) from India

>     (not a 100% sure fact either) but they have NOT borrowed 0.  They

>     invented it, because they were the center of scientific research

>     then, and they simply needed it. Without it, math - as they had

>     (possibly) borrowed it from the Indians - would make much less

>     sense.  That's to the best of my knowledge/research on this

>     off-topic historical point.

>

>     Also, note that even *Indians* of today do call numerals we use

>     'Arabic numerals', because they - digits we/Arabs - use/used *look

>     different* from ones they have/had (check TUG India and their TeX

>     Tutorial, for example).

>

>     Finally, you may also like to check the 'Islamic Mathematics'

>     article, on Encyclopedia Britannica (despite some of its

>     misinformation about Islam), for getting more info about the

>     numerous contributions made by Arabs and Muslims to the fundamentals

>     of Mathematics (should I mention where the word 'Algebra' came from?).

>

>     Now...

>

>     Tony,

>

>     Are your responses an attempt to let ignorance - or misinformation -

>     reign, among Scala users??  I hope not.

>

>     I've *studied* Peirce's TAPL (as it is commonly abbreviated), years

>     ago! It is not The Qur'an, or a Bible, that has to believed in its

>     totality, and without questioning.  TAPL has some fundamental

>     criticisms against it.

>

>     Relevant to our discussion is the fact/criticism that TAPL is too

>     syntactic, and rarely discusses (mathematical) semantics. Saying

>     this, I also recognize it is VERY HARD for people who are not

>     familiar much with PL semantics (particularly Domain Theory, and

>     denotational semantics) to realize TAPL's "syntactic-ness".

>

>     I thus suggest YOU first read more, in PL semantics, particularly

>     Dana Scott seminal work (for which he was awarded the Turing Award

>     [the "Nobel Prize" of CS], and Gordon Plotkin and Cardelli's

>     important work on PL semantics, before talking about _|_ (and

>     wrongly associating it with 'null').

>

>     And please remember: I was once - at the time of that discussion I

>     had with Corky - in your shoes.  Corky then helped me, a lot, to

>     realize the distinction you are now still unable to make.

>

>     So, finally, please be careful before you talk, specially on a

>     mailing list with so many members.  It is only because I am sure of

>     my main premises, backed by Corky's opinion, that I sent to this

>     mailing list (I usually do not follow it/send to it much).  I - and

>     you? - should not want to MISGUIDE the nice people on this list who

>     are looking for sure and true information, right?

>

>     -Moez

>

>     PS: For the one who asked how can the (simple) program that squares

>     its input non-terminate, I think you missed my point (I also

>     suggest, if possible, studying semantics). My point is a GENERAL

>     one, about all possible computations, not a (your) specific one. My

>     point is that if you want ANY programming language to be *useful* it

>     HAS to allow the possibility of non-termination.  That is a

>     consequence of the halting-problem & the Church-Turing thesis, if I

>     recall correctly and properly understand them.  Non-termination

>     ("giving an answer, but at time infinity!") ALWAYS has to be in our

>     (programmers') minds if we want to write any useful general software

>     (as defined by Church's lambda calculus and Turing's Turing

>     machines).  My point is, thus, sort of a "meta"-statement, about all

>     useful programs we can write, not a statement/point about a specific

>     program.

>

>     PS2: Even though I find it exciting, I apologize if I may not

>     continue this discussion further. I have too much other stuff on my

>     plate that needs my immediate attention and time.

>

>

>     Tony Morris wrote:

>      > I strongly recommend Types and Programming Languages by Benjamin

>     Pierce.

>      >

>      > Tony Morris wrote:

>      >> Moez A. Abdel-Gawad wrote:

>      >>

>      >>> Tony Morris wrote:

>      >>>

>      >>>> 0 exists. null represents "that which does not exist." In

>     computational

>      >>>> theory, what null represents is more commonly called bottom, _|_,

>      >>>> undefined, non-terminating computation, logical absurdity. In

>      >>>>

>      >>> philosophy

>      >>>

>      >>>> it is sometimes called "not even false."

>      >>>>

>      >>>>

>      >>> That's not true.

>      >>>

>      >>> Me and Corky (Prof. Robert Cartwright, my PhD advisor)

>     discussed this

>      >>> once while discussing Domain Theory (the "Math of Computing", upon

>      >>> which my PhD thesis is based).  We reached the conclusion that

>      >>> non-termination is just, well, non-termination. It can NOT be

>      >>> eliminated from computation.  Null, on the other hand *exists*,

>     as a

>      >>> genuine real but unusual/ exceptional/ unexpected value.  It

>     should,

>      >>> formally speaking, be added to each type that needs one such value

>      >>> (some don't), or forced on them by belonging to a

>      >>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a

>      >>> subclass) of all types (classes). 'null' - just like all regular

>      >>> values - can be got ridden of (is not absolutely essential).  _|_

>      >>> (bottom)/non-termination is absolutely essential to the nature of

>      >>> computation, and cannot be got ridden of.

>      >>>

>      >> It's true. You may not realise it but you contradicted yourself.

>      >> Non-termination must exist in Scala, therefore, it must be

>     represented.

>      >> You said this yourself.

>      >>

>      >> Pattern matching will never be exhaustive, the error function is

>     of type

>      >> forall A. A (which is a LIE!), and (wait for it) null exists. Null

>      >> represents that which does not exist and that is the extent of its

>      >> existence. In a language with different syntax, you might consider

>      >> calling it _|_. The null value is a value has the type forall A.

>     A. This

>      >> is not a theorem. It represents bottom, non-termination,

>     undefinedness,

>      >> logical absurdity. That is what null is. I recommend you try

>     again with

>      >> Corky. You buggered up.

>      >>

>      >>

>      >>>> Philip Köster wrote:

>      >>>>

>      >>>>> Discovering the `0' was what separated the Arabians from the

>     Romans.

>      >>>>>

>      >>>>>

>      >>> 'Arabs', you mean.

>      >>>

>      >>> One day we used to teach the world.  We hope one day soon we would

>      >>> again!  :)

>      >>>

>      >>> -Moez

>      >>>

>      >>>

>      >>

>      >

>

>

Re: Cost of Option/Some vs null, take 2

2009-11-22T23:56:07Z

On Sun, 2009-11-22 at 18:52 -0800, Blair Zajac wrote:
> That's right, readOnly has been removed. Between the synchronization and the lack of readOnly in 2.8.x I decided to wrap the Google Collection classes.

Does anyone know the reasoning for the removal? Maybe we can lobby to
get it back. :)

Ismael

Re: Re: _|_ vs null (Was Re: [scala-user] Cost of Option / Some vs null)

2009-11-22T23:54:45Z

add some fun: about 3500 yrs ago chinese already had number 1-9. about 2500 yrs ago chinese invent 0. So what YOU did was just invent how to write numbers in a simple way

De Gao

2009-11-23

发件人： Philip Köster

发送时间： 2009-11-21 23:22:08

收件人： Ishaaq Chandy

抄送： Moez A. Abdel-Gawad; Scala User List

主题： Re: _|_ vs null (Was Re: [scala-user] Cost of Option / Some vs null)

To possibly take some strength out of this discussion---none of us lived

4000 yrs ago, so we really don't know---, I'm always surprised to see

that even the Chinese and Japanese and Hindu folks adopted ``our"

numbers. They must have been a good invention. :)

Ishaaq Chandy schrieb:

> We'll just have to agree to disagree - even though the vast majority of

> literature on the topic (including the Encyclopaedia Britannica - which

> you were so quick to quote) agree with what I said: i.e. the decimal

> number system, with zero as a place-holder denoting magnitude was an

> Indian invention.

> ... and yes I already knew the word "Algebra" is rooted from an Arab

> word - that does not mean they invented the discipline - that honour

> belongs to the ancient Babylonians (almost 4000 years ago!) - refined by

> the Greeks and the Indians before the Arabs got hold of it.

> (http://en.wikipedia.org/wiki/Timeline_of_algebra)

> I'm not belittling the myriad achievements of the Arabs - far from it,

> they were essential to the history of Mathematics, but please don't

> miss-attribute stuff.

> Ishaaq

> PS - and no, modern Indians do not call their numerals "Arab numerals",

> I know, because I am one of them :) - "Arab numerals" is western

> nomenclature.

> 2009/11/22 Moez A. Abdel-Gawad <moez@... <mailto:moez@...>>

> Ishaaq,

> You wrote:

> > Slightly off topic, but the Arabs got the concept of zero from the

> > Indians - the Arabs then introduced it to the western world.

> >

> That is a myth that is trying - by some well-intentioned people? -

> to be created/spread.

> Arabs may have borrowed other digits (ie, their shapes) from India

> (not a 100% sure fact either) but they have NOT borrowed 0. They

> invented it, because they were the center of scientific research

> then, and they simply needed it. Without it, math - as they had

> (possibly) borrowed it from the Indians - would make much less

> sense. That's to the best of my knowledge/research on this

> off-topic historical point.

> Also, note that even *Indians* of today do call numerals we use

> 'Arabic numerals', because they - digits we/Arabs - use/used *look

> different* from ones they have/had (check TUG India and their TeX

> Tutorial, for example).

> Finally, you may also like to check the 'Islamic Mathematics'

> article, on Encyclopedia Britannica (despite some of its

> misinformation about Islam), for getting more info about the

> numerous contributions made by Arabs and Muslims to the fundamentals

> of Mathematics (should I mention where the word 'Algebra' came from?).

> Now...

> Tony,

> Are your responses an attempt to let ignorance - or misinformation -

> reign, among Scala users?? I hope not.

> I've *studied* Peirce's TAPL (as it is commonly abbreviated), years

> ago! It is not The Qur'an, or a Bible, that has to believed in its

> totality, and without questioning. TAPL has some fundamental

> criticisms against it.

> Relevant to our discussion is the fact/criticism that TAPL is too

> syntactic, and rarely discusses (mathematical) semantics. Saying

> this, I also recognize it is VERY HARD for people who are not

> familiar much with PL semantics (particularly Domain Theory, and

> denotational semantics) to realize TAPL's "syntactic-ness".

> I thus suggest YOU first read more, in PL semantics, particularly

> Dana Scott seminal work (for which he was awarded the Turing Award

> [the "Nobel Prize" of CS], and Gordon Plotkin and Cardelli's

> important work on PL semantics, before talking about _|_ (and

> wrongly associating it with 'null').

> And please remember: I was once - at the time of that discussion I

> had with Corky - in your shoes. Corky then helped me, a lot, to

> realize the distinction you are now still unable to make.

> So, finally, please be careful before you talk, specially on a

> mailing list with so many members. It is only because I am sure of

> my main premises, backed by Corky's opinion, that I sent to this

> mailing list (I usually do not follow it/send to it much). I - and

> you? - should not want to MISGUIDE the nice people on this list who

> are looking for sure and true information, right?

> -Moez

> PS: For the one who asked how can the (simple) program that squares

> its input non-terminate, I think you missed my point (I also

> suggest, if possible, studying semantics). My point is a GENERAL

> one, about all possible computations, not a (your) specific one. My

> point is that if you want ANY programming language to be *useful* it

> HAS to allow the possibility of non-termination. That is a

> consequence of the halting-problem & the Church-Turing thesis, if I

> recall correctly and properly understand them. Non-termination

> ("giving an answer, but at time infinity!") ALWAYS has to be in our

> (programmers') minds if we want to write any useful general software

> (as defined by Church's lambda calculus and Turing's Turing

> machines). My point is, thus, sort of a "meta"-statement, about all

> useful programs we can write, not a statement/point about a specific

> program.

> PS2: Even though I find it exciting, I apologize if I may not

> continue this discussion further. I have too much other stuff on my

> plate that needs my immediate attention and time.

> Tony Morris wrote:

> > I strongly recommend Types and Programming Languages by Benjamin

> Pierce.

> >

> > Tony Morris wrote:

> >> Moez A. Abdel-Gawad wrote:

> >>

> >>> Tony Morris wrote:

> >>>

> >>>> 0 exists. null represents "that which does not exist." In

> computational

> >>>> theory, what null represents is more commonly called bottom, _|_,

> >>>> undefined, non-terminating computation, logical absurdity. In

> >>>>

> >>> philosophy

> >>>

> >>>> it is sometimes called "not even false."

> >>>>

> >>> That's not true.

> >>>

> >>> Me and Corky (Prof. Robert Cartwright, my PhD advisor)

> discussed this

> >>> once while discussing Domain Theory (the "Math of Computing", upon

> >>> which my PhD thesis is based). We reached the conclusion that

> >>> non-termination is just, well, non-termination. It can NOT be

> >>> eliminated from computation. Null, on the other hand *exists*,

> as a

> >>> genuine real but unusual/ exceptional/ unexpected value. It

> should,

> >>> formally speaking, be added to each type that needs one such value

> >>> (some don't), or forced on them by belonging to a

> >>> (non-expressible-in-Java) 'NullType' that is a subtype (based on a

> >>> subclass) of all types (classes). 'null' - just like all regular

> >>> values - can be got ridden of (is not absolutely essential). _|_

> >>> (bottom)/non-termination is absolutely essential to the nature of

> >>> computation, and cannot be got ridden of.

> >>>

> >> It's true. You may not realise it but you contradicted yourself.

> >> Non-termination must exist in Scala, therefore, it must be

> represented.

> >> You said this yourself.

> >>

> >> Pattern matching will never be exhaustive, the error function is

> of type

> >> forall A. A (which is a LIE!), and (wait for it) null exists. Null

> >> represents that which does not exist and that is the extent of its

> >> existence. In a language with different syntax, you might consider

> >> calling it _|_. The null value is a value has the type forall A.

> A. This

> >> is not a theorem. It represents bottom, non-termination,

> undefinedness,

> >> logical absurdity. That is what null is. I recommend you try

> again with

> >> Corky. You buggered up.

> >>

> >>>> Philip Köster wrote:

> >>>>

> >>>>> Discovering the `0' was what separated the Arabians from the

> Romans.

> >>>>>

> >>> 'Arabs', you mean.

> >>>

> >>> One day we used to teach the world. We hope one day soon we would

> >>> again! :)

> >>>

> >>> -Moez

> >>>

> >>

> >

Re: Re: Nesting alternative parser combinators

2009-11-22T22:49:33Z

Hi Tony,

Thank you very much for explanation. Now I understand.

I have encountered the same problem before, but did not realize, it is the same problem. By same problem, I mean the parser itself succeeds, but the parseAll fails due to remaining unparsed input. The error message was then "`\z' expected but ..." which pointed me to look up in the combination tree, because I had no `\z' in my part of the grammar.

Now it did not occur to me, that 'Y' was succeeding, I was expecting the `\z' message for that case. I guess this is another instance of [scala-user] Confusing parsing combinator errors.

The way how parseAll chooses the error to report does not make sense to me. I see no correlation between the reported failure of an unsuccessful parser that
consumed most of the input before failing and the real error in this case - expected end of input (`\z'), but `-' found. In effect, it is choosing arbitrary previous error message, that hides the true nature of the problem - the topmost user-defined parser _succeeded_, but there was input still left.

Regards
Pavol Vaskovic

On Mon, Nov 23, 2009 at 5:16 AM, Tony Sloane <inkytonik@...> wrote:

Hi Pavol,

BNF semantics is not quite right for this kind of parser. Significant
differences are that alternative order and backtracking behaviour
matter for the alternation combinator but are not really defined for
BNF.

It appears to me that your pY parser works because phrase(X) cannot
succeed (since it doesn't consume all of the input). Hence the second

alternative of pY is chosen and succeeds.

For the Y variant, X actually succeeds since a prefix of the input is
"K", which is a KD, which is an X. Hence Y succeeds. But the next

level up (parseAll (Y, ...)) doesn't succeed, since some of the input
has not been consumed.  It is too late to backtrack into the second
alternative of Y at that point though, since Y has already succeeded.

I think the error you are seeing:

[1.3] failure: `D' expected but `O' found

K-O#1
^

is reported because the phrase combinator (used by parseAll) reports
the last unsuccessful parse (see lastNoSuccess var in Parsers class),
where "last" refers to latest in the input. This makes sense because

that error is the likely cause of the parser not consuming the entire
input. In your case, the most recent unsuccessful parse is the
failure in the K ~ ("-" ~> D) alternative of KD on the D, hence the

error. (There is also a failure in the KD ~ ("#" ~> num) alternative
of X that happens later in time but at an earlier position in the
input (on the "-", expecting a "#"), so it is not preferred.)

Whew! This stuff can be tricky to reason about, but I hope this helps
clarify what is going on.

cheers,
Tony

On 23/11/2009, at 11:54 AM, Pavol Vaskovic wrote:

I've removed the partial function applications from the test case, because they were not affecting the results. This is even simpler demonstration of behavior I can not explain:

object Test extends util.parsing.combinator.RegexParsers {
override val whiteSpace = "".r

def letter = "[A-Z]".r
def lettersAndDash = "[-A-Z]+".r
def num = "[1-9]".r

def pY = phrase(X) | lettersAndDash ~ ("#" ~> num)
def Y = X | lettersAndDash ~ ("#" ~> num)

def X = KD ~ ("#" ~> num) | KD

def KD = K ~ ("-" ~> D) | K

def K = "K"
def D = "D"

def main(args: Array[String]) {
    println(parseAll(Y, "K-O#1"))
    println(parseAll(pY, "K-O#1"))
}
}

Why am I getting the following?
[1.3] failure: `D' expected but `O' found

K-O#1
^
[1.6] parsed: (K-O~1)

Nesting alternatives third time, triggers the failure.
(Commenting out "| KD" in def X or "| K" in def KD causes the Y to parse with " | lettersAndDash ~ ("#" ~> num)".) Why exactly does wrapping the X in phrase make this case work?

This seems like a dangerous pitfall, when using parser combinators naively (assuming EBNF semantics), as I do.
Why does it behave like this? Why doesn't "b ~ c | b" behave same as "b ~ opt(c)"?
Thanks in advance for bringing some light on this issue.

Regards
Pavol Vaskovic

On Thu, Nov 19, 2009 at 2:05 PM, Pavol Vaskovic <pali@...> wrote:

I'm parsing addresses in semi-structured format. I've created a grammar that behaves strange, and I am unable to explain what is going on.

I have been avoiding the use of opt method for wrapping optional parts of grammar, because it complicated the return signatures too much. Instead I was using alternative composition with longer variant first.

Instead of:
def a = b ~ opt(c)

I'm using:
def a = b ~ c | b

When I nest such rules, they start to behave surprisingly - seems like the alternatives are never tried.

Re: Java Parser in Scala avalable ?

2009-11-22T21:52:01Z

Manohar,

On Sun, 2009-11-22 at 17:07 -0800, Manohar Jonnalagedda wrote:

> Hello all,
>
> I am working in a project where I would be needing to analyse Java
> code, and have therefore started to work on a parser for Java. The
> size of the grammar being immense however, before going deeper, I was
> wondering if anyone had attempted a similar (futile ?) feat, and if
> there was some code available in the public domain I could find ?
>
> Thanks,
> Manohar

As Mohamed Bana suggested, if you are working using Eclipse, there is
the Eclipse compiler which can be used programmatically.

There is also the compiler in OpenJDK which could be used.

Another alternative is that the Groovy project has an Antlr grammar for
Java as well as one for Groovy.

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment