new Java lambda syntax

A

Arne Vajhøj

Beg your pardon, I haven't followed this issue as closely as I probably
have should, but does this all mean lambdas are always Runnables? Never
Callable<T>s? IOW, no return values?

Lambdas can be anything.

In this example they are Runnable's because they are
being run later.

Arne
 
J

Joshua Cranmer

Beg your pardon, I haven't followed this issue as closely as I probably
have should, but does this all mean lambdas are always Runnables? Never
Callable<T>s? IOW, no return values?

No, I just opted for Runnable here because it was simple.
 
D

Daniele Futtorovic

No, I just opted for Runnable here because it was simple.

Okay, so you can have a lambda returning a value? Steve Simpson's statement:
There's no (...) long jumps (break, continue, return, throw)

seemed to contradict that, as did Tom's about the "Gafterist nonsense"
(<3), seeing how Gafter et al.'s proposal contained return values, IIRC.

I mean, if they cannot return values, I'm a bit at a loss understanding
how they'll be the nec plus ultra for parallel computing... you'd
publish results to a shared queue, I suppose, but that's a bit unhandy.
 
J

Joshua Cranmer

Okay, so you can have a lambda returning a value? Steve Simpson's statement:


seemed to contradict that, as did Tom's about the "Gafterist nonsense"
(<3), seeing how Gafter et al.'s proposal contained return values, IIRC.

What this is referring to is that lambdas do not have non-local control
flow (the so-called "long jump" -- think about C's setjmp/longjmp
feature [1]). Lambdas are effectively "mini-functions", so I could have
a lambda that looked like this:

(int[] x, int y) => {
for (int i = 0; i < x.length; i++)
if (x == y) return i;
return -1;
};

which would effectively be a method that looked like:
int searchList(int[] x, int y) {
for (int i = 0; i < x.length; i++)
if (x == y) return i;
return -1;
}

In other words, what was not accepted was the thing that pissed me off
about some of the proposals, namely that any block of statements should
do the exact same thing if you wrapped it with ((){/*insert stmt*/})() [2].

So this would return true:
boolean foo() {
((){ return true; })();
return false;
}

Obviously, if you want to have more complex logic in the lambda for
returning multiple values other than what you can do in a simple
expression, you'd need some sort of syntax. The compromise then being
discussed would make this method return false:
boolean foo() {
((){ return true })();
return false;
}

....

It was at that point that I personally hated non-local control flow in
closures, er, lambdas. [3]

[1] Actually, don't. It breaks so many things.
[2] This is, supposedly, Tennent's Correspondence Principle. I say
supposedly since a google search only reveals results that are
specifically brought up in reference to the closures debate in JS and Java.
[3] Actually, doing some more research for this posting, it struck me
that the primary rationale for non-local control flow comes from the
heritage of lambdas. Most of the time, lambdas are used in reference to
functional programming paradigms, and in the purer functional languages,
control flow is not done via explicit constructs but rather via specific
function calls. So it's a list.forEach( { body of loop }) as opposed to
a for (Element e : list) { body of loop }; in such languages, non-local
control flow is more important. However, given that Java is more
imperatively structured than functionally structured, non-local control
flow is by means no natural, nor is it necessary to implement, so I
would still stand by my claim that non-local control flow is not a
feature that should be implemented in Java's version of lambdas. For
example, C++11 appears to omit it in their version of lambdas...
 
T

Tom Anderson

Okay, so you can have a lambda returning a value? Steve Simpson's statement:


seemed to contradict that, as did Tom's about the "Gafterist nonsense"
(<3), seeing how Gafter et al.'s proposal contained return values, IIRC.

Brachaism-Gafterism is the CANCER THAT IS KILLING JAVA!!
I mean, if they cannot return values, I'm a bit at a loss understanding
how they'll be the nec plus ultra for parallel computing... you'd
publish results to a shared queue, I suppose, but that's a bit unhandy.

A lambda can return a value. It just can't return it from another method.

You will be able to say (something like):

