AltME groups: search

Write it yourself. Use a user-defined junk! string type, and your 
own LOAD to work with it. It's easy (for experts). I've rewritten 
LOAD several times in the last week, twice today :)

And re debugging, no I don't think so.  touching junk! would throw, 
and throw hot perhaps.  But it could float around in a block happily 
waiting to be analyzed or triggered.


Dang, another promise broken in under a minute.   One thing, REBOL 
can sure induce passion!   Now, there is a name for a datatype!

for people learning the language and for many short scripts... the 
able is a simple no-brainer, which just works.

The debugging problem is that the locality of the error is lost. 
By allowing invalid data to be loaded, you put a timebomb in your 
data to be triggered at some later time, by code that doesn't see 
it coming. You want errors in your scripts to be triggered as soon 
as possible, and as close to the source of the error as possible, 
or you'll never find it.

See, there was an error in that message, and I regret it already.

depends what your problem is... really. 


 I've had scientific data which was 100% compatible with rebol expect 
 that it used "," to separate things.


having to use parse for that was both tedious, and for me at the 
time, extremely complicated.

and having to create a callback for it would also have been much 
harder than just not doing anything with it.

its just that many throw away code and system-based coding occurs 
with very controled input, which doesn't have errors. its just not 
completely compatible with rebol.

and giving a dead-simple way to ignore or trap it is in line with 
rebol's kiss philosophy IMHO.  


but I do think that for serious *parsing* and dialecting, your proposal 
is much better.

both Brians aren't talking about the same kind of issues, both requiring 
an "ideal" (and different :-)  approach.

datatypes and real world data don't match exactly ... just close 
enough to be frustrating.

You mean that programming language syntax and data syntax don't match 
exactly. LOAD is for REBOL syntax, and we want those errors for REBOL 
syntax. Those thrown errors help you clean up your bugs.

then, maybe, although it does the same thing AS load, it wouldn't 
be used by the interpreter, and would explicitely allow the interpreter 
to use the loading functionality which already understands about 
95% of human readable ascii text as it is.

really brian, I can't recall how many times I've had ascii files 
from sources which I could almost just load as-is.  and when the 
extra syntax, was just useless decoration, which can be ignored.

I do agree with brianh and Carl that I refuse to have to deal with 
commas within rebol code.

but if we allow them, people from other language will start using 
them, and really, its going to be some kind of polio virus.

People underestimate how much thought went into the REBOL syntax. 
REBOL was carefully and deliberately designed for quick programming. 
One of the most important choices was to not use commas and periods, 
because it is tricky to tell them apart or see them when reading 
a lot of code. They are not used in numbers either, because they 
are ambiguous in internationally visible code.

brian, allowing a relaxed mode alllows me to be quick. as opposed 
to try and manually redo what rebol does already.  using the actual 
commas within code IS evil, don't get me wrong.

Unfortunately a lot of the syntax choices were based on the US keyboard 
(hence the [ and ]).

Strangely enough, the ( and ) of Lisp derivitives is better supported 
on phones :)

but then the { } aren't there either and in fact, { } on european 
keybord sometimes is even worse... (alt key use beurk)

There used to be someone on the ML who was always complaining about 
the WinCE version ... and the keys

[

, "]", "/" and "-" were chosen because they can be typed on a US 
English keyboard without using the shift key. The fact that you can 
program in REBOL without using the shift key most of the time speeds 
up your typing of REBOL code (though not the name REBOL).

I'll just make a remark about "invalid" data.  If the lexical stashed 
those in foreign! it would no longer be "invalid", it would become 
the REBOL foreign! datatype!   You can't add email! url!   but they 
are sitll loadable values.   And again, professionals are NOT who 
I want to assist here.  It's the casual home user.   Allow 1000 casual 
users, 30 might become rebols, 1 might become a valued member of 
REBOL3 that we learn something from or develops Video Altme.   We 
add to the pile.

If I had known English and REBOL the same amount of time, I would 
be able to read REBOL quicker because the rules are stricter, and 
because I wouldn't have to look for periods and commas. This goes 
more so for C-like syntax - even slower to read.

On my current screen I can barely see periods and commas in AltMe 
(netbook).

and the new name is... REBORG    ;-)

Steeve; I'm not bringing up this point for OUR scripts, it' grandma's 
and Joe the Plumbers.

Do you not see the simplicity of foreign! data?   No speed problems, 
the lexical gets to a point where it would throw and it stashes a 
foreign!, keeps on truckin'.

