AltME groups: search

Returning null in such a case is natural in other languages as well.

why 1 would be a better starting index than zero? Why not 2, or 10? 
The answer itself is interesting because it shows a lot about the 
though process of the people defending the idea.

 - what an flawed argument - the guy completly missess language as 
 REBOL imo, where we have first, second, etc. And first simply returns 
 first real thing. What is zeroth thing?

I am not sure REBOL introduced the easy model - it is mixture of 
those real existing values, and virtual elements:

blk: [a b c]
index? head blk == 1
index? tail blk == 4


I can imagine tail simply pointing to the last element, as well as 
head pointng to the "zeroth" element. But then, if we would not think 
about "in-between" positions, how would insert behave? If I would 
once agin think about the real example with e.g. 3 ppl standing in 
the line, and I say - go, and insert yourself to the last position 
- does it mean new person is going to be third, and shifts the last 
one to the fourth position, or does it mean the person just adds 
himself/herself to the fourth position?

Completely agreed 0 does not exist, even not for computers. A computer 
with 0 memory does not have memory at address 0 either :)

Counting starting at 0 is nonsense. No matter who and how many times 
it is explained. In human/fysic world we only put letter 1 in envelope 
1, letter 2 in envelope 2 etcetera, there is no letter 0 to put into 
envelope 0. It is only a confusing trick to start at 0. (I know you 
can look at memory like a binary tree) In these days of plenty of 
memory, I say let location 0 unused. Besides for who was REBOL meant 
initially? People. Scientists not computerscientists. Let those struggle 
with C and the likes. 1-base is one of the big plusses REBOL has 
over the majority of other languages. (enough bikeshedding from me 
today)

Please move the discussion whether "0 exists" elsewhere. REBOL's 
integer! corresponds to integers and includes 0. Unless you want 
to change that as well, that's a fact we have to live with.

Andreas - stop pesking us for such a chat. Many arguments areound 
are based upon various arguments, some of them leading to history 
of mankind/math itself. Thanks ...

Whilst Pascal allows arrays to have a user specified base for array 
indeces, the default is 1 based. It also allows a zero element:

Code
program Arrays;
uses SysUtils;
var
  i : Integer;
  myArray : Array[-1..1] of Integer = (1,2,3); 
begin
  for i := -1 to 1 do

    writeln('Element ' + IntToStr(i) + ' Value ' + IntToStr(myArray[i]));
end.

Result
Element -1 Value 1
Element 0 Value 2
Element 1 Value 3

Well at least I understand the issue a little better :-)

But I guess they are all absolute addressing rather than addressing 
realtive to a current position? I believe Pascal is.

Is it true to say that whilst there is no effective difference (in 
logical terms) between 0-based and 1-based absolute indexing, there 
is a difference when it comes to relative indexing,

I feel that there is a consitent way to look at 1-based relative 
addressing but only if you consider 0 to be the position immediately 
before the current position.


It is to define the given index as an offset from 1 (the current 
position). (Examples using current position as absolute index 5 [1-based])


index 10 would be calculated as offset 9 positions from the current 
position [absolute 14]

index 1 would be calculated as offset 0 from the current position 
[absolute 5]
index 0 wold be offest -1 from the current position [absolute 4]

index -1 would be offset - 2 from the current position [absolute 
3]


I know that most people will see this as a kludge or don't like it's 
different behaviour to REBOL2.

On the other hand, it can be explained in a consistent manner.

Here is a new proposition for solving the "PICK issue":

1) Forbid <= 0 indexes.


2) Add a PICK-BACK action that will take only positive integers, 
PICK-BACK series 1 would return the first element on the left of 
current series position.


3) As PICK-BACK is not a very nice and concise name (I like actions 
to be named with a single word), an op! alternative would be provided: 
<- (opening angle-bracket followed by a dash aka "ASCII arrow")

Examples:
    >> series: next [A B C]
    >> pick-back series 1
    == A
    >> series <- 1
    == A
    >> series <- 2
    == none			;-- to be consistent with out-of-bound PICK


For path notations options in such scenario, I'm open to propositions. 
So what are the pros/cons of such solution?

In forbidding indeces < 1 would none be returned or a runtime error 
raised?

