JSON parser

[Sadek Drobi]

Hi everyone,

In 2.9

case class JSONObject ( obj : Map[String, Any] ) extends JSONType with Product with Serializable

Isn't it better to have obj :[String, JSONType] and have JSONType include javascript primitives since it is a small list?

To me it is much more intuitive and practical for pattern matching.

same for 

case class JSONArray ( list : List[Any] ) to have list:List[JSONType]

Thanks

Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Tony Morris]

You're correct. Use an algebraic data type. Don't use Any.

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

[Sadek Drobi]

Thank you Tony for your reply.

My question was: why isn't it actually implemented that way?

Thanks

Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Tony Morris]

I'm not sure which library you're referring to exactly. However, when I
see code like this, it usually means a misunderstanding about how to
design libraries for practical use.

[Sadek Drobi]

I am referring to

scala.util.parsing.json.JSON

http://www.scala-lang.org/api/rc/scala/util/parsing/json/JSON$.html

Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Robert Wills]

My impression is that most people using Scala don't actually using
scala.util.parsing.json
A combination of sjson or lift json with databinder json is more
common and if you look
at the datatypes defined in the dispatch json library you will indeed
see that they are defined
more sensibly there:

http://databinder.net/dispatch-doc/dispatch/json/JsObject.html

As to why scala.util.parsing.json was implemented that way my guess
would be that at the
time it was written it was intended primarily to show of Scala's
combinator parsing and not
necessarily to provide a usable json library.

-Rob

[Matthew Pocock]

On 29 March 2011 10:19, Robert Wills <wrw...@gmail.com> wrote:

My impression is that most people using Scala don't actually using
scala.util.parsing.json

Is the json parser in the core lib used at all by anyone? I gave it about 5 min before using the lift json API. Could the whole thing either be made sane or dropped entirely from the core lib? Perhaps there is a silent army of people who use it daily without any problems.

Matthew

--

Matthew Pocock

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

(0191) 2566550

[john sullivan]

Same here, it took me about 5 minutes to pass up this library in favor of sjson, and about an hour to pass up sjson in favor of the lift json API.

--
There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.

[Derek Chen-Becker]

On 04/02/2011 08:10 PM, john sullivan wrote:
> Same here, it took me about 5 minutes to pass up this library in favor
> of sjson, and about an hour to pass up sjson in favor of the lift json API.
>
> On Tue, Mar 29, 2011 at 1:22 PM, Matthew Pocock
> <turingate...@gmail.com <mailto:turingate...@gmail.com>> wrote:
>
> On 29 March 2011 10:19, Robert Wills <wrw...@gmail.com

> <mailto:wrw...@gmail.com>> wrote:
>
> My impression is that most people using Scala don't actually using
> scala.util.parsing.json
>
>
> Is the json parser in the core lib used at all by anyone? I gave it
> about 5 min before using the lift json API. Could the whole thing
> either be made sane or dropped entirely from the core lib? Perhaps
> there is a silent army of people who use it daily without any problems.

Hi guys,
I just want to chime in as the guy that maintains said parser. I
wrote it a loooong time ago as part of learning the parsing library and
it ended up getting included in the core libs. At the time I knew only a
small fraction of what I do know about writing useful Scala libraries.
If truly no one is using it I would absolutely love to perform a
scorched-earth overhaul and make it a lot more sane (and typed). I'm
really not sure at this point how to gauge that, though. I suppose I
could simply write a new parser under the same package, but that doesn't
leave me with a warm, fuzzy feeling, either.

The other thing is that Joni has done an absolutely amazing job with
lift-json, and I don't think I can replicate that. If that's really what
people want in the core lib then the discussion needs to be with Martin
about how that could be achieved.

Cheers,

Derek

[Sadek Drobi]

If truly no one is using it I would absolutely love to perform a
scorched-earth overhaul and make it a lot more sane (and typed).

 

I am all for this.

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Seth Tisue]

>>>>> "Derek" == Derek Chen-Becker <ja...@chen-becker.org> writes:

Derek> The other thing is that Joni has done an absolutely amazing job
Derek> with lift-json, and I don't think I can replicate that. If
Derek> that's really what people want in the core lib then the
Derek> discussion needs to be with Martin about how that could be
Derek> achieved.

+1

