Tyler Close | 4 Feb 2006 02:00
Picon

A game developer presents needs for future language

A recent post on LtU is relevant to the language design work going
into E and related languages. The post links to a slide set for a
presentation given by someone from the gaming community about what is
needed in a future language. See:

http://lambda-the-ultimate.org/node/1277

One slide in the linked presentation contains the words:

"There is a wonderful correspondence between:
    - Features that aid reliability
    - Features that enable concurrency"

A key insight of the E language.

Other familiar statements can also be found, such as the "threads are
evil" line of thought.

Tyler

--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/extensions/moreinfo.php?id=957
James Graves | 4 Feb 2006 22:43
Favicon
Gravatar

Compiling Java into Scheme


Howdy,

I recently ran across this paper by Katheryn Gray and Matthew Flatt
about compiling Java source code into Scheme source code.  I suspect
that even without a macro system, such a process may work with E as well.

Since the output is supposed to be human-readable, this could be a means
to quickly create native E libraries, rather than relying on wrappers.

http://repository.readscheme.org/ftp/papers/sw2004/gray.pdf

I didn't find any source code on either author's websites.  When I get
done with the paper, I may pester them about that.

At any rate, I didn't think such an approach would be at all feasable,
so it is an interesting approach for that reason alone.

Take care,

James Graves
Lawrence Oluyede | 5 Feb 2006 15:52
Picon
Gravatar

If/else syntax error

I noticed a "wierd" thing in the if/else construct.

Why this is legal

if (2 < 1) {
 # do something
} else { println(3) }

and this

if (2 < 1) {
 # do something
}
else { println(3) }

is not ?

I got a syntax error with the latest version of E.

--
Lawrence
http://www.oluyede.org/blog
Kevin Reid | 5 Feb 2006 16:13

Re: If/else syntax error

On Feb 5, 2006, at 9:52, Lawrence Oluyede wrote:

> I noticed a "wierd" thing in the if/else construct.
>
> Why this is legal
>
>
> if (2 < 1) {
>  # do something
> } else { println(3) }
>
> and this
>
> if (2 < 1) {
>  # do something
> }
> else { println(3) }
>
> is not ?

Because E allows line breaks as 'statement' separators; the second is  
an if expression followed by an expression beginning with the keyword  
"else", which is meaningless.

You can use \, however:

? if (2 < 1) {
 >   # do something
 > } \
 > else { println(3) }
(Continue reading)

Lawrence Oluyede | 5 Feb 2006 16:28
Picon
Gravatar

Re: If/else syntax error

> Because E allows line breaks as 'statement' separators; the second is
> an if expression followed by an expression beginning with the keyword
> "else", which is meaningless.

I thought the parser made a difference on that behavior because "}"
means and of block. Anyway, thanks for the explanation.

--
Lawrence
http://www.oluyede.org/blog
Constantine Plotnikov | 5 Feb 2006 21:34

Somewhat offtopic: Extensible Term Language

As I have written long time ago, I’m currently working on open
source project that has a goal to create a language definition
framework that can be used as textual DSL construction kit.
The framework is currently named Extensible Term Language
(ETL).

This language definition framework is very similar by architecture
to XML.

* There is language definition language that is defined using
framework itself (this aspect is more like XML Schema or
Relax NG rather than DTD). This is a basic dog-food test for
such framework.

* It works with plain text.
- Non ETL-aware editors can work with languages defined using
ETL. This is how I'm living now.
- There is no special hidden markup.
- It is possible to have and edit incorrect text. Even if
syntax changes (for example some keyword is renamed).
It is possible to fix source using normal text manipulation
tools.

* It allows for agile definition of underlying model, language,
and instance sources.

* The syntax has underlying document object model.

* There may be a lot of different implementation of parsers and many
models of parser like AST, DOM, push, or pull parsers.
(Continue reading)

Mark S. Miller | 6 Feb 2006 04:29

Re: Somewhat offtopic: Extensible Term Language

Constantine Plotnikov wrote:
> As I have written long time ago, I’m currently working on open
> source project that has a goal to create a language definition
> framework that can be used as textual DSL construction kit.
> The framework is currently named Extensible Term Language
> (ETL).

Hi Constantine,

Given what you're working on, you may interested in E's draft schema language 
and its two surface syntaxes.

Below, I include first the schema.schema file, which defines the tree-grammar 
of the ASTs of E's schema language. This language has two surface syntaxes: 
term.y defines the surface syntax that schema.schema itself is written in, and 
grammar.y defines a surface syntax suitable for expressing grammars over 
sequences (see comments below).
Following this file, I show a E shell session in which I parse schema.schema 
into a term-tree which represents its AST, and which conforms to the 
tree-grammar it specifies.

I wrote all this ages ago, with the fantasy that someday someone would build a 
parser generator to generate parsers from these grammar descriptions. I'm 
ecstatic to report that Dean Tribble is now making progress on a Packrat-like 
parser generator, written in E and generating E, able to process a useful 
subset of the schema language below. Hopefully, this will enable E to 
self-host its own parser. Eventually it should be practical to use this 
language to generate quasi-parsers as well.

Contents of src/bin/resources/quasiliteral/schema/schema.schema
(Continue reading)

Mark S. Miller | 6 Feb 2006 04:47

Re: Somewhat offtopic: Extensible Term Language

Please view my previous message in a fixed width font.

Mark S. Miller wrote:
> # The language in which term-tree quasiliterals are expressed is the 
> variant
> # of this grammar whose start symbol is <tt>&lt;rhs&gt;</tt> rather than
> # <tt>&lt;schema&gt;</tt>.

Besides the files in the E distributed mentioned in schema.schema, additional 
information about E's term trees can be found at
http://www.erights.org/data/terml/index.html
Some hints of the power of term-tree quasiliterals can be found at
http://www.erights.org/elang/quasi/terms/like-ellipses.html

--

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

     Cheers,
     --MarkM
Constantine Plotnikov | 6 Feb 2006 10:00

Re: Somewhat offtopic: Extensible Term Language

I have put documentation and some XML files generated from samples to 
the project web site:

Start with http://etl.sourceforge.net/etl-java-0_2_0/doc/readme.html

Constantine
Rob Jellinghaus | 8 Feb 2006 23:23

Re: A game developer presents needs for future language

At 09:00 AM 2/4/2006, Tyler Close wrote:
>A game developer presents needs for future language

The game developer in question is Tim Sweeney, technical lead of what is 
probably the pre-eminent next-generation gaming middleware company.

It's interesting that I read his presentation very differently than 
Tyler.  He makes very clear in the presentation that one of the primary 
requirements for next-gen midedleware is making it possible to parallelize 
gameplay logic.  Modern games have an object set that can be 10,000 objects 
(and many more in the future).  Gameplay interactions, which occur hundreds 
or thousands of times per second, may involve anywhere from 5 to 50 objects 
in imperative updates.

The key issue here is that this object set is co-resident.  Any object may 
(generally doesn't, but may) interact with any other(s) at any time; those 
interactions need to be maximally fast.

In the presentation, Sweeney suggests that software transactional memory is 
the right abstraction for this problem space, since it supports optimistic 
concurrency (i.e. interactions are permitted unless collisions are 
detected, in which case at least one transaction still commits, resulting 
in progress).

It's not clear to me that E makes any sense in this context.  The gameplay 
objects are all mutually trusting (at least, in the types of games Sweeney 
is most concerned with).  His main concern is with conflicting updates to 
objects, especially insofar as multiple objects must be consistently 
updated (with transactional semantics -- your ammunition must be depleted, 
and their health must be decreased, or there's a bug).  A pure 
(Continue reading)


Gmane