Seeing as the use cases for accessing elements before the 'HEAD appears 
to be quite rare, couldn't pick-back be left as a "mezzanine":

pick-back: func [ser index] [pick skip ser negate index 1]

A runtime error. Having it as a mezz could be a good option.

As for naming wouldn't a refinement be better?

pick/back series pos-int

Doc, the above proposition makes sense if you *also* have a contiguous 
PICK function which you can loop on from negative to position without 
gap (like R3).  I'd use a PICKZ  to eliminate the "0" weirdness from 
the discussion, in that case.

With that background, I still think adding an ordinal! type is a 
nice solution. Here's the basic proposition:


1. introduce an ordinal! type, with literals: -3rd, -2nd, -1st, 1st, 
2nd, 3rd


2. extend PICK and POKE (and paths) to accept integer! and ordinal!

3. have SKIP only accept integer!, AT only accept ordinal!

4. define FIRST, SECOND, THIRD, etc as PICK 1st, etc

4a. maybe add dual FIRST-BACK (or use a /BACK refinement)


That in place, you keep all the nice "human-friendly" features of 
current R2, at the only expense of sometimes having to type 2 extra 
characters.

first to left

: that's how I read `series/-1` in R2...So if it's just a matter 
of making an implicit convention explicit, better just add a statement 
in the documentation than pay the cost of an additional datatype, 
no?

Fine with me, but I think you will still want a method that allows 
you to used the full range of integers as computed indices.

That is a third debate.

You will still always want a method for computed indexing with the 
full range of integers independently of whether that anchors at 0 
or 1.

Could be another refinement to PICK, such as PICK/FULL. Or a separate 
function. Or if you just PICKZ (or PICK/ZERO), if you want to add 
that

I still fail to see a real-world use-case where you need both negative 
and positive indexes at the same time (in other words, compute indexes 
*over* current position). Even in such rare case, you can still do 
the computation using INDEX? SKIP values (so switching to absolute 
indexes instead of relative ones).

Note also that in the PICK/BACK scenario, negative integers become 
available for a new possible usage, like addressing a series from 
tail (if that makes sense in a REBOL-like language). I know Brian 
is fully against that, but we need objective arguments to reason 
upon. "From tail" indexes are still a toy idea for me, until we can 
list all the pros/cons and see if it is an helpful addition or a 
bad idea.

I basically prefer adding a datatype than adding a syntactic hack.

My Understanding of Series:

A contiguous collection of boxes sequentially numbered in ascending 
order starting at 1.
Each box can contain any rebol value
The head of a series is always box number 1

The last item in a series is always in box number (length? series)
The tail of a series is always box number (length? series) + 1

Any series can have multiple words referencing any box in that series 
resulting in a sub-series (but not a copy)

index? series - always returns the box number of the value referenced 
by series

Evaluating a word referencing a series returns the series from box 
number (index? series) up to and including box number (index? tail 
series)

index? is the only rebol word that directly uses the box numbers 
of the series

All other rebol words that manipulate series are relative to the 
box number of the word referencing the series

A series is empty when: equal? head series tail series => true – 
or – when all boxes are empty

Examples:

s1: [a b c d e f g h i j]  => creates 10 boxes numbered 1 to 10 from 
the left with a in box 1 and j in box 10 – unseen is box 11 which 
is 'tail as seen by: index? tail s1

s2: at s1 3 => references s1 starting from box 3 of s1 - [c d e f 
g h i j]

s3: at s2 4 => references s1 starting from box 6 of s1 - [f g h i 
j] which is item 4 of s2

probe index? s1 => 1
probe index? s2 => 3
probe index? s3 => 6


probe head s3 => [a b c d e f g h i j] - showing that s3 references 
the same series as s1

probe pick s1 2 => 'b
probe pick s2 2 => 'd
probe pick s3 2 => 'g


probe s3/-2 - this is shorthand for back back s3 or pick s3 -2 (the 
negative number simply means move back twice) => 'd

probe tail s1 => []
probe tail s2 => []
probe tail s3 => []

forall s2 [prin first s2] print => cdefghij
forall s3 [prin first s3] print => fghij

probe index? tail s1 => 11

Possible SOLUTION:

So, what is missing? Words that directly manipulate the box numbers 
(index)? – so maybe we need something like this:

