how about a new operator for stream filling ?

lets see... c++ to d dropped -> ..

"Hello World, the value of x is " -> x -> " and the value of obj is " -> obj -> stdout;

or.. for your preference (but it does the same... :D)

stdout <- "Hello World, the value of x is " <- x <- " and the value of obj is " <- obj;

stdin -> x -> y -> z;

binout("mydata.dat") <- x <- y <- z;
x -> y -> z -> binout("mydata.dat");

binin("mydata.dat") -> x -> y -> z;
x <- y <- z <- binin("mydata.dat");

dunno wich one is bether.. but i think we should, for the sake of simpler serialisation, have the same operator for in and out..

davepermen wrote:

> stdout <- "Hello World, the value of x is " <- x <- " and the value of obj is "
> <- obj;

This would be a mess. Imagine this:

    stdout <- "is x less than -2? the answer is " <- x<-2;

davepermen wrote:

> how about a new operator for stream filling ?
> 
> lets see... c++ to d dropped -> ..
> 
> "Hello World, the value of x is " -> x -> " and the value of obj is " -> obj ->
> stdout;
> 
> or.. for your preference (but it does the same... :D)
> 
> stdout <- "Hello World, the value of x is " <- x <- " and the value of obj is "
> <- obj;
> 
> stdin -> x -> y -> z;
> 
> binout("mydata.dat") <- x <- y <- z;
> x -> y -> z -> binout("mydata.dat");
> 
> binin("mydata.dat") -> x -> y -> z;
> x <- y <- z <- binin("mydata.dat");
> 
> dunno wich one is bether.. but i think we should, for the sake of simpler
> serialisation, have the same operator for in and out..

Better than >> and <<, but only because D doesn't define either of those operators currently.

It might be handy to have a few overloadable operators whose only use is in overloading it. (so it'd be operator loading, and not overloading) Handy, but I get the feeling that people would give it all manner of screwy meanings, depending on what amuses them at the moment.

C++ coders would be completely thrown for a loop. (stdin::x does not exist)

 -- andy

-> isn't really a problem, but <- can be confused lexically with less-than / minus

Sean

"davepermen" <davepermen_member@pathlink.com> wrote in message news:bog9kh$1a5q$1@digitaldaemon.com...
> how about a new operator for stream filling ?
>
> lets see... c++ to d dropped -> ..
>
> "Hello World, the value of x is " -> x -> " and the value of obj is " ->
obj ->
> stdout;
>
> or.. for your preference (but it does the same... :D)
>
> stdout <- "Hello World, the value of x is " <- x <- " and the value of obj
is "
> <- obj;
>
> stdin -> x -> y -> z;
>
> binout("mydata.dat") <- x <- y <- z;
> x -> y -> z -> binout("mydata.dat");
>
> binin("mydata.dat") -> x -> y -> z;
> x <- y <- z <- binin("mydata.dat");
>
> dunno wich one is bether.. but i think we should, for the sake of simpler serialisation, have the same operator for in and out..

yeah, realised that.. and now understand why it never got into the language as an operator..

then again, following the basic parsing rule, it shouldn't.. the same reason a<b<>> always got parsed as a < b < operator>> :D

but yes, it could mess up some code.

the -> would then be the collect-operator, or something..

In article <bompde$1kh7$1@digitaldaemon.com>, Sean L. Palmer says...
>
>-> isn't really a problem, but <- can be confused lexically with less-than / minus
>
>Sean
>
>"davepermen" <davepermen_member@pathlink.com> wrote in message news:bog9kh$1a5q$1@digitaldaemon.com...
>> how about a new operator for stream filling ?
>>
>> lets see... c++ to d dropped -> ..
>>
>> "Hello World, the value of x is " -> x -> " and the value of obj is " ->
>obj ->
>> stdout;
>>
>> or.. for your preference (but it does the same... :D)
>>
>> stdout <- "Hello World, the value of x is " <- x <- " and the value of obj
>is "
>> <- obj;
>>
>> stdin -> x -> y -> z;
>>
>> binout("mydata.dat") <- x <- y <- z;
>> x -> y -> z -> binout("mydata.dat");
>>
>> binin("mydata.dat") -> x -> y -> z;
>> x <- y <- z <- binin("mydata.dat");
>>
>> dunno wich one is bether.. but i think we should, for the sake of simpler serialisation, have the same operator for in and out..
>
>

davepermen wrote:

> yeah, realised that.. and now understand why it never got into the language as
> an operator..
> 
> then again, following the basic parsing rule, it shouldn't.. the same reason
> a<b<>> always got parsed as a < b < operator>> :D

Just a little anecdote:

They solved this one in Java, by allowing the >> operator to close a nested generic type definion and the >>> operator to close a triply nested definition. The grammar is a bit hairy thanks to this though. :-)

Elias

I've seriously considered a language where everything was about describing data flow with -> notation.  Input, Output, Assignment, Copying, Conversion, Construction, Destruction, all were accomplished with the same basic operator, the ->.  In an expression A -> B, a is "sent to" B, and the result is dependent on the types of B and A.  Construction is assignment from NIL to a variable, Destruction is assignment from a variable to NIL (and happens implicitly at end of scope, as you can imagine).  Write a value to a file by sending it to the file, get a value from a file by sending the file to the variable.

This ends up being almost the antithesis of a functional language.  Would make a good assembly language notation I think.

The problem with <- is that there is already lots of code written that assumes that <- is not a lexical token and that the source will be lexed as < followed by -.  If <- is added, all that code breaks.

