www.digitalmars.com         C & C++   DMDScript  

D - stream operator suggestions

reply davepermen <davepermen_member pathlink.com> writes:
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..
Nov 07 2003
next sibling parent Elias Martenson <elias-m algonet.se> writes:
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;
Nov 07 2003
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
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
Nov 07 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
-> 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..
Nov 09 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
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..
Nov 10 2003
next sibling parent Elias Martenson <elias-m algonet.se> writes:
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
Nov 10 2003
prev sibling next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
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
Nov 10 2003
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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


and


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 


Hauke
Nov 10 2003
parent reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
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


 and


 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



brackets.

 Hauke
Nov 10 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
how about ~> and <~ ?


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


 and


 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



brackets.

 Hauke
Nov 11 2003
next sibling parent Elias Martenson <elias-m algonet.se> writes:
davepermen wrote:


 how about ~> and <~ ?


That could cause a parsing problem with legal expressions such as:

   if(foo<~0) { // a.k.a. (foo < ~0)
     ....
   }
Nov 11 2003
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
davepermen wrote:

 how about ~> and <~ ?


<- is ambiguous.

a<-b could mean a <- b or a < (-b)

More alternatives:

a <* b
a *> b

or

a <+ b
a +> b

or

a %> b
a <% b



with an arithmetic expression of some kind.

Hauke
Nov 11 2003
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
i haven't written <-, but <~.. but its as ambiguous:D

i just don't like the way the non-ambiguous ones look like..

how about making it one direction only?

inStream ~> intData ~> stringData ~> outStream;

textFile("obj.txt") ~> objType ~> binFile("obj.data");

a simple converter:D


so a general commandline login statement would then look like this:

"Hello, Please Enter your Username:" ~> stdOut;
stdIn ~> userName ~> \n;
"And now your Password, please:" ~> stdOut;
stdIn ~> userPassword ~> \n;

if(userName in userList && userList[userName].passWord = userPassword) {
"Welcome, " ~> userName ~> " on D OS" \n ~> stdOut;
}

something of that kind..

btw, its fun to think about an OS written in D.. what shall i call it? DOS? :D

In article <boqqos$1ems$1 digitaldaemon.com>, Hauke Duden says...

davepermen wrote:

 how about ~> and <~ ?


<- is ambiguous.

a<-b could mean a <- b or a < (-b)

More alternatives:

a <* b
a *> b

or

a <+ b
a +> b

or

a %> b
a <% b



with an arithmetic expression of some kind.

Hauke
Nov 11 2003
next sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
so a general commandline login statement would then look like this:

"Hello, Please Enter your Username:" ~> stdOut;
stdIn ~> userName ~> \n;
"And now your Password, please:" ~> stdOut;
stdIn ~> userPassword ~> \n;

if(userName in userList && userList[userName].passWord = userPassword) {
"Welcome, " ~> userName ~> " on D OS" \n ~> stdOut;
}


I don't get the line "stdIn ~> userName ~> \n;". Does it mean read until \n?
Nov 11 2003
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
davepermen wrote:

 i haven't written <-, but <~.. but its as ambiguous:D


Whooops. Sorry ;)


 i just don't like the way the non-ambiguous ones look like..
 
 how about making it one direction only?


You would have to read pull-lines from left to right and push-lines from 
right to left. That's inconsistent and burdensome to read. The right 
side might be scrolled out of the window for long lines, so you would 
only see a nonsensical chain of values, without knowing where they 
actually go.

Naaah, I think we need two different operators.

Hauke
Nov 11 2003
parent davepermen <davepermen_member pathlink.com> writes:
problem is, that forces us, similar to c++, to write TWO stream operators every
time, wich happen to be the same.. (thats why opCall is great.. its
"bidirectional", or bether "nondirectional" :D)

always overloading operator>> and operator<< is stupid, because there could be
just one..

think of this:

struct vec3 {
float x,y,z;
}

vec3 operator~> {
~> x ~> y ~> z;
}

and we could write like this:

vec3 v;
inFile ~> v;
and to store
v ~> outFile;