s1/index: 4 => sets the index of s1 to 4 and causes word s1 to reference 
the series starting from box 4

add s3/index 2 => adds 2 to the index of s3 causing s3 to reference 
the box 2 places further on => 'h

add s2/index -2 or subtract s2/index 2 => subtracts two from s2's 
index causing s2 to now reference box 1

You can now use any mathematical operations on the index of a word 
referencing a series as long as it results in an integer in range

If index? series > (length? series) + 1  or index? series < 1 then 
an "index out of bounds" error should result
Zero is a non-issue because it has no meaning in a 1 based series

This kind of shorthand: s1/-3 becomes redundant - but if kept still 
means: back back back s1

I honestly think there is so much confusion over this because we 
are trying to merge together two different "concepts". Concept 1 
is a series which is traversed as in Rebol 2 and whre s/-2 is shorthand 
for back back s. Concept 2 is a 0 based sequence which is traversed 
via index manipulation. The concepts need to be kept seperate even 
if they are applied to the same set of contiguous boxes. The only 
way to do this as far as i can see is to develop a set of index manipulation 
functions in addition to the existing series traversal functions. 
The concepts can then be easily taught to newbies and gurus can mix 
and match to their hearts content.

If anything, s/-2 is a shorthand for `FIRST back back s`.

Whereas s/2 could be conceived as shorthand for `first next s`. And 
there you already get a glimpse at the problem:

- s/2 is first next s, s/-2 is first back back -- why is there 1 
next but 2 backs?
- what is s/0?

Concept 2 is a 0 based sequence which is traversed via index manipulation.

That interpretation doesn't match `FIRST s` and `PICK s 1`...

Ken, re maths for ordinals: just a matter of how you want to define 
it.

The more interesting question is how ordinals map to integers :) 
That basically requires a decision of how you want to do indexing 
with integers, then it's easy as well.

It's just a dialect for going in the opposite direction

 - it is not, in fact. (PICK SERIES INDEX) is just an evaluation of 
 a function, not a "dialect"

I don't buy the 

no right" argument. Romans had subtraction without 0. It was a bad 
idea, but it was possible." Yes, but -1 is not "subtraction", it 
is a value.

Now, try to come up with a way to explain to newbies that this phantom 
hole in a series makes sense, or is a good idea.

 - yes, a good illustration from a beginner/documentation/education 
 POV. Also, what is exactly as bad even for experienced users is that 
 it disrespects arithmetic making simple index arithmetic (ADD INDEX 
 OFFSET) not usable.

...it means that 0 doesn't exist, like we're programming in Roman.

 - again, a cute formulation. I bet that there is no "programming 
 in Roman", the word "algorithm" is from the world where 0 does exist.

It's just a dialect for going in the opposite direction" - it is 
not, in fact. (PICK SERIES INDEX) is just an evaluation of a function, 
not a "dialect""

My Understanding of Series:
A contiguous collection of boxes sequentially 
numbered in ascending order starting at 1.

 - this is correct only for series I would call "Head Series", i.e. 
 such series that are their own heads.

Agreed, "not usable" is a little harse. Bad and awkward, but once 
you work around that it is usable.

You actually have that you have to work around it, otherwise R2 will 
bite you hard (and silently).

 - yes, "you have to work around it" is (for me) a different formulation 
 equivalent to "not working"

I am able to do any work-arounds necessary at any time. However, 
I prefer to use a working solution.

Here is a task I consider relevant:


1) define a function obtaining a series S and an index I and yielding 
an index J such that PICK S I would be equivalent to PICK HEAD S 
J
1a) do the task in R2
1b) do the task in R3
1c) do the task in R4 with zero-based indexing

(again, a case of "working index arithmetic")

(although a bit more complicated than the 1c case)

1a) is a task for people stating that "zero does not exist"

I know this would be consiidered a "workaround" but

head-index?: func [s i] [i - (index? head s) + (index? s)]

So, if we consider Peter Wood a "common man"(no offense intended), 
do you state that his solution works?

Kaj is write I wouldn't write such a function.

To oblige you, because Peter is such a nice commoner :-)

Well, I would state that my task looks like a "simple enough task 
to tackle", and the one even inexperienced users (surely not only 
mathematicians) should be able to tackle, and they would, as Peter 
demonstrated, if the index arithmetic weren't broken.