Callable<String> one = () => {return "uno";};
String s = one.call();
assert s.equals("uno");

You will not be able to say:

String thisIsWhatBGGAWanted() {
Callable<String> one = () => {return "uno";};
one.call();
return "ein";
}
String s = thisIsWhatBGGAWanted();
assert s.equals("uno");

Basically, lambdas can be either method-like (they return values from
themselves) or statement-like (they return values from their enclosing
methods). Lambdas are method-like in all the current dynamic languages
(AFAIK - they certainly are in Smalltalk, Python and Javascript). The BGGA
proposal (and i remember this coming from Gafter in particular, BICBW)
would have made them statement-like.

The rationale was that enclosing any given wodge of code in a lambda
definition immediately followed by an invocation of that lambda would not
change the behaviour of the code. This seemed dubious to me, and would
have led to very weird programming experiences. It would, though, have
enabled a wider range of funky control structures implemented on top of
lambdas, which some people are very keen on.

tom
 
D

Daniele Futtorovic

Okay, so you can have a lambda returning a value? Steve Simpson's
statement:


seemed to contradict that, as did Tom's about the "Gafterist nonsense"
(<3), seeing how Gafter et al.'s proposal contained return values, IIRC.

What this is referring to is that lambdas do not have non-local control
flow (the so-called "long jump" -- think about C's setjmp/longjmp
feature [1]). Lambdas are effectively "mini-functions", so I could have
a lambda that looked like this:

(int[] x, int y) => {
for (int i = 0; i < x.length; i++)
if (x == y) return i;
return -1;
};

which would effectively be a method that looked like:
int searchList(int[] x, int y) {
for (int i = 0; i < x.length; i++)
if (x == y) return i;
return -1;
}

In other words, what was not accepted was the thing that pissed me off
about some of the proposals, namely that any block of statements should
do the exact same thing if you wrapped it with ((){/*insert stmt*/})() [2].

So this would return true:
boolean foo() {
((){ return true; })();
return false;
}

Obviously, if you want to have more complex logic in the lambda for
returning multiple values other than what you can do in a simple
expression, you'd need some sort of syntax. The compromise then being
discussed would make this method return false:
boolean foo() {
((){ return true })();
return false;
}

....

It was at that point that I personally hated non-local control flow in
closures, er, lambdas. [3]

[1] Actually, don't. It breaks so many things.
[2] This is, supposedly, Tennent's Correspondence Principle. I say
supposedly since a google search only reveals results that are
specifically brought up in reference to the closures debate in JS and Java.
[3] Actually, doing some more research for this posting, it struck me
that the primary rationale for non-local control flow comes from the
heritage of lambdas. Most of the time, lambdas are used in reference to
functional programming paradigms, and in the purer functional languages,
control flow is not done via explicit constructs but rather via specific
function calls. So it's a list.forEach( { body of loop }) as opposed to
a for (Element e : list) { body of loop }; in such languages, non-local
control flow is more important. However, given that Java is more
imperatively structured than functionally structured, non-local control
flow is by means no natural, nor is it necessary to implement, so I
would still stand by my claim that non-local control flow is not a
feature that should be implemented in Java's version of lambdas. For
example, C++11 appears to omit it in their version of lambdas...


Lovely. I welcome that decision, then, and humbly thank you and Tom for
your elaborations.
 
S

supercalifragilisticexpialadiamaticonormalizeringe

Basically, lambdas can be either method-like (they return values from
themselves) or statement-like (they return values from their enclosing
methods).

Smalltalk blocks can do both. The usual return operator ^foo returns foo
from the enclosing method, but the if the block doesn't do a nonlocal
return or exception throw of any kind it evaluates to a value which is
equal to that resulting from the last expression inside of it. So:

[:a | ^(a + 1)] value: 3

returns 4 from the enclosing method;

[:a | (a + 1)] value: 3

returns 4 into the enclosing scope; and

[:a :b | b ifTrue: [^a] ifFalse: [a]] value: 3 value: x

returns 3 from the enclosing method if x is true and evaluates to 3
otherwise.