and infile on its own knows how to read in a float (wich could be stored binary,
or textual, depending on the in-stream-type, of course).. and then, it would
just read in 3 floats that way, and vec3 would be set.

short, very simple, and very straightforward..

a stream class does then only have to be able to read in, or write out (or
both:D) the basic types, and the rest is done like that.

oh, and

T[] operator ~> {
this.length ~>;
foreach(T component; this) {
component ~>;
}
}

would be the generic solution for an array.. so you can write out, and read in,
those, too..

ack, we need bether templates..

template(T) T max(T a,T b) { return a > b ? a : b; }

template(T) T[] operator ~> {
length ~>;
foreach(T o; this) o ~>;
}



so.. i think that was about that..

In article <bor47q$1ssg$1 digitaldaemon.com>, Hauke Duden says...

davepermen wrote:

 i haven't written <-, but <~.. but its as ambiguous:D


Whooops. Sorry ;)


 i just don't like the way the non-ambiguous ones look like..
 
 how about making it one direction only?


You would have to read pull-lines from left to right and push-lines from 
right to left. That's inconsistent and burdensome to read. The right 
side might be scrolled out of the window for long lines, so you would 
only see a nonsensical chain of values, without knowing where they 
actually go.

Naaah, I think we need two different operators.

Hauke
Nov 11 2003
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
a <* b


so b is a pointer and you want du dereference it?

a <+ b


this gets interesting if you use literals

a <+ 5

which is a < +5




with an arithmetic expression of some kind.


°, µ or § isn't used as well.
Nov 11 2003
next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Matthias Becker wrote:


a <* b


 
 
 so b is a pointer and you want du dereference it?


Ouch, you're right.


 

a <+ b


 
 this gets interesting if you use literals
 
 a <+ 5
 
 which is a < +5


There is a unary + operator? [...looks through docs...]. It seems that 
there is. Interesting. Does it actually do anything, or is it simply 
there because there is also a unary -?

Anyway, you're right, of course. <+ seems to be out of the question.





with an arithmetic expression of some kind.


 
 °, µ or § isn't used as well.


And your point is? ;)

Hauke
Nov 11 2003
prev sibling parent reply "Roald Ribe" <rr.no spam.teikom.no> writes:
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bor3o9$1s40$1 digitaldaemon.com...

a <* b


 so b is a pointer and you want du dereference it?

a <+ b


 this gets interesting if you use literals

 a <+ 5

 which is a < +5




with an arithmetic expression of some kind.


 °, µ or § isn't used as well.


~ is bad enough, on a Norwegian keyboard it is a dead key.
  (Alt Gr + ~) release (SPACE)

° and µ does not even appear on my keyboard.


Can ~ be displayed on 7-bit ASCII terminals? I doubt it.

Roald
Nov 11 2003
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Roald Ribe wrote:

 ~ is bad enough, on a Norwegian keyboard it is a dead key.
   (Alt Gr + ~) release (SPACE)


<snip>

 Can ~ be displayed on 7-bit ASCII terminals? I doubt it.


Jepp. ~ has ASCII code 126, so it will fit into 7 bits.

The keyboard-issue is more important, I think. A week or so ago someone 
reported that it is impossible to type ~ using italian keyboards (except 
using the ALT+<ASCIICode> trick that works for all ASCII characters). 
Seems like ~ is one of those characters that could cause a lot of 
problems with an international audience.

Maybe it would be a good idea to find a replacement for ~. It is the 
concatenation operator, after all, and it will probably be used often in 
everyday coding, so it should be something that most people can easily 
type.

Hauke
Nov 11 2003
parent Elias Martenson <elias-m algonet.se> writes:
Hauke Duden wrote:


 The keyboard-issue is more important, I think. A week or so ago someone 
 reported that it is impossible to type ~ using italian keyboards (except 
 using the ALT+<ASCIICode> trick that works for all ASCII characters). 
 Seems like ~ is one of those characters that could cause a lot of 
 problems with an international audience.
 
 Maybe it would be a good idea to find a replacement for ~. It is the 
 concatenation operator, after all, and it will probably be used often in 
 everyday coding, so it should be something that most people can easily 
 type.


