In search of replacing Groovy by Scala

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

In search of replacing Groovy by Scala

Albert Kurucz
Hi All,

I develop in Java and Groovy, and just started to study Scala.

Please help me find a Java/Scala equivalent of the following Java code:
"
// call groovy expressions from Java code
Binding binding = new Binding();
binding.setVariable("foo", new Integer(2));
GroovyShell shell = new GroovyShell(binding);

Object value = shell.evaluate("println 'Hello World!'; x = 123; return foo * 10");
assert value.equals(new Integer(20));
assert binding.getVariable("x").equals(new Integer(123));
"

I would like to evaluate Scala expressions (from a String to Java Objects).
Sorry if this is an old questions, I was unable to Google the answer.

Thanks,
Al
Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Naftoli Gugenheim
Look at the source code of the interpreter.
Also I think there's a trac ticket for javax.script support with a comment that references some project that has some javax.script implementation for scala.

-------------------------------------
Albert Kurucz<[hidden email]> wrote:

Hi All,

I develop in Java and Groovy, and just started to study Scala.

Please help me find a Java/Scala equivalent of the following Java code:
"
// call groovy expressions from Java code
Binding binding = new Binding();
binding.setVariable("foo", new Integer(2));
GroovyShell shell = new GroovyShell(binding);

Object value = shell.evaluate("println 'Hello World!'; x = 123; return
foo * 10");
assert value.equals(new Integer(20));
assert binding.getVariable("x").equals(new Integer(123));
"

I would like to evaluate Scala expressions (from a String to Java Objects).
Sorry if this is an old questions, I was unable to Google the answer.

Thanks,
Al
Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Randall R Schulz-2
In reply to this post by Albert Kurucz
On Sunday July 19 2009, Albert Kurucz wrote:
> Hi All,
>
> I develop in Java and Groovy, and just started to study Scala.
>
> ...
>
> I would like to evaluate Scala expressions (from a String to Java
> Objects). Sorry if this is an old questions, I was unable to Google
> the answer.

Scala is not really an interpreted language. Programs like the Scala
REPL or SimplyGroovy [1] are really just calling the compiler with
every expression submitted while supplying some implicit surrounding
context to make it appear that you can create defs, vals and vars at a
global scope.

If you want to experiment with the language—a good thing—the REPL or
SimplyScala are more than adequate.

If you're thinking of creating a program that relies on dynamic
compilation of Scala code (a very "heavyweight" process), you should
probably explore alternate designs. E.g., create an external DSL, which
Scala's combinator parser library makes very straightforward.


[1] <http://www.simplyscala.com/>


> Thanks,
> Al


Randall Schulz
Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Albert Kurucz
Randall,


Scala is not really an interpreted language.

How do you define "interpreted"?
I would not call the language interpreted just because it supports the on-the-fly compilation (in case when the passed String evaluates to a Class) or the on-the-fly evaluation (in case when the passed String evaluates to an Object).
 
Programs like the Scala
REPL or SimplyGroovy [1] are really just calling the compiler with
every expression submitted while supplying some implicit surrounding
context to make it appear that you can create defs, vals and vars at a
global scope.

What REPL or SimplyGroovy is doing for evaluating expressions ( Scala expressions), can I do the same from a Java or Scala code as simple as this groovy example?
"
// call groovy expressions from Java code

Binding binding = new Binding();
binding.setVariable("foo", new Integer(2));

GroovyShell shell = new GroovyShell(binding);

Object value = shell.evaluate("println 'Hello World!'; x = 123; return foo * 10");

assert value.equals(new Integer(20));
assert binding.getVariable("x").equals(new Integer(123));

"

If you're thinking of creating a program that relies on dynamic
compilation of Scala code (a very "heavyweight" process), you should
probably explore alternate designs. E.g., create an external DSL, which
Scala's combinator parser library makes very straightforward.

Right, I need dynamic compilation in my program. It should not be a "heavyweight" process from the programmer's point of view. (I am familiar with the big problem what circular references bring, but I could live with a dynamic compilation which does not accept circular references.)

Why should I create an external DSL? I don't want to create a new language, this one should be good enough to do this.

I don't think just because Scala is statically typed, it should have a problem supporting dynamic compilation.

Al

Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Naftoli Gugenheim
In reply to this post by Albert Kurucz
It definitely is possible and was discussed in this list. I don't know more than what I said before, though.

-------------------------------------
Albert Kurucz<[hidden email]> wrote:

Randall,


Scala is not really an interpreted language.


How do you define "interpreted"?
I would not call the language interpreted just because it supports the
on-the-fly compilation (in case when the passed String evaluates to a Class)
or the on-the-fly evaluation (in case when the passed String evaluates to an
Object).


> Programs like the Scala
> REPL or SimplyGroovy [1] are really just calling the compiler with
> every expression submitted while supplying some implicit surrounding
> context to make it appear that you can create defs, vals and vars at a
> global scope.


What REPL or SimplyGroovy is doing for evaluating expressions ( Scala
expressions), can I do the same from a Java or Scala code as simple as this
groovy example?

"
// call groovy expressions from Java code

Binding binding = new Binding();
binding.setVariable("foo", new Integer(2));

GroovyShell shell = new GroovyShell(binding);

Object value = shell.evaluate("println 'Hello World!'; x = 123; return
foo * 10");

assert value.equals(new Integer(20));
assert binding.getVariable("x").equals(new Integer(123));

"


If you're thinking of creating a program that relies on dynamic
> compilation of Scala code (a very "heavyweight" process), you should
> probably explore alternate designs. E.g., create an external DSL, which
> Scala's combinator parser library makes very straightforward.


Right, I need dynamic compilation in my program. It should not be a
"heavyweight" process from the programmer's point of view. (I am familiar
with the big problem what circular references bring, but I could live with a
dynamic compilation which does not accept circular references.)

Why should I create an external DSL? I don't want to create a new language,
this one should be good enough to do this.

I don't think just because Scala is statically typed, it should have a
problem supporting dynamic compilation.

Al
Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Randall R Schulz-2
In reply to this post by Albert Kurucz
On Sunday July 19 2009, Albert Kurucz wrote:

> Randall,
>
>
> > Scala is not really an interpreted language.
>
> How do you define "interpreted"?
> I would not call the language interpreted just because it supports
> the on-the-fly compilation (in case when the passed String evaluates
> to a Class) or the on-the-fly evaluation (in case when the passed
> String evaluates to an Object).

I agree. That's why I don't think Scala qualifies as interpreted. Take
Clojure for example. Even it technically is not interpreted, even
though, like all Lisps, it has a REPL. But that REPL compiles every
expression to JVM bytecode in the exactly same manner that its
ahead-of-time compilation does. In both cases, the source code is
transformed into machine code (taking virtual machines to be machines)
rather than into an internal representation which is then executed by
some sort of ... interpreter. Is that circular??


> > ...
>
> What REPL or SimplyGroovy is doing for evaluating expressions ( Scala
> expressions), can I do the same from a Java or Scala code as simple
> as this groovy example?
>
> ...

I saw it the first time. I don't know what those programs do other than
in extremely general terms as I described it before.


> > If you're thinking of creating a program that relies on dynamic
> > compilation of Scala code (a very "heavyweight" process), you
> > should probably explore alternate designs. E.g., create an external
> > DSL, which Scala's combinator parser library makes very
> > straightforward.
>
> Right, I need dynamic compilation in my program.

Why? What are you actual requirements? Why aren't you providing a more
domain-specific model for whatever programmability you need to supply
to your users? Do they really want to write Scala code?


> It should not be a "heavyweight" process from the programmer's point
> of view. ...

You can't make it go any faster than the Scala compiler, and that's
going to introduce considerable latencies.


> Why should I create an external DSL? I don't want to create a new
> language, this one should be good enough to do this.

To do what?

How will you keep ill-behaved or outright malicious code out?


> I don't think just because Scala is statically typed, it should have
> a problem supporting dynamic compilation.

As a general rule, if you want to call the shots, you have to design the
thing yourself. Saying Scala should this and shouldn't that is all well
and good, but from our perspective it is what it is.


> Al


Randall Schulz
Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Naftoli Gugenheim
In reply to this post by Albert Kurucz
Instead of creating a DSL, why don't you use the javax.script package? Users could script your application with Javascript or whatever--they could even select the language.
Did you find the reference to the javax.script support for Scala?

-------------------------------------
Randall R Schulz<[hidden email]> wrote:

On Sunday July 19 2009, Albert Kurucz wrote:

> Randall,
>
>
> > Scala is not really an interpreted language.
>
> How do you define "interpreted"?
> I would not call the language interpreted just because it supports
> the on-the-fly compilation (in case when the passed String evaluates
> to a Class) or the on-the-fly evaluation (in case when the passed
> String evaluates to an Object).

I agree. That's why I don't think Scala qualifies as interpreted. Take
Clojure for example. Even it technically is not interpreted, even
though, like all Lisps, it has a REPL. But that REPL compiles every
expression to JVM bytecode in the exactly same manner that its
ahead-of-time compilation does. In both cases, the source code is
transformed into machine code (taking virtual machines to be machines)
rather than into an internal representation which is then executed by
some sort of ... interpreter. Is that circular??


> > ...
>
> What REPL or SimplyGroovy is doing for evaluating expressions ( Scala
> expressions), can I do the same from a Java or Scala code as simple
> as this groovy example?
>
> ...

I saw it the first time. I don't know what those programs do other than
in extremely general terms as I described it before.


> > If you're thinking of creating a program that relies on dynamic
> > compilation of Scala code (a very "heavyweight" process), you
> > should probably explore alternate designs. E.g., create an external
> > DSL, which Scala's combinator parser library makes very
> > straightforward.
>
> Right, I need dynamic compilation in my program.

Why? What are you actual requirements? Why aren't you providing a more
domain-specific model for whatever programmability you need to supply
to your users? Do they really want to write Scala code?


> It should not be a "heavyweight" process from the programmer's point
> of view. ...

You can't make it go any faster than the Scala compiler, and that's
going to introduce considerable latencies.


> Why should I create an external DSL? I don't want to create a new
> language, this one should be good enough to do this.

To do what?

How will you keep ill-behaved or outright malicious code out?


> I don't think just because Scala is statically typed, it should have
> a problem supporting dynamic compilation.

As a general rule, if you want to call the shots, you have to design the
thing yourself. Saying Scala should this and shouldn't that is all well
and good, but from our perspective it is what it is.


> Al


Randall Schulz
Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Yuri Magrisso
In reply to this post by Albert Kurucz
Hi,

I read somewhere in the list that they'll introduce some compiler API to better support the Eclipse plugin. I am myself looking forward to that.

To give an example of why it will be great to have it - I wrote a protocol test application that talks to various sensors via serial interface. Currently I am using Groovy to add/modify protocol implementations on the fly. My needs here are very close to those of an IDE - a simple syntax highlighting script editor, where I write the implementation of an interface. To show the errors in the editor I would need the compiler API to return a list of errors with description and position. I think Scala will be much better than Groovy here, because the compiler will catch more errors.

Regards,
Yuri

On Sun, Jul 19, 2009 at 5:23 PM, Albert Kurucz <[hidden email]> wrote:
Hi All,

I develop in Java and Groovy, and just started to study Scala.

Please help me find a Java/Scala equivalent of the following Java code:
"
// call groovy expressions from Java code
Binding binding = new Binding();
binding.setVariable("foo", new Integer(2));
GroovyShell shell = new GroovyShell(binding);

Object value = shell.evaluate("println 'Hello World!'; x = 123; return foo * 10");
assert value.equals(new Integer(20));
assert binding.getVariable("x").equals(new Integer(123));
"

I would like to evaluate Scala expressions (from a String to Java Objects).
Sorry if this is an old questions, I was unable to Google the answer.

Thanks,
Al

Reply | Threaded
Open this post in threaded view
|

RE: In search of replacing Groovy by Scala

Det2
In reply to this post by Randall R Schulz-2
> > Right, I need dynamic compilation in my program.
>
> Why? What are you actual requirements? Why aren't you
> providing a more
> domain-specific model for whatever programmability you need to supply
> to your users? Do they really want to write Scala code?

Hmm. Yes.
For some applications the "user" is a developer, perhaps me!
BTW: The DSL could be an internal one, exploiting what is
already there in Scala without having to create and implement
a complete grammar plus interpreter.

[...]
> > Why should I create an external DSL? I don't want to create a new
> > language, this one should be good enough to do this.
>
> To do what?

You are questioning here the whole javax.script API and
all the languages that support JSR-223 already.

As I mentioned before on this list (IIRC), we are doing a lot
of useful stuff with the Groovy embedding like shown in the
sample code of the original post.

We have a codegenerator that normally does its generation work,
but by settting a parameter with a script name we can simply
plug in any model analysis or every other stuff.

We have a GUI to parameterise our build tool, and by allowing
for script integration every developer can extend the GUI with
some own tasks (extend means: additional buttons or menu items
in dedicated panels/menus, so pluggin in his specific actions).

Embedding the Grooy interpreter was so simple, no need for
more heavy plugin handling stuff (like OSGi or so).

And simply writing a script and giving its name to the embedding
system is so convenient for ad hoc things, rapid scripting a.s.o.

So when developing a Scala app (e.g. rewriting the GUI in Scala),
why should I juggle with two languages (e.g. Java+Groovy or
Java+JavaScript)
if Scala could really "scale", even in usecase terms?

Scala is able to be used for "scripting", as easily the -e option and
the
very existence of the REPL shows.
The ability to embed it in a JSR-223 way to work on a prepared context
would absolutely fit the philosophy IMHO.

[...]
Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Kevin Wright-4
Maybe something like this:
http://suereth.blogspot.com/2009/04/embedding-scala-interpreter.html
is what you're looking for?


On Mon, Jul 20, 2009 at 8:57 AM, Detering Dirk <[hidden email]> wrote:
> > Right, I need dynamic compilation in my program.
>
> Why? What are you actual requirements? Why aren't you
> providing a more
> domain-specific model for whatever programmability you need to supply
> to your users? Do they really want to write Scala code?

Hmm. Yes.
For some applications the "user" is a developer, perhaps me!
BTW: The DSL could be an internal one, exploiting what is
already there in Scala without having to create and implement
a complete grammar plus interpreter.

[...]
> > Why should I create an external DSL? I don't want to create a new
> > language, this one should be good enough to do this.
>
> To do what?

You are questioning here the whole javax.script API and
all the languages that support JSR-223 already.

As I mentioned before on this list (IIRC), we are doing a lot
of useful stuff with the Groovy embedding like shown in the
sample code of the original post.

We have a codegenerator that normally does its generation work,
but by settting a parameter with a script name we can simply
plug in any model analysis or every other stuff.

We have a GUI to parameterise our build tool, and by allowing
for script integration every developer can extend the GUI with
some own tasks (extend means: additional buttons or menu items
in dedicated panels/menus, so pluggin in his specific actions).

Embedding the Grooy interpreter was so simple, no need for
more heavy plugin handling stuff (like OSGi or so).

And simply writing a script and giving its name to the embedding
system is so convenient for ad hoc things, rapid scripting a.s.o.

So when developing a Scala app (e.g. rewriting the GUI in Scala),
why should I juggle with two languages (e.g. Java+Groovy or
Java+JavaScript)
if Scala could really "scale", even in usecase terms?

Scala is able to be used for "scripting", as easily the -e option and
the
very existence of the REPL shows.
The ability to embed it in a JSR-223 way to work on a prepared context
would absolutely fit the philosophy IMHO.

[...]

Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Albert Kurucz
In reply to this post by Randall R Schulz-2
Randall,

Why? What are you actual requirements? Why aren't you providing a more
domain-specific model for whatever programmability you need to supply
to your users? Do they really want to write Scala code?

Yes, I really want to write Scala code, because it is a nice language.
Why should I force the users to learn another language, which is not so.
 


You can't make it go any faster than the Scala compiler, and that's
going to introduce considerable latencies.

It would be preferable to reduce latencies as much as possible.
But first it should work.
 


> Why should I create an external DSL? I don't want to create a new
> language, this one should be good enough to do this.

To do what?

The nice demo app of this feature (dynamic compile/dynamic evaluation) would be for example a Spreadsheet app, which could have Scala expressions in each cell, which cells are allowed to reference other cells within the same sheet.

Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Randall R Schulz-2
On Monday July 20 2009, Albert Kurucz wrote:
> Randall,
>
> > Why? What are you actual requirements? Why aren't you providing a
> > more domain-specific model for whatever programmability you need to
> > supply to your users? Do they really want to write Scala code?
>
> Yes, I really want to write Scala code, because it is a nice
> language. Why should I force the users to learn another language,
> which is not so.

There is a reason we invent DSLs. It is because general-purpose
programming languages are usually too general for more narrow purposes
and concomitantly laden with details that are extraneous and bothersome
in a more specific domain.


> > ...
>
> > > Why should I create an external DSL? I don't want to create a new
> > > language, this one should be good enough to do this.
> >
> > To do what?
>
> The nice demo app of this feature (dynamic compile/dynamic
> evaluation) would be for example a Spreadsheet app, which could have
> Scala expressions in each cell, which cells are allowed to reference
> other cells within the same sheet.

Well, unless your users are themselves pretty good programmers, I think
you're making a mistake, but it is yours to make.

And you still haven't addressed how you're going to protect from
ill-behaved or even malicious code.


Randall Schulz
Reply | Threaded
Open this post in threaded view
|

RE: In search of replacing Groovy by Scala

Det2
> There is a reason we invent DSLs. It is because
> general-purpose programming languages are usually too general
> for more narrow purposes and concomitantly laden with details
> that are extraneous and bothersome in a more specific domain.

You are right.
As long as the "narrow purposes" are the target.

OTOH: There is a reason why people want _internal_ DSLs,
backed by a turing complete and feature rich machine.

If not, all the fuss about Scala's embedded XML literals,
about operator-style method calls, about by-name parameters
would be worthless, because the hype argument always was around
"Builds feature rich internal DSLs" and the like.

If we internalise the DSL and so embed it into a Scala program,
why not on the other hand externalise Scala as application scripting
language?

There ARE usescases for application scripting beyond "narrow purposes",
there ARE reasons why programming happens dynamically and where scripts
come from the outside without compile, package, deploy cycles.

There is a reason why we invent DSLs, but there is NO reason why one
should be taken away from Scala syntax and language features for the
other purposes.

> > The nice demo app of this feature (dynamic compile/dynamic
> > evaluation) would be for example a Spreadsheet app, which
> could have
> > Scala expressions in each cell, which cells are allowed to
> reference
> > other cells within the same sheet.
>
> Well, unless your users are themselves pretty good
> programmers, I think you're making a mistake, but it is yours to make.


Well, hum, don't like this specific example either, but I gave other
ones,
where the users are indeed programmers. No reason to require
'pretty good' ones.

> And you still haven't addressed how you're going to protect from
ill-behaved or even malicious code.

Regarding our development tools:

1.) The protection is achieved by the specific objects in the binding.
2.) We want to protect, not to tie down the developers who use the
tools.
    So writing a script that behaves ill is responsibility of the