Yes, this can be confusing. But blocks are used to implement ifs, loops,
and other control structures so this ability seems necessary,
particularly to have any way to break out of a loop early, say because
you found something. It also means that Smalltalk methods and blocks are
fundamentally different things, whereas the Java lambda proposal
generates methods under the hood, rather than some new, separate
freestanding-function category of thing.
Lambdas are method-like in all the current dynamic languages
(AFAIK - they certainly are in Smalltalk, Python and Javascript).

Um, not really; see above. Smalltalk blocks are objects, and the value:,
value: value:, etc. methods can be called on them to run their code, but
they aren't themselves methods. In particular, they are different
classes in the Smalltalk object system: BlockContext vs. CompiledMethod.

If you meant though that they can evaluate to a value, that's true. On
the other hand if you meant they can't also nonlocal-return, that's not
true.

Incidentally, you can implement the behavior of Smalltalk blocks in even
Java 1.1, with a class something like:

public class BlockReturn extends RuntimeException {
public final Object value;
public BlockReturn (x) { value = x; }
}

public interface Block {
Object do (Object x);
}

....

public static Vector forEach (Vector i, Block b) {
Vector res = new Vector();
for (Enumeration e = v.elements(); e.hasMoreElements();) {
res.addElement(b.do(e.nextElement()));
}
return res;
}

....