Here's the current source for LOAD:

load: func [
	{Loads a file, URL, or string.}
	source [file! url! string! any-block! binary!]

 /header  {Includes REBOL header object if present. Preempts /all.}

;	/next    {Load the next value only. Return block with value and 
new position.}

;	/library {Force file to be a dynamic library. (Command version)}
;	/markup  {Convert HTML and XML to a block of tags and strings.}
	/all     {Load all values. Does not evaluate REBOL header.}
	/unbound {Do not bind the block.}
	/local data tmp
][
	; Note: Avoid use of ALL func, because of /all option
	if any-block? :source [return :source]

	data: case [
		string? source [to-binary source]
		binary? source [source]
		; Check for special media load cases: (temporary code)
		find [%.jpg %.jpeg %.jpe] suffix? source [
			return load-jpeg read/binary source
		]

  url? source [read source] ; can this possibly return not binary! 
  ?
		file? source [read source] ; binary! or block of file!
	]

 ; At this point, data is binary!, a block of file!, or something 
 weird.

	if binary? :data [
		unless find [0 8] tmp: utf? data [
			cause-error 'script 'no-decode ajoin ['UTF tmp]
		]

		; Only load script data:
		if any [header not all] [ ; Note: refinement /all
			if tmp: script? data [data: tmp]
		]
	]

	unless block? :data [data: to block! :data] ; reduce overhead

 ; data is a block! here, unless something really weird is going on
	tmp: none
	
	; Is there a REBOL script header:
	if any [header not all] [ ; /header preempts /all
		tmp: unless any [

   ;not any [file? source url? source] ; removed: hdr in string is same
			unset? first data ; because <> doesn't work with unset!
			'rebol <> first data
			not block? second data
		][ ; Process header:
			attempt [construct/with second data system/standard/script]
		]
		; tmp is header object or none here
		case [
			tmp [
				remove data
				either header [change data tmp][remove data]
				tmp: tmp/type = 'module ; tmp true if module
			]
			header [cause-error 'syntax 'no-header data]
		]
	]
	; tmp is true if module, false or none if not

 ; data is a block!, with possible header object in first position

	; Bind to current global context if not a module:
	unless any [
		unbound
		tmp ; not a module
	][
		bind/new data system/contexts/current
	]

 ; data is a block! here, unless something really weird is going on

	; If appropriate and possible, return singular data value:
	unless any [ ; avoid use of ALL
		all
		header ; This fixes a design flaw in R2's LOAD
		;not block? :data ; can this ever happen?
		empty? data ; R2 compatibility
		not tail? next data
	][data: first data]
	; If /all or /header, data is a block here

	:data
]

and I'm not even American!

We don't want foreign! by default though (or ever, but that is another 
matter), and you can't provide options to TO. We would have to support 
foreign!, or better yet fallback, incrementally with TRANSCODE.

Ok, I'd gladly accept a separate function, but ship it with REBOL 
for grandma and the professors of the world.  Don't make them hunt 
it down and DO it as a special case.    But to be honest, I'd still 
prefer a foreign! datatype! and advertise REBOL as a human readable 
language.  Much power in that ad imho.

Maxim;  And let cunning linguists write some scripts that tally the 
amount of WTF! information in wikipedia.   ;)

wtf! and associated query: wtf?

I can see Brian's and Gabriele's point.   Clear, concise REBOL is 
power.  But so is letting non-techies use the console.  Power in 
numbers.  And it's sooo close already.

BT: It should at least be a separate function, but I suggest separate 
from the language too.  a) it's too much baggage, and b) the scope 
for recognising string patterns could better be handled in a more 
open way.

I still don't see how a lexical foreign! would be that expensive. 
 Am I just not getting it?   Again, you cant   ADD email! url!  but 
they are valid types.  Make foreign! a valid type and then REBOL 
loads anything and series! operations can operate freely.

Adding a lexical foreign! means you add the overhead of checking 
for valid syntax to *all* REBOL code, not just LOAD. It removes your 
ability to trust that what comes out of LOAD is valid. That is a 
huge overhead to all REBOL code, and would be the source of most 
REBOL bugs in the future. It is a horrible thing to do to the community.

Yes, meaningless; but there would be less syntax errors.  And once 
in a block, cleaning could be done, but wouldn't have to be.  That 
would be up to the domain problem at hand.   I may never be convinced 
that having rules for what can be added would be that much different 
if REBOL were allowed to   make foreign!