developer.
    Reg. Malicious:  If he wants to corrupt his own tool, let him, FWIW.

Just my 2ct

Det
Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Ricky Clarkson
I happen to think that using Scala as a DSL for non-techies could be
ok.  You might need to watch them make mistakes and then alter the
messages scalac gives out to dumb them down, and you'll obviously need
to provide a programming guide for whatever subset of Scala you want
them to use.

This may or may not be better than designing your own language.  Most
people would make some/many mistakes that Martin Odersky didn't make,
when designing their own languages, so unless that's what the person
is interested in, I don't think they should feel they need to do it.

It's far too easy to end up stuck in a language that's poorly designed
that you can't change because of backward compatibility.. hey, how did
this topic change into Java?

2009/7/20 Detering Dirk <[hidden email]>:

>> There is a reason we invent DSLs. It is because
>> general-purpose programming languages are usually too general
>> for more narrow purposes and concomitantly laden with details
>> that are extraneous and bothersome in a more specific domain.
>
> You are right.
> As long as the "narrow purposes" are the target.
>
> OTOH: There is a reason why people want _internal_ DSLs,
> backed by a turing complete and feature rich machine.
>
> If not, all the fuss about Scala's embedded XML literals,
> about operator-style method calls, about by-name parameters
> would be worthless, because the hype argument always was around
> "Builds feature rich internal DSLs" and the like.
>
> If we internalise the DSL and so embed it into a Scala program,
> why not on the other hand externalise Scala as application scripting
> language?
>
> There ARE usescases for application scripting beyond "narrow purposes",
> there ARE reasons why programming happens dynamically and where scripts
> come from the outside without compile, package, deploy cycles.
>
> There is a reason why we invent DSLs, but there is NO reason why one
> should be taken away from Scala syntax and language features for the
> other purposes.
>
>> > The nice demo app of this feature (dynamic compile/dynamic
>> > evaluation) would be for example a Spreadsheet app, which
>> could have
>> > Scala expressions in each cell, which cells are allowed to
>> reference
>> > other cells within the same sheet.
>>
>> Well, unless your users are themselves pretty good
>> programmers, I think you're making a mistake, but it is yours to make.
>
>
> Well, hum, don't like this specific example either, but I gave other
> ones,
> where the users are indeed programmers. No reason to require
> 'pretty good' ones.
>
>> And you still haven't addressed how you're going to protect from
> ill-behaved or even malicious code.
>
> Regarding our development tools:
>
> 1.) The protection is achieved by the specific objects in the binding.
> 2.) We want to protect, not to tie down the developers who use the
> tools.
>    So writing a script that behaves ill is responsibility of the
> developer.
>    Reg. Malicious:  If he wants to corrupt his own tool, let him, FWIW.
>
> Just my 2ct
>
> Det
>



