AltME groups: search

sqlab, if you mean at the World prompt, it's ctrl-a

Hi,

  REBOL language differs from other languages because you can write 
  "human resembling" code lines.

  During the past weeks I have thought about a way to make more understandable 
  the language in a simple way

   now you can write:

   mypage: read http://www.rebol.com

    I whish to write:

    set the variable mypage: reading from http://www.rebol.com


    It is actually impossible to have this stile but if you add another 
    way of commenting it woul be possible. Lets assume we have a way 
    to start comments with "/*" and and comments with "*/"

    Now we can write


    /*set the variable*/ mypage: /*reading from*/ http://www.rebol.com

    Another line:

    for myvar 1 10 2 [print myvar]


    for /*(set)*/ myvar /*starting from*/ 1 /*reach*/ 10 /*use the stepping*/ 
    2 /* and execute*/ [print myvar]


    Code editors could remove the pairs /* */ and display commenting 
    words in a different color and each line could be read this way:

    set the variable mypage: reading from http://www.rebol.com


    for (set) myvar starting from 1 reach 10 use the stepping 2 and execute 
    [print myvar]


    For people which are learning the language and even for seniors, 
    having this commenting could help a lot.

I think, you can achieve this with a preprocessor written in REBOL, 
that parse your scripts and remove the comments, before doing the 
script.

Not difficult, but is it necessary, and is it rebolish? I haven't 
done a deeper thought about it, but I would guess, it's as easy to 
implement as long strings { ... }.

And you could probably find other languages with similar, but other 
syntax, and programmers from those languages would ask for their 
way and on and on. Do it in a preprocessor!

Geomol, one year ago NickA wrote about a similar feature available 
in LiveCode. Their language is not so flexible as REBOL, if I remember 
correctly only native and not user generated functions have accept 
neutral strings line "at, the, after" to insert in the code.
Isn't a REBOL goal to be more human friendly ?

We all use descriptions and conections words every day. Inserting 
it *for free* inside a line, eeverywhere you want, makes a language 
more readable.

Obviusly "pros" will like not having them but if they think like 
a newbye or even like a semi-pro I suppose they will find the usefullness 
of this imporvemente.

One frind of mine like named arguments to functions in the call of 
the function. You can probably do that in REBOL easily too. Create 
a function, that remove the names of arguments, that is sent in a 
blok together with the values, and then call the real function with 
only the values.

Or maybe better than my do-this example, create a dialect, where 
all function calls work with named arguments. The parsing then need 
to look for words, that are functions, find out how many arguments 
they take and remove the argument names. And do it recursively also. 
Should be possible, I think.

Just a crazy thought to consider:

	add (1 ; first arg) (2 ; second arg)