No *you* want syntax errors.  I want to load %kingjames.txt  and 
call sort.   ;)

Right, and that throws an error.

I have a variety of booze here, and thanks for reminding me Steeve 
:)

Can't you see how cool it would be to let a person   load %textfile.txt 
and do analysis?  With foreign! sitting there ready to trigger if 
evaluated?

Absolutely.  And ship that with Core.  I'll stop whining and whinging. 
  ;)

Some time ago we discussed this on a blog post.  Carl had some valid 
concerns about "where to restart the lexical scan", but I trust him 
and you and Gabriele to get that right, in an explainable way.   
So yes.

I don't know the name of the option, and I wouldn't be able to start 
implementing it until TRANSCODE gets more work.

I can't wait to plug the C version of liquid within R3 and be able 
to browse associations using paths!   :-)

I mean that AltME crashed on me twice in 5 minutes, and when I got 
back all of the messages in this group were gone. After the dot, 
the messages came back. Yay! I hate AltME.

I was working. I just fixed LOAD, DO and CLEAN-PATH, and they will 
be incorporated tomorrow. The current build has built-in functions 
to get to DocBase, RebDev and CureCode. We're really close to release.

No, you are not alone, I also think that and argued that point above 
:)

Sure, and it'll still be foreign!   so would 1212.12.1212.12121212.121212. 
  S'okay   still just foreign!   as would  $$$$12@@!@!@#3   just 
foreign!   instead of a syntax error during the make phase.

And tomc, yes,  unrefined load  is a poor choice of example   load/somerefinement 
 would be far better, but I still don't see the fear of foreign!

just as today   $123,45  loads as $123.45   I'm ok with that.   REBOL 
reports the type as money! and math won't break.  math (and other 
ops) would reject foreign!  just as it does now for email! or url!

To state my position - I have nothing against adding such functionality 
(if it does not slow central rebol parser). I did not use it, and 
I would feel more safe with string parsing anyway :-) I just need 
Carl to implement Parse proposal enhancements, and even lamers like 
me would be able to create decent parsing schemas :-)

In your cases, I do:

result: copy []

foreach line read/lines %kinggames.txt [parse-the-line-and-append-to-result-structure]

I'm aiming to open up REBOL to "all data" analysis and I don't see 
where that should scare normal rebols from going about producing 
good clean parses just as today;  with the addition of a foreign! 
datatype that has semantics of "junk"

yeah parse-the-line-and ... is not code a History Professor may feel 
comfortable writing.   I want REBOL to open up new domains, and I 
don't think this change really hurts existing usage.

But now it's sack time for me and I've broken a promise that I'd 
keep quiet on the issue (for another 2 months ... then I'll whinge 
again)   ;)

OK, I don't mind either way. Talk to gurus, as i can't see the consequences. 
If it does not slow rebol code parser, then it is OK. And as BrianH 
said - 'load is a mezzanine. It can be patched. I think that adding 
one refinement would not hurt us ...

Well, a refinement and a datatype with semantics of junk, power in 
my opinion, scary REBOL breaking crud to others (others that I do 
respect the opinion of), but I can't see the fear of this datatype!

conceptually even more complex than regular expressions cause they 
are recursive and stacked, when you build real parsers.

the syntax is pretty, but the concept of parsing is like lisping... 
and how popular is lisp... hummm... try learning lisp to your mom...

Where I had problem with parse was with some recursion, and variables 
not beeing local to the recursion level. That is going to be fixed 
with parse proposal. There are some really nice helpers suggested, 
so if we got them, parse is the king ...

but parsing is a hell of a complicated thing.  on the surface it 
looks easy, then you start trying stuff and the vast majority of 
people are stumped.

I think that if loading non rebol values would make many rebollers 
happy, and if there are no consequences to add such functionality 
to rebol, then there is not reason to actually not have it available 
...

We need something like load/markup.....That splits a string into 
<tags> and "strings". The strings can then be processed separately 
from the tags.

So load/datatypes -- split a string into recognisable REBOL datatypes, 
and other! (aka Junk!)

a bit like saying that series is the super type of both string and 
block.

when parsing it could be usefull sometimes, to be able to assign 
a label to a block, so we can leave it where it lay and know later 
on that its a block of some type.

that means additional transformations, memory management, and in 
other setups, it means your labellin is outside of the data...