--
Ricky Clarkson
Java Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: In search of replacing Groovy by Scala

Det2
> It's far too easy to end up stuck in a language that's poorly
> designed that you can't change because of backward
> compatibility.. hey, how did this topic change into Java?

*LOL*
Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Randall R Schulz-2
In reply to this post by Det2
On Monday July 20 2009, Detering Dirk wrote:
> > There is a reason we invent DSLs. It is because
> > general-purpose programming languages are usually too general
> > for more narrow purposes and concomitantly laden with details
> > that are extraneous and bothersome in a more specific domain.
>
> You are right.
> As long as the "narrow purposes" are the target.

Narrowing the domain and elevating the level of abstraction is the
entire purpose of a DSL.


> OTOH: There is a reason why people want _internal_ DSLs,
> backed by a turing complete and feature rich machine.

About the only thing internal and external DSLs have in common is those
three letters. The context of their use, the criteria for their design,
and the virtues they afford don't much overlapp (beyond the very
generic "provide a way to capture some domain's requiremets in a
language specific to that domain"). Internal DSLs for any given
language that hosts them are still designed for programmers in that
language. External DSLs are for a separate class of users (or, at
least, users wearing different hats than that of a professional
programmer).


> If not, all the fuss about Scala's embedded XML literals,
> about operator-style method calls, about by-name parameters
> would be worthless, because the hype argument always was around
> "Builds feature rich internal DSLs" and the like.

