headers
Tyler Close | 1 Nov 2003 19:29

Is Groovy syntax E-like?

Came across a link to a JVM hosted language called Groovy.

http://groovy.codehaus.org/

The Introduction says:

"Groovy is a powerful new high level dynamic language for the JVM
combining lots of great features from languages like Python, Ruby
and Smalltalk and making them available to the Java developers
using a Java-like syntax.

Groovy is designed to help you get things done on the Java
platform in a quicker, more concise and fun way - bringing the
power of Python and Ruby inside the Java platform.

Groovy can be used as an alternative compiler to javac to generate
standard Java bytecode to be used by any Java project or it can be
used dynamically as an alternative language such as for writing
scripts or unit test cases."

The language's stated aims align well with the aims of the E
language. See:

http://wiki.codehaus.org/groovy/AimsOfGroovy

It appears as if there is substantial duplication of effort
between these two projects. Is a merger possible?

Tyler
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark S. Miller | 1 Nov 2003 20:27

Re: Is Groovy syntax E-like?

At 10:29 AM 11/1/2003  Saturday, Tyler Close wrote:
>The language's stated aims align well with the aims of the E
>language. See:
>
>http://wiki.codehaus.org/groovy/AimsOfGroovy
>
>It appears as if there is substantial duplication of effort
>between these two projects. Is a merger possible?

This list doesn't include anything about security (capability or otherwise), 
concurrency (event loop or otherwise), or distribution (semi-transparent or 
otherwise). As these are the high order bits of E's rationale, I'm not sure 
what kind of merger you might have in mind. Also, they seem to be defining 
Groovy to be JVM specific, while E is currently struggling to gain 
independence from the JVM.

Certainly, languages with overlapping goals should learn from and influence 
each other. But beyond that... ?

----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM
Permalink | Reply | 1 comment |
headers
Tyler Close | 1 Nov 2003 22:28

Re: Is Groovy syntax E-like?

On Saturday 01 November 2003 15:27, Mark S. Miller wrote:
> At 10:29 AM 11/1/2003  Saturday, Tyler Close wrote:
> >The language's stated aims align well with the aims of the E
> >language. See:
> >
> >http://wiki.codehaus.org/groovy/AimsOfGroovy
> >
> >It appears as if there is substantial duplication of effort
> >between these two projects. Is a merger possible?
>
> This list doesn't include anything about security (capability or
> otherwise), concurrency (event loop or otherwise), or distribution
> (semi-transparent or otherwise). As these are the high order bits of E's
> rationale, I'm not sure what kind of merger you might have in mind.

Their list might be a subset of the E list.  The E language might
be able to meet their needs. If so, the compiler code would be
useful to both projects.

If you look at their mailing list archive, you might notice a
striking similarity to the initial threads on the e-lang list. The
thread on syntax for maps, sets and lists looks like the first
thread on the e-lang list.

> Also, they seem to be defining Groovy to be JVM specific, while
> E is currently struggling to gain independence from the JVM.

One of the options you proposed was a fancy compiler that was able
to use type information to transform reflective invocations into
compiled ones. As the Groovy project is also building a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark S. Miller | 2 Nov 2003 18:20

Fwd: [groovy-dev] Groovy Thread on e-lang

To follow up on Tyler's suggestion, I just posted the following to groovy-dev.

>To: groovy-dev@...
>From: "Mark S. Miller" <markm@...>
>Subject: [groovy-dev] Groovy Thread on e-lang
>List-Subscribe: <http://lists.codehaus.org/mailman/listinfo/groovy-dev>,
>        <mailto:groovy-dev-request@...?subject=subscribe>
>List-Archive: <http://lists.codehaus.org/pipermail/groovy-dev/>
>Date: Sun, 02 Nov 2003 09:10:15 -0800
>
>
>Tyler Close, one of the members of the e-lang community, suggests, in the 
>thread starting at 
>http://www.eros-os.org/pipermail/e-lang/2003-November/009214.html , that 
>there may be some useful cross-fertilization between the E and Groovy 
>projects. More than you ever wanted to know about E can be found at 
>http://www.erights.org . Tyler proposes that Groovy's stated goals are a 
>subset of E's, so here's a first cut commentary on Groovy's goals from E's 
>perspective:
>
>>* Concise dynamically yet strongly typed HighLevelLanguage for writing 
>>PlainOldJavaObjects and TestCases and ScriptingObjects. 
>
>Rather similar, but E is currently struggling to gain independence from the 
>JVM, while Groovy's goals are wedded to the JVM. Also, the semantics and 
>style of E's objects are different from Java's objects. As one of many 
>examples, E methods can only be overloaded on arity (number of parameters), 
>not on the types of the parameters.
>
>>* JavaClassCompatible to allow for using/extending existing Java classes and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Hibbert | 2 Nov 2003 19:03
Gravatar