public Object nullOrHashCodes (Vector v) {
try {
return forEach(v, new Block() { public Object do (Object x) {
if (x == null) throw new BlockReturn(null);
return Integer.valueOf(x.hashCode());
}}
} catch (BlockException b) { return b.value; }
}

That last should end up taking a vector and returning null if it
contains nulls and otherwise a vector of Integers equal to the hash
codes, in order, of the objects in the input vector. Obviously, it's not
idiomatic Java 1.1, let alone idiomatic Java SE 6 where you'd just use a
foreach loop over a List, but it is isomorphic to how you'd do something
like that in Smalltalk, where it would be something like

coll collect: [:x | x ifNil: [^nil] ifNotNil: [x hash]]
The rationale was that enclosing any given wodge of code in a lambda
definition immediately followed by an invocation of that lambda would
not change the behaviour of the code. This seemed dubious to me, and
would have led to very weird programming experiences. It would, though,
have enabled a wider range of funky control structures implemented on
top of lambdas, which some people are very keen on.

Smalltalkers, probably. Possibly Lispers too, though in Lisp lambdas
can't nonlocally return; Lispers implement new control structures using
macros instead, at least in the case that they need short-circuiting
behavior under some circumstances, such as loops in the bodies of which
there's some kind of break statement analogue possible. But both
Smalltalkers and Lispers are used to being able to implement new control
structures inside of their language.

It's not the first thing they'd probably miss in Javaland, though; the
lack of an interactive transcript would probably top the list, and the
limited reflection/introspection capabilities would come a close second.
It's easy to create new functions, methods, or classes on the fly at
runtime, for example, in those but not in Java. In fact, this is related
to Java's lack of an interactive transcript, in that that degree of
runtime reflection capability is needed to implement such a transcript
if it's to be possible to enter new code or bugfixes at it and not just
run ad hoc tests of existing code. (Not to mention, Windows-based
Lispers tend to use their Lisp repl as a command line shell in
preference to Windows's crummy cmd.exe. But inability to define new
functions at the repl would make it much less useful for such, since you
couldn't write ad hoc scripts and thus couldn't do the equivalent of
sed, awk, and perl hacking at it. For that matter, you'd lack lambdas
too, since using a lambda at the repl implicitly defines a new function,
so even doing something as simple as get a list of files in some
directory, sort descending by size, and return that list would become
impossible given that Lisp sort functions tend to expect the less-than
relation to use to be provided via lambda and tend not to already have a
built-in function that implements a less-than relation on files that is
based on file size.)
 
J

Joshua Cranmer

Basically, lambdas can be either method-like (they return values from
themselves) or statement-like (they return values from their enclosing
methods). Lambdas are method-like in all the current dynamic languages
(AFAIK - they certainly are in Smalltalk, Python and Javascript).

As I recall, Smalltalk lambdas were actually discrete blocks (Smalltalk
has (almost? [1]) no control structure primitives, and I distinctly
recall them allowing non-local control flow, since actual structures as
we know them in Java and its ilk don't exist. Python's lambdas are
single expressions (in a language that distinguishes between expressions
and statements), so it can't really be classified as statement-like or
method-like easily. JavaScript actually doesn't have lambdas [2], it
just has first-class functions that can be defined anywhere.

A more natural breakdown of lambdas, or at least clearer, is on whether
or not the lambdas are designed primarily for thunking expressions
(e.g., the parameter to a sort method), or if they are designed for
implementing control structure.

[1] My only exposure to Smalltalk was in my software engineering class
(don't ask), so we never really discussed any implications of its
functional paradigm.
[2] Actually, distinguishing between a lambda and a function is
sometimes difficult and perhaps pointless. The basic definition I'm
using here is meaningful only for object-oriented languages, and it's
the question of does `this' (or equivalent) refer to the same `this' as
in the enclosing scope or not. JS doesn't support OO in the classical
way, and how `this' gets resolved is actually handled by the way you
call the method. Another metric is whether or not the syntax of defining
a lambda is the same as a regular method call.
 
S

supercalifragilisticexpialadiamaticonormalizeringe

Basically, lambdas can be either method-like (they return values from
themselves) or statement-like (they return values from their enclosing
methods). Lambdas are method-like in all the current dynamic languages
(AFAIK - they certainly are in Smalltalk, Python and Javascript).

As I recall, Smalltalk lambdas were actually discrete blocks (Smalltalk
has (almost? [1]) no control structure primitives,

I seem to recall it having exactly one: method dispatch. Even blocks are
invoked by calling value:, value:value:, valueWithArguments:, etc.
methods on them. (The low level guts are ultimately accessed by methods
declared primitive, something like Java methods that are declared
native. Obviously the native code has its own control structures,
typically those of C. And ultimately it's the various branch and
compare-and-branch instructions of the hardware that implement
everything at the level of the metal.)
 
S

supercalifragilisticexpialadiamaticonormalizeringe

Basically, lambdas can be either method-like (they return values from
themselves) or statement-like (they return values from their enclosing
methods). Lambdas are method-like in all the current dynamic languages
(AFAIK - they certainly are in Smalltalk, Python and Javascript).

As I recall, Smalltalk lambdas were actually discrete blocks (Smalltalk
has (almost? [1]) no control structure primitives,

I seem to recall it having exactly one: method dispatch.
No, sorry: it was Dispatch Method.
DM: like Digital Menses? From times when I get
to wear my skirts /giggle
I was thinking of lits.
That lits I am on? Worse than snorting coke is my lits!

Leave about fucking with my lits and I get total Xross!
Nobody talks to me but me. Got it?

--- . ... ..- ... <[email protected]>
00101010 <[email protected]>
3k7e4intna <[email protected]>
3x7r4vagan <[email protected]>
3x+r4v4g4n <[email protected]>
Alice <[email protected]>
Arne Këndoj <[email protected]>
Boojum <[email protected]>
B1ll Gat3s <[email protected]>
Canuck <[email protected]>
ClassCastException <[email protected]>
Cthun <[email protected]>
Chad Carmichael <[email protected]>
dark-zark-fark <[email protected]>
Deep Green <[email protected]> (forgery)
Deeyana <[email protected]>
De Lurker <[email protected]>
Derek Yancey <[email protected]>
Extravagan <[email protected]>
Ferdinand the -14th <[email protected]>
Fuschia, President-Elect of the Bright Purplish-Green Council <[email protected]>
George Arctos <[email protected]>
Greg Kelly <[email protected]>
Greg Sandoval <[email protected]>
Gheerax IV <[email protected]>
Handkea fumosa <[email protected]>
Hieronymus S. Freely <[email protected]>
Hydrocon <[email protected]>
Henry Harrison <[email protected]>
Henderson <[email protected]>
Heike Svensson <[email protected]>
Harry Greer <[email protected]>
Janie Zanie <[email protected]>
Jerry Gerrone <[email protected]>
John Kirkpatrick XVII <[email protected]>
Katie Gerrolds <[email protected]>
Kevin Hadron <[email protected]>
kensi <[email protected]>
KitKat <[email protected]>
Meerkats <[email protected]> (forgery)
Mister Scott <[email protected]>
Mrs. Danforth <[email protected]>
Mike Faramis <[email protected]>
Mamac <[email protected]>
Nancy 3 <[email protected]>
Nancy 4 <[email protected]> (forgery)
Nebulous <[email protected]>
Nightcrawler <[email protected]>
Nougat Surprise <[email protected]>
Orange Green <[email protected]>
Paul Derbysh!re <[email protected]>
Purpleswandir <[email protected]>
RichB <[email protected]>
(e-mail address removed)
SFTV_troll <[email protected]>
Sulfide Eater <[email protected]>
<supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>
Spock <[email protected]>
Series Expansion <[email protected]>
Seamus MacRae <[email protected]>
Snicker-snack! <[email protected]>
Tim <[email protected]>
Thursday's Leftovers <[email protected]>
thoolen <[email protected]>
thoolen <[email protected]>
thoolen <[email protected]>
<[email protected]>
Willy Wonka <[email protected]>
 
S

supercalifragilisticexpialadiamaticonormalizeringe

Basically, lambdas can be either method-like (they return values from
themselves) or statement-like (they return values from their enclosing
methods). Lambdas are method-like in all the current dynamic languages
(AFAIK - they certainly are in Smalltalk, Python and Javascript).

As I recall, Smalltalk lambdas were actually discrete blocks (Smalltalk
has (almost? [1]) no control structure primitives,

I seem to recall it having exactly one: method dispatch. No, sorry: it
was Dispatch Method. DM: like Digital Menses? From times when I get to
wear my skirts /giggle
I was thinking of lits. That lits I am on? Worse than snorting coke is
my lits!

Leave about fucking with my lits and I get total Xross!
Nobody talks to me but me. Got it?

What the **** is this? I didn't write this, yet it shows up in my
newsreader as if I did.

Whoever is pulling childish pranks: please piss off and let us adults
discuss computer programming in peace.

There may be newsgroups where your brand of silliness is appropriate.
However, the comp.* newsgroups are certainly *not* among them.
 
A

Arved Sandstrom

On 11-09-13 11:36 PM, Joshua Cranmer wrote:
[ SNIP ]

JS doesn't support OO in the classical
way, and how `this' gets resolved is actually handled by the way you
call the method.
[ SNIP ]

I point out somewhat tongue-in-cheek that JavaScript indeed isn't
"classical" OO, since it's not class-based OO; rather it's object-based
(prototype-based) OO. I think the argument can be made that it's a purer
and more fundamental object-orientation, since you dispense with the
class baggage.

I confess to being seriously biased: lots of experimentation with
non-Web JS programming, and Self and Lua programming. And certainly some
strengths of Scala lead one to think more about runtime objects and not
so much about instances of classes.

Even though "classical" is strictly speaking a correct description of
class-based OO, I sort of prefer "dominant" or "original". Or just
"class-based". Again revealing my bias, I think class-based OO has done
some degree of harm to object-oriented programming, so I am reluctant to
associate it with a word like "classical".

AHS
 
W

winkleMeister

AIOE.org UID string: b5kJAimWrsL2GXuQEHm5xA.user.speranza.aioe.org

From: 3x7r4vagan <[email protected]>
Newsgroups: comp.os.os2.advocacy
Subject: Re: Mark Morgan, World Class Moron
Date: Tue, 13 Sep 2011 22:51:38 -0400
Message-ID: <[email protected]>
NNTP-Posting-Host: b5kJAimWrsL2GXuQEHm5xA.user.speranza.aioe.org

From: supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: new Java lambda syntax
Date: Tue, 13 Sep 2011 22:49:48 -0400
Message-ID: <[email protected]>
NNTP-Posting-Host: b5kJAimWrsL2GXuQEHm5xA.user.speranza.aioe.org

hi seamus!

i winkles you out LOL LOL
 
S

supercalifragilisticexpialadiamaticonormalizeringe

Basically, lambdas can be either method-like (they return values from
themselves) or statement-like (they return values from their enclosing
methods). Lambdas are method-like in all the current dynamic languages
(AFAIK - they certainly are in Smalltalk, Python and Javascript).

As I recall, Smalltalk lambdas were actually discrete blocks (Smalltalk
has (almost? [1]) no control structure primitives,

I seem to recall it having exactly one: method dispatch. No, sorry: it
was Dispatch Method. DM: like Digital Menses? From times when I get to
wear my skirts /giggle
I was thinking of lits. That lits I am on? Worse than snorting coke is
my lits!

Leave about fucking with my lits and I get total Xross!
Nobody talks to me but me. Got it?

What the **** is this? I thought I wrote this, yet it does not show up in my
broswer as if I did.

I did forget my lits again!
Must be that "morning fog" between my ears LOL
Lits updated :

--- . ... ..- ... <[email protected]>
00101010 <[email protected]>
3k7e4intna <[email protected]>
3x7r4vagan <[email protected]>
3x+r4v4g4n <[email protected]>
Alice <[email protected]>
Arne Këndoj <[email protected]>
Boojum <[email protected]>
B1ll Gat3s <[email protected]>
A Canuck <[email protected]>
Canuck <[email protected]>
ClassCastException <[email protected]>
Cthun <[email protected]>
Chad Carmichael <[email protected]>
dA.b0mB <[email protected]>
dark-zark-fark <[email protected]>
Deep Green <[email protected]> (forgery)
Deeyana <[email protected]>
De Lurker <[email protected]>
Derek Yancey <[email protected]>
Extravagan <[email protected]>
Ferdinand the -14th <[email protected]>
Fuschia, President-Elect of the Bright Purplish-Green Council <[email protected]>
George Arctos <[email protected]>
Greg Kelly <[email protected]>
Greg Sandoval <[email protected]>
Gheerax IV <[email protected]>
Handkea fumosa <[email protected]>
Hieronymus S. Freely <[email protected]>
Hydrocon <[email protected]>
Henry Harrison <[email protected]>
Henderson <[email protected]>
Heike Svensson <[email protected]>
Harry Greer <[email protected]>
Janie Zanie <[email protected]>
Jerry Gerrone <[email protected]>
John Kirkpatrick XVII <[email protected]>
Katie Gerrolds <[email protected]>
Kevin Hadron <[email protected]>
kensi <[email protected]>
KitKat <[email protected]>
Meerkats <[email protected]> (forgery)
Mister Scott <[email protected]>
Mrs. Danforth <[email protected]>
Mike Faramis <[email protected]>
Mamac <[email protected]>
Nancy 3 <[email protected]>
Nancy 4 <[email protected]> (forgery)
Nebulous <[email protected]>
Nightcrawler <[email protected]>
Nougat Surprise <[email protected]>
Orange Green <[email protected]>
Paul Derbysh!re <[email protected]>
Purpleswandir <[email protected]>
RichB <[email protected]>
(e-mail address removed)
SFTV_troll <[email protected]>
Sulfide Eater <[email protected]>
<supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>
Spock <[email protected]>
Series Expansion <[email protected]>
Seamus MacRae <[email protected]>
Snicker-snack! <[email protected]>
Tim <[email protected]>
Thursday's Leftovers <[email protected]>
thoolen <[email protected]>
thoolen <[email protected]>
thoolen <[email protected]>
<[email protected]>
Willy Wonka <[email protected]>
 
B

BGB

On 11-09-13 11:36 PM, Joshua Cranmer wrote:
[ SNIP ]

JS doesn't support OO in the classical
way, and how `this' gets resolved is actually handled by the way you
call the method.
[ SNIP ]

I point out somewhat tongue-in-cheek that JavaScript indeed isn't
"classical" OO, since it's not class-based OO; rather it's object-based
(prototype-based) OO. I think the argument can be made that it's a purer
and more fundamental object-orientation, since you dispense with the
class baggage.

I confess to being seriously biased: lots of experimentation with
non-Web JS programming, and Self and Lua programming. And certainly some
strengths of Scala lead one to think more about runtime objects and not
so much about instances of classes.

Even though "classical" is strictly speaking a correct description of
class-based OO, I sort of prefer "dominant" or "original". Or just
"class-based". Again revealing my bias, I think class-based OO has done
some degree of harm to object-oriented programming, so I am reluctant to
associate it with a word like "classical".

yeah.

my own language started out as pure Prototype-OO, but has since
implemented more of a hybrid model (partly influenced by ActionScript).

in this model, one can have plain dictionary objects (traditional
JS-like objects), dynamic class objects (which look more like
class/instance objects, but can have fields added dynamically), and
plain class objects (implement class/instance, objects are fixed-form /
may not be structurally altered at runtime).

whether the language behaves more like static or dynamic typing, or is
early or late-binding, has more to do with ones' choice of types.

var i:int; //behaves more like a statically-typed integer
var x; //is more dynamically type.
var obj:SomeObject;

i=3.0; //will coerce the type to an integer
x=3.0; //will simply assign the value
i="3"; //bad/error
x="3"; //yep, now x holds a string
....
x.someMethod(); //late-bound / duck-typed
obj.someMethod(); //early-bound (sort of)

in a technical sense, the VM doesn't support early binding in the JVM
sense (where the method call's type/... is defined in the bytecode ops),
rather it is theoretically bound at load-time/"prejit-time" (in reality,
this is an optimization feature, and is technically optional).


a partial merit of delaying type-handling until load-time or run-time is
that it allows a lot more flexibility (and greatly simplifies things
like having a semi-transparent C FFI without needing explicit compiler
support).

one can also do many more things which look like dynamic and duck-typing
without incurring nearly as many costs related to run-time type-checking
and similar as well (to the codegen, they may still appear as static types).

a downside though is that a lot more of the "work" is shifted onto the
VM, so "a simple naive bytecode interpreter which is also really fast"
is mostly ruled out. however, this issue is mostly eliminated by using a
JIT, and even with its slowdown, the plain interpreter is often "plenty
fast enough" for most tasks.


or such...
 
L

Lew

BGB said:
my [sic] own language started out as pure Prototype-OO, but has since
implemented more of a hybrid model (partly influenced by ActionScript).

in [sic] this model, one can have plain dictionary objects (traditional
JS-like objects), dynamic class objects (which look more like
class/instance objects, but can have fields added dynamically), and
plain class objects (implement class/instance, objects are fixed-form /
may not be structurally altered at runtime).

whether [sic] the language behaves more like static or dynamic typing, or is
early or late-binding, has more to do with ones' choice of types.
... [snip] ...
one [sic] can also do many more things which look like dynamic and duck-typing
without incurring nearly as many costs related to run-time type-checking
and similar as well (to the codegen, they may still appear as static types).

a [sic] downside though is that a lot more of the "work" is shifted onto the
VM, so "a simple naive bytecode interpreter which is also really fast"
is mostly ruled out. however, this issue is mostly eliminated by using a
JIT, and even with its slowdown, the plain interpreter is often "plenty
fast enough" for most tasks.


or such...

Are you willing to provide a link to SlicedBread (or whatever you call your own language) so we can all learn from it (or judge it or whatever people choose to do), or are we doomed to second-hand descriptions?

Or such...
 
B

BGB

BGB said:
my [sic] own language started out as pure Prototype-OO, but has since
implemented more of a hybrid model (partly influenced by ActionScript).

in [sic] this model, one can have plain dictionary objects (traditional
JS-like objects), dynamic class objects (which look more like
class/instance objects, but can have fields added dynamically), and
plain class objects (implement class/instance, objects are fixed-form /
may not be structurally altered at runtime).

whether [sic] the language behaves more like static or dynamic typing, or is
early or late-binding, has more to do with ones' choice of types.
... [snip] ...
one [sic] can also do many more things which look like dynamic and duck-typing
without incurring nearly as many costs related to run-time type-checking
and similar as well (to the codegen, they may still appear as static types).

a [sic] downside though is that a lot more of the "work" is shifted onto the
VM, so "a simple naive bytecode interpreter which is also really fast"
is mostly ruled out. however, this issue is mostly eliminated by using a
JIT, and even with its slowdown, the plain interpreter is often "plenty
fast enough" for most tasks.


or such...

Are you willing to provide a link to SlicedBread (or whatever you call your own language) so we can all learn from it (or judge it or whatever people choose to do), or are we doomed to second-hand descriptions?

I didn't want to come off like I was being spamming or similar.


but, some basic (high level) info exists here:
http://cr88192.dyndns.org/wiki/index.php/BGBScript

and a basic language spec:
http://phi/SilvVMSpec/2011-05-25_BGBScript15.html

however, as a whole the project documentation is a bit weak.


here is a snapshot of the sub-project:
http://cr88192.dyndns.org/2011-09-14_bscc.zip

however, getting it to work or doing much of anything useful with it is
"an exercise to the reader..." (it is at this stage very much a
"personal use" piece of technology).

note: ZIP is 112MB, and hosted on a personal internet connection (ADSL).
potentially using wget or similar to retrieve it may make some sense,
and I will not make any guarantees regarding server uptime...

current (usable) build configurations include MSVC+GNU Make, and Linux.
YMMV.


or such...
 
L

Lew

BGB said:
I didn't want to come off like I was being spamming or similar.


but, some basic (high level) info exists here:
http://cr88192.dyndns.org/wiki/index.php/BGBScript

and a basic language spec:
http://phi/SilvVMSpec/2011-05-25_BGBScript15.html

however, as a whole the project documentation is a bit weak.


here is a snapshot of the sub-project:
http://cr88192.dyndns.org/2011-09-14_bscc.zip

however, getting it to work or doing much of anything useful with it is
"an exercise to the reader..." (it is at this stage very much a
"personal use" piece of technology).

note: ZIP is 112MB, and hosted on a personal internet connection (ADSL).
potentially using wget or similar to retrieve it may make some sense,
and I will not make any guarantees regarding server uptime...

current (usable) build configurations include MSVC+GNU Make, and Linux.
YMMV.


or such...

Thanks. With all the references you've made to it I figured someone might find it interesting to look at it. It could be very instructive.

One of the strengths of Java is the internal criticism it receives from its own adherents. You're the only one I have contact with who's tried to address some of the issues with their own approach. That has to be illuminating.

It's easy to armchair the language's choices. It's more challenging to try to solve the problems directly.
 
B

BGB

Thanks. With all the references you've made to it I figured someone might find it interesting to look at it. It could be very instructive.

One of the strengths of Java is the internal criticism it receives from its own adherents. You're the only one I have contact with who's tried to address some of the issues with their own approach. That has to be illuminating.

It's easy to armchair the language's choices. It's more challenging to try to solve the problems directly.

yeah.

(BTW: 'phi' is the internal name of the server on my own network,
correcting the URL):
http://cr88192.dyndns.org/SilvVMSpec/2011-05-25_BGBScript15.html



one thing one may realize when designing their own languages is that the
existing languages are often not really all that bad. one can try
drastically different solutions to problems, but one may realize that
everything is tradeoffs, and that very often the most popular strategies
often tend to be reasonably close to the optimal strategies.

designing something clearly better (rather than simply finding a
different set of tradeoffs) is not always an easy task (nor is having
something anywhere near a "production quality" implementation...).


not to say that things are perfect with existing languages though, and
there may still be room for experimentation and improvement.


also, I use it some for scripting my 3D engine, ...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,013
Latest member
KatriceSwa

Latest Threads

Top