I don't get the point here.


> If we internalise the DSL and so embed it into a Scala program,
> why not on the other hand externalise Scala as application scripting
> language?

Because then you haven't elevated the level of abstraction. We've got
people coming to Scala from Java, Python, Ruby, Groovy (and maybe
others) complaining about the funky squiggles. It's only going to be
worse when people who are not professional software engineers are
confronted with all that low-level power and detail.


> There ARE usescases for application scripting beyond "narrow
> purposes", there ARE reasons why programming happens dynamically and
> where scripts come from the outside without compile, package, deploy
> cycles.

Yes, but those things still don't justify exposing the user of the DSL
to the underlying language.


> There is a reason why we invent DSLs, but there is NO reason why one
> should be taken away from Scala syntax and language features for the
> other purposes.

There may be a small minority of applications where a DSL that fits the
external criteria should be a superset of the host programming
language, but I think they're pretty rare.


> ...
>
> > Well, unless your users are themselves pretty good
> > programmers, I think you're making a mistake, but it is yours to
> > make.
>
> Well, hum, don't like this specific example either, but I gave other
> ones, where the users are indeed programmers. No reason to require
> 'pretty good' ones.

And I addressed this. Scala is off-putting to people who program for a
living. External DSLs are usually for a class of users with primarily
non-programming backgrounds. I don't think they want see or would even
tolerate all the incidental detail that a general-purpose language
presents.