This is a fun subject because everybody can have an opinion, and no one 
is correct. I hope Walter puts his foot down soon. :-)

In the meantime, may I suggest an alternative?

Comcatenation: :+  (COLON PLUS)

Rationale: + is used in many languages for concatenating things. It's 
not entirely accurate since addition and concatenation are two different 
concepts. Making a new operator which still contains the + makes it 
familiar for users of those other languages but still different enough 
to point out that it's not an addition.

Extract operator: :>  (COLON GREATER-THAN)
Inject operator: :<  (COLON LESS-THAN)

Rationale: Familiarity for C++ programmers, but still not overloading 
multiple functionalities on a single operator (C++ seems to love that, 
and it's one of the reasons I can't stand that language). The bracket 
points in the direction of data flow.

An alternative to :< would be <: but personally I this that always 
having : as a prefix for a whole new set of operators is advantageous.

Well, those are my suggestions. Have fun. :-)

Elias
Nov 11 2003
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Roald Ribe wrote:


~ is bad enough, on a Norwegian keyboard it is a dead key.
  (Alt Gr + ~) release (SPACE)

° and µ does not even appear on my keyboard.


Can ~ be displayed on 7-bit ASCII terminals? I doubt it.

Roald


  


Why not just use a Norwegian symbol and run in through a simple 
preprocessor.  Since D supports unicode, another option (I think this 
has been discussed before), is to have some support for aliasing 

pluginable language module.  But this can all be done with a 
pre-compiler anyways.

IMHO: There's always going to be some keyboard without the required keys 
(what about mobile phones and handled devices?).
Nov 11 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
IMHO: There's always going to be some keyboard without the required keys 
(what about mobile phones and handled devices?).


i feel good that i don't code yet on those while i'm bored... i feel sort of..
free:D

but yeah, ~ is not one key on my keyboard, but it is on it.. alt-gr and the one
left of backspace.. so what? i'm trained to use it..
Nov 11 2003
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
Perhaps we should post the symbols that we have on our keyboards and than we
could the which everybody has.


(BTW: it's a german keyboard)
Nov 12 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <botkrj$2q4m$1 digitaldaemon.com>, Matthias Becker wrote:

 Perhaps we should post the symbols that we have on our keyboards and than we
 could the which everybody has.


Cool idea. I never knew that German keyboard had *those* keys...





Remove °˛ł, add ˝¨Ł¤ (which nobody really uses), and you have the
Finnish/Swedish keyboard. The keys that are common for them are:



I think the US keyboard doesn't have § or ´ so we're left with:



Now what was the key missing from the Italian layout? ~? So there:



-Antti
Nov 12 2003
next sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
Now what was the key missing from the Italian layout? ~? So there:





Oh, of courase I forgot the €. But I don't think any non-european country has
this.
Nov 13 2003
next sibling parent reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bovl0i$2tc9$1 digitaldaemon.com...

Now what was the key missing from the Italian layout? ~? So there:





 Oh, of courase I forgot the €. But I don't think any non-european country


has

 this.


My Spanish keyboard has € (using AltGr+E) and I live in Colombia. Also, I've
seen some US english keywords with it.
Nov 13 2003
parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bovveo$b9q$1 digitaldaemon.com...
|
| My Spanish keyboard has € (using AltGr+E) and I live in Colombia. Also,
I've
| seen some US english keywords with it.
|

So does mine (although I have it as latin american, so it doesn't work ;) )


—————————————————————————
Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003-11-10
Nov 13 2003
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Matthias Becker wrote:

 Oh, of courase I forgot the =80. But I don't think any non-european cou=


ntry has

 this.


It is unicode, so better not use it. Not everyone uses a unicode editor=20
all the time.

Italian keyboard also lacks ` and some other keys. Really bad. :(

-eye
Nov 14 2003
prev sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <slrnbr56le.7v8.jsykari pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?=
says...


[...]

Now what was the key missing from the Italian layout? ~? So there:




The italian keyboard is missing also ` (the backquote : Alt-96), So there:



Ciao



 Nov 14 2003