I see this come up over and over and over again on IRC. Beginners pop
up, want to do JSON stuff, naturally they try the standard library stuff
first, and then suddenly they find themselves in a world of untyped hurt
and have all sorts of weird questions and misunderstandings about Any,
type erasure, and so on. Eventually someone tells them to use lift-json
instead and sends them on their way.

Even if lift-json isn't added right away, it seems to me that the old
stuff could simply be deprecated in 2.9?

--
Seth Tisue | Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[martin odersky]

On Mon, Apr 4, 2011 at 4:27 PM, Seth Tisue <se...@tisue.net> wrote:

>>>>> "Derek" == Derek Chen-Becker <ja...@chen-becker.org> writes:

 Derek> The other thing is that Joni has done an absolutely amazing job
 Derek> with lift-json, and I don't think I can replicate that. If
 Derek> that's really what people want in the core lib then the
 Derek> discussion needs to be with Martin about how that could be
 Derek> achieved.

+1

I see this come up over and over and over again on IRC.  Beginners pop
up, want to do JSON stuff, naturally they try the standard library stuff
first, and then suddenly they find themselves in a world of untyped hurt
and have all sorts of weird questions and misunderstandings about Any,
type erasure, and so on.  Eventually someone tells them to use lift-json
instead and sends them on their way.

Even if lift-json isn't added right away, it seems to me that the old
stuff could simply be deprecated in 2.9?

Yes, I think that would be the right thing to do. CCing Phillip who's currently doing a deprecation sweep through the libraries.

 -- Martin

[Kevin Wright]

I love the smell of napalm in the morning...

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

mail: kevin....@scalatechnology.com

vibe / skype: kev.lee.wright

quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Sadek Drobi]

Actually what I was thinking of is something similar to Haskell's Text.JSON in the way that it defines a generic get with a type class (implicit parameter in Scala) and then would offer a typed interface to reading JSON values.

http://hackage.haskell.org/packages/archive/json/0.4.3/doc/html/Text-JSON.html

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Tony Morris]

Hi Sadek
You can have both the generic version and the other. Note that in scala the advantage is not as high due to the type inference -- the type will have to be specified by the calling client.

I've considered writing a JSON parser because I am not happy with any of the existing ones.

You might be interested in this
http://hackage.haskell.org/package/JSON-Combinator

Unfortunately this kind of library is not possible in scala without functional dependencies/type families, but I can specialise (repeat) it to each parser.

On 05/04/2011 4:33 AM, "Sadek Drobi" <sadek...@gmail.com> wrote:

[Sadek Drobi]

Thanks Toni for the link, I haven't crossed this api before...

On Mon, Apr 4, 2011 at 9:57 PM, Tony Morris <tmo...@tmorris.net> wrote:

You can have both the generic version and the other. Note that in scala the advantage is not as high due to the type inference -- the type will have to be specified by the calling client.

Yeah that's right. Between get[String] and getString. Maybe for extensibility (just implement type class instance for your type and you are good to go) 

I've considered writing a JSON parser because I am not happy with any of the existing ones.

You might be interested in this
http://hackage.haskell.org/package/JSON-Combinator

Unfortunately this kind of library is not possible in scala without functional dependencies/type families, but I can specialise (repeat) it to each parser.

I had a fast look, and it seems to me that functional dependencies are there just because it is parameterable on String and List type. You ignore these and put String and List and you can get rid of functional dependency. 

Sadek.

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Tony Morris]

On 06/04/11 08:01, Sadek Drobi wrote:
> I had a fast look, and it seems to me that functional dependencies are
> there just because it is parameterable on String and List type. You
> ignore these and put String and List and you can get rid of functional
> dependency.

This is a bit of a simplification, but yes. The fundeps are there so
that I can parameterise on all the different ways of representing JSON
data types (I keep thinking I've seen them all, then another one pops up).

As for the practical application for this thread, yes, you can just
specialise to one representation and there is no need for fundeps --
scala is capable of everything else besides this.

[Arioch]

В письме от Mon, 04 Apr 2011 03:00:21 +0400, Derek Chen-Becker
<ja...@chen-becker.org> сообщал:

> wrote it a loooong time ago as part of learning the parsing library and
> it ended up getting included in the core libs.

Perhaps it would be a good thing then to make it part of documentation ?

1st part - how the certain Scala feature allowed to make a library
and 2nd part - why this approach for given task is not practical

--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/