> > And you still haven't addressed how you're going to protect from
> > ill-behaved or even malicious code.
>
> Regarding our development tools:

Whose development tools are you talking about? Do you work with the
original poster?


> 1.) The protection is achieved by the specific objects in the
> binding. 2.) We want to protect, not to tie down the developers who
> use the tools.
>     So writing a script that behaves ill is responsibility of the
> developer.
>     Reg. Malicious:  If he wants to corrupt his own tool, let him,
> FWIW.

Simply shifting the responsibility for the system not malfunctioning to
its users is only acceptable when the only user is the author their
team and there is nothing at stake when bad code is submitted. Again, a
tiny minority of use cases.


> Just my 2ct
>
> Det


Randall Schulz
Reply | Threaded
Open this post in threaded view
|

RE: In search of replacing Groovy by Scala

Tim Pigden
In reply to this post by Albert Kurucz
>>> OTOH: There is a reason why people want _internal_ DSLs,
backed by a turing complete and feature rich machine.

Indeed! I had a nice internal DSL in groovy for defining reports. It was
simply a few extra things tacked onto the standard builder. And I could
use the standard groovy features to drop into complex expressions and
chase around after objects in the internal domain model. We could then
upload new reports without restarting or recompiling the running
(Grails) application - great for getting user acceptance/testing. This
took about 2 or 3 days to develop.
Giving equivalent power in an external DSL would have taken far longer
to develop and would have gained little. I'd certainly want to do the
same in Scala because I can't be bothered with keeping more than 2
programming languages in my head at the same time - and scala would be
more likely to pick up errors first time I tried to run the report
because of strong type checking (and all the reasons we're looking at
Scala instead of Groovy)