That's not the point; as Peter said, a common REBOL programmer wouldn't 
program this function exactly because there are better solutions

Give us a better solution than PICK/POKE then.

One note: as far as I can tell, s/-1 is not a common pattern at all, 
but rather a quite "uncommon" one in as far as it is rarely encountered 
in real REBOL code. FIRST and /1 are the common patterns, which are 
not touched by R3.


Actually, the only thing different in R3 that arguably "works for 
common people" in R2 is this uncommon pattern of s/-1 and s/-2. Every 
other use of negative indices is broken in R2 (and as such, works 
for neither mathematicians nor common people) but works in R3.

I really don't care about path syntax with computed indexes, it's 
ugly and awkward, and broken because of the 0 hole. I'd really rather 
use a function. As long as we get PICKZ/POKEZ, I'll be good. We already 
have SKIP to act as a non-broken AT. But at least plug the hole with 
a triggered error, so it won't mess people up silently. It's a huge 
failure, at least make not fail silently.

Nenad already counted a lot of occurrences of /-1 in Red. Most others 
have failed to contribute analyses of real code

In the ancient (!!) rebol.org snapshot I have locally, I counted 
11 occurrences in 8 files (blog, new-blog, make-doc, make-doc-pro, 
makedoc2, json, translate, xml-dom) in a total of ~1000 files and 
255k lines of code.

Just to make myself more clear for "common people": I think that 
the programming language should be designed so that "common people" 
should not need a specialized mathematical training to be able to 
define the HEAD-INDEX? function; rather I think that they should 
be able to successfully tackle a problem of such a low complexity 
without any problem. Also, I noticed that Kaj's opinion differs.

Brian, just for the record, I find your proposal reasonable and pragmatic.


If I'm given PICKZ and POKEZ, I couldn't care less about the poor 
souls suffering from trying to use path syntax with negative indices 
and falling into the 0 hole. Maybe a bit egoistic, but well.

I was bothered by them not fixing AT in R3 as well. There's a lot 
wrong with R2.

The hole roams with the position of s, so the result would be a constant 
regardless of that position.

Ladislav, thanks for bringing a tangible example that demonstrates 
our both points. I will try to be brief:


1) I will start by repeating again that nobody contests that having 
a continuous numbering is better than a discontinuous one (for pure 
arithmetic efficiency, as you've showed).


2) Brian showed that R2 is not "broken" as the head-index? function 
can be written. 


3) I have never needed to write such "workaround" in R2, nor did 
I remember seeing it in others code (if someone did use such workaround, 
please step in, we need real-world use-cases).


4) According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases. 


5) I often use series with an offset and I do index computation on 
them, but usually, in a single direction at a time (using only positive 
*or* negative indexes). In the very rare cases where I need an index 
computation "over 0", I switch to absolute (from head) indexing, 
but not relying only on index arithmetic, but also on series navigation 
using the INDEX? SKIP idiom. This short idiom gives exactly what 
your head-index? function gives to you, but using series navigation 
abilities rather than pure index arithmetic. Of course, it works 
because SKIP is an implicit 0-based system with no hole.


6) INDEX? SKIP in R2 solves the "hole issue", for the very rare cases 
where we need to solve it. So, allow me now to propose my own head-index? 
implementation:

    head-index?: func [s [series!] i [integer!]][index? skip s i]


It is not pure arithmetic for sure, but we are programmers, not mathematicians 
(except you who is both :-)), so this solution is IMHO as acceptable 
as pure arithmetic ones, from a programmer's point of view.


So, what I contest is the trade-off required for "fixing" index arithmetic 
in R3, resulting in IMHO "broken" PICK and path notation for 0 and 
negative indexes. Also, given that INDEX? SKIP is available in R2, 
the "fixing" seems even less necessary. Still, I am open to discussing 
options for improving index arithmetic but *without* having to break 
other features.


I think we will agree to disagree about the right trade-offs between 
R2 and R3.


So, can we now all focus on studying the different improvements proposed?

Excellent. With such a simple solution, even ordinal! seems excessive

Doc, I can splint a broken leg but it doesn't make it less broken. 
Still, you're lucky thet you haven't been caught by this.