[groovy-dev] re: Groovy Thread on e-lang

[Sent to both e-lang and groovy-dev.]

MarkM wrote:
 > >* SupportStaticClassConstant
 >
 >E has no classes

While it's true that E doesn't have Classes in the sense that it would 
take to support Class constants, this is too quick an answer to do 
justice to E on a list for people familiar with OO languages.

E doesn't reify classes at run-time; there is no object representing 
the class, and thus no place in the language to share state among the 
objects of a class.  But E does provide syntactic support in the 
language for defining classes of objects.  Most of the people working 
with E have a long history of OO programming, and think in terms of 
encapsulated objects.

On the scale of building objects with classes (e.g. Smalltalk), versus 
prototypes (Self), or each one unique (Actor), E is in the camp with 
Smalltalk, though the ability to build lightweight one-off objects for 
callbacks and the like is probably as easy as it was in Actors.

Chris
--

-- 
   Pictures from my trip to the Four Corners area:
    http://discuss.foresight.org/~hibbert/Canyon02/canyon.html

Chris Hibbert
hibbert@...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Constantine Plotnikov | 4 Nov 2003 14:34

Language skins for E runtime

Hi!

Are parsing of E language and E runtime separated well enough to create 
other langauge skin for E runtime?

I'm experementing with a bit untraditional parsing technology and want 
to check how well it supports defining functional languages. As one of 
case studies I would like to create other language skin for E runtime 
(like C# and VB.NET are for CLI).

It could be also useful for other purposes, for example others could 
experiment with backward incompatible features like mandatory returns.

Selection of langauge before parsing could be done by extension or if 
extension is .e or .emaker by comment at start of file like:
#!/bin/env rune -srcversion 0.18.100experimental_mandatory_return

Mapping of file extension or version number to parser class could be 
done by some property file for E. This would also allow to break 
backward compatiblity in future and retire older version smoothly.

Constantine
Permalink | Reply | 1 comment |
headers
Mark S. Miller | 4 Nov 2003 17:13

Re: Language skins for E runtime

At 05:34 AM 11/4/2003  Tuesday, Constantine Plotnikov wrote:
>Are parsing of E language and E runtime separated well enough to create 
>other langauge skin for E runtime?

I'd never thought of calling them "skins" before, but this is clearly a 
better term than "surface syntax".

In any case, the answer is yes, at two different levels.

The E semantics of inter-object interaction ("apply") is given by ELib. ELib 
is defined as a layer below ELang, and has no dependencies on ELang. ELang 
provides E's semantics for what happens within an E object ("eval"). For a 
language built on ELib to provide essentially the same security as is 
provided by ELang, mostly it need merely assure that there is no causality 
into or out of its objects other than through ELib. Further, all mutable 
state must be multiply instantiable ("no static state"), and all sources of 
authority must be granted explicitly ("no static authority"). All sources of 
authority should also be virtualizable. A language built on ELib in this way 
will also have E's semi-transparent distribution essentially for free.
Of course, the way in which ELang is built on ELib should serve as an 
example of how to build other languages on ELib.

Within ELang, the E parser expands E source code to Expanded-E, which is 
then transformed to Bound-E, and then to Kernel-E, all of which are quite 
similar, and use the same AST nodes for their representation. Any of these 
representations correspond to what we mean when we refer to the "Kernel-E" 
language. Just as the JVM's execution contract is defined by JVM class 
files, not by Java, the E Virtual Machine's execution contract is based on 
accepting Bound-E ASTs as the form in which code is presented for execution, 
and on presenting the corresponding Kernel-E fragments to any Auditors of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kazunori UEDA | 5 Nov 2003 12:36
Picon

ASIAN'03 -- Call for Participation

		  Call for Participation ---ASIAN'03
	      Eighth Asian Computing Science Conference

		 Mumbai, India, December 10-12, 2003
		Collocated with ICLP'03 and FSTTCS'03
		   http://www.cse.psu.edu/asian03/

The Eighth Asian Computing Science Conference, ASIAN'03, will be held
at Tata Institute of Fundamental Research, Mumbai, India, collocatied
with ICLP'03 (Dec.9-13, workshops Dec.8+14) and FSTTCS'03 (Dec.15-17,
workshops Dec.14).

The series of Asian Computing Science Conferences was started in 1995
to provide a forum for researchers in computer science from the Asian
region and to promote interaction with researchers from other regions.
The proceedings have been published as Springer LNCS volumes.

The theme of this year's conference is Programming Languages and
Distributed Computation.  The conference features three invited talks 
by

 - Greg Morrisett (Cornell Univ., USA),
 - Mark Miller (Hewlett Packard Lab. and Johns Hopkins Univ., USA), and
 - Andrew Birrell (Microsoft Research, USA),

as well as sixteen refereed papers selected from 53 submissions.

Registration
------------
Travel Information and Registration Details can be found at the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kazunori UEDA | 5 Nov 2003 12:36
Picon

ASIAN'03 -- Call for Participation

[----- The Types Forum, http://www.cis.upenn.edu/~bcpierce/types -----]

		  Call for Participation ---ASIAN'03
	      Eighth Asian Computing Science Conference

		 Mumbai, India, December 10-12, 2003
		Collocated with ICLP'03 and FSTTCS'03
		   http://www.cse.psu.edu/asian03/

The Eighth Asian Computing Science Conference, ASIAN'03, will be held
at Tata Institute of Fundamental Research, Mumbai, India, collocatied
with ICLP'03 (Dec.9-13, workshops Dec.8+14) and FSTTCS'03 (Dec.15-17,
workshops Dec.14).

The series of Asian Computing Science Conferences was started in 1995
to provide a forum for researchers in computer science from the Asian
region and to promote interaction with researchers from other regions.
The proceedings have been published as Springer LNCS volumes.

The theme of this year's conference is Programming Languages and
Distributed Computation.  The conference features three invited talks 
by

 - Greg Morrisett (Cornell Univ., USA),
 - Mark Miller (Hewlett Packard Lab. and Johns Hopkins Univ., USA), and
 - Andrew Birrell (Microsoft Research, USA),

as well as sixteen refereed papers selected from 53 submissions.

Registration
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Reid | 5 Nov 2003 21:46

Bug: e.safej.bind-var-to-varName=false breaks universal scope's 'char' and 'float64'

I just installed E 0.8.23d. I set e.safej.bind-var-to-varName to false.
Doing so caused this problem:

? float64
# problem: <NoSuchMethodException: <a Double__Maker>.TYPE/0>
#
#   <import:java.lang.Double>.TYPE()
#   <import:java.lang.Double>.TYPE()
#   <import:java.lang.Double>.TYPE()
#   e`float64`.eval(<an OuterScope>)
#   ***  <at> 
<jar:file:/Stuff/e/e.jar!/org/erights/e/elang/cmd/cmdMakerMaker.emaker#:
span::75:25::75:28>

Assuming that the statement in eprops.txt that "This binding is hereby
deprecated, and we expect to set this property to false by default in a
future release." is true, then this should be corrected to be getTYPE().

The relevant code appears to be in
jsrc/org/erights/e/elang/interp/ScopeSetup.java lines 179 and 182.

Other occurrences of .TYPE():

$ grep -rn '[. ]TYPE(' src/ 
src/esrc/caplets/capWebServer/sampleDocRoot/ewalnut.html:1432:
  def byte := &lt;unsafe:java.lang.Byte&gt; TYPE()
src/esrc/com/skyhunter/capDesk/makeFileNavigatorAuthor.emaker:8:
      def byte := <import:java.lang.Byte> TYPE()
src/esrc/scripts/webServer/ewalnut.html:1432:
  def byte := &lt;unsafe:java.lang.Byte&gt; TYPE()
(Continue reading)

Permalink | Reply | 7 comments |

Gmane