And it was as secure as most other things on a web platform because of
access rights to the server.

Tim

Reply | Threaded
Open this post in threaded view
|

RE: In search of replacing Groovy by Scala

Tim Pigden
In reply to this post by Albert Kurucz
>>> There may be a small minority of applications where a DSL that fits
the
external criteria should be a superset of the host programming
language, but I think they're pretty rare.

Hi Randall,

I think the internal/external distinction is a bit of a red herring or
you are taking too narrow a view of what a DSL is. Many external DSLs
are full-blown, sophisticated programming languages. Lots of apps script
with Javascript, and what about Java stored procedures in DB2 and MS
Office and VBA? There is a whole industry built on VBA extensions to MS
Office. So to set these in juxtaposition to scripting in Scala merely
because the underlying engine is C++ (or C or Java or whatever) rather
than being the same language doesn't help. If your DSL needs a full
language then there is no reason to rule out Scala. If the language is
good enough to write the app in then why not write scripts in it too?

Tim

Reply | Threaded
Open this post in threaded view
|

Re: In search of replacing Groovy by Scala

Randall R Schulz-2
On Monday July 20 2009, Tim Pigden wrote:
> >>> There may be a small minority of applications where a DSL that
> >>> fits the external criteria should be a superset of the host
> >>> programming language, but I think they're pretty rare.
>
> Hi Randall,
>
> I think the internal/external distinction is a bit of a red herring
> or you are taking too narrow a view of what a DSL is.