As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work. If PICKZ and POKEZ are available, those of us who need something 
that works will have something. I don't mind even making R3 work 
like this, but only with the error and the alternate working functions. 
Let the people who insist on using path notation bear the brunt of 
the problem, so be it.

According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases.

 - as opposed to that, my opinion is that the HEAD-INDEX? function 
 represent an, "extremely simple" use case that everyone should be 
 able to solve without having a specialized training to be able to 
 do so.

Instead of throwing error on pick 0, can I propose adding undefined! 
datatype? In ActionScript, which I use quite often last days you 
can distinguish not defined and null values like:
	var a:Array = new Array();
	a[1] = 1;
	a[2] = null;
	log(a[1], a[2], a[3]); //<-- would output: 1, null, undefined

Btw.. I think it was me who asked Carl to implement path notations 
with parens allowing to write b/(n) It's in REBOL since 2.6.. sorry 
if it's causing confusion.
http://www.rebol.com/docs/changes-2-6.html#section-8

'So, what I contest is the trade-off required for "fixing" index 
arithmetic in R3, resulting in IMHO "broken" PICK' - this is the 
main point, as I see it. If I remember well, you consider PICK broken 
since "0 points (maybe unnaturally for you?) backwards for PICK"? 
If that is what you dislike, then I can sympathize, having similar 
feelings:


It is necessary to realize what PICK SERIES INDEX is supposed to 
do. In my opinion it is a "relative operation" (relative to the current 
series "index" - having two series with common head but different 
"indices" we expect the PICK function to yield different results). 
Us such, we need to realize that we already have a "relative operation" 
for series for quite some time, which nobody contests to be "relative" 
- it is the SKIP operation. So, we have SKIP SERIES I being relative 
and we should have a natural obtain-value-of SKIP SERIES I shortcut 
instead of the whole nonsense, which is what you instinctively do 
presenting your (in R2 wrong!) HEAD-INDEX?.

Excellent. With such a simple solution, even ordinal! seems excessive

 - OK, since Kaj named the solution "simple", I can agree that (and 
 never questioned) that SKIP SERIES I is a good operation to use and 
 that really produces the simplest possible:

(PICKZ SERIES I) ?= (PICKZ SKIP SERIES I 0)

Now we see why AT is designed with a discontinuity: to compensate 
for the discontinuity in indexes

Well, I wonder, if the debate can have any resolution at all? What 
would be probably good would be if each person (who feels skilled 
enough to provide a solution), would define complete solution to 
the problem in REBOL-like languages ....

(what is interesting is the fact that when you rely on this, you 
get 
kicked in the butt" like Carl was)"


I respectfully disagree. :-) You are right in that my proposition 
doesn't exactly match the requirements, because the requirements 
imply a 0-based reference that I've missed. So, here's a corrected 
version that matches your requirements:


    head-index?: func [s [series!] i [integer!]][(index? skip s i) - 
    1]


I am probably too influenced by the way Carl designed R2, but I still 
think that a 1-based index system has value. (Let's save the 0-based 
vs 1-based debate for another day)

As long as pick or poke series 0 triggers an error instead of returning 
none, that will be enough to stop people from using it when it doesn't 
work


I agree that R2 not returning an error on 0 is a real issue that 
needs to be fixed. If someone thinks that disallowing 0 in a 1-based 
system makes me stupid, so be it.

You are right in that my proposition doesn't exactly match the requirements, 
because the requirements imply a 0-based reference that I've missed.
 - exactly the opposite is true, no "the requirements imply..."

I agree that R2 not returning an error on 0 is a real issue that 
needs to be fixed.

 - if you want, you can trigger an error, but I don't think it makes 
 any sense to "return an error".

Ladislav, I didn't say triggering an error wasn't stupid, I said 
that it was less stupid because it was louder. R2's current behavior 
is made worse by it happening silently, making it difficult to track 
down where you code went wrong when it called PICK or POKE with 0 
by accident. Triggering an error makes it easier to find these situations. 
It's a way to ameliorate a bad situation.

Doc, refinements slow down functions unless the optimizer can resolve 
them staticly. If compatibility is a value, it's worth mentioning 
that REBOL doesn't have such an optimizer, so it is stuck with the 
same situation that you have when you can't know whether the refinement 
will be used ot not (see APPLY). Separate functions are better in 
this case.