Anyway other languages have <- (Haskell, for one).  It doesn't seem to cause
them many problems.

Sean

"davepermen" <davepermen_member@pathlink.com> wrote in message news:bonkk5$2rjg$1@digitaldaemon.com...
> yeah, realised that.. and now understand why it never got into the
language as
> an operator..
>
> then again, following the basic parsing rule, it shouldn't.. the same
reason
> a<b<>> always got parsed as a < b < operator>> :D
>
> but yes, it could mess up some code.
>
> the -> would then be the collect-operator, or something..
>
> In article <bompde$1kh7$1@digitaldaemon.com>, Sean L. Palmer says...
> >
> >-> isn't really a problem, but <- can be confused lexically with
less-than /
> >minus

davepermen wrote:
> yeah, realised that.. and now understand why it never got into the language as
> an operator..
> 
> then again, following the basic parsing rule, it shouldn't.. the same reason
> a<b<>> always got parsed as a < b < operator>> :D
> 
> but yes, it could mess up some code.
> 
> the -> would then be the collect-operator, or something..

Why not create two operators with a defined but more general meaning, so that it is not directly linked to file I/O?

I'm thinking about a "push" and a "pull" operator. The "push" operator pushes data/objects/whatever into another object, the pull operator pulls it out.

Could be used for file I/O, some collection classes (e.g. stack push/pop), enumerations, etc.

People will want to have something like this anyway, and with push/pull operators it would at least be standardized to some degree. Better than have people abuse + or the shift operators...

Howsabout

a <# b	for push?
and
a #> b	for pull

or maybe

a <| b
and
a |> b

or

a <: b for push?
and
a :> b	for pull


Should all be unambiguous to parse, except maybe the last one (possible clash of a:>b with code labels?). I think I prefer the first alternative, since I find it a little easier to distinguish between push and pull if there is a "fat" symbol like the # one one side of the brackets.

Hauke

Comments embedded.

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:boo3ou$fav$1@digitaldaemon.com...
> davepermen wrote:
> > yeah, realised that.. and now understand why it never got into the
language as
> > an operator..
> >
> > then again, following the basic parsing rule, it shouldn't.. the same
reason
> > a<b<>> always got parsed as a < b < operator>> :D
> >
> > but yes, it could mess up some code.
> >
> > the -> would then be the collect-operator, or something..
>
> Why not create two operators with a defined but more general meaning, so that it is not directly linked to file I/O?
>
> I'm thinking about a "push" and a "pull" operator. The "push" operator pushes data/objects/whatever into another object, the pull operator pulls it out.
>
> Could be used for file I/O, some collection classes (e.g. stack
> push/pop), enumerations, etc.
>
> People will want to have something like this anyway, and with push/pull operators it would at least be standardized to some degree. Better than have people abuse + or the shift operators...

I like this idea. An operator for file IO is nice but better if it's standarized for other related concepts.



>
> Howsabout
>
> a <# b for push?
> and
> a #> b for pull
>
> or maybe
>
> a <| b
> and
> a |> b
>
> or
>
> a <: b for push?
> and
> a :> b for pull

I prefere the last one ( :> and <: ) but I see your point with labels. What
about "@>" and "<@"?


> Should all be unambiguous to parse, except maybe the last one (possible clash of a:>b with code labels?). I think I prefer the first alternative, since I find it a little easier to distinguish between push and pull if there is a "fat" symbol like the # one one side of the
brackets.
>
> Hauke

how about ~> and <~ ?

i hate #, and @.. they both don't fit into programming imho.. dunno why:D it's just me:D

In article <booo6b$1e46$1@digitaldaemon.com>, Julio César Carrascal Urquijo says...
>
>Comments embedded.
>
>"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:boo3ou$fav$1@digitaldaemon.com...
>> davepermen wrote:
>> > yeah, realised that.. and now understand why it never got into the
>language as
>> > an operator..
>> >
>> > then again, following the basic parsing rule, it shouldn't.. the same
>reason
>> > a<b<>> always got parsed as a < b < operator>> :D
>> >
>> > but yes, it could mess up some code.
>> >
>> > the -> would then be the collect-operator, or something..
>>
>> Why not create two operators with a defined but more general meaning, so that it is not directly linked to file I/O?
>>
>> I'm thinking about a "push" and a "pull" operator. The "push" operator pushes data/objects/whatever into another object, the pull operator pulls it out.
>>
>> Could be used for file I/O, some collection classes (e.g. stack
>> push/pop), enumerations, etc.
>>
>> People will want to have something like this anyway, and with push/pull operators it would at least be standardized to some degree. Better than have people abuse + or the shift operators...
>
>I like this idea. An operator for file IO is nice but better if it's standarized for other related concepts.
>
>
>
>>
>> Howsabout
>>
>> a <# b for push?
>> and
>> a #> b for pull
>>
>> or maybe
>>
>> a <| b
>> and
>> a |> b
>>
>> or
>>
>> a <: b for push?
>> and
>> a :> b for pull
>
>I prefere the last one ( :> and <: ) but I see your point with labels. What
>about "@>" and "<@"?
>
>
>> Should all be unambiguous to parse, except maybe the last one (possible clash of a:>b with code labels?). I think I prefer the first alternative, since I find it a little easier to distinguish between push and pull if there is a "fat" symbol like the # one one side of the
>brackets.
>>
>> Hauke
>
>