I don't think either of those things are true. Internal DSLs are
integrated with the host language. The Scala combinator parser library
is a good example. External DSLs are entirely apart from the language
that happens to implement them. Among the advantages of an external DSL
and it's separation from the implementation language is the possibility
of rehosting it in a different language or of compiling it to (virtual)
machine code, e.g.


> ... If your DSL needs a full language then there is no reason to
> rule out Scala. If the language is good enough to write the app in
> then why not write scripts in it too?

If your DSL needs a full general-purpose language, it's an internal DSL:
an adjunct to the general-purpose language that hosts it. In that case,
Scala is an excellent choice. By making it an internal DSL, you needn't
do anything to give the user of that DSL access to the host language's
full power.

But the original poster was asking about what was clearly an external
language. He wanted to accept statements / expressions in this language
from outside the program as one of its inputs and then execute or
interpret those statements. And because he wants that external language
to be Scala, he's faced with the level-mixing entailed by that choice.
If he pursues it he will be forced to incorporate the operation of the
Scala compiler into his program. Furthermore, he will be compelled to
deal with all the exigencies that entails, such as supplying the
context required by Scala (a class or classes to hold the vals and defs
that must be implicitly created to evaluate Scala expressions, e.g.)
and handling all the security vulnerabilities created by accepting and
executing arbitrary Scala from outside the program.


There's nothing about any of this that is 100% bad, but I maintain that
the cases in which its a good idea are pretty rare, especially if you
make a careful analysis of whether the language you're creating should
be an internal or an external DSL.


> Tim


Randall Schulz
Reply | Threaded
Open this post in threaded view
|

RE: In search of replacing Groovy by Scala

Tim Pigden
In reply to this post by Albert Kurucz
>> especially if you make a careful analysis of whether the language
you're creating should be an internal or an external DSL

Now I'm confused about where you are putting the boundaries between
internal and external.

To my mind the issues are
a) whether the language is accessible to somebody outside the initial
build-deploy cycle.
b) whether the language permits access to the internal data model of the
application in question.
c) whether it's a rich and effectively unlimited language or whether
it's highly restricted in scope of function (obviously there are points
along the way).

How does your definition relate to these issues?

Tim
12