And, yes, Henrik's solution using AT could be considered a 1d) solution 
for Red in case the functions will work as he indicated

BTW, 0 is the reason why many arithmetic algorithms work, so getting 
rid of 0 helps only to get back in time before 0 was invented, to 
the time when those algorithms did not exist. (the word algorithm 
itself is actually pointing to the city where a zero proponent and 
matmenatical giant Muhammad ibn Musa lived).

However, in REBOL (no matter how it is implemented) there is a difference 
between "returning an error" and "triggering an error". A compatible 
implementation would need to maintain such difference, I guess.

While it's too late to keep all this chat out of the Red channel, 
if you would all like to continue this very specific discussion, 
I will create a group just for that.

Cool, now it's a real programming language

This is a great new Doc ! BTW why  use /local refinement ? Don't 
you think that would be better to have words local by default, and 
to use /global when needed ?

Such model would not work with lexical scoping. For example, you 
wouldn't be able to access words from parent object from a function 
because you will be only able to define local (to function context) 
or global context words.

It doesn't scale well, and as you can see in the following example, 
it can quickly get nasty:


    [/external obj1 [a b] /external obj2 [c d] /external obj3 [e f] /global 
    g h]

You can't arbitrary pick a feature in one language and drop it in 
another one and expect it to have the same benefits...especially 
when they are so different. ;-)

That design note would make a great doc entry somewhere. Is there 
a Red wiki where we can stash these things, or what would be the 
preferred method at this point?

Now Red supports 21 datatypes. In the following R3 datatype list, 
datatypes with a minus prefix are not supported in Red yet.


action -binary -bitset block char -closure -command datatype -date 
-decimal -email -end -error -event -file -frame function get-path 
get-word -gob -handle -image integer -issue -library lit-path lit-word 
logic -map -module -money native none -object op -pair -paren path 
-percent -port -rebcode refinement set-path set-word string -struct 
-tag -task -time -tuple -typeset unset -url -utype -vector word

just a note: there is absolutely no need to support the end! datatype. 
REBOL doesn't support it either, in fact.

Jerry, I am not sure, I would post such a list, especially to Red 
FB channel. It looks almost discouraging. How will you measure the 
quality of Red e.g. running on ARM, and R3 not?

Moreover - Red is not a clone of R3, some things might be done quite 
differently in the end imo ....

Jerry: command!, end!, frame! and rebcode! are very unlikely to be 
adopted in Red. Also following will probably not be part of Red too 
(or not in a near future): event!, gob!, handle!. Meaning of decimal! 
will most probably be changed, float! or real! will be used instead. 
Money! will receive a different treatment than in REBOL (number of 
digits after comma will probably be adjustable).


Also, expect the return of hash! in Red, and new datatypes that do 
not exists in REBOL.

As you can see, it is not a 1-1 matching between Red and R3.

I agree with Peter, you can't measure Red's progress by taking R3 
as a target goal. It is better and more accurate to measure progress 
by counting what is built in Red.

Hopefully less buggy too. The rebcode dialect caused a lot of crashes 
and security holes, which is why it was removed. The new mechanism 
doesn't have that problem.

For handle!, what type are you using to be an opaque pointer-sized 
type that all pointer operations are prohibited on? Can such a thing 
be typedefed?

If you had an ability to create an opaque value of any size that 
will fit in a value slot, or maybe just limited to pointer size, 
only accessible from Red/system code, that would be a good replacement 
for handle!.

The advantage to rebcode isn't that it's fast, it's that its semantic 
model is similar to assembler. That makes it useful for a lot of 
interesting problems. Also, there might be times when you don't want 
to allow Red/System to be inlined - it's basically the same as unsafe 
code in C#, with the same security characteristics.

In Red, there might be an advantage to making a compiled rebcode 
equivalent (but without the stability and security bugs). Unlike 
REBOL (ignoring the debate), rebcode is inherently compilable. It 
wasn't designed to be interpreted the way REBOL was. It just had 
a fast interpreter implementation, which has been adapted to other 
dialects in R3.

Right, found it, the DO-COMMANDS function. That is what implements 
the rebcode interpreter model. And it's another reason to have a 
command! type.

Sure, but Red and Red/System are also inherently compilable. I think 
there's very little advantage left in a virtual assembly dialect