En Python, et très probablement dans de nombreux autres langages de programmation, des structures de données communes peuvent être trouvées comme une partie intégrée du langage de base avec leur propre syntaxe dédiée. Si nous mettons de côté la syntaxe de liste intégrée de LISP, je ne peux pas penser à d'autres langages que je connais qui fournissent une sorte de structure de données au-dessus du tableau comme partie intégrante de leur syntaxe, bien que tous (mais C, je suppose) semblent les fournir dans la bibliothèque standard.
Du point de vue de la conception d'un langage, que pensez-vous de la présence d'une syntaxe spécifique pour les structures de données dans le langage principal? Est-ce une bonne idée et le but de la langue (etc.) change-t-il la qualité de ce choix?
Edit: je suis désolé d'avoir (apparemment) causé une certaine confusion sur les structures de données que je veux dire. Je parle de ceux de base et couramment utilisés, mais toujours pas des plus basiques. Cela exclut les arbres (trop complexes, peu communs), les piles (trop rarement utilisés), les tableaux (trop simples) mais inclut par exemple les ensembles, les listes et les hashmaps.
Réponses:
Cela dépend à quoi sert la langue.
Quelques exemples (quelque peu volés dans d'autres réponses):
Je pense que cela dépend du but / de l'esprit / du public de votre langue; dans quelle mesure vous êtes abstrait et éloigné du matériel. Généralement, les langues qui prennent en charge les listes en tant que primitives vous permettent de créer des listes infiniment longues. Tandis qu'un niveau bas comme C / C ++ n'en aurait jamais, car ce n'est pas le but, l'esprit de ces langages.
Pour moi, la collecte des ordures suit la même logique: le public de votre langue se soucie-t-il de savoir exactement quand et si la mémoire est allouée ou libérée? Si oui, malloc / free; sinon, la collecte des ordures.
la source
malloc
etnew
non déterministe en C / C ++).Perl a des hashmaps et PL / SQL prend en charge les enregistrements, et j'ai des souvenirs très brumeux de matlab ayant une syntaxe pour prendre en charge des vecteurs et des matrices de toutes les différentes dimensions (bien que je puisse me tromper à propos de celui-ci et on pourrait faire valoir qu'il s'agit de types de données et non de données structures ) ... Je dirais que d' avoir un soutien natif pour des structures très communes est agréable d'avoir. Habituellement, il semble que les tableaux et les hashmaps / tableaux associatifs soient les structures supportées nativement les plus courantes, et elles sont probablement aussi les plus couramment utilisées.
N'oubliez pas que si vous ajoutez le support de la syntaxe native pour d'autres structures telles que les arbres binaires, ces structures ont également été implémentées par les outils de support du langage (compilateur / runtime / etc). Pour combien de structures souhaitez-vous obtenir un support?
Vous devrez inventer une nouvelle notation pour les structures moins nativement supportées ... Keep It Simple !.
la source
Mon exemple préféré ici est Lua . Lua n'a qu'un seul type de données intégré, la " table ", mais sa flexibilité et sa vitesse signifient que vous les utilisez réellement à la place des tableaux réguliers, des listes liées, des files d'attente, des cartes et ils sont même la base des fonctionnalités orientées objet de Lua (c.-à-d. classes).
Lua est un langage incroyablement simple, mais la flexibilité de la structure des données de la table le rend également assez puissant.
la source
{}
non[]
, dans Lua vous en avez{}
pour les deux. Les tables Lua se comparent mieux aux listes en Lisp.Vous n'avez pas besoin d'avoir une syntaxe dédiée pour chaque type de données de haut niveau. Par exemple, il est tolérable d'avoir
set([1, 2, 3])
(comme Python 2.x) au lieu de{1, 2, 3}
.L'important est d'avoir une façon pratique de construire une structure de données de haut niveau. Ce que vous voulez éviter, c'est du code comme:
ce qui me gêne beaucoup quand je l' utilise
std::vector
,std::set
etstd::map
en C ++. Heureusement, la nouvelle norme aurastd::initializer_list
.la source
À mon avis, c'est un ajout incroyablement simple qui peut être utile étonnamment souvent, du moins s'il est fait avec prudence - c'est-à-dire tout au plus pour les tuples, les listes, les cartes et les ensembles car ceux-ci ont des littéraux bien reconnus.
someBracket {expr ','} someBracket
ousomeBracket {expr ':' expr ','} someBracket
, avec quelques extras simples morts si vous voulez des choses comme des virgules de fin facultatives. Les littéraux flottants peuvent facilement être plus longs dans la grammaire.{1, 2}
).add
/.append
/.setItem
une fois par expressions données avec cette (ces) expression (s) comme arguments".la source
Clojure est un vif mais prend en charge
la source
Plus vous avez de structures de données dans la langue elle-même, plus la langue sera difficile à apprendre. C'est peut-être une préférence personnelle, mais j'ai tendance à préférer un langage plus simple et tous les extras peuvent être fournis par les bibliothèques.
Les langages conçus pour des domaines spécifiques peuvent parfois bénéficier de la présence de certaines structures de données dans le langage comme Matlab. Mais trop de gens peuvent vous submerger.
la source
Pour qu'une langue soit vraiment utile, elle doit effectuer un certain degré de tâches prêtes à l'emploi. Parce que la programmation quotidienne pratique nécessite des outils qui résolvent leurs problèmes à un certain niveau générique. Le minimalisme a l'air compact et cool, mais lorsque vous souhaitez commencer à utiliser pour résoudre des problèmes importants mais répétés, vous avez besoin d'un niveau d'abstraction sur lequel vous pouvez vous appuyer.
Je pense donc que les langages de programmation devraient intégrer la prise en charge des structures de données les plus couramment utilisées dans la syntaxe des tâches pour lesquelles le langage est conçu.
la source
En général, je trouve pratique d'avoir des littéraux pour les listes, les ensembles, etc. Mais cela me dérange parfois de ne rien savoir de l'implémentation réelle de - disons - la liste Python ou le tableau Javascript. La seule chose dont je peux être sûr, c'est qu'ils exposent une interface donnée.
Je prends comme référence de l'expressivité d'un langage à quel point il peut écrire ses propres structures de données en tant que bibliothèques et à quel point il est pratique de les utiliser.
Par exemple, Scala propose différentes collections avec différentes garanties de mise en œuvre et de performances. Tous sont implémentés dans Scala lui-même, et la syntaxe pour les utiliser n'est que légèrement plus complexe que s'ils étaient intégrés et avaient un support d'exécution.
La seule structure de base qui a vraiment besoin d'être prise en charge par le runtime lui-même, au moins dans un langage géré, est le tableau: si vous ne gérez pas la mémoire, vous aurez du mal à obtenir un tas d'octets adjacents. Toute autre structure peut être construite à partir de tableaux et de pointeurs (ou références).
la source
APL (et les variantes modernes connexes, A +, J et K) ont des structures de données scalaires, vectorielles et matricielles de première classe.
Oui, ils peuvent être déconseillés en tant que simples variantes sur le tableau. Mais ils sont également exempts de déclarations complexes et ne proviennent pas d'une bibliothèque distincte, ils se sentent comme des structures de données complexes qui sont une partie de première classe du langage.
la source
Les littéraux de liste et de carte et une syntaxe de fermeture pratique sont des caractéristiques essentielles des langages de haut niveau.
La différence entre ce code Java:
et ce code Groovy:
est énorme. C'est la différence entre un programme de 40 000 lignes et un programme de 10 000 lignes. La syntaxe est importante.
la source
var t = new Thing(foo: 3, bar: 6.3, baz: true);
- seulement 4 caractères supplémentaires.Bien sûr, cela dépend de l'application du langage de programmation, mais pour les langages de niveau supérieur, il devrait être aussi pratique que possible de travailler avec n'importe quelle structure de données commune. Jetez un oeil à la liste des types de données abstraits dans Wikipedia pour des exemples. J'ai trouvé les principes de base suivants les plus courants (mais j'aimerais aussi entendre d'autres opinions):
Vous pouvez émuler n'importe quelle structure avec n'importe quelle autre structure - cela ne dépend que de la facilité et de la clarté du langage de programmation. Par exemple:
La plupart des langages fournissent au moins un type pour les séquences ordonnées, un pour les cartes à une dimension et un pour les cartes à plusieurs dimensions, limité aux fonctions. Personnellement, je manque souvent des ensembles et des structures multidimensionnelles ordonnées dans des langages comme Perl, PHP, JavaScript, Lua ... car les émuler n'est pas assez pratique.
la source
Je pense que c'est une mauvaise idée d'avoir trop de types de données privilégiés qui obtiennent une syntaxe spéciale. Cela complique inutilement la syntaxe du langage, ce qui rend le code plus difficile à lire, le rend plus difficile à apprendre pour les débutants et rend plus difficile le développement d'outils pour le langage.
Il est correct de faire une exception pour un petit nombre de types de structure de données très courants. J'autoriserais probablement au maximum:
Tout ce qui est plus sophistiqué que cela devrait probablement être laissé aux bibliothèques pour gérer, en utilisant la syntaxe normale du langage pour les types de données personnalisés.
En particulier, des choses comme les arbres rouges / noirs, les files d'attente prioritaires, etc. ont beaucoup d'options d'implémentation possibles, il n'est donc pas judicieux de faire une implémentation particulière dans le langage principal. Il vaut mieux laisser les gens choisir la mise en œuvre la plus appropriée à leur situation. Exemples de choix d'implémentation sur lesquels je ne souhaiterais pas qu'un concepteur de langage restreigne mon choix:
la source