I see your point, but it just raises some concerns in relation to 
REBOL. For example, /* is a valid refinement:

>> type? /*
== refinement!


So some might wanna make a shell command in REBOL to be used at the 
REBOL prompt, that reads /* as all the files in the root directory, 
like

	LS /*

That will not be possible, if /* is part of a comment.

Tilde is an option. There are three function in REBOL using that 
char, the function variations of and, or and xor. I call those and', 
or' and xor' in World, so that's a possibility in R3, if people wants.

And then tilde can be used in URLs, like:

>> type? url://~a
== url!


I can't judge, if that's a problem, if tilde should be used for comments 
too.

I don't think REBOL should support it Giuseppe, but you can write 
a dialect that does. Carl mentioned at one point that he considered 
allowing "filler" words, but decided against it. I sometimes allow 
them in my dialects.

Gregg, in my scenario I propose filler "comments" and not words. 
This should not change REBOL language but only commenting.

The Editor will be in charge for diplaing these comments in different 
colors.

Adding filler words should be a major change in REBOL. I don't wont 
to propose something so big.

Filler values of any kind change REBOL. If you really want to do 
that, experiment by using tags as comments, strip all tags after 
loading your code, then DO it. Now see if if really helps people 
when they use your simple dialect. Can the same be acheived, roughly, 
with reformatting and end-of-line comments? 


None of us here can tell you if it is really helpful. It's different, 
but that doesn't mean better. 


Using semicolons as an alternate comment end mark is a HUGE change, 
and not for the better IMO.

Yes, the tilda used in urls is a showstopper. Personaly I don't think 
that inline comments are necessary and add some readability. I'm 
fine with current state.

I can't find a problem in it, but I'm not sure, if I like it.

Gregg, Oldes, it is a feature for people who like it.

Having verbose lines really help understand the language but it is 
not for all. I think about it for new user and to say to the world 
"you can write human language resembling lines".

I was sure that professional rebolers would not find this useful... 
but it is not useful for them, for us, it is for another part of 
the world.

Yes, I understand that. But some things may not be good to get used 
to from the start. Because once you're used to that, would you continue 
using it? Probably you will. So we'll start seeings scripts with 
comments inside lines. Would it be easier or harder to maintain such 
code? Would it be easier or harder for other people to learn from 
such scripts?

I'm not sure.


Maybe I could implement it in a version of World alpha, so we can 
see, how it works in practise.

Even my example in the #World group with comments inside parentheses 
together with arguments are ugly to me. I'm wondering, if it's a 
good thing, that you can do such. :)

Should smileys be allowed in a computer language? :D

#[[Giuseppe

  REBOL language differs from other languages because you can write 
  "human resembling" code lines.

  During the past weeks I have thought about a way to make more understandable 
  the language in a simple way

   now you can write:

   mypage: read http://www.rebol.com

    I whish to write:

    set the variable mypage: reading from http://www.rebol.com
]]Giuseppe


Carl really took some "architectural" principles of Rebol from human 
laguages making it resemble human languages in that respect. However, 
he did not want to immitate everything. Sorry, Giuseppe, but I must 
say that you are missing big what is the main principle of advancement 
relative to other computer languages. It is dialecting and not the 
ability to write the primitive and verbose

    "set the variable mypage: reading from http://www.rebol.com"

Ladislav, I disagree with your (not so) hidden opinion that the feature 
I proposed is not useful at all.

During my early days and even now I find difficult to uderstand REBOL 
code without "connectors" words which makes a line more descriptive.

I agree that dialecting is a big advancement. I also like the opportinity 
to write "first, second,... last" but  adding ";" should be a big 
change and you should really walk in the shoes of a newbie where 
reading a line with connector words really makes the difference.

I think that presenting a line with connectors would let many new 
developers say "WOW, I can understand this so I can program using 
this language".

Please note I don't want to say that REBOL will be better for all, 
that it will be more elegant. 

It is a cosmetic factor which adds readability to the code. Then, 
when coders get used to the rebol sintax they will naturally drops 
inline descriptions.

Geomol: "is this a good thing ?"
Only time and experience will tell.

But I am sure that if I write on the top of a web page a full line 
of code and the If you can understand this, you can write code in 
WORLD" people will feel they can.

*But I am sure that if I write on the top of a web page a full line 
of code and then "If you can understand this, you can write code 
in WORLD" people will feel they can.

A big reason to give World a try.

On the same subject, I wish I could write:

	foreach item in the serie [do something]

and I'd like to have single-word comments so it become:

	foreach item /in-the serie [do something]

(the slash is only a possible (?) solution)

in-the: function [a [series!]][a]
foreach item in-the serie [do something]
???

Henrik, while I respect your, we have a different opinion.

Everytime I see THE word in a ny language I'm finished with it  :-)

Whether the primitive verbosity property could be useful and for 
whom is a matter I did not want to discuss at all.

it will make it 90% less usable.

 - what I mean is that the beginner will grow out of this in a matter 
 of, perhaps, days and then it will only be seen as a nuisance than 
 an advantage. REBOL is about words and symbols and now we're spending 
 words and symbols for no real purpose.


I'm afraid it will just confuse and complicate programming in REBOL, 
when you first learn it with fill in words and then without those 
words, and simply slow down the learning process.

Good news are that there already is a language following this design 
goal:
#[[Wikipedia

One of the design goals of it was that non-programmers—managers, 
supervisors, and users—could read and understand the code. This is 
why it has an English-like syntax and structural elements—including: 
nouns, verbs, clauses, sentences, sections, and divisions. Consequently, 
it is considered by at least one source to be "The most readable, 
understandable and self-documenting programming language in use today. 
[...] Not only does this readability generally assist the maintenance 
process but the older a program gets the more valuable this readability 
becomes." On the other hand, the mere ability to read and understand 
a few lines of its code does not grant to an executive or end user 
the experience and knowledge needed to design, build, and maintain 
large software systems."
#]]Wikipedia

Some other good news:

- the wheel has already been invented:
- the language is mature, having been designed in 1959


So, Giuseppe, aren't you eager to try it? It might be quite an enlightening 
experience for you, realize that you would immediately understand 
the expresions!

Ladislav, why don't you try to add this feature and lets see if the 
user will like it ?
 - I think I did explained it sufficiently:

- such a feature has been implemented in a language since 1959

- I do not feel responsible for implementing every feature you may 
find useful

- such a feature has been implemented in a language since 1959
I think it had a great moment.

not finished imo. But I tried to put some code in a task - wait, 
print, and IIRC it did so ... console was freed, later it printed 
the message. But it was long time ago ...

As for networking, R3 uses devices. Please consult the rebol.net/wiki 
docs, there's quite a bit info about it. As for tasking, during one 
session we asked Carl to clarify, so he did. BrianH or others would 
be most probably able to describe, how Carl envisioned it to work. 
The only thing I can remember is, that it was supposed to be called 
task! datatype, but internally using threads with some automatic 
syncing, or something like that ...

Missing a yield return function to have rebol tasks really usefull

#[[AdrianS
...if you have the following in a script:

print sumn 1 2
print "hello"

The "hello" doesn't print.
]]AdrianS


Yes, that is not surprising. SUMN (referring to its last version) 
is taking unlimited number of arguments and stops taking them only 
if it obtains an argument that is not a number. In the above case 
SUMN consumes the ''print word, that is why nothing is printed. To 
stop SUMN before it consumes the 'print word, you can use either 
paren:

    (sumn 1 2)
    print "hello"


or just supply NONE (or some other non-numeric value)  to be consumed 
by SUMN as the last (stopping) argument

    sumn 1 2 #
    print "hello"

#[[Adrians

Among other things, how is it OK to invoke arg-adder without providing 
the one arg it expects when you have "return/redo :arg-adder?
]]AdrianS


RETURN/REDO is a construct returning (in this case) the ARG-ADDER 
function and setting up an indicator telling the interpreter that 
after obtaining the function as a result it should reevaluate it 
collecting the respective number of arguments for it (one in this 
case).

Thanks, Ladislav. I was hoping that there would be a "magical" way 
of telling Rebol to somehow back up and re-evaluate the consumed 
stop argument. Maybe return could have a /back refinement which you 
could use when exiting a variadic function. What do you think?

Carl has been talking for some time about integrating streaming protocols 
into Rebol (probably like h264, mpeg4, mp3, wmv, etc.).  Is that 
something that could be plugged into the existing codebase rather 
directly, or will it take a lot of changes to make it work?

avconv (formerly ffmpeg) is open source, so I imagine some or all 
of that could be used as a starting point (if the licenses are compatible).

Yes, but I think Carl was talking about making it more of an integrated 
component so it can be easily accessed Rebol-style.  It's like the 
difference between loading a jpg in Rebol (it just works) or trying 
to link Imagemagick (or comparable) to load a jpg into a binary image 
format that can be modified by Rebol.

Maybe return could have a /back refinement which you could use when 
exiting a variadic function.

 - not a good idea. Variadic functions don't differ from "normal" 
 functions in this respect. If consuming an "undesired" argument, 
 it actually is an error. That is a good enough solution as far as 
 I am concerned. In case of SUMN this behaviour can be also implemented 
 by requiring the argument to always have a specific type. e.g. [number! 
 none! unset!], where number! would be a "normal" argument while none! 
 and unset! would be stopping. Any other argument causes an error, 
 which should suffice for you to note that something went wrong.

A question for AdrianS or other lurkers: I already mentioned that 
SUMN actually used unevaluated argument passing style (APS). Do you 
find that style appropriate or would you prefer SUMN to use a different 
APS? (Consult https://github.com/saphirion/documentation/blob/master/argpass.mdp
if you don't know what I am talking about).

Advantages of using evaluated APS for SUMN:


- argument can be a result of an expression, i.e., the function would 
be referentially transparent in the sense that it would accept expression 
results, e.g. sumn 1 2 * 3

Disadvantages of evaluated APS for SUMN:


- (sumn 1 2) would not work since the function would miss a stopping 
argument

Advantages of using literal APS for SUMN:


- partiall referential transparency, the function can accept result 
of an expression, if the expression is in parentheses, i.e. sumn 
1 (2 * 3) would work
- partial referential transparency, sumn 1 :x * 3 would work

- (sumn 1 2) would work, since the literal APS obtains the stopping 
#[unset!]

Disadvantages:

- sumn 1 2 * 3 would not work
- sumn 1 x would not work either

Advantages of using unevaluated APS for SUMN:


- (sumn 1 2) would work, since the literal APS obtains the stopping 
#[unset!] at the end of the paren
- sumn 1 (2 * 3) can be made to work if desired
- sumn 1 x can be made to work if desired

Disadvantages:

- sumn 1 2 * 3 would not work
- sumn 1 :x * 3 would not work

I will have to think about this. I'm curious, though, what your opinion 
is of return/redo given that BrianH said in the SO chat that it had 
been decided to remove this and yet you documented it and showed 
its usefulness. Later, Brian also said:


Ladislav proved that RETURN/redo needed to be removed, by writing 
example code that was safe to run, but used methods that were provably 
unsafe if used mistakenly or maliciously. It would actually take 
a programmer of Ladislav's calibre to use the feature safely. But 
DO function is provably OK.

So, is the intent to remove the feature?

BrianH said in the SO chat that it had been decided to remove this 
 - I do not know about such a decision yet

Well, I was originally against /REDO, taking a more moderate point 
now, but, as I said, I am not sure there was an agreement to remove 
it.

In /REDO case it looks that I am something like  "permanent opposition". 
When there was a "hurray /REDO" atmosphere I was trying to chill 
it down pointing at the disadvantages, now, when there is the "phew 
/REDO" atmosphere, I seem to be an opposition as well...

Gregg, BrianH reported this issue as a bug today:
http://issue.cc/r3/2031

cant' we press escape to halt a script or when at an    'ASK  prompt?

Did anyone started a R3 code-review and already took notes that are 
published?

I think it makes a lot of sense to publish all notes in a structred 
way, so it's easier to work on the R3 code base.

#[[Bo
Rebol 2.101.0.4.20:

>> difference #{FFFFFF} #{EEEEEE}
== #{FFEE}

I would expect it to return #{111111}
]]Bo

That is not a well informed expectation, Bo.:


* in Rebol, binary values are series of octets (small integers, 0 
to 255)
* in Rebol, set functions handle series as sets of values
* DIFFERENCE is a set function yielding set difference

* in the above case the first st contains #{FF} (=255), which is 
not contained in the second series

* the second series contains #{EE} (=238), which is not contained 
in the first series
* thus, the set difference is #{FFEE}

hum, wow.  there always seems to be a conversion path to get the 
numbers do what we want... I'm sure accountants would love rebol 
 ;-)


want a deficit... just turn it into a binary, want a profit, just 
turn it into a bitset first   ;-)

Bo, I'm not sure, if that makes sense. What you're suggesting is, 
that this should be possible:

	(read/binary %file1) - (read/binary %file2)


So it's like looking at a long sequence of binary data as a number? 
And if the series are of different length, they should be right aligned. 
Is that really useful? :)

I would say so.  The great thing about datatypes is that they can 
save us a lot of work doing manipulations.

The downside to datatypes is that it is hard for the developer to 
determine proper behavior of different operations on the different 
datatypes.  Like, what should happen when you add a char! and an 
integer!...  My opinion would be that because your first argument 
is a char!, you want to increment/decrement it by the value of the 
integer!.  This could be useful in some situations.

Is there a GUI that currently works with Carl's last r3 alpha?

sure!   have a link?

good thing is that I've got a VM running XP all setup, so I don't 
mind hacking it up to make it work... :-)

Here are some optional environment variables that you may have to 
set for a Windows build:

is this a file type for some batch processing app, or just a hand 
written  note for  memory sake?

It's a formal file for my build system. A build dialect

funny, I have a power build system too..  called maker.

I have tons of unreleased stuff.  Amongst other things, I'll be giving 
away a new app at the devcon... a header conformance editing tool 
... using a header description dialect,  I hope people like it.

when I run make all, I get an endless loop in the prep stage.  

Duplicate: a-lib.c : RL_API void RL_Version(REBYTE vers[])

Duplicate: a-lib.c : RL_API int RL_Init(REBARGS *rargs, void *lib)

Duplicate: a-lib.c : RL_API int RL_Start(REBYTE *bin, REBINT len, 
REBCNT flags)
Duplicate: a-lib.c : RL_API void RL_Reset()

Duplicate: a-lib.c : RL_API void *RL_Extend(REBYTE *source, RXICAL 
call)
Duplicate: a-lib.c : RL_API void RL_Escape(REBINT reserved)

Duplicate: a-lib.c : RL_API int RL_Do_String(REBYTE *text, REBCNT 
flags, RXIARG *result)

Duplicate: a-lib.c : RL_API int RL_Do_Binary(REBYTE *bin, REBINT 
length, REBCNT flags, REBCNT key, RXIARG *result)

Duplicate: a-lib.c : RL_API int RL_Do_Block(REBSER *blk, REBCNT flags, 
RXIARG *result)

Duplicate: a-lib.c : RL_API void RL_Do_Commands(REBSER *blk, REBCNT 
flags, REBCEC *context)
Duplicate: a-lib.c : RL_API void RL_Print(REBYTE *fmt, ...)

Duplicate: a-lib.c : RL_API void RL_Print_TOS(REBCNT flags, REBYTE 
*marker)
Duplicate: a-lib.c : RL_API int RL_Event(REBEVT *evt)

IIRC some started to write a formal grammar for Rebol3. Is there 
anything available to look at?

Hmmm...interesting behavior.  I am trying to use R3 to act as a TCP 
server on Linux-ARM.  Here's a code snippet:

	if probe port? prt: wait [1 camsrv][
		probe cmd: copy prt
		call/wait reform [cmd "> cmdout.txt"]
		insert prt probe read cmdout.txt
		close prt
	]


The probe at the top returns 'false when there is no TCP activity, 
but it returns "TCP-event accept" when there is, and then it just 
sits there.  Escape (ESC) and CTRL-C will not break out of R3 at 
that point.  CTRL-C just outputs "[escape]" each time it is pressed, 
but doesn't escape.

wow that's a nasty bug.

But my real problem is that the line

	probe cmd: copy prt


never outputs anything, even after the "TCP-even accept" line is 
printed.  Even if I put a 'print statement as the first line of the 
'if block, nothing is printed.  So that leads me to believe that 
there is a problem right at the

	probe port? prt: wait [1 camsrv]

that locks up R3 hard.

a bug worthy of a hackathon session at ReCode ?

I have a couple questions about how to deal with actors and I think 
an example will illustrate it best.

Trying to modify use click actions on a text-table to affect filtering 
on another text-table:

ind: [
	[1 "Jones" "Tom"]
	[2 "Smith"	"William"]
	[3 "Jones" "Stephen"]
]

eve: [
	[1 "Arrival"  "Wearing a red hat"]
	[1 "Departure" "No hat"]
	[2 "Lunch" "Salmon Sandwich"]
	[1 "Dinner" "Pasta"]
	[2 "Departure" "Red shirt"]
]

view [

 tt1: text-table 600x400 ["ID" #1 70 "Last Name" #2 200 "Given Name" 
 #3 200 ] ind on-focus [
		print face/name
	]

 tt2: text-table 600x400 ["ID" #1 70 "Event" #2 150 "Description" 
 #3 300] eve
]

Josh, there's an r3-gui group that might be a more appropriate place 
to ask.

@BrianH, I searched CureCode, but couldn't find any notes from you 
on SPLIT, other than one that said you think it needs a rewrite.

bug?

v: 5
a: compose/deep [(v) q]
reduce a

Cyphre wrote 2-Apr 2013 22:03:
For those interested in the 
alpha-channel change": ..."


It's a good change to get the alpha-channel 'right' or similar to 
most other standards. Have there been thoughts about including the 
alpha-channel with the RGB values, so it becomes RGBA, which we know 
from OpenGL and other places?

From my R3 console:

>> i: make image! [1x1 #{01020304}]
== make image! [1x1 #{
010203
}]


The alpha values seems to be left out. (It might have changed in 
newer versions.) Setting the pixel will include alpha values:

>> i/1: 1.2.3.4
== 1.2.3.4
>> i
== make image! [1x1 #{
010203
} #{
04
}]


But it seems, the alpha channel is separate from RGB values. Why 
not always have the alpha channel, and include it with the RGB values, 
so we have: [1x1 #{01020304}]

f: does [2]
;on R3
>> reduce/only [a f] none
== [1 make function! [[][2]]]
;On R2
>> reduce/only [a f] none
** Script Error: Invalid argument: f

Is it a bug on R2?

a: 1 ;for sure..

Looks like a bug in R2 to me.


It's interesting, that the word for the function is reduced to the 
function, but not evaluated. An alternative could be, that the word 
isn't touched, if it represents a function. I'm not familar with 
what practical challenges, that lead to this refinement for REDUCE. 
I've never used it myself.

An alternative could be, that the word isn't touched
You can do that like
>> reduce/only [a f] [ f ] ;this doesn't touch to F
== [1 f ]

But this is not only for functions of course.

Do you see my point? For a target, we need to estbalish a time/money 
budget and ratio.

Yes, absolutely. Any good open source projects to use as a model? 
:-\

Because, if I set R3 for development against Scala/Lift/Akka in back 
ends, it's a long way.... Same on mobile: there's Livecode, Corona, 
all of them more mature. So if I treat R3 as an "investment" of sorts, 
the risk/reward ratio needs to be established

Bit of both in my view. Money to support full time development. And 
the knowlegde to know how to is also sparse. A little bit extra on 
info and tutorial like stuff could maybe get some more people started. 
Google's summer of code like the HAIKU project is putting to use 
is beyond reach for the small base of devs for instance.

We are on the other hand lucky to have the enthousiastic giants we 
have now. It is enough to let the projects live on, but not in the 
way blooming as we feel should be the case. 

Yet the progress even in the last weeks is a great accomplishment, 
cannot be said enough..

One of my views is a way of providing a webhosting service based 
on REBOL/Red and additional open source technology.

If we had a monetary amount needed, would it be possible to write 
up a Kickstarter campaign to fund R3 development?

shure, as long as you have a precise end-result with milestones, 
 time estimates, and realistic goals.

but would it actually end up working?

We need more momentum. Meaning a small usable base to start serious 
advocating the pro's with and possibilities of generating a little 
money. Attracting young programmers/students willing to contribute, 
one advantage for students is that not everything is carved in stone 
yet. (Only what we want to achieve and the toolset is chosen)

So you could start with a small Kickstarter campaign just to get 
some momentum going, and then maybe follow it up with a larger one 
once momentum is up.

@Graham: GitX; found another alternative very promising, even did 
a fetch(!) from the master branch I wanted but could find nowhere: 
sourcetree 
http://www.sourcetreeapp.com/

Maarten, some thoughts about all this. IMO R3 or what it's than called 
is not the end product. It's an enabeling technology to make good 
products in a very short time.

So, what's interesting about it is, that one gets access to a complete 
vertical technology stack. The black-box dependencies (those that 
you can't influence) are mostly zero. Of course you don't have a 
big community, eco-system etc. around. But I'm coming more and more 
to the point that I don't need a big eco-system, I need the right 
eco-system. I don't want to use big frameworks, zillions of libs 
etc. This all makes product development a hell.

A mean and lean technology stack, that is maintainable, can be adjusted 
to some special needs with the fundamental things available is everything 
you need.

What I would do if I could afford is, is to re-implement R3 using 
the D language. This should result in a more simple code base (Carl's 
code base is in a very good shape, so don't take me wrong), and using 
this we would close the most fundamental missing parts in R3. There 
are around 5-8 topics that need to be addressed. Andreas and I just 
had a short chat about this this week.

R3 gives us the chance to use one technology on a broad range of 
systems. I don't say the same code, but the same technology.

Than we have fundamental frameworks and libs like R3-GUI etc. this 
is a mix of Rebol code and enhancements on the C/D level.