adding this basic functionality in the language would allow us to 
use it directly in load and then just have a simple mechanism where 
either a new word, like 'ASSIMILATE is used and indentifies foreign 
data with a  !foreign!   label.

hmmm...[spoiler]

in R3, seems that to send and receive requests to an html server, 
it's really as simple as.

data: load write http://www.rebol.net/cgi.rto-binary "my request"

I like that a link too the RebDev chat client is built into R3 (as 
of the last build). Links to DocBase and CureCode too.

for Docbase and curecode it's only open the browser

And the CureCode access willl let yo see bugs when REBOL itself is 
too buggy to see them. I find that comforting.

and with no parameters too, y

For example, I'd add quite a few protects in my user.r to ensure, 
no application tries to replace how LOAD and SAVE function...

The medium is the message and the message is sweet.

Site is currently on my laptop and is sometimes disconnected.

at sound (to my limited knowledge) there are many solutions but neither 
one is ideal. It's not like software rendering for graphics - where 
you know they will work everywhere. Or even OpenGL (which has problems 
on certain % of windows users because of bad drivers)... there is 
OpenAL but it also won't work on some hardware. Example of this is 
that something as big as Java doesn't have a solid sound library 
that would work in non-signed applets. I wrote a game in processing(java 
lib/lang) but had to rewrite it to java+lwjgl+jopenAL because there 
was no way to make native java play sound consistenty. Basically 
it didn't work on more computers that it did, and processing is very 
media oriented.

IMHO rebol makers shouldn't worry about these side things... they 
should take care of the language design, it's runtime ( easy to extend, 
embed, stabile,. fast) , and the core/native libraries that they 
decided to bring like networking, gui.. if that will be good I am 
sure community will bring in the various external bindings, and build 
rebol frameworks/libs etc (like they have so far)..

I will prey my God that RT will be able to provide what I described, 
because that is the root of all things and I imagine no simple task. 
I don't worry for community part.. when someone will need something 
bad enought  they will make a binding/lib/framework

Hopefully, Gabriele can stop by and give us some scoop on when they 
think it will actually be released.  I don't know if I should hold 
off on Tretbase development or continue.  Since my plan was to port 
to R3 eventually anyway.

Why could it not run on R2 and R3 both?

Kaj, there will be a useful subset of REBOL that will work on R2 
and R3 both. Optimized code will often not do so.

(and I have a few)

and cat

btiffin also finds the behavior of H to be wrong and I agree. It 
will quickly degrade into huge lists. Just imagine 20 more users.

I agree with btiifin, that 'tags for numbers would be nice. It would 
be nice to have e.g. R3 heading tagged as R3, and refer to it as 
R3 instead of the need to remember the number. I think that once 
GUI is available, this point will be moot. But I agree to provide 
some directory navigation like functionality.

A GUI client will certainly help usability, but since we have console, 
we can use it over SSH and that's a great thing.

Well, it is more flexible than Altme and Carl wanted to be some prototype 
start of new Altme. It has real threading, tagging, ranking, private 
messaging, is spriptable. So good so far. But - we also need read-only 
groups, private groups, or other app schema over it.

Graham, yes, just like you can SSH to a linux box and use Rebol/Core 
through that already now.

kib2, yes and I hate to say it again, but: R3 also solves this problem. 
:-) It's quite amazing how many times I've said that now.

Just wondering how this will all scale over different devices and 
media

kib2: why? Perl 6 is in development two times the R3. And one year 
ago there was a public alpha. Soon enough there will be another one. 
This time with final GUI architecture (although not complete yet)

So Carl1 could focus on rebdev, Carl2 could focus on tasks and Carl3 
could focus on modules. Carl4 would work on the GUI and ReBrowser.

just give us more docs and we can do this

It is _the_ issue. Carl trusts no one unless you can work at his 
level. And that is also why the quality of R3 alpha feels like everyone 
elses release versions. :-)

When we use to block! on input data, most of the time we don't want 
 duplicate them if data are already a block.
(we use copy instead if we really want that behavior)

i think to block!, to string! , form and some other native conversions 
should never duplicate the data if they already have the correct 
format.

This, should limit the memory overhead in many scripts or mezzanines, 
and save us from coding many useless tests.

it appears to me that most of mezzanines who have to do such conversions 
could be 1) shorter and faster 2) with less memory overhead

I agree with you and it seems to me that it would be a wise fix.