As all features in the specifications are not yet implemented (I would say 85% is already done), I have added a todo-list on github's wiki to track the missing parts.
Also, all features are not yet set in stone, there are still a few important design decisions to take in the next weeks:
- Pointer! datatype: should we keep it or consider that struct! datatype can do the same job, so it's not worth the trouble of supporting an additional type for the syntactic sugar? Let's take an example with a pointer on integer and struct having a single integer member:
p: &[integer! 0]
Looks pretty much the same. Pointers have a shorter literal form, but once declared, structs could be used the same way and replace pointers in all use-cases.
p/value: 123
p: struct [value [integer!]]
p/value: 123
- Array!: will it be necessary to add a standalone array! datatype or could its semantics be simply added to struct! or pointer! (if finally kept)?
- Booleans: there's currently no true/false support in Red/System, so that boolean values are not first class (can't be assigned nor passed as argument). This is quite limiting the expressibility of the language. Is using simple integer values (0,1 or 0,-1) enough or will it be better to support it as a separate datatype (logic!)?
The answers to these questions will come while working on unit tests and coding Red's runtime (written in Red/System). Feel free to share your thoughts about these features here, in comments, or on Google groups.
avantage supplémentaire boolean taille en mémoire
ReplyDeletede même que pointeur par rapport à structure.
De plus ces types sont usuels et cela risque d'être déroutant pour programmeurs habitués à les utiliser.
Oui, il a y a un coût mémoire supplémentaire pour le struct! comparé au pointer!. Je crois qu'il sera préférable de garder les deux. Je vais également revoir la syntaxe pour la rendre plus cohérente entre les deux types.
ReplyDeleteje pense effectivement que de créer les booleans et les pointeurs est le mieux, en revanche je ne vois pas l'utilité de rapprocher les syntaxes des structs et des pointeurs. Il me semble normal que les syntaxes soient différentes puisque les structures contiennent des champs contrairement aux pointeurs.
ReplyDeleteCorrection: tu dois vouloir parler des crochets autour du type.
ReplyDeletedifficile car les crochets sont cohérents avec les habitudes de déclarations de variables dans les fonctions en rebol, cependant sans crochet c'est plus lisible selon moi.
En fait je pencherais pour le sans crochet, mais dans toutes les situations y compris dans les déclarations de fonctions...
Je pensais aux pointeurs sur struct! qui s'écrirait: &[struct! [...] 0], la déclaration d'une valeur struct garderait une syntaxe différente.
ReplyDeleteDe toute manière, je dois refaire une passe dans les prochaines jours sur les syntaxes string!, pointer!, struct! et surtout array! afin de voir s'il n'y a pas des améliorations ou corrections à apporter avant de les figer et finir leur implémentation.
A propos, merci pour tes retours. :-)
la syntaxe &[nom_de_la_structure 0]est un peu plus légère, non?
ReplyDelete&[struct! [...] 0] s'apparenterais à une double déclaration pointeur et structure à la fois.
alors qu'il me semble plus didactique de faire en deux passes, une déclaration puis l'autre. Les manips de pointeurs sont des points de programmation sensibles. Par conséquent il faut être précautionneux quand on les abordes en tant que prog et plus encore en tant que concepteur de langage. Car la conception du langage formate très largement le style de programmation possible avec le langage créé.
Cela peut amener des malentendus, et c'est quelquefois à partir de là que l'on fait des reproches à un langage de prog, alors que le défaut est un manque de maîtrise de ce langage.
this:
ReplyDeletebah
is a word or a number?
bah is an hex, but it should be written BAh for easier reading ;)
ReplyDeleteHi,
ReplyDeleteSomebody out there who has the knowledge to create a compiler for RED/System to Java Runtime. Would be a fantastic addition to Red!
That is on our roadmap. An experimental JVM port will start soon.
ReplyDeleteThats right @nenad
ReplyDelete