Offene Fragen bei der Entwicklung einer kleinen Programmiersprache
-
Ethon schrieb:
volkard schrieb:
Bei 5.sqrt würde ich 2.23 hoffen. Wer den int haben will, kann ja 5.sqrt.int schreiben.
Macht Sinn, danke.
Dann beachte aber, daß es (gut, aber nur in der hand des compilerbauers) allen Deiner Verantwortung unterliegt,
5.sqrt.int
und
5.sqrt
was vollkommen verschiedenes machen zu lassen! Erstere Version ist evtl viel schneller.
Kann es möglich sein (besser, in der hand des bibliotheksschreibers!!!!!), daß der Anwender beschreiben kann, daß .sqrt.int vorrangich matcht vor .sqrt ?
Und wäre das überhaupt tragfähig für viele andere Optimierungen oder nur eine Eintagsfliege?
-
Basic mag ich da. 5/2==2.5 aber 5\2==2.
Diese Syntax ist irritierend.
Kaum zu unterscheiden, wobei Code flink lesbar und verständlich sein soll.
Einen Strich auf verschiedene Seiten zu kippen ist für einen Menschen nicht schnell genug unterscheidbar und kann und wird zu vielen Missverständnissen führen/geführt haben.Du hast, beiläufig gesprochen, Ethon falsch zitiert.
-
Sone schrieb:
Basic mag ich da. 5/2==2.5 aber 5\2==2.
Diese Syntax ist irritierend.
Kaum zu unterscheiden, wobei Code flink lesbar und verständlich sein soll.
Einen Strich auf verschiedene Seiten zu kippen ist für einen Menschen nicht schnell genug unterscheidbar und kann und wird zu vielen Missverständnissen führen/geführt haben.Nö, wenn mans ein wenig gewohnt ist, kein Problem.
Sone schrieb:
Du hast, beiläufig gesprochen, Ethon falsch zitiert.
Hab's nur auf die Nicht-Basic-Sache reduziert. Bin sicher, es war in seinem Sinne.
-
volkard schrieb:
Nö, wenn mans ein wenig gewohnt ist, kein Problem.
Nun, du wirst es wissen.
Sone schrieb:
Du hast, beiläufig gesprochen, Ethon falsch zitiert.
Hab's nur auf die Nicht-Basic-Sache reduziert. Bin sicher, es war in seinem Sinne.
Oh, ich hätte schwören können, du hast die Basic-Syntax zitiert... nun, ich bin blind.
Wie willst du aber auch die Basic-Syntax auf das Radizieren anwenden?
Bei 5.sqrt würde ich 2.23 hoffen. Wer den int haben will, kann ja 5.sqrt.int schreiben.
Das ist nicht so hübsch wie bei C++, wo man das alles auf das Typsystem reduzieren kann. Hat diese Skriptsprache eigentlich ein statisches Typsystem?
bibliotheksschreibers!!!!!
Was ist denn da so überaus wichtig, dass du es mit fünf Ausrufezeichen hervorhebst?????
-
volkard schrieb:
Ethon schrieb:
volkard schrieb:
Bei 5.sqrt würde ich 2.23 hoffen. Wer den int haben will, kann ja 5.sqrt.int schreiben.
Macht Sinn, danke.
Dann beachte aber, daß es (gut, aber nur in der hand des compilerbauers) allen Deiner Verantwortung unterliegt,
5.sqrt.int
und
5.sqrt
was vollkommen verschiedenes machen zu lassen! Erstere Version ist evtl viel schneller.
Kann es möglich sein (besser, in der hand des bibliotheksschreibers!!!!!), daß der Anwender beschreiben kann, daß .sqrt.int vorrangich matcht vor .sqrt ?
Und wäre das überhaupt tragfähig für viele andere Optimierungen oder nur eine Eintagsfliege?Naja, das sind ja Properties.
Integer(5).sqrt().int()
wäre es mit Funktionsaufrufen.
Da zu optimieren würde einiges an statischer Analyse verlangen auf die ich schlichtweg wenig lust habe.
Machen die wenigsten Scriptsprachen, also versuchen zu erraten was der Nutzer ausdrücken wollte und dementsprechend optimieren.
Durch die Dynamik ist das auch reichlich schwer.Da würde ich zb.
(5).trunc_sqrtbevorzugen.
(Die Zahl muss btw in Klammern da der Parser sonst ein Float-Literal matcht. Hat mich einiges an Verwunderung gekostet
)
-
Sone schrieb:
Wie willst du aber auch die Basic-Syntax auf das Radizieren anwenden?
Klappt nicht.
Kenne Smalltalk!Sone schrieb:
Bei 5.sqrt würde ich 2.23 hoffen. Wer den int haben will, kann ja 5.sqrt.int schreiben.
Das ist nicht so hübsch wie bei C++, wo man das alles auf das Typsystem reduzieren kann. Hat diese Skriptsprache eigentlich ein statisches Typsystem?
Letztendlich irrelevant.
bibliotheksschreibers!!!!!
Was ist denn da so überaus wichtig, dass du es mit fünf Ausrufezeichen hervorhebst?????
Um nicht in den PHP-Großnotstand zu fallen.
-
Sone schrieb:
Bei 5.sqrt würde ich 2.23 hoffen. Wer den int haben will, kann ja 5.sqrt.int schreiben.
Das ist nicht so hübsch wie bei C++, wo man das alles auf das Typsystem reduzieren kann. Hat diese Skriptsprache eigentlich ein statisches Typsystem
Nein, dynamisch typisiert, wenn auch mit strengeren Regeln als zb. PHP.
Es wird nicht allzuviel geraten, manchmal muss man eben explizit sagen was man meint. Damit mit dem Cast nach int ist aber eher ein Hack (da man das Implementierungsdetail ausnutzt dass bei Float -> Integer abgerundet wird), schöner wäre(5).sqrt.floorUm nicht in die PHP-Großnotstand zu fallen.
Was meinst du damit?
Den Krempel um die Basistypen herum möchte ich als builtins implementieren (allein schon damit Libraries nicht mit internen Repräsentationen der Grunddatentypen arbeiten müssen - wie hier eben GMP).
Den Rest komplett als Librarylösungen.
-
Ethon schrieb:
Um nicht in die PHP-Großnotstand zu fallen.
Was meinst du damit?
Da haben es Fremdbibliotheken gelinde gesagt schwer.
edit: Nicht im Sinne von Fremd, aus einer anderen Sprache, sondern fremd als nicht vom PHP-Vertreiber mitvertrieben.
-
Okay.
Das habe ich nicht vor. Im Moment spiele ich sogar mit dem Gedanken Grunddatentypen austauschbar zu machen.Zb. bei Python funktioniert ja auch soetwas:
> class Foo:
... pass
...> class Bar:
... pass
...> Foo = Bar
> Foo()
<__main__.Bar object at 0x7ffcd675d890>Wäre noch eine nette Idee wenn mein Compiler ein
5zu
int(5)umschreiben würde und
int = MyIntmöglich wäre?
-
(5).sqrt.floorDas eh. Wollte ich nennen, war mir aber hier nebensächlich.
Weil bisher, wo int=>int und double>=double wäre ja
5.sqrt==2
5..sqrt==2.23
Nöö,
(5).sqrt==2
(5.).sqrt==2.23
da würde ich zwingen, daß Zahlenliterale Klammern brauchen, bevor sie vollwerteige Zahlenobjekte sind.
Aber ist auch bös inkonsequent. Vielleicht nur Klammern verlangen, daß sie Methoden aufrufen können. Macht mir keinen Spaß. Was ist an Zahlenliteralen so besonders? "hallo".reverse muss ja auch gehen, ohne ("hallo").reverse zu schreiben. Locker bleiben, man gewöhnt sich dran. Der . vom Funktionsaufruf bindet einfach viel schwächer als der Dezimalpunkt.
Ranges wie von 1 bis 10 schreibt man als 1..10
Naja, da wirds wirr, 1...10 könnte 1..(.10) oder (1.)..10) sein. Würde mir kein early-match wünschen, sondern schlicht einen Fehler, wenn man 1...10 schreibt. 1. ..10 oder 1.. .10 aber nicht 1...10. (In C++ wäre das vielleicht sowas wie - ++i oder -+ +i aber nicht -++i).
-
Natürlich bindet das Dezimltrennzeichen stärker als der Element-Selektor, allein schon weil der Parser das so schon falsch vom Lexer gefüttert bekommt.
Problem ist aber bereits behoben. Kommt eine Zahl nach dem Punkt ist es ein Float, ansonsten ein Integer + ein Element-Selektor. Offensichtliche Lösung.